Re: Proposal for issue 394: Some unprocessed headers should stay

Overall, I like this.  A few specific suggestions below.  A version marked 
up with "diffs" is attached.


Message-ID: <3DB95387.4070708@crf.canon.fr>
Date: Fri, 25 Oct 2002 16:21:59 +0200
From: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
To: XMLP Public <xml-dist-app@w3.org>
Subject: Proposal for issue 394: Some unprocessed headers should stay
 
 
Dear all,
 
On Wenesday, the XMLP WG decided to further pursue the idea of an 
extra attribute ("relayIfNotProcessed", name TBD) to solve issue 
394. As per my action item, here is the corresponding text.
 
Some things to note:
 
* I have named the attribute simply "relay" (until
   we find something better).
 
* The type of the "relay" attribute is "xs:boolean".
   There might be benefits in changing it to "xs:anyURI"
   instead to allow future specifications to specify
   additional forwarding behaviour. I don't know if we
   want to do this at this stage, but I thought I should
   mention the possibility.
 
* I will make a separate proposal for how to include the
   role (Gudge/J-J's) table.
 
Jean-Jacques.
 
=============
 
New section 2.7.0 Relaying SOAP Header Blocks
---------------------------------------------
 
[Ednote: This text is new.]
 
The specification for a SOAP header block may call for the
header block to be forwarded to the next SOAP node if the
header block is targetted at a role played by the forwarding
SOAP intermediary, but not otherwise processed by the intermediary.
By default, SOAP does not require that
unprocessed header blocks targetted at a role assumed by a
SOAP intermediary be forwarded.
 
SOAP header blocks MAY carry "relay" attribute information
items (see 5.2.4 SOAP relay Attribute). When the value of
such an attribute information item is "true", the header
block is said to be relayable. The forwarding of relayable
header blocks is described in section 2.7.1 SOAP Forwarding
Intermediaries.
 
The "relay" attribute information item has no effect on SOAP
header blocks targetted at a role other than one assumed by
a SOAP intermediary.
 
{I changed the following because I think the implication
of the word "ignore" is unclear.  I am reluctant to lose
the normative MUST, but can't at the moment see a convenient
way to retain it.}
 
The "relay" attribute information item 
has no effect on the SOAP processing model when
the header block also carries a "mustUnderstand" attribute
information item with a value of "true".
 
The "relay" attribute information has no
effect on the processing of messages by
the SOAP ultimate receiver.
 
 
Amendment to section 2.7.1 SOAP Forwarding Intermediaries
---------------------------------------------------------
 
[Ednote: The text for this section is base on
Noah's earlier proposal.]
 
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:
 
* Remove all processed SOAP header blocks.
 
* Remove all non-relayable SOAP header blocks that were
   targeted at the forwarding node but ignored during
   processing.
 
* Retain all relayable SOAP header blocks that were targeted
   at the forwarding node but ignored during processing.
 
[Ednote: The following paragraph is left unchanged
and cited here for reference only.]
 
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.
 
[Ednote: The rest of the section is unchanged.]

 
New section 5.2.4 SOAP relay Attribute
--------------------------------------
 
[Ednote: This section largely mirrors section
"5.2.3 SOAP mustUnderstand Attribute". Some
factorization may be useful.]
 
The SOAP "relay" attribute information item is used to
indicate whether a SOAP header block targetted at a SOAP
receiver must be relayed if not processed (see section 2.7
Relaying SOAP Messages).
 
The "relay" attribute information item has the following
Infoset properties:
 
      * A [local name] of "relay".
 
      * A [namespace name] of
        "http://www.w3.org/2002/06/soap-envelope".
 
      * A [specified] property with a value of "true".
 
The type of the relay attribute information item is
xs:boolean.
 
Omitting this attribute information item is defined as
being semantically equivalent to including it with a value
of "false".
 
SOAP senders SHOULD NOT generate, but SOAP receivers MUST
accept the SOAP "relay" attribute information item with a
value of "false" or "0".
 
If generating a SOAP "relay" attribute information item, a
SOAP sender SHOULD use the canonical representation "true"
of the attribute value (see [XML Schema Part2]). A SOAP
receiver MUST accept any valid lexical representation of the
attribute value.
 
If relaying the message, a SOAP intermediary MAY
substitute "true" for the value "1", or "false" for "0".
 
A SOAP intermediary MAY omit the SOAP "relay" attribute
information item if its value is "false"
 
A SOAP sender generating a SOAP message SHOULD use the
"relay" attribute information item only on SOAP header
blocks. A SOAP receiver MUST ignore this attribute
information item if it appears on descendants of a SOAP
header block or on a SOAP body child element information
item (or its descendents). 




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