Re: rfc2518bis issue 03-C03 - DAV: Scheme

Dennis E. Hamilton wrote:

> Oh my.
> 
> Let me make sure I understand the key aspects of the situation here:
> 
> 1.	The DAV and opaquelocktoken URI scheme *names* are registered with IANA (with the names as their descriptions and citation of rfc2518 as the source), 
> <http://www.iana.org/assignments/uri-schemes>.  
> Is there actually a defined scheme, or has there been merely registration of the scheme name?

A URI scheme registration takes place by defining it inside a standards 
track document. For "opaquelocktoken", the scheme is indeed defined 
inside RFC2518 (both purpose and syntax), while there isn't a lot of 
text about "DAV:". We may want to fix that.

> 2.	The form "DAV:" is not an acceptable form for a URI according to the URI format specifications, although the editors of the URI specification revision have accepted the request to allow that form.

Correct.

> 3.	The XML Namespace specifications requires a URI as the value for the xmlns attribute.  At the moment, it would be permissible for an XML processor to reject DAV XML because of a malformed xmlns URI, though I doubt that has come up in practice, since a URI is basically opaque in the context of XML Namespace.

Yes. In fact, the namespace recommendation only says "takes the form of 
a URI (reference)", so there was a lot of dicussion about that two years 
ago.

Fact is, the whole issue was triggered by Jing (a schema validator 
written by Jim Clark) rejecting the namespace name "DAV:".

> This is an interesting nit.  I gather it is not new news.  

Nope.

> What is the appropriate action?

Make "DAV:" a legal URI (update RFC2396) and apologize for the URI abuse 
(updated RFC2518). Both underway.

> PS: I don't think the passage in <urn:ietf:id:draft-rfc-editor-rfc2223bis-07> is about XML Namespaces as such.  If the DAV WG thinks that the DAV namespace is an assigned-number space -- that is, the equivalent of a protocol tag set, then the issue should be addressed (even by an explicit statement that it is not being addressed or the requirement is not applicable, etc.).  I don't believe that registering a scheme name is responsive to this requirement, however.  My sense is that the greatest contribution to management of the protocol elements identified using the DAV namespace would be making an explicit, clear statement about what the extension mechanism is and who is the authority for additions to the DAV namespace, since it is allowed to be extended over time.  The question then becomes, what is invariant over time?  And once an element is introduced, what is then invariant over time? -- dh

No, it's not about XML namespaces. But that doesn't change the fact that 
RFC2518 introduces new spaces of names, and it needs to define them 
(syntax, change control and so on).

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 2 November 2003 17:14:31 UTC