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

Mark,

I think the main insight is that we need both mechanisms: some header
blocks CANNOT be forwarded if ignored and others can. It depends on the
semantics. As a result, which way the default behavior falls doesn't
really address the deeper problem. Given this, and that flipping the
default will make the overall impact bigger, I would advise against
doing this.

Regarding the  <hdr mustUnderstand='true'
role='http://www.w3.org/2002/06/soap-envelope/role/relay'> case, we
don't say that it will never get forwarded, merely that the forwarding
is defined by the header block.

Henrik

>-----Original Message-----
>From: jones@research.att.com [mailto:jones@research.att.com] 
>Sent: Thursday, October 10, 2002 06:22
>To: Nilo.Mitra@am1.ericsson.se; fallside@us.ibm.com; 
>gdaniels@macromedia.com; Henrik Frystyk Nielsen; 
>jones@research.att.com; marc.hadley@sun.com; Martin Gudgin; 
>moreau@crf.canon.fr; noah_mendelsohn@us.ibm.com
>Cc: www-archive@w3.org
>Subject: Re: Proposal for new last call issue: Some 
>unprocessed headers should stay
>
>
>Another alternative solution we had discussed was:
>
>  (a) retain non-mandatory headers if they are not processed 
>at a node, and
>
>  (b) if a header is processed then re-insertion is dictated 
>by the spec for the header.
>
>Essentially this make 'relay' the default behavior for 
>non-mandatory headers (mustUnderstand='false') that are not 
>processed.  This avoids defining another role 
>(http://www.w3.org/2002/06/soap-envelope/role/relay), and 
>makes sense semantically since a given role ('next' or 
>otherwise) can be assumed by multiple nodes, but some may not 
>have deployed software (for whatever reason) at any given 
>point in time.  Optional headers would simply be processed by 
>the first node actually equipped to do so which seems like the 
>right semantics anyway.
>
>Is there a reason why this isn't preferable to the role=relay 
>formulation?
>
>Also, the role=relay solution leaves us with a strange looking 
>edge case of <hdr mustUnderstand='true' 
>role='http://www.w3.org/2002/06/soap-envelope/role/relay'>,
>which will get processed by any node wanted to act as 'relay', 
>but in fact will never relay at all!
>
>--mark
>
>Mark A. Jones
>AT&T Labs
>Shannon Laboratory
>Room 2A-02
>180 Park Ave.
>Florham Park, NJ  07932-0971
>
>email: jones@research.att.com
>phone: (973) 360-8326
>  fax: (973) 236-6453
>
>
>	From: noah_mendelsohn@us.ibm.com
>	To: Marc Hadley <marc.hadley@sun.com>, henrikn@microsoft.com,
>	        mgudgin@microsoft.com, moreau@crf.canon.fr, 
>Nilo.Mitra@am1.ericsson.se,
>	        jones@research.att.com, fallside@us.ibm.com, 
>gdaniels@macromedia.com
>	Cc: www-archive@w3.org
>	Subject: Proposal for new last call issue:  Some  
>unprocessed headers should stay
>	Date: Wed, 9 Oct 2002 22:57:14 -0400
>
>	==============================================================
>	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:44:57 UTC