W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

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

From: Doug Davis <dug@us.ibm.com>
Date: Wed, 7 Nov 2001 13:31:17 -0500
To: Jacek Kopecky <jacek@systinet.com>
Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
Message-ID: <OF93D93260.CDB7CF77-ON85256AFD.006189EE@raleigh.ibm.com >
Obviously, I like the idea of making no-actor semantically
equal to what actor="any" would have meant - it makes a lot
more sense to me.  I need to think more about whether the
idea of having a "final" (pick your favorite word) actor
is a good idea - can't explain why, but for some reason it
feels strange to allow the client to specify which HOP in
the message path instead of which actor/role should process
a header.
<warning-ramblings>
Should a sender be allowed to say "only process
this header on the same Node that processes the Body" - this
is in essence what actor="final" will do.  Shouldn't we allow
someone to configure it so that all headers are processed
by intermediaries and the Body on the ultimate recipient
(how they share the data is up to them)? Remember, the semantic
meaning behind the Header(and actor?) will say how the header
changes the processing of the Body, so as long as those rules
are adhered to should we really care whether its on one Node
or two? And of course, this configuration should be transparent
to the sender - so by having a "final" actor we could be
breaking their configuration.  Aside from actor="next" (always
have to have one exception to any rule), it seems like headers
should be required to ask that they be processed by a Node
who is agreeing to take on a "role" rather than they just happen
to appear at the right place in the message path.
</warning-ramblings>
But I need to think more about it...

-Dug


Jacek Kopecky <jacek@systinet.com> on 11/07/2001 12:33:28 PM

To:   Doug Davis/Raleigh/IBM@IBMUS
cc:   "Williams, Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
Subject:  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 13:31:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT