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.

> Furthermore,
> it seems inappropriate to embed a requirement for some third-party in the
> body of the DAV specification.  It would seem that the DAV WG must take
> responsibility for ensuring that there is appropriate reservation of the
> DAV and opaquelocktoken schemes, and section 19 should assert that such
> reservation has been accomplished (and a reference would be useful).

In general, I disagree. Publishing an RFC is actually the correct way to 
register a URI scheme.

As RFC2518bis is supposed to "obosolete" RFC2518, it should contain the 
same information. Quote from <urn:ietf:id:draft-rfc-editor-rfc2223bis-07>:

          Obsoletes

             Specifies an earlier document that is replaced by the new
             document.  The new document can be used alone as a
             replacement for the obsoleted document.  The new document
             may contain revised information or all of the same
             information plus some new information, however extensive or
             brief that new information may be.

> AMENDED CHANGE PROPOSAL
> 
> -05 section 4.4, last paragraph: 
> 
>    Note that “DAV:” is a scheme name defined solely to provide a
>    namespace for WebDAV XML elements and property names.  This practice
>    is discouraged in part because registration of new scheme names is
>    difficult. "DAV:" was defined as the WebDAV namespace before
>    standard best practices emerged, and this namespace is kept and
>    still used because of significant existing deployments, but this
>    should not be emulated.
> 
> rewrite as:
> 
>    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 Saturday, 1 November 2003 14:09:16 UTC