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

Re: Proposal for various Infosetisms

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 1 Oct 2002 12:17:15 -0400
To: Marc Hadley <marc.hadley@sun.com>
Cc: "Martin Gudgin" <mgudgin@microsoft.com>, "Rich Salz" <rsalz@datapower.com>, xml-dist-app@w3.org, xml-dist-app-request@w3.org
Message-ID: <OFC958B4D7.0070081F-ON85256C45.00591DB3@lotus.com>

Marc Hadley writes:

>> You still need canonicalization to get a 
>> signature that will validate following an 
>> intermediary switching from "1" to "true" 
>> as we allow

(sorry for so many notes in rapid succession, our correspondence is 

...and for reasons that should now be clear, I am against what I think is 
the status quo which is to allow such rewriting at intermediaries.  I do 
understand that some implementors asked for this lattitude and I respect 
that.  From the point of view of signatures (not SOAP itself), changing 1 
to TRUE conveys information, it can expose bugs in receiving software, 
etc.  Yes, there may also be value in signatures over the "logical 
meaning" of a SOAP message, for which indeed you need a canonical 
representation to bring together the equivalence classes.  For reasons 
I've about beat into the ground, I think users will also want signatures 
that go beyond the bounds of what SOAP considers equivalent, and that 
convey the stronger "has anyone messed with this message in any way, or 
can I assume that it is exactly the same infoset?".   BTW:  I can also see 
some call for users wanting to sign XML serializations, but that is 
binding specific in our architecture, and I see no need to get into it 
now.   Of course, such a signature over the "<...>" is quite close to but 
not identical in practice to a signature over the infoset.  Thanks!

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Tuesday, 1 October 2002 12:20:00 UTC

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