W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2002

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

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Tue, 29 Oct 2002 15:28:06 +0100
Message-ID: <3DBE9AF6.8050505@crf.canon.fr>
To: noah_mendelsohn@us.ibm.com
CC: XMLP Public <xml-dist-app@w3.org>

Good, I'm glad you like it. Your suggestions look fine to me (I 
already had to use "has no effect" instead of "MUST" on one 
occasion myself).

Jean-Jacques.

noah_mendelsohn@us.ibm.com wrote:
> 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
> ------------------------------------------------------------------
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
>   Proposal for issue 394: Some unprocessed headers should stay
> 
> *From:* Jean-Jacques Moreau (/moreau@crf.canon.fr/ 
> <mailto:moreau@crf.canon.fr?Subject=Re:%20Proposal%20for%20issue%20394:%20Some%20unprocessed%20headers%20should%20stay&In-Reply-To=%3C3DB95387.4070708@crf.canon.fr%3E&References=%3C3DB95387.4070708@crf.canon.fr%3E>)
> *Date:* Fri, Oct 25 2002
> 
> ·  *Next message:* Nilo Mitra (EUS): "proposal for issue 391 (how IDREF 
> URIs are dereferenced)" <0145.html>
> 
> · *Previous message:* David Orchard: "RE: proposal for issue 393 
> (concrete packaging spec)" <0143.html>
> 
> · *Next in thread:* Jean-Jacques Moreau: "Forwarding table" <0153.html>
> 
> · *Reply:* Jean-Jacques Moreau: "Forwarding table" <0153.html>
> 
> · *Messages sorted by:* [ date ] <index.html#144> [ thread ] 
> <thread.html#144> [ subject ] <subject.html#144> [ author ] 
> <author.html#144>
> 
> · *Other mail archives:* [this mailing list] <..\> [other W3C mailing 
> lists] <..\..\>
> 
> · *Mail actions:* [ respond to this message ] 
> <mailto:xml-dist-app@w3.org?Subject=Re:%20Proposal%20for%20issue%20394:%20Some%20unprocessed%20headers%20should%20stay&In-Reply-To=%3C3DB95387.4070708@crf.canon.fr%3E&References=%3C3DB95387.4070708@crf.canon.fr%3E> 
> [ mail a new topic ] <mailto:xml-dist-app@w3.org>
> 
> ------------------------------------------------------------------------
> 
>  
> 
> Message-ID: <3DB95387.4070708@crf.canon.fr>
> 
> Date: Fri, 25 Oct 2002 16:21:59 +0200
> 
> From: "Jean-Jacques Moreau" <moreau@crf.canon.fr <mailto:moreau@crf.canon.fr?Subject=Re:%20Proposal%20for%20issue%20394:%20Some%20unprocessed%20headers%20should%20stay&In-Reply-To=%3C3DB95387.4070708@crf.canon.fr%3E&References=%3C3DB95387.4070708@crf.canon.fr%3E>>
> 
> To: XMLP Public <xml-dist-app@w3.org <mailto:xml-dist-app@w3.org?Subject=Re:%20Proposal%20for%20issue%20394:%20Some%20unprocessed%20headers%20should%20stay&In-Reply-To=%3C3DB95387.4070708@crf.canon.fr%3E&References=%3C3DB95387.4070708@crf.canon.fr%3E>>
> 
> 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.
> 
> This might happen, for example if the intermediary does not
> 
> understand the header block and hence is unaware that it
> 
> requires forwarding. 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 MUST be ignored
> 
> 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 item MUST be ignoredhas 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).
> 
> ------------------------------------------------------------------------
> 
> · *Next message:* Nilo Mitra (EUS): "proposal for issue 391 (how IDREF 
> URIs are dereferenced)" <0145.html>
> 
> · *Previous message:* David Orchard: "RE: proposal for issue 393 
> (concrete packaging spec)" <0143.html>
> 
> · *Next in thread:* Jean-Jacques Moreau: "Forwarding table" <0153.html>
> 
> · *Reply:* Jean-Jacques Moreau: "Forwarding table" <0153.html>
> 
> · *Messages sorted by:* [ date ] <index.html#144> [ thread ] 
> <thread.html#144> [ subject ] <subject.html#144> [ author ] 
> <author.html#144>
> 
> · *Other mail archives:* [this mailing list] <..\> [other W3C mailing 
> lists] <..\..\>
> 
> · *Mail actions:* [ respond to this message ] 
> <mailto:xml-dist-app@w3.org?Subject=Re:%20Proposal%20for%20issue%20394:%20Some%20unprocessed%20headers%20should%20stay&In-Reply-To=%3C3DB95387.4070708@crf.canon.fr%3E&References=%3C3DB95387.4070708@crf.canon.fr%3E> 
> [ mail a new topic ] <mailto:xml-dist-app@w3.org>
> 
Received on Tuesday, 29 October 2002 09:27:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT