RE: Soap Message Canonicalization (SM-C14N)

I agree.  We do need to say something about where blocks can be inserted. 
I would suggest a default behavior that blocks can be inserted anywhere in 
the header, with the usual proviso that mU headers targeted to the node 
can change the rules.  Does that sound right?

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

"Henrik Frystyk Nielsen" <>
02/21/2002 01:01 PM

        To:     <>
        cc:     "Marc Hadley" <>, <>, "xml-dist-app" 
        Subject:        RE: Soap Message Canonicalization (SM-C14N)

I see, thank you for the clarification! Doesn't it become our business
at least to some degree when describing the rules for where an
intermediary may insert a new header block? How does it handle the case
where existing blocks not intended for it provides such absolute
ordering rules?

It seems perfectly fine to define blocks that work closely together and
to rely on lexical ordering between those blocks - the proposal is
certainly to allow this without any additional constraints. 

We should by no means preclude even stricter constraints but it might be
better to leave that to our normal extensibility mechanism. For example,
if one wants to control the complete order of ALL blocks through ALL
SOAP nodes in a message path, would this not be better accomplished by
providing a next hop block that indicates this additional constraint on
every node? 

Henrik Frystyk Nielsen

>Sorry, I wasn't clear.  I am not _encouraging_ anyone to say 
>"my block has 
>to come first", I'm saying that "we leave it up to the 
>specifications for 
>various modules to coordinate the rules for their 
>coexistence." Obviously, 
>if the specification for your module causes the wrong kinds of 
>dependencies and brittleness, then you've created a module that's less 
>likely to be useful.  The point is, that's your business not 
>ours.  If you 
>want to create a suite of modules that work closely together 
>and have to 
>be used carefully together, that too is your business, and we 
>preclude it. 
>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/21/2002 11:16 AM
>        To:     "Noah Mendelsohn" <>
>        cc:     "Marc Hadley" <>, 
><>, "xml-dist-app" 
>        Subject:        RE: Soap Message Canonicalization (SM-C14N)
>I agree that this is somewhat out of scope of SOAP but I am not sure it
>is a good path to go down regardless. What you are proposing seems to
>require that all SOAP blocks have intimate knowledge about each other
>which I think is against our goal of promoting decentralized
>extensibility without central control. In other words, if a 
>block states
>that it has to be first, all other blocks must know about this rule in
>order not to violate it even if they may not care about order at all.
>This seems very brittle - are there any scenarios that may potentially
>justify this model?
>From a SOAP perspective, all I think we can talk about is relative
>ordering which brings me back to the earlier proposal of preserving
>relative ordering within a SOAP message but not provide any guarantee
>about absolute positioning. That is, if three header blocks: 
>A, B, and C
>are passed through (i.e. not targeted at) an intermediary they 
>will come
>out in the same order as they went in. If somebody wants to enforce
>stricter rules then they can use the SOAP processing model itself to
>enforce it at every SOAP node along the message path.
>Henrik Frystyk Nielsen
>>-----Original Message-----
>>From: Noah Mendelsohn [] 
>>Sent: Wednesday, February 20, 2002 15:01
>>To: Henrik Frystyk Nielsen
>>Cc: Marc Hadley;; xml-dist-app
>>Subject: RE: Soap Message Canonicalization (SM-C14N)
>>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 
>>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 
>>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" <>
>>02/20/2002 05:50 PM
>>        To:     Noah Mendelsohn/Cambridge/IBM@Lotus
>>        cc:     "Marc Hadley" <>, 
>><>, "xml-dist-app" 
>>        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
>>>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

Received on Friday, 22 February 2002 18:43:53 UTC