RE: Proposal for new last call issue: Some unprocessed headers should stay

I agree that the relay role has a more narrow scope but it also avoids
many of the edge cases that another attribute would create like the
following:

        <soap:Header>
                <hfn:myHeader role="..any role you like..." 
                                mustUnderstand="true"
                                relayIfNotProcessed="true">
                        ...
                </hfn:myHeader>
        </soap:Header>

and

        <soap:Header>
                <hfn:myHeader role="none" 
                                relayIfNotProcessed="false">
                        ...
                </hfn:myHeader>
        </soap:Header>

and

        <soap:Header>
                <hfn:myHeader role="ultimate receiver" 
                                relayIfNotProcessed="true">
                        ...
                </hfn:myHeader>
        </soap:Header>

Given that it is strictly speaking only a small subset of this
functionality we are after, I would at this time tend to lean towards a
more targeted (punt intended) approach.

I think it is a reasonable assumption that any header block which may be
processed and forwarded should define that functionality itself because
the exact result of the forwarding will likely be a result of the
processing of that header block.

...and avoiding going back to WD is definitely a goal!

Henrik

>-----Original Message-----
>From: Jean-Jacques Moreau [mailto:moreau@crf.canon.fr] 
>Sent: Thursday, October 10, 2002 00:36
>To: noah_mendelsohn@us.ibm.com
>Cc: Marc Hadley; Henrik Frystyk Nielsen; Martin Gudgin; 
>Nilo.Mitra@am1.ericsson.se; jones@research.att.com; 
>fallside@us.ibm.com; gdaniels@macromedia.com; www-archive@w3.org
>Subject: Re: Proposal for new last call issue: Some 
>unprocessed headers should stay
>
>
>Essentially, you're collapsing "relayIfNotProcessed" and 
>"role=next" into "role=relay" (with the combined semantics)? I'm 
>fine if this avoids us going back to WD (although I'd prefer the 
>more general option "relayIfNotProcessed" [actually relay="..." 
>with a variety of options]).
>
>Isn't there also the case of relaying even when processed? Yes, 
>currently this is supported by reinsertion, but is header 
>specific. Doesn't your description of a generic SOAP middleware 
>also call for doing this automatically at the SOAP middleware level?
>
>This brings another question: can an intermediary change a role 
>before forwarding? I.e. could I decide to change "role=relay" 
>into "role=next"?
>
>Anyway, this goes into the right direction, and I'm all for 
>forwarding to distApp (but no relay ;-))!
>
>Jean-Jacques.
>
>PS. I think we will also need to list "relay" into section "SOAP 
>Roles and SOAP Nodes".
>
>noah_mendelsohn@us.ibm.com wrote:
>> ==============================================================
>> I expect to be submitting the following to distApp within 
>the next day 
>> or
>> two as a proposed new issue.  I think the note is 
>self-explanatory, but I 
>> wanted to show it in advance to those of you who have been 
>involved in 
>> informal discussion of this issue, and also to one or two 
>more whom I 
>> thought might be interested.  Comments welcome (but I will 
>mostly be at 
>> DevCon the next few days, and then at Schema WG Monday and 
>Tues.  If you 
>> think this is good enough to start discussion on distApp, 
>let me know and 
>> I'll put it there asap.  We can decide what if anything to 
>actually do 
>> with the proposal once that's done.)  Thanks.
>> 
>> Noah ==============================================================
>> 
>> 
>> At the face-to-face on the West Coast at SAS, several us noticed and 
>> began
>> 
>> privately discussing what we now believe is a problem that needs at 
>> least
>> some attention in the specification.  Specifically, there is 
>a use case 
>> that more or less all of us have come to believe is 
>important, and for 
>> which the specification is at best ambiguous and at worst in 
>capable of 
>> meeting without republication.  Several of us have come up 
>with a proposed 
>> 
>> resolution that we believe to be straightforward, low risk, 
>and within
>> the bounds of what we can reasonably do without going back 
>to last call. I 
>> 
>> am indebted to Mark Jones for first pointing this out, and 
>to numerous
>> others including Henrik and Marc Hadley for helpful discussion and 
>> comment.  Particular thanks to Henrik for helping me to refine early
>> drafts of this note. 
>> 
>> The Problem
>> -----------
>> 
>> Among the reasons that we have the "next" role is for headers that 
>> carry
>> information to be available to all downstream nodes.  One of 
>the simplest 
>> scenarios would be to have such a header that would travel with the 
>> message, to be available to those nodes that "understand" 
>the header, and 
>> to be ignored and passed on by nodes that do not understand 
>it.  As a 
>> simple example, I might want to put in the header indicating 
>the time at 
>> which the message was originally sent. More substantively, I 
>might wish to 
>> 
>> put in a digital signature, to be checked by those who care, and 
>> ignored but retained by others.
>> 
>> SOAP 1.2 as proposed cannot support these simple scenarios. Why? 
>> Because
>> section 2.7.1 makes clear that a forwarding intermediary 
>MUST remove from 
>> the message all headers targeted to it, and can trigger 
>reinsertion only 
>> by processing and understanding a header.  In the case where 
>you don't 
>> understand the header, you must remove it.  It's essential 
>to note that we 
>> 
>> are considering the case of mustUnderstand='false';  there is no 
>> problem
>> with the 'true' case.
>> 
>> Approaches to Resolving the Problem
>> -----------------------------------
>> 
>> Discussion of this problem has been going on at a low level for 
>> awhile, in
>> 
>> part because some of us have been trying to decide whether the 
>> existing
>> specification can somehow be made to do the right thing.  
>Given that we 
>> are in last call, that would obviously be a desirable 
>approach.  So, here 
>> I briefly outline some of the approaches that were 
>considered, and then in 
>> 
>> the next section I propose one that seems to some of us to be the 
>> best.
>> 
>> It is tempting to ask whether a user might be able to design specific
>> headers and/or roles that would meet the need.  In other 
>words:  if I 
>> define a role and some headers to use with it, then I could 
>say that you 
>> wouldn't assume that role unless you knew the specification 
>for at least 
>> one of the headers, and that specification would implement a 
>feature to 
>> change the relay rules for that role.  My personal 
>conclusion is that this 
>> 
>> is possible in principle, but would not be practical when one 
>> considers
>> the way that most SOAP software will in fact be built.  
>Reason: the core 
>> rules regarding the relaying of headers are baked into 
>section 2.7.1, and 
>> in practice will often be implemented by general-purpose 
>SOAP middleware. 
>> The key point is that such middleware will in general be 
>written to treat 
>> all user-defined roles identically.  Allowing particular 
>roles to change 
>> the relay rules requires that such middleware have pluggable 
>handlers that 
>> 
>> key on specific role names, and this is something that few of us
>> anticipate doing.
>> 
>> There is another alternative which is also coherent, and indeed is 
>> more
>> powerful than the one proposed below, but which seems to be 
>overkill and 
>> would probably take us back to last call.  That alternative 
>would be to 
>> introduce a new attribute for use on header entries along 
>the lines of 
>> relayIfNotProcessed='true'.  Thus:
>> 
>>         <soap:Header>
>>                 <nrm:myHeader role="..any role you like..." 
>>                                 mustUnderstand="false"
>>                                 relayIfNotProcessed="true">
>>                         ...
>>                 </nrm:myHeader>
>>         </soap:Header>
>> 
>> This seems to work, and has the capability of working with 
>any role.  
>> It
>> just seems like more power and complexity than we need to 
>deal with the
>> specific use case.  If we were to get serious about this proposal, 
>> there would be several details requiring refinement, but for now 
>> I am just suggesting that this is not the direction to go.
>> 
>> A Proposal
>> ----------
>> 
>> Having done the above analysis, we conclude that:
>> 
>> * The use case is important that we must find a way to meet it
>> * The draft as written doesn't give explanation of how
>> * We need a simple, minimally invasive fix to what we have
>> 
>> We propose one new builtin role to be called: 
>> http://www.w3.org/2002/06/soap-envelope/role/relay . In most 
>respects, 
>> this role would be like any other. Any intermediary or ultimate 
>> receiver MAY choose to assume this role.  The one significant 
>> difference, and it is one that we believe has to be baked into the
>> specification from day one, is that section 2.7.1 will
>> be changed as follows:
>> 
>> <original>
>> Forwarding SOAP intermediaries MUST process the message according to 
>> the SOAP processing model defined in 2.6 Processing SOAP Messages. 
>> 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. 
>> 
>> In addition, forwarding SOAP intermediaries MUST also
>> obey the specification for the SOAP forwarding feature
>> being used. The specification for such a feature MUST describe the 
>> required semantics, including the rules describing how the forwarded 
>> message is constructed. Such rules MAY describe placement of
>> inserted or reinserted SOAP header blocks. Inserted
>> SOAP header blocks might be indistinguishable from one
>> or more of the header blocks removed above.
>> </original>
>> 
>> <proposed>
>> Forwarding SOAP intermediaries MUST process the message
>> according to the SOAP processing model defined in 
>> 2.6 Processing SOAP Messages. In addition, when 
>> generating a SOAP message for the purpose of forwarding, 
>> they MUST:
>> 
>> * For any processed SOAP header block, as well as for
>>   ignored SOAP header blocks targeted to the node
>>   using a role other than
>>   http://www.w3.org/2002/06/soap-envelope/role/relay:
>>   remove the header block prior to forwarding
>> 
>> * Retain all SOAP header blocks that were targeted at 
>>   the forwarding node using the role 
>>   "http://www.w3.org/2002/06/soap-envelope/role/relay"
>>   but ignored during processing.
>> 
>> 
>> In addition, forwarding SOAP intermediaries MUST also
>> obey the specification for the SOAP forwarding feature
>> being used. The specification for such a feature MUST describe the 
>> required semantics, including the rules describing how the forwarded 
>> message is constructed. Such rules MAY describe placement of
>> inserted or reinserted SOAP header blocks. Inserted
>> SOAP header blocks might be indistinguishable from one
>> or more of the header blocks removed above.
>> </proposed>
>> 
>> [1] 
>> 
>http://www.w3.org/2000/xp/Group/2/06/LC/soap>12-part1.html#forwardinter
>> 
>> ------------------------------------------------------------------
>> Noah Mendelsohn                              Voice: 1-617-693-4036
>> IBM Corporation                                Fax: 1-617-693-8676
>> One Rogers Street
>> Cambridge, MA 02142
>> ------------------------------------------------------------------
>> 
>> 
>> 
>
>
>

Received on Thursday, 10 October 2002 11:54:46 UTC