- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Mon, 15 Oct 2001 09:42:04 +0200
- To: Glen Daniels <gdaniels@macromedia.com>
- CC: Noah_Mendelsohn@lotus.com, Doug Davis <dug@us.ibm.com>, Jean-Jacques Moreau <moreau@crf.canon.fr>, mnot@akamai.com, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
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