Re: Proposal for resolution of issue 176

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 16:50:40 UTC