FW: Possible Baseline Feature List for MSH

[Rik Drummond <rvd2@worldnet.att.net>]

-----Original Message-----
From: Cameron Young [mailto:cn_young@attcanada.ca]
Sent: Saturday, February 17, 2001 10:52 PM
To: jdurand@savvion.com; ebxml-transport@lists.ebxml.org
Subject: Possible Baseline Feature List for MSH


The following is my thoughts as a newbie to the TRP group of a minimum
feature set suitable for a very lightweight transport layer
implementation.

The objective is to enable baseline communication.  This doesn't mean
other features can't be added, but they would be "nice to have" as
opposed to essential to even start.

*** NOTES***
1) These are my views only, and do not represent concensus of the TRP
group.
2) These are intended only to start a discussion ... they are not a
proposal.
3) This is based on the 0.93 version of the specification, that will
clearly go through changes based on the Vancouver meetings.

Requirements for lightweight / small business ebXML access
- Low cost
- Low functions (basic capabilities are all they need to enter the
market)
- Will simply call in errors to their software vendor.  Won't have IT
staff to analyze problems

Core Features for Lightweight MSH:

1) Use Transport binding of HTTP only
- This eliminates the need for support for ordered delivery in the TRP
layer.
- Use periodic polls (like checking for mail) to receive incoming ebXML
messages to avoid setting up a listening port

2) Single From / To addressing domain
- consistent address domain (eg DUNS number) among all partners

3) Simple manifest
- Just a pointer to the payload, no description or schema

4) Simple MessageData Element
- Message ID and Timestamp only
- Eliminate TimeToLive

5) Default QOS features only
- Best Effort delivery only (rely on HTTP 200 message confirmation of
delivery)
- No message order delivery in MS transport (rely on sync HTTP
serialization)
- No delivery receipts
- Use SyncReplyMode=true, where the HTTP successful reply indicates
successful submission of the payload to the destination.
(POC commented that this could be a problem for long-delay responses)

6) Basic diagnostic features
- Routing Header for diagnostics only
- Support for Ping/Pong
- Diagnostic support for Status Request/Resonse only

8) Basic Error messages only, single language

9) No Message Ack

10) Security - Profile 0 only
- Rely on lower layer security like SSL / TLS ...


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org