- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 10 Oct 2001 10:55:34 +0100
- To: "'Doug Davis'" <dug@us.ibm.com>, Noah_Mendelsohn@lotus.com
- Cc: Henrik Frystyk Nielsen <henrikn@microsoft.com>, jacek@idoox.com, "Williams, Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app@w3.org
So I find myself asking in this scenario A -> B -> ANON -> C -> ANON -> D which node is the ultimate recipient aka. the default actor and the anonymous actor? It would seem pretty plain that D is the ultimate recipient of the message. However if we're willing to say the 3rd and 5th node along the path MAY act in the role of the anonymous actor, then I think we've established a contratiction. Either, the default actor, anonymous actor and ultimate recipient are synonymous with respect to a given message, or they are not. If they are synonymous, then we have this contradiction. If they are not synonymous, then at least two of them are distinct and we need to be very clear, as I think Doug is suggesting, that the default/anonymous actor and the ultimate recipient may be different... and we might what to say there is a semantic difference between a block explicitly targetted at '../default' and a block that carries on explicit actor attribute. Personnally, i don't think we want to go there... we'll come up with another way to denote the difference and the discussion will just recurse one level. Regards Stuart > -----Original Message----- > From: Doug Davis [mailto:dug@us.ibm.com] > Sent: 10 October 2001 04:20 > To: Noah_Mendelsohn@lotus.com > Cc: Henrik Frystyk Nielsen; jacek@idoox.com; skw@hplb.hpl.hp.com; > xml-dist-app@w3.org > Subject: RE: Issue 140 bogus? > > > I've never read any version of the spec to mean that > A -> B -> ANON -> C -> ANON -> D > is not possible because ANY node can process ANY block. > Yes certain headers (and the body) are targeted but > the processing model does not preclude a SOAP node > from processing blocks that are not targeted for it. > So while conceptually the above scenario might look > strange, in reality I believe it will happen. Take > the example you gave a note earlier this evening, > an encryption intermediary, if the sender has no > notion of what SOAP nodes the message is going > through, the SOAP envelope might look like: > <env> > <header>encryption data</header> > <body>...</body> > </env> > and if the message goes through a decryption > intermediary it will pick-off and process the > untargeted (or should I say anon-targeted) > header and process it. Thus giving us 2 SOAP > nodes that will in essence be the anon actor > (the intermediary and the ultimate destination). > > -Dug > > > Noah_Mendelsohn@lotus.com@w3.org on 10/09/2001 09:04:49 PM > > Sent by: xml-dist-app-request@w3.org > > > To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com> > cc: jacek@idoox.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org > Subject: RE: Issue 140 bogus? > > > > Henrik Frystyk Nielsen writes: > > >> I would prefer to be formal > >> about saying *what* it means > >> to act in the role of the anonymous actor, > >> rather than *how* that can be accomplished > > The question, I think, is what can you say about the message > path. Is it > possible that it extends beyond the node assuming the > anonymous role? Is > it possible that a path like this would emerge: > > A -> B -> ANON -> C -> ANON -> D > > SOAP 1.1 sure seems to rule that out. It says: > > "Omitting the SOAP actor attribute indicates that the recipient is the > ultimate destination of the SOAP message." > > I think that pretty formally boils down to "the message path > ends at the > node assuming the anonymous role. There can be no node > further along the > message path, and there can therefore be no more than one > node assuming > the anonymous role." I don't think that's unduly telling the > node how to > do its job. > > > -------------------------------------------------------------- > ---------- > Noah Mendelsohn Voice: > 1-617-693-4036 > Lotus Development Corp. Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > -------------------------------------------------------------- > ---------- > > > > >
Received on Wednesday, 10 October 2001 05:56:28 UTC