W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

RE: Soap Message Canonicalization (SM-C14N)

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 20 Feb 2002 18:01:13 -0500
To: henrikn@microsoft.com
Cc: "Marc Hadley" <marc.hadley@sun.com>, rsalz@zolera.com, "xml-dist-app" <xml-dist-app@w3.org>
Message-ID: <OF4C1D342D.58206BA3-ON85256B66.007EC42D@lotus.com>
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 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" 
        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 Wednesday, 20 February 2002 18:16:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:18 UTC