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

At the 18 July telcon, we discussed whether issue 107 [1] was resolved in
our current working draft.  I volunteered to look at the text and report to
the group at large.

Issue 107 asks five semi-independent questions: 
what is the definition of an application,
how does the actor attribute affect processing, e.g., processing of
mustUnderstand headers, generation of faults, and etc., 
can users create their own actor aliases,
what are the rules for applications that process headers with user-created
actor names,
and, can the end point be addressed with a user created alias. 

First, application is never explicitly defined in the SOAP specification.
One could construe that a SOAP application is implicitly defined in 1.4.1
under the SOAP definition as a mechanism that "[generates] and [accepts]
SOAP messages for the purpose of exchanging information along a SOAP message
path."  This definition implies that an application can be the originator of
a SOAP message, the receiver of a SOAP message, an intermediary handler of a
SOAP message, and, potentially may serve multiple of these roles.  This,
however, begs the question of how a SOAP application is different from a
SOAP node.  Potentially, it could imply that there exists some notion of a
'virtual' application that encompasses all of the nodes that participate in
the information exchange, e.g., the 'client' message sender and the 'server'
message receiver together embody a single 'application', although I don't
think that this was the intent.  

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".  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." 

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".  

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.

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."

Eric

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x107


Eric A. Jenkins
Engenia Software, Inc.
703.234.1416

Received on Monday, 23 July 2001 23:39:39 UTC