- From: Jean-Jacques Moreau <moreau@crf.canon.fr>
- Date: Tue, 29 Oct 2002 15:28:06 +0100
- 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 UTC