- From: Pae Choi <paechoi@earthlink.net>
- Date: Mon, 15 Oct 2001 05:50:35 -0700
- To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "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>
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