RE: rfc2518bis issue 03-C03 - DAV: Scheme

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

I would be surprised to hear this -- I'd like to see what 
makes it unacceptable.  I agree it's not well specified, so to
believe it's acceptable means you have to assume that the 
definition for the DAV: scheme allows a null URI after the
scheme part.  But why would you assume that would be 
unacceptable? Most URI schemes require something after the
scheme name, but clearly DAV: doesn't.

> 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

That's a good point.  It *is* possible to create new URIs
under the DAV: scheme name, now that it's defined.  E.g. we
could have defined "DAV:deltav", "DAV:bindings", etc as
namespaces for various extension elements.  There isn't anything
written down, however, about how to construct valid URIs using
the DAV: scheme.  

lisa


> -----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-20
02/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:58:15 UTC