RE: Soap Message Canonicalization (SM-C14N)

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 shouldn't 
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" <henrikn@microsoft.com>
Sent by: xml-dist-app-request@w3.org
02/21/2002 11:16 AM

 
        To:     "Noah Mendelsohn" <noah_mendelsohn@us.ibm.com>
        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 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
mailto:henrikn@microsoft.com

>-----Original Message-----
>From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com] 
>Sent: Wednesday, February 20, 2002 15:01
>To: Henrik Frystyk Nielsen
>Cc: Marc Hadley; rsalz@zolera.com; 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 
>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
>
>
>

Received on Thursday, 21 February 2002 12:04:54 UTC