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: T2 - Intermediaries/Message Status Request


David -

I have no doubt that one could think up functions for an IM. The question is
whether, in ebXML messaging, we want to distinguish an end-point-MSH from an
IM-MSH, or simply treat them all as instances of a 'branded' MSH. All the
recent (and past) email traffic showing complex and varient what-if cases
tells me we need simplicity in the architecture, at least for the next round
of definition. Your suggestions below could well be value-add layers above
the IM-MSH, not defined in our spec...

jim



> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Sunday, August 12, 2001 10:12 AM
> To: HUGHES,JIM (HP-Cupertino,ex1); ebxml-msg@lists.oasis-open.org
> Subject: RE: T2 - Intermediaries/Message Status Request
> 
> 
> Jim, I can think of one BP/non-routing function an IM might 
> perform -- time
> stamping w/ signature (I'm not sure exactly how this is done 
> but I know there is
> a use case).  What other non-routing functions might an IM 
> perform?  Perhaps EDI
> validation, although that is done less now-a-days?  I expect 
> there to be lots of
> ebXML sends of EDI data for the first few years at least.
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: HUGHES,JIM (HP-Cupertino,ex1) [mailto:jim_hughes@hp.com]
> Sent: Saturday, August 11, 2001 11:59 AM
> To: ebxml-msg@lists.oasis-open.org
> Subject: RE: T2 - Intermediaries/Message Status Request
> 
> 
> It might also be helpful to be very clear about the 
> functionality presumed
> at intermediate nodes in this discussion. Obviously, the initial and
> terminating nodes on the path are proper (dare I say, 
> 'branded'?) MSHs and
> meet our spec. Are the other, intermediate nodes, also proper 
> MSHs, that
> could
> 
> 1) participate in some other BP as the initial/terminal MSH, and
> 
> 2) Conceptually, at least, operate a 'routing application' 
> that receives a
> message on one inbound port, figures out how to send it on 
> with a few mods
> to the headers, and sends the message on through an outbound port.
> 
> Or, are we assuming that these intermediate nodes are really 
> crippled MSHs,
> only able to do (2)? If so, are we specifying clearly this 
> functionality? Or
> should we treat this case as something that happens "at a 
> lower level" and
> keep it quite distinct from our simple FromPartyMSH <--> 
> ToPartyMSH model,
> much as we've separated BP Acks from MSH Acks?
> 
> jim
> 
> 
> 
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Thursday, August 09, 2001 3:20 PM
> > To: 'David Smiley'; 'Martin W Sachs'
> > Cc: ebxml-msg@lists.oasis-open.org
> > Subject: RE: T2 - Intermediaries/Message Status Request
> >
> >
> > David said ...
> >
> > >>>It seems to me that any party which handles my business
> > transactions,
> > intelligently, persistently or otherwise, is part of the business
> > process.<<<
> >
> > Yes and No. Suppose you are a small business and you use a PO
> > Box to receive
> > your mail. Is the post office part of your inernal business 
> processes,
> > definitely yes, it's how you work. But do they need to know
> > anything about
> > how do business with your customers, definitely no. The Post
> > Office is an
> > intermediary in the message path but not a relevant one to
> > the business
> > processes. Do your customers know you use an intermediary,
> > probably as they
> > can work it out from the address.
> >
> > >>>In the discussion of acks, delivery receipts, reliable
> > messaging and
> > floods, no mention is made of the use of Message Status Requests.<<<
> >
> > Definitely yes, see my other recent email. Greate minds 
> think alike ;)
> >
> > David
> >
> > -----Original Message-----
> > From: David Smiley [mailto:dsmiley@mercator.com]
> > Sent: Thursday, August 09, 2001 3:07 PM
> > To: 'Martin W Sachs'; Burdett, David
> > Cc: ebxml-msg@lists.oasis-open.org
> > Subject: T2 - Intermediaries/Message Status Request
> >
> >
> > Being relatively new to the ebXML world, but learning more
> > every day, I have
> > been hesitant to jump in where those even more experienced 
> may fear to
> > tread, but here I go...
> >
> > I have extracted a relevant paragraph from the large body of the "T2
> > SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI nfo" thread.
> >
> > <Martin W Sachs>
> > The problem about this use case is that the intermediary is 
> neither a
> > participant in the business process nor strictly a
> > pass through.  I suspect that means that it does participate in the
> > business process though "not much".
> > </Martin W Sachs>
> >
> > From a business perspective, please help me understand how
> > any intermediary
> > is not a participant in the business process? If they are 
> only a "pass
> > through", why are they used? If they are involved, but "not
> > much", is that
> > like being "a little pregnant" ;-)? It seems to me that any
> > party which
> > handles my business transactions, intelligently, persistently
> > or otherwise,
> > is part of the business process.
> >
> > In the discussion of acks, delivery receipts, reliable
> > messaging and floods,
> > no mention is made of the use of Message Status Requests. I
> > realize that
> > this capability is optional in the implementation of a 
> Message Service
> > Handler, but wouldn't it be useful in some of the scenarios
> > mentioned? In
> > lieu of always resending a message whose delivery status is
> > unknown, use of
> > Message Status Requests could reduce the number of large
> > messages that are
> > resent unnecessarily. This may result in a very high tide,
> > but floods may be
> > avoided :-O.
> >
> > TIA for helping me understand this more thoroughly.
> >
> > David Smiley
> > Director of Standards
> > Mercator
> >
> >
> >
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Thursday, August 09, 2001 4:47 PM
> > To: Burdett, David
> > Cc: ebxml-msg@lists.oasis-open.org
> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI nfo
> >
> >
> >
> > David,
> >
> > In other words, if the Delivery Receipt does not arrive, the
> > From party's
> > MSH does not attempt to re-send the original message and may
> > or may not
> > inform the from application.  To me that says that the
> > delivery receipt is
> > not part of reliable messaging. Failure to receive a delivery
> > receipt is
> > not a guarantee that the To party did not receive the
> > original message.
> > The From party is in as much doubt as to the status of the
> > transaction as
> > if reliable messaging had not been used.
> >
> > A phone call is not the answer here because it may not
> > produce a timely
> > resolution of the in-doubt status.  For example, the To 
> party may only
> > update its database overnight and thus customer service may
> > not be able to
> > help until the next day.  If you submit a stock trade for immediate
> > execution, you won't want to wait for the next day to decide
> > whether you
> > should resubmit the trade - and you will be nervous about
> > resubmitting it
> > right away because you don't want it executed twice. The purpose of
> > reliable messaging is to let the From party know
> > unambiguously, and in a
> > timely manner, that the message either did or did not get to
> > the To party.
> >
> > 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
> > 08/09/2001 04:24:24 PM
> >
> > To:   Martin W Sachs/Watson/IBM@IBMUS
> > cc:   ebxml-msg@lists.oasis-open.org
> > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI
> >                     nfo
> >
> >
> >
> > Marty said ...
> >
> > >>>Is the delivery receipt used by the From party's MSH in
> > the reliable
> > messaging algorithm?  If not, we still have the problem 
> that the From
> > party's MSH does not know whether the message got to the To 
> party.<<<
> >
> > Yes and no. The ebXML RM spec provides two methods by which
> > the From Party
> > MSH is notified of the status of the delivery of a message:
> > 1. A negative ack - this is the "Delivery Failure" error 
> message. This
> > occurs whenever DeliverySemantics is OnceAndOnlyOnce and one
> > of the MSHs in
> > the path (including the To Party MSH) cannot deliver the
> > message to the
> > final destination
> > 2. A positive ack - this is the Delivery Receipt which, if
> > its signed, is
> > proof that the message was delivered.
> >
> > These can be used separately or together.
> >
> > So yes the Delivery Receipt is part of Reliable Messaging but
> > there is no
> > MSH action proscribed if it does not arrive, although
> > probably it should
> > notify the sending application.
> >
> > Does this answer the question?
> >
> > David
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Thursday, August 09, 2001 12:43 PM
> > To: Burdett, David
> > Cc: ebxml-msg@lists.oasis-open.org
> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI nfo
> >
> >
> >
> > David,
> >
> > Comments in line.
> >
> > I assume that you intended to post to the list server, so I
> > posted this
> > response there.
> >
> > 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
> > 08/09/2001 01:04:56 PM
> >
> > To:   Martin W Sachs/Watson/IBM@IBMUS
> > cc:
> > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI
> >                nfo
> >
> >
> >
> > Marty
> >
> > See comments inline.
> >
> > David
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Thursday, August 09, 2001 9:38 AM
> > To: Burdett, David
> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI nfo
> >
> >
> >
> > David,
> >
> > I agree that if the intermediary undertakes to guarantee
> > forwarding of a
> > message once it reaches the intermediary's persistent store,
> > and guarantees
> > to return a delivery failure message, it might work. You do need to
> > substitute SHALL for SHOULD in that sentence, however.
> > [David B]I agree.
> >
> > The problem here is that when a delivery failure notification
> > originates in
> > an external node, rather than in the From party's MSH, the
> > delivery failure
> > notification is subject to the same losses that a normal
> > message is subject
> > to, so the delivery failure notification itself has to be
> > sent via reliable
> > messaging.
> > [David B]I agree.
> >
> > I suspect that when this is looked at carefully, there may be
> > opportuntities for things like delivery failure notifications
> > of delivery
> > failure notification messages, possibly multiple times around
> > this loop.
> > [David B]The spec says if a Delivery Failure message cannot
> > be delivered
> > reliably then the problem is solved by other means ... e.g.
> > the phone. See
> > last paragraph of section 10.4
> >
> > MWS:  That's probably OK but we really should work on improving teh
> > algorithm.
> >
> > There is also the question of the flood of ACKs from
> > different intermediate
> > points that David Fischer referred to.
> > [David B] I'm not sure where the flood is - apart from the flood of
> > emails;). But the Acks only goes to the previous hop and 
> the Delivery
> > Receipt (if any) goes end to end.
> >
> > MWS:  Yes, this eliminates the flood (I was referring to 
> one of David
> > Fischer's
> > postings).
> >
> > MWS:  Is the delivery receipt used by the From party's MSH in
> > the reliable
> > messaging algorithm?  If not, we still have the problem 
> that the From
> > party's MSH
> > does not know whether the message got to the To party.
> >
> > 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
> > 08/09/2001 12:06:36 PM
> >
> > To:   Martin W Sachs/Watson/IBM@IBMUS
> > cc:
> > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI
> >           nfo
> >
> >
> >
> > >>However, I as I said earlier today,
> > if the RM ACK is not end to end, there are
> > opportunities for failures that won't be detected at the MSH
> > level of the
> > From party and will leave the From party in doubt
> > as to whether the message got to its final destination.<<
> >
> > That's why you have the Delivery Failure error message which an
> > intermediary
> > (or even final) MSH should send back to the "From" MSH if they can't
> > forward
> > the message. Intermediaries are nothing special. If you are
> > doing point to
> > point and the To Party MSH can't deliver a message to the
> > Application then
> > the message delivery has failed.
> >
> > Best wishes.
> >
> > David
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Thursday, August 09, 2001 6:26 AM
> > To: Burdett, David
> > Subject: RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI nfo
> >
> >
> >
> > The problem about this use case is that the intermediary is 
> neither a
> > participant in the business process nor strictly a
> > pass through.  I suspect that means that it does participate in the
> > business process though "not much".
> >
> > We should support all these use cases.  However, I as I said
> > earlier today,
> > if the RM ACK is not end to end, there are
> > opportunities for failures that won't be detected at the MSH
> > level of the
> > From party and will leave the From party in doubt
> > as to whether the message got to its final destination.  SMTP
> > without RM
> > works just as well for these cases.
> >
> > 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
> > 08/08/2001 09:35:13 PM
> >
> > To:   "'SHIMAMURA Masayoshi (E-mail)'"
> > <shima.masa@jp.fujitsu.com>, Scott
> >       Hinkelman/Austin/IBM@IBMUS, Martin W Sachs/Watson/IBM@IBMUS,
> >       "Christopher Ferris (E-mail)"
> > <chris.ferris@east.sun.com>, "'David
> >       Fischer'" <david@drummondgroup.com>, "Jim Hughes (E-mail)"
> >       <jim_hughes@hp.com>
> > cc:   "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> > Subject:  RE: T2 SyncReply and ReliableMessagingMethod in
> > QualityOfServiceI
> >       nfo
> >
> >
> >
> > Masayosi/Scott/Marty/Chris/David F
> >
> > Phew! This is quite a thread which I have just caught up on. I also
> > apologise for the length of this reply but to try and come to
> > some type of
> > resolution I have:
> > 1. Presented a specific use case involving an intermediary
> > 2. Analyzed the use case to draw out some of the key issues 
> that arise
> > 3. Responded individual emails by extracting relevant items
> >
> > The bottom line is that, apart perhaps from some
> > clarifications, I don't
> > think the spec needs changing. Details below ...
> >
> > David
> > --------------------------------------------------------
> > USE CASE
> > This use case describes the characteristics of two parties 
> exchanging
> > messages via an intermediary. Specifically:
> > 1. There is one intermediary between the two parties.
> > 2. When the intermediary receives a message from a "From
> > Party" they do not
> > always forward it immediately to the "To Party"
> > 3. The intermediary has separately agreed with each of the other two
> > parties:
> >    a) the messaging protocols that will be used between the
> > intermediary
> > and
> > the party
> >    b) that the intermediay will transform messaging protocols
> > and payloads
> > if the From Party and To Party use different protocols.
> > 4. Specifically the agreements are:
> >    a) One party and the intermediary will use RosettaNet 
> documents as
> > payload with MQ Series without the ebXML Reliable Messaging 
> protocols
> >    b) The other party and the Intermediary use EDI Messages 
> with ebXML
> > messaging using SMTP and the ebXML Reliable Messaging Protocol
> > 5. The intermediary does not take part in the business
> > process between the
> > To and From Parties - i.e. the intermediary does not alter
> > the semantic
> > meaning of any of the data in the payload
> > 6. The Application that is the ultimate destination at one of
> > the parties
> > runs in batch and therefore their MSH needs to store messages
> > and deliver
> > them to the application later.
> >
> > USE CASE ANALYSIS
> > There is one intermediary
> > Although there is only one intermediary the same principles
> > will apply if
> > there are many.
> >
> > The intermediary stores messages before forwarding
> > This is a valid use case since it is possible that the final
> > destination of
> > a message is off-line (e.g. they are a SME who only uses
> > email) but they
> > want to be able to let their customers also use HTTP.
> >
> > What this means is that there is benefit in the intermediary
> > returning an
> > "acknowledgment message" as the From Party can then turn off
> > their retry
> > process without waiting for the message to reach the final
> > destination.
> >
> > The intermediary has separate agreements with each party
> > What this means is that there two types of agreements in place:
> > 1. Between the From or To Party and the Intermediary which 
> covers how
> > messages are sent but NOT the business process.
> > 2. Between the From and To Party directly that cover the
> > business process
> > they will follow but not how messages are sent.
> >
> > As each party uses diferent transport protocols for reliable
> > messaging, one
> > MQ Series and one the ebXML RM Protocol, you need to specify
> > separately for
> > each hop which RM protocol to use. This is why
> > reliableMessagingMethod is
> > in
> > the Via rather than the main message header.
> >
> > The application at the ultimate destination runs in batch
> > If the rule is that application always provides the Delivery
> > Receipt, then
> > the sender of the message might have to wait a long time to
> > get a response,
> > even though the message has actually been received by the MSH
> > running at
> > the
> > To Party. As the To Party is running both the MSH AND the
> > Application it is
> > OK for the MSH to send the Delivery Receipt. If the
> > Application is online
> > and can send a receipt immediately after say it has checked
> > the payload,
> > then the MSH level Delivery Receipt is not necessary.
> >
> > Now for some comments on individual emails ...
> >
> > EMAIL THREAD
> > The following are extracts from various emails on this topic
> > with responses
> > to each one.
> >
> > David Fischer: Tue 8/7/2001 1:02 PM
> > >>  We had long (heated) discussions about this in London and
> > David (B)
> > assured us that Acknowledgements were for intermediate hops only.
> > Acknowledgement (sp) only goes back to the previous hop.
> > This is why it is
> > only in the Via.<<
> > <DB>No. Acknowledgements are for Reliable Messaging using 
> the ebXML RM
> > only.
> > If a message is being sent over MQ Series then an
> > Acknowledgment message is
> > not needed (although it could be requested) as reliable delivery is
> > provided
> > in a different way. However whether you are using the ebXML
> > RM protocol or
> > a
> > proprietary protocol such as MQ Series, you still might want Non
> > Repudiation
> > of Receipt. This is why you need the Delivery Receipt
> > separate from the
> > Acknowledgement.</DB>
> >
> > Chris Ferris: Tue 8/7/2001 9:58 PM
> > >>The following references cite discussion that clearly
> > demonstrates that
> > the team had felt that the delivery receipt is an application-level
> > response
> > [1] [2] [3] [4] and that we endeavored to separate the two so
> > that it was
> > clear that DR was not related to RM. <<
> > ... and ...
> > >>Again, it clearly states "To Party" which equates to
> > "application" which
> > means that it is a business level signal. Nowhere in this
> > section will you
> > find any discussion of reliable messaging because it is completely
> > unrelated. A search of the Reliable Messaging section (10) 
> in the spec
> > turns
> > up a whopping 0 (zero) occurances of the word DeliveryReceipt.<<
> > <DB>I disagree. The Delivery Receipt is a MSH level response.
> > For example,
> > in the use case where the To Party MSH stores a message
> > before passing it
> > to
> > the application. Indeed, if the application receiving the
> > message is an old
> > application it may not be able to generate the equivalent of
> > a Delivery
> > Receipt. Hence a Delivery Receipt produced by the MSH is useful. In
> > addition, I don't think it is the MSH's responsibility to
> > generate messages
> > business application responses.</DB>
> >
> > David Fischer: Tue 8/7/2001 6:03 PM
> > (David B) I am also uncomfortable with having two parameters
> > that imply
> > essentially the same thing. For example if 
> deliveryReceiptRequested or
> > immediateAckRequested are both set to NONE, then a syncReplyMode of
> > AcksOnly
> > or AcksAndResponse would be inconsistent. We really ought be
> > able to avoid
> > this sort of problem with the correct choice of parameters.
> >
> > (David F) I still agree. David Burdett may prefer
> > AckRequested rather than
> > DeliveryRequested (David?).
> > <DB>In this quote, the two parameters I was refering to as
> > having similar
> > functionality were the syncReplyMode and either or both of the
> > deliveryReceiptRequested and intermediateAckRequested. The
> > deliveryReceiptRequested and the intermediateAckRequested
> > parameters have
> > different meanings (see above).</DB>
> >
> > SHIMAMURA Masayoshi: Wed 8/8/2001 5:44 AM
> > >>It means that if syncReply is set to False, the Reliable
> > Acknowledgement
> > Message can not carry business level response. If so, at same
> > time, the
> > Reliable Acknowledgement Message can not carry
> > deliveryReceipt element when
> > syncReply is set to False. Because deliveryReceipt element is always
> > carried
> > together business level response.<<
> > <DB>As the Delivery Receipt is a MSH level response, it can be sent
> > separately from the business level response.</DB>
> >
> > David Fischer: Wed 8/8/2001 8:56 AM
> > >>How about section 9.2.1 & 9.2.2 which describes MSH level
> > Ping & Pong?
> > Yet the spec says the response is sent:
> >      The message is then sent to the To Party.
> > The words "To Party" & "From Party" in these sections are
> > used to describe
> > the MSH, not an application.<<
> > <DB>The To Party is BOTH the MSH AND the Application. The MSH
> > is equivalent
> > to the mail room and the Application to the individual who opens and
> > processes a letter. They are both part of the same party.</DB>
> >
> > Jim Hughes: Tue 8/7/2001 10:00 AM
> > >>Maybe you get more "reliability" if an intermediate MSH
> > node pair use
> > MQseries, but I think it really confuses the issue when you 
> allow the
> > presence of intermediate nodes to affect the basic RM
> > algorithm. I think
> > that a node's use of RM should be quite distinct from the
> > (higher layer?)
> > RM
> > between the endpoint MSHs.<<
> > <DB>A node can usefully do its own RM processing especially
> > if it stores a
> > message before forwarding it as can easily be the case.
> > However hop by hop
> > RM does not mean that the sender knows that the final
> > destination received
> > the message which is why you need a Delivery Receipt to let
> > the original
> > sender know.</DB>
> >
> > Scott Hinkelman: Tue 8/7/2001 10:17 AM
> > >>I agree. RM is From <-> To. However, does this imply that
> > if a CPA is
> > used, and IMs are in the picture that multiparty (if an IM is
> > a party) CPA
> > is required? Seems to me.<<
> > <DB>Yes and no. In the exmple above, the intermediary is providing
> > transformation services but does not "process" the payload in any
> > conventional sense as they are not the final destination. For
> > example you
> > could organize it that all letters from French customers go to an
> > outsourced
> > translation service before they are sent to you. Is the
> > translation service
> > an integral part of the business relationship between you and
> > your French
> > customers. I don't think so. Do your French customers need to
> > know that you
> > have outsourced this part of your operation? Again, I don't
> > think so. On
> > the
> > other hand there is definitely a business relationship
> > between you and the
> > French translation service you are using which will need 
> agreements in
> > place.</DB>
> >
> > Scott Hinkelman: Wed 8/8/2001 7:22 AM
> > >>(Marty). It is not at all clear that a multiparty CPA is
> > always needed to
> > handle intermediaries.  It mostly depends on whether the 
> intermediary
> > particpates in the business process between the from and to
> > party or acts
> > as
> > a pass-through. At the moment, the BPSS handles  a multiparty
> > collaboration
> > as a set of
> > (Scott) You are hitting on exactly the issue I brought up in
> > [1]. I believe
> > we need to understand and clearify the functionality and
> > responsibility
> > differences between a Trading Partner and an IM in order to
> > to resolve much
> > of this.<<
> > <DB>Intermediaries CAN be pass throughs in that they do not
> > process the
> > payload. However intermediaries still have agreements with
> > the parties they
> > work with. For example as an email user, you have an
> > agreement with your
> > ISP. However the people you exchange emails with don't need to know
> > anything
> > about your agreement with them yet the agreement still exists.</DB>
> >
> > Marty Sachs: Wed 8/8/2001 11:06 AM
> > >>Certainly an adjacent pair of pass-through intermediaries
> > can forward
> > messages between themselves reliably "under the covers" but I
> > have no idea
> > why they would do so since they have no skin in the outcome.
> > The only ones
> > the outcome matters to are the From and To parties.<<
> > <DB>I disagree. They might have a lot of skin in the outcome.
> > For example
> > if
> > an intermediary stores and forwards a message as a service
> > then they will
> > want to make sure that they do not lose messages they have
> > received before
> > forwarding them.</DB>
> >
> > Let the discussion continue ... ;)
> >
> >
> > 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
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org


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


Powered by eList eXpress LLC