- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Mon, 11 Feb 2002 19:02:36 -0500
- To: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>
- CC: henrikn@microsoft.com, xml-dist-app@w3.org
Noah, 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. My $0.02, Chris Noah Mendelsohn wrote: > I see your point. What do you propose when (a) removing and/or > reinserting either a header that it has processed or (b) making other > alterations to a header such as removing for encryption under the control > of yet another header? Do we legislate which whitespace and comments go > with which removed headers? I think we either need to lock down a fixed > rule, or make clear what lattitued is allowed. > > ------------------------------------------------------------------ > Noah Mendelsohn Voice: 1-617-693-4036 > IBM Corporation Fax: 1-617-693-8676 > One Rogers Street > Cambridge, MA 02142 > ------------------------------------------------------------------ > > > > > > > > Christopher Ferris <chris.ferris@sun.com> > 02/11/2002 05:44 PM > > > To: Noah Mendelsohn/Cambridge/IBM@Lotus > cc: henrikn@microsoft.com, xml-dist-app@w3.org > Subject: Re: Proposal for resolution of issue 176 > > > I guess my point is that if we leave the door open > even slightly, that whitespace et al between header blocks > is insignificant and MAY be omitted by an intermediary > that an implementation might then treat that as an invitation > to simply strip off all whitespace, etc. which would > potentially wreak havoc with the likes of dig sig. > > I guess what I'm getting at is that we cannot endow > different parts of the same message with different rules. > It'll only lead to problems in the long run. > > Cheers, > > Chris > > Noah Mendelsohn wrote: > > >>FWIW, my assumption was that what we used to call header and body blocks >>would be treated consistently: anything between those start and end >> > tags, > >>including whitespace, is significant. Comments and whitespace _between_ >>header blocks insignificant. I'm a little unsure on the body, given our >>new rules for interpretation: maybe evertying between <body> and >> > </body> > >>should be significant. Was that your point? If so, I agree. >> >>------------------------------------------------------------------ >>Noah Mendelsohn Voice: 1-617-693-4036 >>IBM Corporation Fax: 1-617-693-8676 >>One Rogers Street >>Cambridge, MA 02142 >>------------------------------------------------------------------ >> >> >> >> >> >> >> >>Christopher Ferris <chris.ferris@sun.com> >>02/11/2002 03:44 PM >> >> >> To: Noah Mendelsohn/Cambridge/IBM@Lotus >> cc: henrikn@microsoft.com, xml-dist-app@w3.org >> Subject: Re: Proposal for resolution of issue 176 >> >> >>I have a concern with regards to treating the header(s) >>differently than the body itself. Specifically, when used >>as a document/literal exchange, the Body may indeed have >>need to treat comments and/or whitespace as significant. >> >>Thus, while the header elements might be c14n'ed using >>the "without comments" algorithm[1], the content of the body may impose >>different requirements which might be inconflict. >> >>If we allow an intermediary to strip out whitespace that has been >>used in calculation of a digest of the message, then clearly that >>might invalidate the signature applied if the c14n method >>used was the "with comments" algorithm[2]. >> >>[1] http://www.w3.org/TR/2001/REC-xml-c14n-20010315 >>[2] http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments >> >>I think that we need to consider this issue very carefully >>before we allow for intermediaries to alter the infoset in potentially >>unacceptable ways. >> >>My $0.02 USD, >> >>Chris >> >> >>noah_mendelsohn@us.ibm.com wrote: >> >> >> >>>Overall, I like it. A couple of small questions/suggestions: >>> >>>* The changes to 4 and 4.2 seem a bit strong wrt/ comments and maybe >>>whitespace. Would it be reasonable to say that comments and/or >>> >>> >>whitespace >> >> >>>are insignificant if included. Senders MAY include them if useful as >>>documentation, but not for other processing. Receivers must accept. >>>Intermediaries MAY but NEED NOT relay? >>> >>>* The changes in 4 and 4.2 need to be worded carefully to make sure >>>they're not taken to preclude character info, comments (and I suppose >>>PI's) within header and body blocks. >>> >>>What do you think? Thanks. >>> >>>------------------------------------------------------------------ >>>Noah Mendelsohn Voice: 1-617-693-4036 >>>IBM Corporation Fax: 1-617-693-8676 >>>One Rogers Street >>>Cambridge, MA 02142 >>>------------------------------------------------------------------ >>> >>> >>> >>> >>> >>> >>> >>>"Henrik Frystyk Nielsen" <henrikn@microsoft.com> >>>Sent by: xml-dist-app-request@w3.org >>>02/11/2002 12:37 AM >>> >>> >>> To: <xml-dist-app@w3.org> >>> cc: >>> Subject: Proposal for resolution of issue 176 >>> >>> >>> >>>I took an action item to propose a resolution for issue 176 [1] >>>regarding what kind of information intermediaries must relay when it >>>comes to comments and similar xml information items. However, working on >>>this a bit more, it seems that at least portions of the issue applies >>>equally to any SOAP sender and SOAP receiver and not just >>>intermediaries. Note that this does mail does not address issue 137 [2] >>>which is being dealt with in parallel. >>> >>>Discussion >>>---------- >>> >>>While the SOAP 1.2 spec, part 1 is clear on what elements can be present >>>in a SOAP envelope and where, in particular with respect to immediate >>>child elements of the envelope and the header and body, it is less clear >>>about what to do with comments etc. As mentioned, this is not only a >>>problem for intermediaries but for any SOAP node receiving a SOAP >>>message. The intent of the proposal below is to clarify the rules for >>>such information. >>> >>>Proposal Outline >>>---------------- >>> >>>The proposal is to *disallow* any child information items other than the >>>ones that are explicitly allowed for both the document information item, >>>the Envelope element information item and the Header element information >>>item. This proposal says nothing about SOAP Header blocks and Body >>>element information items which are being discussed as part of issue 137 >>>[2]. >>> >>>In addition, this mail attempts to deal with the related question >>>brought up by 176 as to what values to use for SOAP defined attributes >>>like mustUnderstand and how they must be relayed. >>> >>>Specific Text Modifications >>>--------------------------- >>> >>>* In section 4 at the very beginning, add to first sentence: >>> >>>A SOAP message has an XML Infoset that consists of a document >>>information item with exactly one child, which is an element information >>>item as described below. A SOAP sender MUST NOT include any other child >>>information items including processing instruction information items, >>>comment information item, or a document type declaration information >>>item. With the exception of a document type declaration information item >>>(see the "DTDNotSupported" SOAP fault code in section 4.4), a SOAP >>>receiver MUST ignore such information items and a SOAP intermediary MAY >>>discard them if relaying a SOAP message. >>> >>>* Add the following paragraph to each of the descriptions of the SOAP >>>envelope (section 4) and SOAP header (section 4.2) element information >>>items: >>> >>>A SOAP sender MUST NOT include any other child information items >>>including element, processing instruction, unexpanded entity reference, >>>character, and comment information items. A SOAP receiver MUST ignore >>>such information items and a SOAP intermediary MAY discard them if >>>relaying a SOAP message. >>> >>>* In section 4.2.2, add the sentence at the end >>> >>>If relaying the message, a SOAP intermediary MAY omit the SOAP actor >>>attribute information item for SOAP header blocks targeted at the >>>ultimate SOAP receiver. >>> >>>* In section 4.2.3, add the two paragraphs at the end: >>> >>>When a mustUnderstand SOAP header block attribute information item is >>>present, a SOAP sender SHOULD use the canonical representation of the >>>attribute value (see schema ...). A SOAP receiver MUST accept any valid >>>lexical representation of the attribute value. If an invalid value is >>>encountered, a SOAP receiver MUST generate a "Sender" fault. >>> >>>If relaying the message, a SOAP intermediary MAY substitute a >>>non-canonical value with the canonical value and MAY omit the SOAP >>>mustUnderstand attribute information item if the value is "false" or >>>"0". >>> >>>Comments? >>> >>>Henrik Frystyk Nielsen >>>mailto:henrikn@microsoft.com >>> >>>[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x176 >>>[2] http://www.w3.org/2000/xp/Group/xmlp-issues#x137 >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > >
Received on Monday, 11 February 2002 19:03:19 UTC