Re: Issue 107: Clarify the terms application, actor & related notions of identity.

Eric Jenkins wrote:
> 
> <snip/>
> 
> Second, the specification is somewhat unclear about the effect that the
> ACTOR attribute has on header processing.  In Section 4.2, the third
> encoding rule states that, "The SOAP actor attribute (see section 4.2.2) and
> SOAP mustUnderstand attribute (see section 4.2.3) MAY be used to indicate
> which SOAP module will process the SOAP header block, and how it will be
> processed (see section 4.2.1)."
> This could be read to imply that both attributes affect how the header will
> be processed. Assuming that this is not our intent, I recommend that we make
> two changes.  First, modify the above statement to include the word,
> "respectively".
>
+1

> Second, add the following sentence to the end of Section
> 4.2.2, "The processing rules regarding mustUnderstand and the generation of
> faults apply to all headers, whether the ACTOR is implicitly or explicitly
> defined, and whether or not the ACTOR value is user-created."
> 
I think section 2 already pretty much nails this point home. There is
currently some overlap between section 2 and section 4.2.2. In fixing
this, section 4.2.2 can probably be reduced to a short definition of the
actor attribute and it's allowable values which I think would address
the above point. 

> Third, Section 2.2 states that "it is also appropriate to use SOAP actor
> roles with names that are related more indirectly to message routing (e.g.
> "http://example.org/banking/anyAccountMgr") or which are unrelated to
> routing (e.g. a URI meant to identify "all cache management software";" The
> implication here is that anyone may create an alias for an actor.  However,
> it might be helpful if we were to add a statement, such as,  "There are no
> restrictions on the URIs that may be used as the value of an ACTOR
> attribute, other than those implied by the use of the special SOAP actor
> named "http://www.w3.org/2001/06/soap-envelope/actor/next".
> 
Again, I think this would fit in best in a rewritten 4.2.2 as described
above.

> Fourth, nowhere is it explicitly stated that applications should or should
> not process headers with user-created aliases differently. The
> recommendation from the Second issue above should cover this as well.
> 
The description of the processing model makes no distinction, isn't this
enough ?

> Fifth, while it is never explicitly stated that an end-point node may or may
> not be addressed with a user-created alias, the statement that "Each SOAP
> node . . . can additionally assume the roles of zero or more other SOAP
> actors," seems to imply that any node may be addressed with a user-created
> alias, and thus, by extension, can the end-point node. However, the
> statement, "Omitting the SOAP actor attribute indicates that the SOAP header
> block is targeted at the ultimate SOAP receiver," might be construed as
> suggesting that ONLY by ommiting the SOAP actor attribute can a header block
> be targeted at the end-point node.
> Therefore, I recommend that we add the following statement, " Any SOAP node,
> even the ultimate SOAP receiver, may be addressed by a user-created SOAP
> actor name."
>
I'm not convinced that we need the extra sentence, I think this is
covered by "Each SOAP node . . . can additionally assume the roles of
zero or more other SOAP actors".

Regards,
Marc.

--
Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740

Received on Tuesday, 24 July 2001 07:12:45 UTC