Re: Soap Message Canonicalization (SM-C14N)

I'm not an official part of this group -- just following the mailing 
list with an interest in the future of web services.  I'll interject a 
point here that I hope is of value.

I find this line of thought somewhat troubling.  It seems that allowing 
one header/intermediary to exert this type of control over all others 
(especially in the "header" area which is specifically included to allow 
components in the periphery (and thereby not necessarily known to either 
the service itself or to one another)) is going to encourage problems of 
interoperability, compatibility, etc. -- something that I would hope a 
standard would attempt to avoid.

I think that the best approach is to state that "header order is not 
relevant" and avoid the problem entirely.  However, I can see that there 
may be times when layering may be important, so this could be relaxed in 
such a way that a particular feature might specify that it interacts 
with other headers {given list} or that it interacts with other headers 
{given list} that are encountered {before , after} it in the list.  So 
relative position might be permitted to be meaningful, but absolute is not.

The caveat to this would seem to be the case where a header specifies 
the order of processing (as outlined in section 2.6 of the 1.2 spec). 
 In that case, the order (obviously) is significant, and insertions 
should be placed accordingly (that is, one might insert something at the 
beginning to have it be processed "next").

That said, might it be worthwhile to consider a similar extension for 
changes to the header.  That is, just as the spec alludes to the ability 
to define a header which specifies processing order, why not define a 
similar header which specifies where additions are allowed.  (This, of 
course, attempts to sidestep the question of what to do if someone 
removes that header...But that's probably "not fair")

Bottom line:  My vote (if I had one) would be that the spec disallow 
these troublesome cases, and expect the software (SOAP Nodes) to operate 
under clearcut rules that order is not significant, or, if it is, that 
only relative order is important.  This seems important, especially 
since a common use of headers is likely to be for various levels of 
containers to add instructions to messages on the way in & out. 
 Allowing these to operate with well-understood rules (both of structure 
and non-interference) is critical to developing the intereoperability 
needed to make web services a viable platform.

On 2/20/2002 3:01 PM, noah_mendelsohn@us.ibm.com wrote:

>Well, there's a general principle I've been suggesting we apply to the 
>simultaneous use of multiple features or modules:  when the SOAP 
>specification says that a module or feature specification MUST .... 
>(provide some rules for doing something), SOAP itself will not say 
>anything about how to combine such features.  Instead, we say that when 
>multiple features are to be used together the specifications for such 
>features MUST provide information sufficient to enable their correct use 
>together.   For example, a specification for feature F1 might say 
>something along the lines of:
>
>"The header required by this feature may be be placed anywhere in the SOAP 
>message."
>
>F2 might say:
>
>"The header required by this feature must be the first child element of 
><header>.  This feature MUST NOT be used in the same envelope with any 
>other feature that would require other blocks in this initial position.
>
>Some module specs will explicitly refer to others, some will rely on 
>general rules such as those above.    I think this approach neatly covers 
>the re-insertion rules, as well as others.
>
>------------------------------------------------------------------
>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>
>02/20/2002 05:50 PM
>
> 
>        To:     Noah Mendelsohn/Cambridge/IBM@Lotus
>        cc:     "Marc Hadley" <marc.hadley@sun.com>, <rsalz@zolera.com>, "xml-dist-app" 
><xml-dist-app@w3.org>
>        Subject:        RE: Soap Message Canonicalization (SM-C14N)
>
>
>
>I agree with the "re-insert" but not sure how we can require it to say
>*where* other than in special cases where it knows about other blocks
>that may also be present. How can it say anything regarding header
>blocks it doesn't know about? What if we address the general case while
>allowing more special cases to take advantage of additional knowledge?
>That is, saying something like (just a rough draft):
>
>In the general case, a SOAP node MAY insert header blocks into a SOAP
>message without specific knowledge about other header blocks. In the
>case of known interdependencies between header blocks, the semantics of
>such header blocks may define more specific rules as to where and under
>what circumstances the header blocks can be inserted into a SOAP
>message.
>
>>I think it's a fairly hard requirement on the specification
>>for a module that requires re-insertion. It's not machine
>>testable, necessarily, but one certainly can look at such
>>a specification ask:  "does it tell you whether to reinsert,
>>and if so where?".
>>
>
>Does that come closer?
>
>Henrik Frystyk Nielsen
>mailto:henrikn@microsoft.com
>


-- 
Fred Carter
mailto:fred.carter@edgility.com
phoneto:510.433.6525