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/soap12-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 12:02:56 UTC