Re: SOAP intermediary - issue 70 (cont'd)

If the follow scenarios is a correct and acceptable forwarding scenario as:

SN(0) => SN(1) => . . . => SN(n-1) => SN(n)

SN(0): Initial SOAP Sender
SN(n): Ultimate SOAP Receiver
SN(1..[n-1]): SOAP Intermediary from 1 to n-1
     Ex, SI(k) is a receiver from the SI(j)'s point of view where, k = (j +
1) and 0 <= j < k
           SI(k) is a sender as well from the SI(m)'s point of view where, k
= (m - 1) and k < m <= n

Would it be more proper as well as acceptable if we change the definition of
"SOAP Intermediary" from

"SOAP Intermediary: A SOAP intermediary is both a SOAP receiver and a SOAP
sender, target-able from within a SOAP message. It processes a defined set
of blocks in a SOAP message along a SOAP message path. It acts in order to
forward the SOAP message towards the ultimate SOAP receiver."

to:

"SOAP Intermediary: A SOAP intermediary is both a SOAP receiver and a SOAP
sender, target-able from within a SOAP message excluding the ultimate SOAP
receiver. It processes a defined set of blocks in a SOAP message along a
SOAP message path. It acts in order to forward the SOAP message towards the
ultimate SOAP receiver."

by adding "excluding the (initial SOAP sender and the) ultimate SOAP
receiver."


Pae




>I certainly like this one.
>
>Can this please be added as an issue?
>
>Jean-Jacques.
>
>
>Glen Daniels wrote:
>
>> This seems like a job for the "any" actor to me.
>>
>> The thing is, we've got a
>> very well-defined processing model which clearly equates the empty actor
with
>> the ultimate destination of the message.  Although, as Noah points out,
>> processing of blocks targeted at a particular node may result in that
node
>> touching/modifying other blocks in the message, it seems to me that
allowing
>> intermediaries to actually process blocks that aren't targeted at them
would
>> lead to potentially confusing and fragile systems.  In particular, it may
be
>> important for a processor to be able to distinguish all blocks targeted
to the
>> ultimate destination for encryption or checksumming... if it can't tell
that a
>> block may "really" be processed by an intermediary that might be
dangerous...
>>
>> It's not as if there are a lot of systems that use intermediaries yet who
rely
>> on this kind of underspecified feature.  It seems to me to be entirely
>> reasonable to ask users who want this kind of functionality to tack on
the
>> "actor='any'" attribute to headers which might be processed anywhere
along the
>> path.
>>
>> --Glen
>>
>> ----- Original Message -----
>> From: "Doug Davis" <dug@us.ibm.com>
>> To: <Noah_Mendelsohn@lotus.com>
>> Cc: <jjmoreau@acm.org>; <mnot@akamai.com>; <w3c-xml-protocol-wg@w3.org>
>> Sent: Wednesday, October 10, 2001 5:18 PM
>> Subject: Re: Extra agenda item (short) for Oct 3 XMLP telcon -- issue 70
>>
>> > I believe this is a recent change and I also believe it is a
>> > bad change.  Take the example of a SOAP sender not having
>> > any notion of intermediaries, all it knows is the next
>> > (or the only) SOAP node to send its message to, and the
>> > message looks like:
>> >  <env>
>> >     <header>encryption data</header>
>> >     <body>...</body>
>> >  </env>
>> >
>> > If the text stays as is then we can NOT have an intermediary
>> > that does decryption (and removes the header) because the
>> > header is not explicitly targeted for it.  This, IMHO, is
>> > a big change from the 1.1 spec and I might have just forgotten
>> > but I don't remember the WG agreeing to this change.  Or, if
>> > we did I'd like to reopen the issue.  Also, doesn't this then
>> > preclude an intermediary from removing an encrypted header
>> > and replacing it with one that is not-encrypted, unless that
>> > header just happen to be targeted at it (and that would
>> > of course include doing it to the body as well).
>> >
>> > -Dug
>> >
>> >
>> > Noah_Mendelsohn@lotus.com@w3.org on 10/10/2001 04:10:49 PM
>> >
>> > Sent by:  w3c-xml-protocol-wg-request@w3.org
>> >
>> >
>> > To:   Doug Davis/Raleigh/IBM@IBMUS
>> > cc:   jjmoreau@acm.org, mnot@akamai.com, w3c-xml-protocol-wg@w3.org
>> > Subject:  Re: Extra agenda item (short) for Oct 3 XMLP telcon -- issue
70
>> >
>> >
>> >
>> > Doug Davis writes:
>> >
>> > >> Also, note that I removed 'targeted at the
>> > >> intermediary' since I an intermediary can
>> > >> process ANY block not just the ones targeted
>> > >> at it.
>> >
>> > With respect, I strongly disagree.  The specification makes very clear
>> > that headers are "targeted" at nodes that play specific roles [1],
gives a
>> > rigorous notion of "understanding" such headers  [2] which applies only
in
>> > the case that the header is so targeted, and very clearly indicates a
set
>> > of rules for processing such headers only in the case where they are so
>> > targeted [3].
>> >
>> > By contrast, the specification makes clear that while it is blocks
>> > targeted at a node are the ones to be processed, other blocks can be
>> > "referenced."  Also from [3]:
>> >
>> > "SOAP nodes can make reference to any information in the SOAP envelope
when
>> > processing a SOAP block. For example, a caching function can cache the
>> > entire SOAP message, if desired."
>> >
>> > In this case, none of the rules about "understanding" apply.  None of
the
>> > rules about order apply.  There is merely permission to use data in
from
>> > throughout the message as input to processing of the blocks that are
>> > targeted and understood.  For these reasons, I disagree that an
>> > intermediary can "process" ANY  block, not just the ones targeted to
it.
>> > Thank you.
>> >
>> > [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#N4002A2
>> > [2] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#muprocessing
>> > [3] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#procsoapmsgs
>> >
>>
> ------------------------------------------------------------------------
>> > Noah Mendelsohn                                    Voice:
1-617-693-4036
>> > Lotus Development Corp.                            Fax: 1-617-693-8676
>> > One Rogers Street
>> > Cambridge, MA 02142
>>
> ------------------------------------------------------------------------
>> >
>> >
>> >
>> >
>> >
>

Received on Monday, 15 October 2001 08:47:12 UTC