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 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.

* 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.

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 Monday, 30 September 2002 17:57:46 UTC