RE: TPA and ebXML Header question

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

>Before we go too far in considering what is in scope for MS and 
>what is out of scope (someone else's problem), I believe we got 
>into message sequencing because the RM potentially destroys the 
>sequencing that comes as part of the underlying transport (all 
>connection oriented transports I can think of give you sequencing 
>and we haven't seriously consider connectionless, e.g., UDP).  

I do not see that TRP RM in any way "destroys" the sequencing
of the underling transport. The TCP sequencing is, sorry,
about this-- at the network/transport layer, and RM pertains
to the whole ebXML protocol data unit, offered by the MSH layer,
that is well above IP and TCP. We don't even "see" TCP sequencing
at this level and certainly don't alter anything in that layer.
The sequencing is not sequencing of IP packets
(TCP does that, end of story)  but of the ebXML messages.
Mixing apples and kumquats here.



>If the MS layer has caused the problem, shouldn't we fix it?

You must explain here clearly which problem it is alleged to 
have caused. 

>(providing a service whose QoS is lower than that of the underlying 
>service on which it is built, doesn't seem too helpful -- though 
>there are precedents, e.g., OSI Session [however, OSI is a beer 
>driven discussion -- not for this list]).

I agree that OSI specifics are history, but what is it that they say
about people who ignore history? IETF mainly ignores the higher layers
because those layers were not "bits on the wire" layers. They were
layers involved in getting the bits off and back on the wires :-)
These middleware layers just 
might be relevant to business 
uses of messaging even
though they are not "strictly" network layers.