RE: Question on section 2.7.1, Part 1

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.

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.

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.

A possible definition of a "relay" role is as follows:

* * * * * 

Role identifier:

http://www.w3.org/2002/06/soap-envelope/role/relay

Role semantics:

If forwarding a SOAP message, a SOAP node acting in the role of "relay"
MUST insert in the forwarded message all header blocks targeted at the
"relay" role as follows:

A) If the header block is processed, the relayed header block is the
output of the processing specified by that header block.

B) If the header block is not processed, the header block is reinserted
in the relayed message.

Ultimate SOAP receivers MUST NOT act in this role.

* * * * * 

FWIW, if people find it useful, and it doesn't introduce a huge delay, I
would not be opposed to defining such a role, in the SOAP 1.2 spec,
presumably in section 2.7. However, given that we have extensibility,
and this does seem to fall in that category, I would equally not be
opposed to defining such a role in another spec.

Henrik 

>-----Original Message-----
>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
>Sent: Friday, October 04, 2002 15:16
>To: Nilo Mitra (EUS)
>Cc: Henrik Frystyk Nielsen; marc.hadley@sun.com; Martin 
>Gudgin; moreau@crf.canon.fr; Nilo.Mitra@am1.ericsson.se; 
>www-archive@w3.org
>Subject: Re: Question on section 2.7.1, Part 1
>
>
>Nilo Mitra asks:
>
>>> I wonder if the MAY in the last quoted part is valid for 
>the case of 
>>> a
>>> SOAP header block with a role attribute of "next". Surely for such 
>>> blocks, the header block MUST be reinserted, whether this block is 
>>> processed or ignored. In fact, shouldn't something be mandated 
>>> regards forwarding for header blocks with a role="next"?
>
>Actually, no.  In general, the rule is that whether to reinsert is 
>determined when you understand and choose to process the header. 
>
>Now, I actually do think there is an issue here.  It's one 
>that some of us 
>have been discussing privately, sort of deciding whether to 
>raise it as an 
>issue.  I've owed a few people including Mark Jones, David 
>Fallside, and 
>Henrik a decision on whether I want to pursue it.  Basically:  the 
>question arises, what happens if a non mU header addressed to 
>next is not 
>understood at some intermediary stop.  The draft rec is clear that it 
>disappears from the relayed message, for the reason you 
>question above. It 
>could not possibly be processed, since it's not understood;  
>it doesn't 
>have to be processed, because it's not mU;  it is definitely removed 
>(except on the off chance that processing of some other 
>feature causes it 
>to stay) because it's addressed to the node and not processed.
>
>The potential question is:  what if I want to create a header with the 
>following characteristics:
>
>        * it can be processed at any node.
>        * the default is that it not disappear (as you 
>essentially propose 
>above)
>
>I think it is nearly essential that this be possible.  There 
>are several 
>ways one might imagine getting it.  Some clearly would change 
>our rec. For 
>example, I've always found the "remove and reinsert" rule 
>unduly tricky 
>and would be just as happy to have a default that says "leave 
>it if you 
>don't process it."  Another change to the rec would be a controlling 
>attribute soapenv:removeIfNotProcessd, or some such.  I think I've 
>understood Henrik to say in private conversation:  "if you 
>make up your 
>own role name and send to that, you essentially have 
>permission to change 
>the processing rules on this for the role", essentially because if you 
>don't know what the role is, you don't play it, and the header will 
>survive.
>
>I'm sort of torn about whether I think Henrik's approach is 
>the right one. 
> Add to that a real reluctance to raise formally any issues unless 
>something is truly and provably broken, and I've been dragging 
>my feet. 
>about this. 
>
>So, this same analysis should probably go on distApp, but as I 
>say, I've 
>been holding off until I can figure out whether I should say "this is 
>broken and needs fixing" vs.  "we noticed this but we think it's OK." 
>Advice and help most welcome.
>
>Having said all of that, I think the status quo is clear, and 
>it's that 
>you remove the header if it's targeted to you (including next), and 
>reinserted only if some explicit processing has that result.
>------------------------------------------------------------------
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
>------------------------------------------------------------------
>
>
>
>
>
>
>
>"Nilo Mitra (EUS)" <Nilo.Mitra@am1.ericsson.se>
>10/04/02 03:47 PM
>
> 
>        To:     "'Martin Gudgin'" <mgudgin@microsoft.com>, 
>"Nilo Mitra (EUS)" 
><Nilo.Mitra@am1.ericsson.se>, Jean-Jacques Moreau 
><moreau@crf.canon.fr>, 
>Marc Hadley <marc.hadley@sun.com>, Noah Mendelson 
><noah_mendelsohn@us.ibm.com>, Henrik Frystyk Nielsen 
><henrikn@microsoft.com>
>        cc:     W3C Public Archive <www-archive@w3.org>
>        Subject:        Question on section 2.7.1, Part 1
>Categories: 
> 
>
>
>
>
>Dear Editors: 
>While attempting to put in some text on forwarding 
>intermediaries in the 
>Primer, I took a look at Section2.7.1, Part 1 [1],
>and have a question about some aspects of the text there: 
>Para 2 says: "....They MUST also remove from the SOAP message all SOAP 
>header blocks targeted at themselves, prior to forwarding, 
>regardless of 
>whether these header blocks were processed or ignored."
>Para 3 says: "....Such rules MAY describe placement of inserted or 
>reinserted SOAP header blocks. ...." 
>I wonder if the MAY in the last quoted part is valid for the case of a 
>SOAP header block with a role attribute of "next". Surely for 
>such blocks, 
>the header block MUST be reinserted, whether this block is 
>processed or 
>ignored. In fact, shouldn't something be mandated regards 
>forwarding for 
>header blocks with a role="next"?
>Please could someone clarify. 
>Thanks, 
>Nilo 
>[1] 
>http://www.w3.org/2000/xp/Group/2/06/LC/soap12->part1.html#forwardinter

>
>
>