Re: Proposal for resolution of issue 176

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 18:07:38 UTC