Title: 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.
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
- 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
>
