Last minute suggestions for MS Spec non-normative additions

[Cameron Young <cn_young@attcanada.ca>]

Hi,

I apologize in advance for raising these late in the cycle.  In the off
chance that there is immediate concensus (unlikely) I'll put them
forward.

I also want to make clear that nothing in here is a showstopper issue
for version 1.0.  I support the approach that it is much better to get
an acceptable solution done on time than a slightly better solution
late.

Background:

This is based on a detailed review of the spec during the Vancouver
meeting involving Jacques Durand and Mike Joya of the POC team and
myself from the TRP group.  As a newbie, I mostly listened.  The first
step was to define the scope of each of the header elements (MSH config,
per CPP, per conversation, per message). The assessment was largely
based on implementation experience.  The resulting .xls spreadsheet
(based on version 0.93) has been distributed on the POC mailing list.  I
don't want to confuse things by including the details here, but it is
available if anyone wants to look at it.

The next step was to assign a source of the element values (MSH setup,
CPP, higher-level application)  This is where it became clear that the
MS Specification did not stand on its own, but required the completion
of the CPP specification.  I haven't read it, but if the CPP spec also
includes dependencies on other specifications, the outcome will be a
large learning curve for developers.

Recommendations:

I should point out that these are my personal recommendations.  Maybe
POC implementers will like them ... maybe not.  I did not bounce these
off them at all.  (I imagine they would comment quickly if this was put
out on the POC list.)

1) In a non-normative appendix, define a "transportServiceProfile"
element that defines key configuration values for the transport layer
operation that are required input to control the behavior of the
receiving MSH.

This element can be resolved to either:
- within a future CPP document (the current vision, but with dependency
and flexibility issues)
- within a profile document sitting in a location such as
www.ebxml.org/namespaces/messageService/profiles  (developers will
*like* this I think because it can be locally cached)
- *within the header document itself* meaning that the transport layer
could be used without knowlege of the CPP. (allows operation without
CPP, and could be used during bootstrap phase if the default profile is
not appropriate)

This element should include the following, with the definition lifted
from the appropriate parts of the TRP spec.

transportServiceProfile Element
    deliverySemantics
    messageOrderSemantics
    deliveryReceiptRequested
    syncReplyMode
    reliableMessagingMethod
    intermediateAckRequested

(For the moment ignore the post-0.93 changes.  Just consider the
concept.)

<<< WARNING: Orthogonal issue which can be ignored but I'll mention
since this is maybe a solution ...

While the pointer to this element could replace the CPAId, I expect
those with a marketplace point of view (David, Doug) will want the link
to this element located in the RoutingHeaderList (aka TraceHeaderList).

This is less controversial than putting the CPAId in the
RoutingHeaderList, since it doesn't contain addressing or business
information.  It simply defines the expected behavior of the receiving
MSH.  Also note that while the CPP space may be virtually infinate,
there are a relatively small number of useful profiles for these
transport values.  If, however, they are buried within a CPP, it may not
be possible to access or cache them on intermediate nodes.
>>>

2) In a non-normative appendix, define a
"transportServiceLocalConfiguration" structure that defines key
configuration values that controls local MSH behavior.  This provides a
consistent format to define behaviors of a MSH.  This information does
not need to be known by the receiver since it is limited to controlling
local behavior.  (The sub-elements are referenced in various places in
the 0.93 document.)

transportServiceConfiguration Element
    timeout
    retries
    retryInterval
    mshTimeAccuracy
    reliableMessagingSupported
    persistDuration

If there are security concerns regarding item 1 above, a configuration
option could be added to this element that restricts the source of
transportServiceProfile to acceptTspFromCPP, acceptTspFromAnyURI,
acceptTspFromHeader.  Turning off the latter two configures the MSH to
CPP only operation.

Regards,
Cameron Young