Re: Soap Message Canonicalization (SM-C14N)

Noah,

My comments below.

noah_mendelsohn@us.ibm.com wrote:

> Rich Salz writes:
> 
> 
>>>I agree with you, and would like to see SOAP make guarantees
>>>about how intermediaries must preserve the order.  Until or
>>>unless that is done, however, SM-C14N requires a unique sorting
>>>order; if you can think of a more streaming-friendly way to do
>>>it, I'm all ears.
>>>
> 
> I now see where the confusion is coming from.  In fact, there is
> work going on right now in the protocols WG to nail down the
> responsibilities of an intermediary in relaying a SOAP message.
> While nobody can say for sure until the WG commits, I strongly
> suspect that the rules will be much more restrictive than you
> seem to be assuming.  For example, I would expect (hope) that
> headers not processed by the intermediary would be preserved in
> order.
> 

> So: rather than defining an elaborate canonicalization with
> sorting, etc., and then waiting to see what the SOAP rec says,
> why not first wait for the SOAP rules to crystalize? 
> 

The C14N being proposed is intended to be a more rigorous description of 
said rules expressed in the form of a transformation for inclusion in 
the specification.

The current spec does require header blocks to be forwarded in the same 
order they were received: "Such relayed SOAP messages MUST contain all 
SOAP header blocks and the SOAP body from the original SOAP message, in 
the original order, except that SOAP header blocks targeted at the SOAP 
intermediary MUST be removed (such SOAP blocks are removed regardless of 
whether they were processed or ignored)." Unless we change this rule I 
am not convinced that we need sorting in the C14N algorithm.

> 
> OK, that makes sense, but my preferred model would be that SOAP
> intermediaries do very little to change the order or content of
> the message, therefore the canonicalization algorithm needed to
> establish equivalence between all possible forms of a relayed
> message becomes near trivial (e.g. strip whitespace and
> comments).
> 

There's more to it than that, the proposed rules allow intermediaries to 
remove mustUnderstand="true|1", role=".../ultimateReceiver" attributes 
for instance. This is why the C14N transform would be a useful addition 
to the spec.

Regards,

Marc.

-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Tuesday, 19 February 2002 04:55:18 UTC