RE: Question on section 2.7.1, Part 1

Meta concern: if we're going to pursue this discussion,
I think we should take it to distApp.  So, let's decide
that first.  Anyone who has contributed object to
having their text copied to distApp if I decide to move
it?

Now, to ignore my own advice, a response:

Henrik writes:


>> Just to elaborate a bit on the explanation below: In
>> order for a SOAP node to know that it can act in a
>> certain role, it must understand the semantics of that
>> role. For example, for the roles named in the SOAP 1.2
>> spec, we define not only how they are identified but
>> also the semantics of acting in those roles: Acting in
>> the role of the ultimate receiver requires that you
>> process the body and don't act as an intermediary and
>> so on.

This is where I'm not sure I agree.  I had always
interpreted the ultimate receiver as a special case,
that we baked into the spec as special for that reason.
Your interpretation is coherent, but the spec certainly
declines to introduce any explicit notion of
'understanding' a role, something with which we take
great care for headers.


>> The same is the case for roles not defined in SOAP 1.2
>> although we don't say much about it in
>> general. However, we at least recognize this model in
>> step one of the processing model where we require a
>> SOAP Node to determine the set of roles in which the
>> node is to act.

Right, we don't say much, and determining a list of
roles you play is arguably not the same as
understanding a set of semantics that >> can change the
processing model for intermediaries as clearly
described in section 2.7.1.  So, I think your
interpretation is not just that knowing how to act in a
role implies knowing the semantics as conveyed in some
spec for that role, but that roles can in effect embody
features!  I see this is a fundamental structural 
change.<<

For that reason, I believe your proposal on a spec for
the relay role would have to be rewritten to imply that
any header addressed to that role would necessarily be
in some sense understood and processed (because we're
clear in 2.7.1 that it's processing that causes
reinsertion.)  There would have to be 
an implication that, whether or not you
recognized the QName in any distinct sense, that you
would infer that any such header had a processing
semantic of "reinsert me if you choose not to do any
other useful processing of me."  What's disturbing
about that is that I might (admittedly erroneously)
include a QName with a spec that says just the opposite
and address it to relay. Then what? So, I don't think we
have any precedent that roles implement features.
Lacking that, I think that your proposed formuation of
2.7.1 violates the spec, and would at best have to be
replaced with something like I've proposed here.

>> Any extensibility should obviously be designed with
>> care and the best extensibility mechanism should be
>> used for any particular extension. I am in no way
>> saying that the extensibility of roles should be used
>> instead of mU but for the specific semantics you point
>> out below, the notion of roles does seem to be a useful
>> fit, especially as "forwarding" is itself a feature not
>> defined in the SOAP 1.2 spec as described in section
>> 2.7.1.

I remain nervous about the whole state of affairs.  Take it to distApp?

Thanks.

Noah

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 4 October 2002 21:56:44 UTC