RE: Significant W3C Confusion over Namespace Meaning and Policy

Hi Roy,

Also, I think you missed the point I made about signatures
because I believe you unknowingly argued in favor of the
position of requiring a namespace URI change when the 
collection of names changes (or repealing the entire XML
signature recommendation).  You said:

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

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.

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.

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

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.

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.

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.

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.

So when you are "weighing" the drawbacks, so to speak, 
perhaps you could get a bit more specific about how the
"weights" are assigned.

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



-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Wednesday, February 09, 2005 6:30 PM
To: John Boyer
Cc: www-tag@w3.org; Bjoern Hoehrmann
Subject: Re: Significant W3C Confusion over Namespace Meaning and Policy


On Feb 9, 2005, at 4:54 PM, John Boyer wrote:
>> so I hope you forgive me for rejecting *identified* as having
>> the meaning you suggest.
>
> Fair enough.  The only problem I have with it is that this is
> what the word means in the dictionaries to which I have access
> as well as in computer science texts.
>
> So, given the field we're in, 'identified' is the wrong word to use
> to achieve your interpretation.  I think your interpretation
> would correspond more to
>
> a collection of names "[currently] associated with" a URI

Umm, I've already quoted text on this mailing list from a
dictionary that directly contradicts what you said above, but
that doesn't matter since it has been answered normatively:

<http://gbiv.com/protocols/uri/rfc/rfc3986.html#sec_1_1>

   Identifier

     An identifier embodies the information required to distinguish
     what is being identified from all other things within its scope
     of identification. Our use of the terms "identify" and
     "identifying" refer to this purpose of distinguishing one
     resource from all other resources, regardless of how that purpose
     is accomplished (e.g., by name, address, or context). 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. Nor should it be
     assumed that a system using URIs will access the resource
     identified: in many cases, URIs are used to denote resources
     without any intention that they be accessed. Likewise, the
     "one" resource identified might not be singular in nature
     (e.g., a resource might be a named set or a mapping that
     varies over time).

   A URI is an identifier consisting of a sequence of characters
   matching the syntax rule named <URI> in Section 3. It enables
   uniform identification of resources via a separately defined
   extensible set of naming schemes (Section 3.1). How that
   identification is accomplished, assigned, or enabled is
   delegated to each scheme specification.

>> In my opinion, you should put aside the process issues and state
>> clearly what the technical benefits/drawbacks are of allowing a
>> new name to be added to an existing namespace.
>
> OK.  For one, if XML markup that was signed can be processed
> differently after the signature was affixed relative to when
> the signature was affixed, then XML signatures becomes insecure.

Well, no, they just wouldn't work.  So we should list that as
one of the drawbacks because such processing is required by
the presence of a new attribute even though that new attribute
does not appear within the signed content, right?

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.

>> Merely claiming "it is defined that way in Namespaces" doesn't
>> really argue for anything more than changing the Namespaces
>> recommendation to better suit the architecture.
>
> Merely claiming that it is defined a particular way in namespaces
> doesn't merely argue for a namespace erratum.  It argues that
> either a namespaces erratum be issued (and fixes to any specs
> that may have counted on the meaning being corrected) OR for
> correcting the use of namespaces within the W3C going forward.

Right, one or the other (the other being less).

> The job of the TAG is to think about all the Recs they have
> and choose.

No, the TAG is not bound by existing Recs.  We are here to help
the WGs make forward progress towards the technical nirvana of
the W3C mission.

> This thread started out because a large number in the W3C
> community did not even believe that a change was required,
> other than an erratum from some obscure little spec.  Even
> the suggestion that a fix could occur by an erratum to
> Namespaces is significant progress.  Still, it'd break things.

Yep, omelette all over the place.  If you know of more examples
of breakage, please continue to send them to the list.  At some
point we just have to decide what is better: the breakage as
described or the ability to extend existing namespaces.


Cheers,

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

Received on Thursday, 10 February 2005 17:53:20 UTC