RE: Soap Message Canonicalization (SM-C14N)

>> What about saying something like the following... I think it is a
>> compromise proposal that should clarify what intermediaries are
>> allowed to do with respect to ordering:
>> 
>> * A SOAP intermediary must not change the order of header blocks
>> NOT targeted at it.

Yes.

>> * There are no ordering constraints for "re-inserted" header
>> blocks.  That is, if one uses "repeated header blocks" then an
>> intermediary is NOT required to re-insert them in the same order
>> as they were received nor necessarily in the same location in the
>> SOAP message.

Suggestion:  "SOAP requires that 'header blocks be processed in
a manner fully conformant with the specification for that block' [1].
Such specifications MUST indicate (a) the situations, if any in which
an intermediary is to 're-insert' a header block into a relayed
SOAP message and (b) any constraints on the position within the
relayed header at which the re-insertion is to occur." 
Editorial wordsmithing is required, but I think this is the
right approach.

>> * There are no restrictions on where a SOAP intermediary can
>> insert additional header blocks. That is, an intermediary can
>> insert blocks between any other blocks in a SOAP header.

Again, I think the proper positioning of a header block should be 
per the specification for that block.  As always, if multiple 
modules are used together, the specs must explain how to use
the modules together - in this case, how to position all of 
the required blocks.  I think this is true both at the original
sender of a message, and at an intermediary inserting new
headers.

>> Hope this makes sense!

Yes, absolutely.  Do my suggested changes also make sense?

>> Henrik

Thanks.

Noah

[1] http://www.w3.org/TR/soap12-part1/#procsoapmsgs

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Wednesday, 20 February 2002 15:11:55 UTC