RE: [ebxml-msg] RE: The Return Path Problem

["Burdett, David" <david.burdett@commerceone.com>]

Title: RE: [ebxml-msg] RE: The Return Path Problem

Thanks Bob! Comments below.

 

David

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
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:david.burdett@commerceone.com]
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:Robert.Miller@gxs.ge.com]
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:david.burdett@commerceone.com]
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:david.burdett@commerceone.com; Web: http://www.commerceone.com
>