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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


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


Marty

In the examples you give, are these PartyIds or are they the URL to which a
message is physically sent. I'm assuming the latter.

If so, then your suggestion works for the outbound message but I doesn't as
far as I can see work for *the return path* as the MSH returning the message
does not know which service sent the original message and therefore what it
should put on the end of the URL.

For example, if the outbound message was as follows ...

<MessageHeader>
  <From><PartyId>XYZinc</PartyId></From>
  <To><PartyId>ABCco</PartyId></To>
  <CPAId>ABC-XYZ-CPA</CPAId>
  <ConversationId>5678</ConversationId
  <Service>PriceCheck</Service>
  <Action>PriceCheckResponse</Action>
  <MessageData>
    <MessageId>56723</MessageId>
    <RefToMessageId>79465</RefToMessageId>
    ...
  </MessageData>
  ...
</MessageHeader>

... then the only way the MSH sending the response to this message can know
what to put at the end of the URL is from the CPAId and the agreement that
was set up previously. 

This means that you need separate CPAs for, in Use Case 1, the Buyer order
Management Service and the Price Query Service. I don't think this is right
as why should XYZ Co care which internal service made the request for a
Price Check.

... or am I missing something.

David

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, November 12, 2001 10:21 AM
To: Burdett, David
Cc: 'Miller, Robert (GXS)'; Burdett, David; 'ebXML Messaging (E-mail)'
Subject: RE: [ebxml-msg] RE: The Return Path Problem



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></Fro
m>

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
>





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


Powered by eList eXpress LLC