RE: rfc2518bis issue 03-C03 - DAV: Scheme

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?

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.

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.

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

What is the appropriate action?

-- Dennis

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


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, November 01, 2003 11:05
To: dennis.hamilton@acm.org
Cc: w3c-dist-auth@w3.org
Subject: rfc2518bis issue 03-C03, was: rfc2518-bis-05 issues (part 1) -
DAV: Scheme


Dennis E. Hamilton wrote:

> I support Julian's observation about the paragraph on use of the "DAV:" 
> URI scheme.  The earlier statement snarls up scheme names and Namespace
> URIs too much.
> 
> I proposed the following amendment, although I am not entirely happy
> with it.  It is not clear to me what this provides. It is informative.
> Is there anything more to say about this.  I.e., are we promising not
> to do this again, not to expand it beyond the current approach to DAV
> interoperability preservation, or what?  

Yes. This, and: "we are aware of the fact that this was a mistake".

BTW: we want to do this because it seems that many abuses of ad-hoc URI 
scheme usage was indeed inspired by WebDAV.

> Finally, section 19's discussion about what IANA must do (!?) should be
> repaired to identify the two *URI*schemes* that must be registered, the one
> for "DAV:" URIs and the one for "opaquelocktoken:" URIs.  IANA does not
> register namespaces, and that language should be removed from section 19.

I agree with the statement that "DAV:" and "opaquelocktoken:" are URI 
schemes, not URI namespaces. I'm *not* sure that I agree with the rest. 
"Instructions to Request for Comments (RFC) Authors" says in 
<urn:ietf:id:draft-rfc-editor-rfc2223bis-07>:

       Any RFC that defines a new "namespace" of assigned numbers should
       include an IANA Considerations section specifying how that space
       should be administered.  See "Guidelines for Writing an IANA
       Considerations Section in RFCs" [IANA98] for a detailed discussion
       of the issues to be considered and the contents of this section.

RFC2518 does define several namespaces: the space of WebDAV property 
names, the space of WebDAV protocol element names, and so on. I think 
it's correct to mention that in the IANA Considerations section.

[ ... ]
> 
>    Note that both defining a new URI scheme just for the purpose of 
>    identifying protocol elements and using just the scheme name as a 
>    namespace name are inconsistent with current best practice.  Use
>    of the "DAV:" and "opaquelocktoken:" URIs is preserved for 
>    compatibility with existing deployments. There will be no further
>    introduction of new URI schemes as part of DAV. 

I like that except for "...are inconsistent with current best practice". 
The usage of a URI scheme name as a URI indeed does not comply to the 
URI syntax (according RFC2396, there is no such thing as a URI with an 
empty scheme-dependant part).

If we want to get really verbose we can also state that RFC2396bis 
(<urn:ietf:id:draft-fielding-uri-rfc2396bis-03>) is going to lift this 
restriction in order to make usage of URIs auch as "dav:" or "about:" 
legal 
(<http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html?rev=1.55#014-empty-opaque_part>). 
But that's a future IETF document we probably don't want to wait for.

Julian


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

Received on Sunday, 2 November 2003 16:33:13 UTC