RE: Issue 146 (default and anon actors, endpoints and ultimate re cipients - for danbri :-))

 Doug,
 I think your semantics were intended for the .../any actor URI.
IIRC we've decided against it, but I don't recall the reasons,
probably "against the rest of the actor semantics". 8-)
 I think the solution could be to redefine the default actor to
be as you want it (equivalent to .../any) and add a .../default
for the "final", "ultimate", whichever of the synonyms.
 The rationale: I think it's not assymetric if nothing (omitted
actor) has different meaning from something (actor specified). I
think that it is assymetric when nothing brings a default
something (default meaning of the omitted actor), and all
somethings have such and such semantics, with the one exception
(.../any).
 But this change might be pushed against by those who value
backwards compatibility between 1.2 and 1.1 more than I do. 8-)
 Best regards,


                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 6 Nov 2001, Doug Davis wrote:

 > Agreed - "processing" is different than "just peeking".  :-)
 > I also agree that the wording you quoted does seem to prevent
 > the scenario I'd like to see us support - so using the current
 > spec how does someone say "here's a header, and I don't care
 > who *processes* it just as long as someone does" ?  I'm beginning
 > to think that we don't allow this (as of now).
 >
 > In the 1.1 spec it says:
 >    The SOAP actor global attribute can be used to indicate
 >    the recipient of a header element.
 > Its the "can" part that interests me.  I read that to mean
 > that there may be other pieces of information that determine
 > who the recipient is.  So, in my head (scary place) I extended
 > that to  mean that any Node along the path may pick-off any header
 > and *process* it - as long as it adheres to the semantics defined
 > by the header.  And if this were true then my scenario would
 > be supported.  But we seem (based on ch2) to be headed away from
 > this.
 >
 > -Dug
 >
 >
 > "Williams, Stuart" <skw@hplb.hpl.hp.com> on 11/06/2001 10:14:45 AM
 >
 > To:   Doug Davis/Raleigh/IBM@IBMUS
 > cc:   xml-dist-app@w3.org
 > Subject:  RE: Issue 146 (default and anon actors, endpoints and ultimate re
 >       cipients - for danbri :-))
 >
 >
 >
 > Hi Dug,
 >
 > So now on the other tack of discussing the issue rather than framing it...
 >
 > The 'tricky' word in what you describe is 'processed'. I think that we've
 > long agreed that there is little we can do to prevent any SOAP Node along
 > the message path peeking inside any part of the message (other than
 > encrypting it out of sight). I don't think that just looking constitues
 > processing. According to the Section 2 rules processing a SOAP Message at a
 > SOAP Node involves the removal (and possible replacement) of header blocks
 > targetted at that node [1]
 >
 > Part 1 section 2.3 defines the targetting of SOAP headers and states
 > "...SOAP header blocks with no such attribute information item [actor] and
 > the SOAP body are implicitly targeted at the anonymous SOAP actor, implying
 > that they are to be *processed* by the *ultimate SOAP receiver*."
 >
 > I guess you would argue... yes, but it doesn't say that blocks targetted at
 > default/anon can't be 'processed' elsewhere. It seems to me that all the
 > indications in the spec. are that default/anon is intended to denote the
 > ultimate recipient. I think this make it pretty implicit that there is only
 > one default/anon actor per message (excepting multicast cases!) - which
 > SOAP
 > Node along a message path takes on the default/anon actor role may be
 > emergent, but I think it is always the last node on the message path for
 > that message.
 >
 > It may be that we want to separate the concepts of default actors,
 > anonymous
 > actors and ultimate recipients, but I think the terms have grown up as
 > synonyms and if they are distinct then we have not described the
 > differences.
 >
 > Regards
 >
 > Stuart
 > [1] http://www.w3.org/TR/soap12-part1/#procsoapmsgs
 > [2] http://www.w3.org/TR/soap12-part1/#N4002A2
 >
 > > -----Original Message-----
 > > From: Doug Davis [mailto:dug@us.ibm.com]
 > > Sent: 06 November 2001 13:03
 > > To: xml-dist-app@w3.org
 > > Subject: RE: Issue 146
 > >
 > >
 > > Stuart,
 > >  Yep, sorry, I misunderstood your note.  Related to the issue at hand,
 > > I'm wondering how people view the following example:
 > >   <env>
 > >     <headers>
 > >       <h1 MU="1"/>
 > >       <h2 MU="1"/>
 > >     </headers>
 > >     <body.../>
 > >   </env>
 > >
 > > h1 and h2 don't have actor attributes.
 > > As you said in your note, people are using the terms default actor,
 > > anonymous actor and ultimate recipient interchangeably, so can h1
 > > and h2 be processed by anyone other than the ultimate recipient?
 > > I always thought so.  I interpreted it this way:
 > >  - any node along the message path may process untargeted headers
 > >    as long as they fully understand the semantics of the header
 > >  - the ultimate recipient, however, MUST assume the role of
 > >    default/anonymous actor.  Meaning that it MUST process h1 and h2
 > >    if they are still in the message.
 > > The main reason I see behind allowing other nodes to assume the role
 > > of the anon actor is that a client knows nothing about the message
 > > path - all it really knows is the one/next node it is supposed to
 > > send it's message to.  So, there will be times when it does not know
 > > what Nodes the message will pass through and as such can't control
 > > which Node along the message path will process which part - so by
 > > leaving the "actor" off (IMO) it is saying "I don't care which exact
 > > Node processes this header, just as long as it does get processed
 > > (hence the MU="1")."
 > > So, while I agree that the ultimate recipient is also the default/anon
 > > actor - I do not agree that a Node that acts as a default/anon
 > > actor is also the ultimate recipient.
 > > Am I alone in this interpretation?
 > > -Dug
 > >
 >
 >

Received on Wednesday, 7 November 2001 12:33:31 UTC