The way I read Bob Miller's posting he is suggesting completely separating
routing through the network from the PartyIds. He is suggesting using the
endpoint URL to do the routing in the standard way. Thus a message might
go to
http://www.ABCco.com/CustomerService or
http://www.ABCco.com/Procurement/CustomerService
The domain name gets the message to the mail room and the rest of the
segments of the URL get it to its final destination behind the mail room.
The enterprise may design the routing however it wishes and express it in
the URL.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
"Burdett, David" <david.burdett@commerceone.com> on 11/12/2001 12:47:45 PM
To: "'Miller, Robert (GXS)'" <Robert.Miller@gxs.ge.com>, "Burdett,
David" <david.burdett@commerceone.com>, "'ebXML Messaging (E-mail)'"
<ebxml-msg@lists.oasis-open.org>
cc:
Subject: RE: [ebxml-msg] RE: The Return Path Problem
Bob
This effectively what I am suggesting except that I want to make it
explicit. The PartyId should identify the "business" or a division of the
business. In the real world we would would say,please reply to:
��� Customer Service
��� ABC Co
��� 123 Main St
��� Smallville, CA
In this instance the internal department is "Customer Service" and the
Party is "ABC Co".
Doing it your way we would say, please reply to:
��� Customer Service, ABC Co
��� 123 Main St
��� Smallville, CA
Where "Customer Service, ABC Co" is the Party and department combined.
Although we could do it the way you suggest and concatenate the two in the
spec, this is not the best way to do it if you are using XML where the
whole idea is to make the different elements of a data structure explicit.
It also causes problems for the recipient. For example, following your
suggestion your PartyId might look something like:
<From><PartyId>urn:duns:1234567:fromservice:CustService</PartyId></From>
The recipient now has a problem that they don't which part of the PartyId
identifies the business and which the service unless we specify the
standard in the spec. This means that they might not even be able to
recognize the sending Party. I think it would be much easier if we had:
<From><PartyId>urn:duns:1234567</PartyId><Service>CustService</Service></From>
In this case the PartyID represents the business and the "From Service" is
identified separately. So really I am agreeing with you except that I
think we should make the information explicit rather than buried in the
PartyId.
David