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

RE: Proposal for resolution of issue 176

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Mon, 11 Feb 2002 17:49:59 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D0656A9B2@red-msg-07.redmond.corp.microsoft.com>
To: "Christopher Ferris" <chris.ferris@sun.com>, "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>
Cc: <xml-dist-app@w3.org>

Maybe I am misinterpreting your mail but the premise seems to be that it
should be possible to sign a complete SOAP message from top to bottom
and have that signature survive SOAP processing through the complete
message path. Unless we only envision SOAP receivers to be strict
tunnels then I strongly doubt that this will be a realistic scenario.
For example, it doesn't seem to match the very possibility that header
blocks may be inserted.

I think a more likely scenario is that one signs specific header blocks
and the body, say, but not the entire envelope. I agree that we have to
be clear on what SOAP nodes can rely on but I think the proposed text
does provide strict rules for what is allowed and hence also provides
guidelines for what is good to sign.

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>This point should be capable of being addressed by Infoset. 
>Character info items belong to (have as a property) a parent 
>element information item (at least as I understand it). Thus, 
>we could say that when removing an element information item or 
>inserting a new element info item, that the characeter info 
>items which are not parented by said element info item SHALL 
>NOT be disturbed or possibly SHALL be preserved. We would 
>probably need to also say that no character information items 
>may be added/removed to/from a the following parent element 
>information items:
>	Envelope
>	Header
>	Body
>by an intermediary.
>
>The issue of removed and reinserted SOAP header element info items
>(blocks) becomes more relevant because technically, it is not 
>the same element information item as was received. By that, we 
>absolve an intermediary from having to necessarily preserve 
>the whitespace, etc. as might have been included in the 
>removed element. We have also made it crystal clear that 
>because it is technically a new element information item that 
>has been inserted into the message/envelope that no claims can 
>be made that apply end-to-end with regards to these SOAP 
>header element info items (blocks) because the SOAP process 
>model states that they MUST be removed.
>
>That seems to me to be the safest approach.
Received on Monday, 11 February 2002 20:50:54 GMT

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