Re: Significant W3C Confusion over Namespace Meaning and Policy

On Feb 10, 2005, at 9:52 AM, John Boyer wrote:
>> I believe it is an error in the digital signature specification
>> to specify an algorithm that is impacted by changes outside
>> the content (such as any changes influenced by context). That
>> error should be fixed regardless of the namespaces discussion.
>
> First, maybe you missed the fact that I was not talking about
> any minor technical issue in C14N that arises *only when a document
> subset* is being processed.

No, but I should have said *if* such an error exists.

> Even if you don't use C14N, a signature is applied over a blob
> of XML markup.  The signature is signing the markup because the
> markup is supposed to representative of a concrete set of operations.
>
> That markup can be impacted by changes outside of the content
> if you allow changes the meaning of any name in the namespace or
> if you allow changes to the namespace.

The signature applies to what is signed -- nothing more than that.

> You said "the signature wouldn't work".   No!  The signature will
> in fact continue to validate, but the subsequent processing of the
> signed information may not be in accord with what the signer 
> authorized.

Let's consider a signed purchase order agreement.  It contains all
of the usual data for the purchase and is enclosed by a signature.
When that XML blob is placed within a protocol action consistent
with making a transaction, it has one meaning that everyone can
agree upon.  When that same XML blob is placed within a document
in which the surrounding text says:

    This is the purchase agreement we had in effect between
    the years 1999-2001.

then does that context somehow invalidate the signature?

Context does not invalidate a signature because the signature
is upon the ordered bits within the blob, not the meaning of
those bits when interpreted in context.  Any other interpretation
of digital signatures is fundamentally flawed because the entire
purpose of such signatures is accountability.

> So, to fix this error, one has to conclude that neither
> changing the namespace nor changing the semantics of the
> namespace are permitted.  Again, THIS HAS NOTHING TO DO
> WITH C14N!!!!!

Someone said that c14n contained instructions to treat all
xml namespaced attributes as inherited.  That is a rather
obvious error, assuming it actually says it (I haven't checked).

> On a separate point, it is interesting that you've used an RFC let
> in Jan. 2005 to justify your interpretation of words appearing in
> a W3C recommendation published in 1999.

Yes, interesting in that it reflects the most recent international
standard on what it means, agreed to in public, and thoroughly
vetted by the TAG.  Namespaces is dependent on URI.

> But, to play ball, let's take a look at the words you quoted, focusing 
> on
>
> "These terms should not be mistaken as an assumption that an identifier
>      defines or embodies the identity of what is referenced, though
>      that may be the case for some identifiers."
>
> Thus, even by your definition, it may be the case for some
> identifiers that they are indeed meant to embody the identity
> of something.  And my position remains that the material
> created in 1999 (the namespaces rec and the namespaces conventions)
> were intended to create this class of identifiers.

Great, then we have resolved the question.  The namespaces rec
had no such intention, and even if it could be interpreted the
way you suggest, that only means we will have to edit the Namespaces
draft to bring it in line with reality.

Again, please do not play W3C process games here.

> Regardless of what new meaning you and others may want to
> assign to the word identify, the fact remains that their
> usage in dictionaries and computer science texts do not use
> the meaning you define.
>
> So, clearly we're not going to get anywhere by continuing to
> haggle over this point.

Good, because it would be far easier to agree to disagree than
to explain to you the 16 different definitions of identify

   <http://dictionary.reference.com/search?q=identify>

only one of which agrees with your assumed meaning.

> What I would like instead is for someone to explain to me
> exactly why it is so hard for implementations to be what
> I perceive to be only slightly more intelligent about their
> handling of namespaces.  You make a big deal out of the idea
> of changing the namespace when the language schema changes,
> but this is a trivial thing for an implementer to account for.

Since "xml" is a reserved qualifier, the difference is
between having id available automatically within all XML
languages (a universal standard for a universal concept)
or requiring that any use of it be xmlns declared like
other extended name sets.

Uniformity has considerable value and the "xml" namespace
has *always* been intended for extension.  Hence, our prior
conclusion that xml:id is a desirable extension still seems
to be true.  If that causes breakage, we need to fix the real
reasons for that breakage, not become reactionary and reduce
XML to the lowest common denominator of past Recommendations.


Cheers,

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

Received on Friday, 11 February 2005 02:37:23 UTC