Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 14, 2005, at 10:24 AM, John Boyer wrote:

> You stopped reading the prior email at a critical moment,
> just before getting to the most important question.
> Why do you think your new RFC means that a URI may never
> be used for identification purposes, when your definition
> states that it may be used for this purpose and the
> namespace rec says that, when used with namespaces, it is
> used for that purpose?

I don't (in fact, you even quoted part of the URI spec that
I wrote that says it may).  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.

> 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.  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.

> Moreover, is it part of
> process to irreparably break other IETF and W3C technologies?

Only on a good day.

> 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.

> It sounds more like a technical oversight or misunderstanding.

Perhaps, which is why we need concrete examples.

>>> Changes to the context do
>>> not affect the serialization over which the hash is
>>> ultimately computed, then the signature is repudiable.
>
>> I cannot parse that sentence because it is missing a word.
>
> Please prepend the word 'if'.
> You asked me to provide an example of failure. I provided
> one which is quite understandable despite a missing word
> in one sentence.  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
does not mean that new words cannot be added to a namespace,
nor does it reflect an example wherein xml:id could in any way
invalidate the signature.

> 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.
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.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Monday, 14 February 2005 19:52:37 UTC