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


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 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" <>
> Sent by:
> 02/11/2002 12:37 AM
>         To:     <>
>         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
> [1]
> [2]

Received on Monday, 11 February 2002 15:45:28 UTC