RE: Significant W3C Confusion over Namespace Meaning and Policy

OK, now we're getting somewhere in my view.  The content
of this email seems very progressive to me...

>> Why do you think your new RFC means that a URI may never
>> be used for identification purposes

>I don't (in fact, you even quoted part of the URI spec that
>I wrote that says it may).

This is good!  This is very good!

> What you ignored was the statement that you made to which 
> I was responding in the first place, namely that *identified* 
> had only one definition in computer science and, in particular, 
> it meant content-equality in the case of URIs.

Regardless of what I think 'identify' does mean, I have not
represented it as meaning content-equality in the case of URIs.
The namespace definition said the collection of names is
'identified' by a URI.  The rest of the spec (and the namespace
conventions doc) then went on to describe how we could identify
which element or attribute was intended by a document author 
based on expanded name.  This caused me to attach the particular
meaning of identify that I have to the words in the namespace
rec.  I did not ignore your statement; this prior response appears
a number of times in the tag archive.

>> The URI spec talks about all URIs, whereas there use in
>> namespaces is only one application.  Any implied IETF
>> process to update other technologies should not take
>> hold until it is shown that the debated aspect of the RFC
>> actually has the meaning implied.

>Huh?  The URI standard has already taken hold.  

Agreed.  My statement above was a refutation of the assertion
I thought you were making that the standard should already be
applied to update the namespaces rec to eliminate its notion
of using URIs for namespace identity until we finish the debate
about whether the standard really applies to the namespace
rec's use of URIs.  I think we agree that this is what we're
still debating.

>As I said in that message, whether or not Namespaces URIs 
>specifically hold the meaning of identified that you claim is 
>a separate matter and one that we are trying to determine -- 
>it is not written in stone simply because that is how you 
>interpret the NS spec.

>> I don't understand how that is a process issue.

>The process issue is claiming that we cannot come up with a
>technical answer to the question at hand simply because the
>Namespaces draft was published in 1999 and c14n was published
>at some other date and that somehow another recommendation is
>dependent on both, and the sky will fall if we make any changes.
>None of those is a technical answer to the issue of whether or
>not an existing namespace can be extended through the addition
>of new (non-conflicting) names, nor are they examples of software
>that breaks due to the addition of xml:id.

First of all, to me this is not just an issue with c14n.  It 
so happens that c14n manifests a specific problem because of 
a specific addition now being attempted (xml:id).  

The issue is not just whether id can be added to xml, but whether 
in general new names can be added to a namespace and by extension
whether the meanings of existing words can be changed.  When you 
add id to xml, it breaks c14n because some part of c14n relies on 
the idea that you can't change a particular defined namespace
upon which it is dependent.

Consider changing c14n to remove the 'undesired' dependence. 
Signatures created with a c14n that conforms to the change
will not validate on implementations that don't have the
changed c14n algorithm. 

This is a small problem.  So you asked me to provide a bigger
example of what breaks if 'identify' does not mean what I claimed
it means in the namespaces rec.  That's when I told you about
signatures in general.  More below...

>> It sounds more like a technical oversight or misunderstanding.

>Perhaps, which is why we need concrete examples.

The resulting frailty of XML signatures is a concrete
example of what breaks if a namespace is allowed to change
once signatures are applied to markup in that namespace.
I will be even more concrete (if that is possible) below.

>>A user signs some bits under the assumption
>> that those bits have a particular meaning in some application
>> context. Users don't understand bits; they understand application
>> context. Changing the meaning of words in a namespace means
>> that the signed bits are changing meaning without changing
>> serialization.  So the signature validates, but the XML
>> does not result in the same processor behavior that it once did.

>Right, which is one reason we do not allow new recommendations
>to change the meaning of existing words in a namespace.  

It is SO great for you to say this!  This is part of what I've
been trying for the last week to get some agreement on.

>It does not mean that new words cannot be added to a namespace,

The reason why we cannot change the meaning of existing words 
in a namespace once signatures are applied to markup in that
namespace is *exactly the same* as the reason why words cannot
be added or deleted.  It's impossible to accept one but not
the other!

>nor does it reflect an example wherein xml:id could in any way
>invalidate the signature.

As I said above, my beef is that, while a small problem is
created now with the addition of xml:id, it continues to 
set a terrible precedent that undermines XML signatures.

So, yes, concretely, adding xml:id and creating software
that creates signatures for this amended xml namespace
causes previously deployed, previously conformant software
to choke on the resulting signatures.  But, as a bigger and
no less concrete issue, the general practice of adding 
names to a namespace hurts not just c14n but XML signatures
in general. Not to lay an interstate highway here, but:

Consider a processor P for the namespace N=({A, B}, http://example.org)

Now create the distinct namespace N'=({A, B, C}, http://example.org)
and create a processor P' for N'.

Use P' to create a document D that contains markup from namespace N',
especially including C. Let the user sign D with signature S.
Now, send D to someone having only P.  Signature S validates, then 
D is presented to the validating user.  Problem is, P does not 
understand C, so only A and B are presented as being 'what got 
signed' by the original signer.

This is not different from changing the meaning of A or B in N'
relative to their meaning in N.  The user of P would get a 
validated S followed by an incorrect rendition of A or B.  So, the
argument for the immutability of A and B, which you seem to accept, 
is the argument for the immutability of N.  In fact, the former
is the weaker argument because, through adding C to N', P is 
*guaranteed* not to show *anything* to the user.  Whereas,
modifying the meaning of A or B in N' does not necessarily mean
the user of P will see something inappropriate (it just means
he might, which is enough from a security standpoint).

>> Just so I'm clear, is this the understanding you had of
>> my prior communications when you implied that I had yet
>> to produce a "useful" example?  If so, then I'm pretty sure
>> you're advocating that the IETF process of applying your RFC
>> should repeal or substantially qualify the use of the
>> XML signatures recommendation.

>It is quite possible that shining a little light on the
>XML signatures recommendation will reveal that it is fundamentally
>flawed with regards to URIs, but that isn't the purpose of this
>review of xml:id and I have no particular desire to go there.

This is the major source of our misunderstanding because I have
been trying to 'go there' ever since you challenged the legitimacy
of my interpretation of the namespaces rec.

This thread started because I explained why I believed that the
problem with c14n was degenerate.  If you fix the fact that xml:id
is being added to the xml namespace when it shouldn't be, then 
you don't have to fix c14n.  Everyone then started sending

>It is also absolutely true that W3C specifications are subject
>to the URI standard as specified by RFC 3986, and thus flaws
>in those specifications should be noted as errata as early as
>possible.

Agreed, but as previously discussed, there is nothing in that
RFC to state that my interpretation of namespaces is incorrect.
URIs may not always be used for identification, but the standard
says they may be, as you agreed above.  Hence, the standard is
not applicable to determining whether URIs *are* used for 
identification *in the case of the namespaces recommendation.*

Best regards,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.

Received on Monday, 14 February 2005 21:21:05 UTC