W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2003

RE: Intermediaries

From: Ricky Ho <riho@cisco.com>
Date: Fri, 05 Dec 2003 11:30:23 -0800
Message-Id: <>
To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, www-ws-arch@w3.org

1) I can't see how B or C can determine whether the modified message is the 
same message given that they haven't seen the original one.

2) SOAP doesn't have the "SAME MESSAGE" concept and therefore it is NOT 
possible to make such differentiation at the SOAP level.  In some other 
spec (such as RM), the "SAME MESSAGE" concept is very important, there they 
define the messageID explicitly.

About your encryption scenario, if determining the "SAME MESSAGE" is 
important to me, then I have to decrypt the messageID.  And if I cannot 
decrypt it, I shouldn't process the message.

Rgds, Ricky

At 12:45 PM 12/5/2003 -0600, Cutler, Roger (RogerCutler) wrote:
>I'm not an expert here, and I was mostly trying to capture the sense of
>a conversation.  However, I believe that several people agreed that it
>is, indeed, up to B and C to participate in this decision, and that the
>"application" envisaged includes both sender and receiver.  This was
>explicitly stated, I believe, by both David Booth and at least one other
>person, I've forgotten whom.
>About the messageID -- does a SOAP message necessarily have one?  If the
>intermediary encrypts the message, including the ID, do you have the
>same messageID?  It seems to me, from listening and participating in a
>certain amount of conversation trying to sharpen up the concept of "same
>message" that this is a swamp.
>-----Original Message-----
>From: Ricky Ho [mailto:riho@cisco.com]
>Sent: Friday, December 05, 2003 10:49 AM
>To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
>Subject: Re: Intermediaries
>Can we use messageID to determine whether this is the "SAME" message ?
>other words, all other modification is insignificant.
>1) Intermediary isn't the endpoint so it doesn't generate new messages,
>the message it send MUST have same messageID as some previous messages
>2) Orchestration is the endpoint which produce or consume messages, so
>message it send MUST have different messageID from previous received
>Going back to your example, it is NOT up the B and C to interprete the
>changes made by I differently.  The decision is completely finalized by
>Best regards,
>At 09:44 AM 12/5/2003 -0600, Cutler, Roger (RogerCutler) wrote:
> >Here is some text that expresses my understanding of the sense of some
> >of the telcon conversation about intermediaries.  Please use, modify or
> >ignor as seems appropriate.
> >
> >It is useful to draw a distinction between situations where messages
> >are passed through intermediaries and choreographies.  The essential
> >issue is that an intermediary passes along a message that is
> >essentially, or functionally, the same as it received.  If, on the
> >other hand, the purpose or function of the message is substantially
> >changed one should consider the situation to be a choreography.  This
> >cannot be defined, however, in an entirely rigorous or black and white
> >way -- one person's intermediary may legitimately be considered a
> >choreography by others. Note that since an intermediary can change the
> >message, for example by encrypting it or by adding ancillary
> >information, it remains a judgment call whether those changes are
> >significant and functional.  In addition, whether a service that passes
> >messages is considered an intermediary depends on participants in the
> >entire chain of the message.  For example, if sender A sends messages
> >through I, which modifies the messages, to receivers B and C, B might
> >consider the modified message to be functionally unchanged whereas C
> >might consider it to be different and take different action because of
> >the modification.  In the first case I would be considered an
> >intermediary, in the second it would not.
Received on Friday, 5 December 2003 14:34:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:09 UTC