Title: RE: [ebxml-msg] RE: The Return Path Problem
Thanks
Bob! Comments below.
David
-----Original Message-----
From: Miller, Robert (GXS)
[mailto:]
Sent: Monday, November 12, 2001
10:59 AM
To: Burdett, David; Miller, Robert (GXS); 'ebXML Messaging
(E-mail)'
Subject: RE: [ebxml-msg] RE: The Return Path
Problem
David,
Martin Sachs response shows how I would use a URL to
identify both the company and the internal company
'routing'.
In your example puporting to convey a 'DUNS' number,
their would not be a textual appendage to the DUNS number. The DUNS
number would identify botht he Company and the internal company
'routing'. My recollection is that the DUNS 'appendage is four digits
long (DUNS+4), where the last four digits identifies the internal
routing.
<db>OK, but 1.
We are not standardizing on DUNS, and 2. DUNS+4 is I think meant to identify
divisions of a company.
I could not find a
quote on the D&B web site but on "Defense & Logistics Agency"
press release, it says ...
"DUNS+4, a more
specific 13-character identifier than the original 9-digit DUNS, is currently
being used to identify subsidiaries and/or divisions at separate addresses
from the registered "main" or "parent"
company"
This is not the
same as identifying the Accounts Receivable, Accounts Payable, Customer
Service within a division of a
company.
</db>
Other companies might use some other means to
represent 'internal routing' (E.g., a telephone number (or extension
thereof).
I
guess I do not appreciate your concern that the recipient "might not
even be able to recognize the sending party."
- The end user application identifies
the sender from the appliction data (the payload) in some manner outside
the scope of TRP
<db>But the
application you send a message to might depend on who sent it. What you are
describing is "content based routing" wheras really this type of "routing" is
what the MSH is designed for.
</db>
- If the MSH has need to identify the
sender it may do so by looking up the 'PartyID' in a table of acceptable
'PartyID's. I don't know why the MSH would have this need, but the
solution to the need is certainly straightforward.
Cheers,
Bob
-----Original Message-----
From: Burdett, David
[mailto:]
Sent: Monday, November 12,
2001 11:48 AM
To: 'Miller, Robert (GXS)'; Burdett, David; 'ebXML
Messaging (E-mail)'
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
-----Original Message-----
From: Miller, Robert (GXS)
[mailto:]
Sent: Monday, November 12,
2001 6:24 AM
To: Burdett, David; 'ebXML Messaging
(E-mail)'
Subject: RE: [ebxml-msg] RE: The Return Path
Problem
Good People,
In the EDI world, we simply use multiple from party
addresses. For example, we might use a DUNS number, in which the
high order part of the number has been assigned to our compnay, and the
low order portion is internally assigned.
Seems to me that life gets even easier in the Internet
world. We're all familiar with the EMail 'mailroom'. It's the
name that follows the "@" symbol. The internal address is the part
that preceeds the "@" symbol. We're also familiar with subaddesses
in the WWW. The mailroom address preceeds the '/', and the
subaddresses follow the first '/'/
Why isn't the obvious solution being considered? I'm
confused.
Cheers,
Bob Miller
-----Original Message-----
From:
Burdett, David [mailto:]
Sent: Friday, November 09, 2001 7:31 PM
To: 'ebXML Messaging (E-mail)'
Subject:
[ebxml-msg] RE: The Return Path Problem
I forgot the attachment ... ;(
David
<<The Return
Path Problem.pdf>>
> -----Original Message-----
> From: Burdett,
David
> Sent: Friday, November 09, 2001
5:28 PM
> To: ebXML Messaging
(E-mail)
>
Subject: The Return Path Problem
>
> Folks
>
> Here's a PDF that describes three
use cases that illustrate the return
> path
problem that is on the agenda for next week's F2F. Two of the use
> cases are from the meeting at SAP in October which
we never got round to
> discussing the third is
new.
>
> I also
suggest some solutions. Note that these are suggestions and I am
> open to alternatives.
>
> If anyone has any comments before the meeting
then ... ;)
>
>
Regards
>
>
David
>
> Product
Manager, xCBL, XML Standards
> Solution
Strategy, Commerce One
> 4400 Rosewood Drive,
Pleasanton, CA 94588, USA
> Tel/VMail: +1 (925)
520 4422; Cell: +1 (925) 216 7704
> mailto:;
Web: http://www.commerceone.com
>
