RE: Proposal for various Infosetisms

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: 30 September 2002 22:55
> To: Martin Gudgin
> Cc: xml-dist-app@w3.org
> Subject: Re: Proposal for various Infosetisms
> 
> 
> I basically like this, and have a few small suggestions:
> 
> * Doesn't allowing an intermediary to remove a <HEADER> eii 
> potentially 
> break a signature over the envelope just as much as defaulting an mU 
> breaks a signature that includes the header entry?  I'm not 
> sure this is a 
> big deal, but wouldn't it be better to be consistent?  Why allow an 
> intermediary to remove an emty <HEADER>, particularly if the inbound 
> message had such an empty element.  If intermediaries can 
> track all those 
> attributes, then why not one empty element (signing that it's 
> empty could 
> be as significant as signing explicit headers, though I admit that in 
> practice I'd expect to see individual header entries signed, 
> or perhaps 
> groups of them.)

I don't expect people to sign the envelope. I think people will sign
individual headers, groups thereof or the body.

> 
> * I think you also need to reference the other rules on what 
> intermediaries do, or else include this text in a position where it's 
> clear that they apply.  In other words:  the rules on removing header 
> entries targeted to your role(s), etc.

No problem, I'll add a reference.

> 
> * Purely editorial:  I think we have to say "Forwarding 
> intermediaries MAY 
> remove an empty soap:Header element >information item< from 
> the [children] 
> property of soap:Envelope."  and so on for similar 
> constructions in the 
> other bullets.

Oh yeah, I wasn't trying to specify the actual text for the spec.

Gudge

> 
> Thanks.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
>         "Martin Gudgin" <mgudgin@microsoft.com>
>         Sent by: xml-dist-app-request@w3.org
>         09/25/2002 01:22 PM
>  
>                  To: <xml-dist-app@w3.org>
>                  cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
>                  Subject: Proposal for various Infosetisms
> 
> 
> 
> I took an action at the face-to-face in Palo Alto last month 
> to write a proposal for dealing with various aspects of the Infoset;
> 
> 1. comment information items
> 2. [prefix] property on element and attribute information items 
> 3. [namespace attributes] on element information items
> 
> generally in a SOAP message and with respect to processing at 
> intermediaries. This proposal also addresses issue 355[1] and 
> editorial issue 262[2]
> 
> Proposal:
> 
> The intent of this proposal is to provide an infoset based 
> description of the rules already defined in section 2.6 and 
> 2.7.1. It is not the intent to change those rules. That is, 
> the proposal is intended to provide a "section 5" version of 
> the "section 2" description. The proposal can be incorporated 
> somewhere in section 5 [4] as appropriate:
> 
> 1.   Forwarding intermediaries MUST preserve all the infoset
> properties of soap:Body if forwarding.
> 
> 2.   Forwarding intermediaries MUST preserve all the infoset
> properties of header blocks not targetted at them if forwarding.
> 
> 2a.   We will need to remove the sentence in 5.2.3[3] which says 
> 
>    'A SOAP intermediary MAY omit the SOAP mustUnderstand 
> attribute information item if its value is "false"'
> 
>    because that sentence is in conflict with 2. above. Given 
> the way xmldsig works, dropping such attributes would break 
> the signature, which we don't want to happen.
> 
> 3.    Forwarding intermediaries MAY change the value of the [children]
> property of soap:Envelope and/or soap:Header as follows:
> 
>    a) Forwarding intermediaries MAY remove an empty 
> soap:Header element from the [children] property of soap:Envelope.
> 
>    b) Forwarding intermediaries MAY add a soap:Header element 
> to the [children] property of soap:Envelope if it does not 
> already have one. 
> 
>    c) Forwarding intermediaries MAY remove whitespace 
> character information items ( those whose [character code] 
> property is #x20, #x9, #xD or #xA ) appearing in the 
> [children] property of soap:Envelope or soap:Header.
> 
>    d) Forwarding intermediaries MAY add ( or remove ) Comment 
> Information Items to ( from ) the [children] property of 
> soap:Envelope and/or soap:Header.
> 
> 4.   Forwarding intermediaries MAY add attributes to the [attributes]
> property of both soap:Envelope and soap:Header.
> 
> 5.   Forwarding intermediaries MUST preserve all other infoset
> properties of soap:Envelope and soap:Header.
> 
> I consider all the above to be clarifications of the way our 
> spec works today. Essentially we don't constrain the 
> structure or content of the body or header blocks ( other 
> than saying that PIs are not allowed, which is covered 
> elsewhere in the spec ). We allow intermediaries to drop 
> whitespace and/or comments appearing as children of 
> soap:Envelope and/or soap:Header. We allow intermediaries to 
> drop an empty soap:Header element or to add headers ( and 
> hence a soap:Header element ) to a message which doesn't have any.
> 
> As a secondary action, the editors need to go through Section 
> 5[4] and add some text either up-front or for each 
> information item stating which properties are NOT defined 
> and/or constrained by our spec. My preference would be to 
> just have some text at the top of Section 5 that says something like:
> 
> 'Where a given property of an information item is not defined 
> in this section, this specification places no contraints on its value'
> 
> Gudge
> 
> [1] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x355
> [2] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x262
> [3] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#soapmu
> [4] http://www.w3.org/2000/xp/Group/2/06/LC/soap12-part1.xml#soapenv
> [5] 
> http://www.w3.org/2000/xp/Group/2/06/LC/soap12>
-part1.xml#forwardinter
> 
> 
> 
>

Received on Tuesday, 1 October 2002 09:18:49 UTC