RE: C14N: Non-absolutized URIs

Hi James,

Firstly I am curious how applications are even supposed to know that the
namespace name is a relative URI as opposed to a simple string.  For
example, in <e xmlns="string"/>, is the 'string' a simple string or does it
mean 'baseURI/string'?  According to rfc2396, a relativeURI can be a
rel_path, and a rel_path can consist solely of a rel_segment, and a
rel_segment can consist solely of one or more unreserved characters.
Perhaps there I've made a mistake, the plenary's suggestion is that, in the
future, every xmlns should be an absolute URI that includes a scheme.  Is
this correct?

Secondly, your point is well-taken on the fact that using the literal
contravenes the plenary's recommendation (in part because, if this is a
public document, it seems to have become so yesterday).

Nonetheless, I read it and I draw your attention first to section 4.1:

"As always, the final decision on what a WG does rests with the WG, not with
the Plenary: the Plenary decision is only advisory" [1]

In the case of c14n, we cannot simply fail to create an unambiguous
canonical form because this is equivalent to saying that, for the purposes
of dsig, the document is no different than if it were not well-formed.  I am
personally OK with this, but it does seem to contradict [1], answer 2, which
argues that the document is well-formed.  I also wonder how many existing
documents we will not be able to sign as a result.

Perhaps it would be better to focus on the essential message of [1], which
can be found in the answer to question 4 in [1]:

<quote>
Q4:OK, then, what's the namespace name of the root element in thatDoc?

A4:../foo, per the namespaces spec as written.

But be careful with terminology. The 'namespace name' is ../foo, but the
Namespaces Rec doesn't define a term 'Namespace URI'. According to section
4, URI References, in RFC 2396, "the URI" denoted by ../foo is
http://example.org/foo -- and terms like "namespace URI", which allude to
that mechanism, should be used with great caution
</quote>

Therefore, as long as we are careful to say that the serialization contains
the namespace name, not a namespace *URI*, then I think we will be adhering
to the plenary in the best way that is possible for c14n and dsig.

Thanks,
John Boyer
Development Team Leader,
Distributed Processing and XML
PureEdge Solutions Inc.
Creating Binding E-Commerce
v: 250-479-8334, ext. 143  f: 250-479-3772
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>


-----Original Message-----
From: James Clark [mailto:jjc@jclark.com]
Sent: Monday, September 11, 2000 8:13 PM
To: John Boyer
Cc: w3c-ietf-xmldsig@w3.org; w3c-xsl-wg@w3.org
Subject: Re: C14N: Non-absolutized URIs


John Boyer wrote:

> <john>Right, and as an application of XPath, we are choosing the behavior
> that is most appropriate to our application.  No matter how much the
plenary
> wants to force things on dsig, there is nothing they can do to change the
> behavior of a sha-1 hash.  We MUST have a single behavior, therefore we
MUST
> </john>

The decision of the plenary at:

  http://www.w3.org/2000/09/xppa

concludes:

  new specifications prepared by W3C Working Groups include statements
  similar to the following:

    This specification does not define an information set
    [or whatever] for XML documents which use relative URIs
    in namespace declarations."

  or

     The scope of this specification includes all well-formed
     XML documents which use only absolute URI references in
     namespace declarations. Documents which use relative
     URI references are out of scope, and not addressed by
     this specification.

   or words to similar effect.

If you follow this, then you would simply say that you spec does not
apply to XML documents including relative namespace declarations, just
as it does not apply to ill-formed XML documents, nor to documents not
conforming to the Namespaces Rec.  If you do this, you don't need to
wait for any XPath errata.

> It is essential that a single behavior be defined for C14N, and the fact
> that XPath permits application-dependent behavior means that applications
> (such as C14N) are permitted to define the most appropriate behavior.

Having C14N define the behaviour of namespace URIs is not inconsistent
with XPath (per the proposed errata), but is most definitely
inconsistent with the XML Plenary decision.

James

Received on Tuesday, 12 September 2000 12:25:27 UTC