OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: ebXML TR&P comment: question on routing header


Just to make sure an answer to Phillipe's question gets to everyone:

Please, please read the Reliable Messaging Spec v-0.080, posted on 2 
October to the TRP email list. In section 2 of this document, you will find 
the changes proposed for Messaging Spec v-0.21c, including a definition of 
the Routing Header Document and changes to ReliableMessagingInfo. This RM 
spec will be discussed in the TRP meeting today.

Regarding "routing" (meaning, sending a message from the Sending MSH to the 
Receiving MSH through intermediate MSHs), TRP has not defined all the error 
and other elements necessary for routing in Phase 1 - this is Phase 2 work, 
in my understanding. Certainly, "routing" at a lower level (involving 
redirection in IP, for example, where the intermediate node is not a proper 
MSH) is possible as an implementation-defined activity, and even the use of 
multiple Routing Headers might be done with a proper intermediate MSH, but 
these semantics are undefined in the MS as of this point because of open 
design questions.

Jim Hughes
Fujitsu

At 06:40 PM 10/11/2000 -0700, Philippe DeSmedt wrote:
>[Rik, Chris, Dave, Jim:
>
>I've been trying to send this to the mailing list, but it failed. If one of
>you could post it for me, that'd be great. Thanks. ]
>
>All,
>
>I've been looking at the latest spec of the ebXML TR&P messaging service,
>and, unless I'm not looking at the very latest version, there may be
>something missing that we agreed upon at the Dallas face-to-face.
>
>We discussed creating a separate header to allow routing through
>intermediaries (hubs). This message delivery header would have the following
>elements: from, to, and a message ID. The reason to have them separate is
>to, in the future, allow the encryption of the header if desired, but having
>the minimal set of elements available to accommodate routing through
>intermediaries. We decided to modify the spec accordingly, but this does not
>appear to have been done.
>
>-Philippe
>
>_______________________________
>Philippe De Smedt
>Architect
>Viquity Corporation (www.viquity.com)
>1161 N. Fair Oaks Avenue
>Sunnyvale, CA 94089-2102
>(408) 548-9722
>(408) 747-5586 (fax)
>pdesmedt@viquity.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC