W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

RE: Whitespace

From: Brian LaMacchia <bal@microsoft.com>
Date: Fri, 11 Jan 2002 17:30:20 -0800
Message-ID: <BCDB2C3F59F5744EBE37C715D66E779C0290318C@red-msg-04.redmond.corp.microsoft.com>
To: <reagle@w3.org>
Cc: <w3c-ietf-xmldsig@w3.org>
I object to the proposal for including xml:space as an attribute of
SignatureProperties and Object for the following reasons:

1) This change introduces new interop requirements that we'd have to
test & meet in order to progress to Standard/Recommendation.
(Specifically, do applications properly interop if the attribute is
xml:space=default or xml:space=preserve.) 

2) I'm not convinced that supporting or depending on xml:space is the
right way to go.  If we need space-removal semantics I believe we should
do that with a better, XML Schema-aware canonicalization algorithm.

2a) Related to (2), in the existing two C14N algorithms the presence or
absence of an xml:space attribute doesn't actually affect the execution
of the algorithm (indeed: per the C14N spec, "All whitespace in
character content is retained") so I can't see this change being
justified on grounds of affecting the actual signature; the xml:space
would instead only be of significance to an app-level semantic that
interprets the contents of an Object element.

3) If we were going to put the attribute anywhere, then I believe
Joseph's comment is correct that it would be more appropriate for the
attribute to go on ext:Foo.  (Notice that since dsig:Object does not
itself have any significant semantic beyond a mere container, it is the
case that in fact doing it this way (on ext:foo) is fully equivalently
expressive.)

4) Finally, as the owner of a V1-compliant implementation that has been
frozen for months, I must object to any change that could potentially
make my implementation non-compliant.

So, basically, it's too little and too late.  The chance that
implementations might become non-compliant at this point, combined with
the time it would take to perform new interop testing, is sufficient
reason in my opinion to reject this proposal.  

					--bal   

-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org] 
Sent: Tuesday, January 08, 2002 1:08 PM
To: Rich Salz; w3c-ietf-xmldsig@w3.org
Subject: Re: Whitespace

On Tuesday 08 January 2002 13:04, Rich Salz wrote:
> I believe that the SignatureProperty and Object element definitions
> should be modified to allow the xml:space attribute.  I'm proposing
> those two, because I believe those are the most likely elements within
> ds:Signature that will be covered by a signature.

Hi Rich, we are on the very cusp (I hope this week) of getting IESG 
approval and moving forward. Consequently, the only tweaks we've
accepted 
since we entered PR are those that don't upset *any* person, previous 
concensus, instances, or implementations: just small tweaks that  make
the 
spec better in everyone's eyes.

To implement your proposal we'd have two options:
1. Add the following to the two element definitions that would then
permit 
xml:space and xml:lang
  <anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/> 
2. Or to enable xml:space but preclude xml:lang:
  <xsd:import namespace="http://www.w3.org/XML/1998/namespace" 
    schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    ...
     <xsd:attribute ref="xml:space" use="optional"/>

I don't see either violating my threshold of slipping it in if others
think 
this is a good idea and no one objects. (The first is better IMHO.)

However, if you did this, wouldn't this also preserve the whitespace 
between the ds:Object and the ext:Foo? I'd think that if you're worried 
about the whitespace in ext:Foo, it should have the xml:space, not 
necessarily the ds:Object?

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Friday, 11 January 2002 20:30:56 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:14 GMT