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

RE: exc c14n bugs

From: John Boyer <JBoyer@PureEdge.com>
Date: Wed, 5 Jun 2002 11:03:20 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B523287CE@tigger.PureEdge.com>
To: "merlin" <merlin@baltimore.ie>
Cc: <w3c-ietf-xmldsig@w3.org>

Hi Merlin,

>Also, in 3.4.3, it seems that we should be emitting xmlns="" slightly
>more often than the current rule suggests.  If an element E has no
>output ancestor that visibly utilizes the default namespace and E meets
>the first two conditions, then xmlns="" should be emitted.  This ensures
>E cannot change in meaning if its exclusive canonicalization is
>transferred from one enveloping element to another.  This also makes the
>handling of xmlns="" consistent with the first part of 3.3.3.

I would disagree here. C14n does not emit xmlns="" in this
case, and we don't need to either. It is not the canonical
form that will be reparented, but the node set from which
the canonical form is generated. If the input node set is
reparented correctly, even into a document that uses the
default namespace, it will carry its (null) namespace URI
with it; For example, take the following document:
  <Foo />

Reparent it into this:
  <Bar xmlns="http://example.org/bar />

The result will be:
  <Bar xmlns="http://example.org/bar><Foo xmlns="" /></Bar>

And the (exclusive) canonical form, in either case will be:

Well, we are already overriding the c14n handling of xmlns="", so it doesn't seem a justifiable defense. Also, your conclusion that the xmlns="" is unnecessary is based only on the specific implementation method of transferring E from one envelope to another by reparenting a node-set.  The developer cannot write a new envelope by writing "<envelope xmlns='http://mynamespace'>" + Exclusive canonicalization + "</envelope>", and it seems odd that such a simplistic thing is broken.  Finally, why would we handle:

<Foo xmlns="http://example.org"/>

differently from 

<Foo xmlns=""/>

Best regards,
Received on Wednesday, 5 June 2002 14:03:51 UTC

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