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

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 03:42:44 UTC