Re: Possible Baseline Feature List for MSH

[jacques durand <jacques@savvion.com>]

Cameron:

Thanks for starting this. I think it is important to establish a list of
default basic settings more disctinctly, so that interoperability will be
guaranteed up-front,
prior to any CPA negotiation. I think the POC group has to
iterate on your list, so I forward it.

Yet I am uneasy with the idea that this list looks like a cut-back on some
specs features.
Actually,  its first merit is to define a "default TRP-level CPA". I assume
the features not required by
this default, should not be automatically  left out of a base MSH
implementation...
For example, even if the default for delivery semantics is "Best Effort",
a compliant MSH implementation should be able to support the
"Once-and-Only-Once"
semantics with standard ebXML method. Same for other features.

Normally, a compliant implementation should cover all the specs options,
unless we consider two (or more) levels of compliance: e.g.  "basic" (just
the default CPA settings)
and "full" (all options). In which case, TRP should at least support some
means to
recognize (dynamically) what is the level of compliance of an MSH.
I leave this open for consideration to  TRP and POC, but it is an
important one from a practical viewpoint...

Below, I am going to summarize some of the points of TRP-POC Vancouver
meetings (or at least those I remember best...) that I feel need follow-up
(both TR&P and POC),
especially from an implementation perspective:

--------------------------------------------------

1. One of the outcome of our meetings last week was that the specs needed
to
be more explicit about where each field of the  message header  comes  from

(CPA? application? MSH? previous messages?), if only to avoid any ambiguity

from an implementation point of view. That is where your "header summary
spreadheet"  helps.
We need to complete it, and as Chris said, that could be useful
non-normative material.

2. Also it was apparent that some CPA-originating info was not actually
required
to appear in message headers at all, because it belongs more to
MSH-configuration data
(another gray area for implementors). That would reduce some kind of
"header inflation".
For example, if reliable messaging is required
by a CPA for a connection, we do not need to repeat the DeliverySemantics
in the
header of each message: it is reasonable to assume all business messages on
this connection will
automatically use it. And "CPA-Overriding" header attributes only seem to
add complexity in that case.
(Now, depending on the CPA option, additional header data may need be
passed
at run-time for each message, e.g. digital sig, sequence data, etc, that is
OK.)

3. We can assume that a CPA negotiation, prior to any business exchange,
will
result in the synchronization of sender and receiver MSHs for a particular
connection (From/To).
The way to achieve this synchronization should also be considered by TRP,
as it impacts
MSH. So far, I heard of two "partner discovery use cases" from previous
documents:

(UC1) Discovery by prior agreement - here, both  partners  (or parties)
negotiate the agreement
independently from any Reg Rep, and set up their communication accordingly.

At MSH level, that could mean some "communication profile" (CP) interface,
for setting up
the communication.

(UC2) Discovery through a registry. Here, the requesting partner (say a
Buyer) will query
the Registry to get a Supplier partner profile. Then it will make up a
proposed CPA from
both CPPs + roles, and sends that to the other partner. At receiver MSH
level, that could mean
being able to automatically extract the communication layer of this CPA
message.

So, in both scenarios UC1, UC2, the MSH must support in some way  the
setting of communication
profiles. Note that direct access to registry from MSH was not mentioned
here... in fact, there
is some reluctance from POC on this point, as this introduces dependency
with registry and CPA
format. Note also UC1 does not assume registry, and receiver in UC2 may not
want to access it.
And in turn, that makes the presence of a CPAid questionable in the MSH
state, not to
mention the message Header...

So these are 3 points that I feel  still need clarification, bordering to
implementation but
certainly also relevant to spec. Other POC comments?

Regards,

Jacques Durand
Savvion

Cameron Young wrote:

> 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 ...