Subject: RE: rfc2518-bis-05 issues (part 1) - DAV: Scheme

From: "Dennis E. Hamilton" <[email-masked]>
Date: Sat, 1 Nov 2003 08:44:19 -0800

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?  

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.

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

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. 

-- Dennis

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Julian Reschke
Sent: Tuesday, October 28, 2003 12:18
To: [email-masked]
Subject: rfc2518-bis-05 issues (part 1)

Hi.

Below is a list of issues I raised against drafts 03 and 04 which IMHO 
have not been adequately addressed in the latest draft (see [1] for the 
original message).

03-C03

4.4: “Note that the use of a new top-level URI identifier as a namespace 
is considered by many to be a bad thing…”

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 is to be considered a bad practice, and should not be 
copied”.

[draft 05 now says...]

    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.

[ ... ]

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0040.html>

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 01 Nov 2003 20:05:07 +0100

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

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

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

>    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

---

From: "Dennis E. Hamilton" <[email-masked]>
Date: Sun, 2 Nov 2003 13:32:46 -0800

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:[email-masked]]
Sent: Saturday, November 01, 2003 11:05
To: [email-masked]
Cc: [email-masked]
Subject: rfc2518bis issue 03-C03, was: rfc2518-bis-05 issues (part 1) -
DAV: Scheme

[ ... ]

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 2 Nov 2003 13:58:24 -0800

> 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

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 02 Nov 2003 23:13:31 +0100

> 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 for…

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…

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, t…

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 02 Nov 2003 23:27:00 +0100

> I would be surprised to hear this -- I'd like to see what 

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2001OctDec/0193.html>

It should also be mentioned in:

<http://www.webdav.org/wg/rfcdev/issues.htm>

> makes it unacceptable.  I agree it's not well specified, so to

It isn't an absolute URI because absolute URIs have non-empty 
scheme-dependant parts. It's not a URI reference either because it 
contains an unescaped ":".

Again - see the entries on the issues lists for RFC2396 and RFC2518.

> scheme name, but clearly DAV: doesn't.

No, no, that's incorrect. The syntax of "DAV:" URIs MUST comply to what 
the URI specification says (see above).

> written down, however, about how to construct valid URIs using

...because we are too lazy, and this doesn't seem to be an issue. What 
we *should* state is: only WebDAV WG standard tracks documents may 
define/use new URIs in the DAV: scheme (that's the "change control" part).

Julian

---

From: "Dennis E. Hamilton" <[email-masked]>
Date: Sun, 2 Nov 2003 16:41:15 -0800

Lisa,

My reading of this is the same as Julian's.  The URI RFC stipulates the admissible syntax of URIs, with a modest variety of flavors.  None of the rules currently allow "DAV:" as a valid URI form.  And the editor of their -bis document has accepted a modification that allows the empty part. 

Julian,

I think a bigger part of the change control has to do with use of a DAV URI as a namespace identifier.  Something similar should be stated in that respect, along with the condition on who gets to create URIs in the DAV scheme.  I think that means I am also aligned with what you say about defining the "namespace" in your other note with this subject line.

-- Dennis

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Sunday, November 02, 2003 14:27
To: Lisa Dusseault
Cc: [email-masked]; [email-masked]
Subject: Re: rfc2518bis issue 03-C03 - DAV: Scheme

[ ... ]

>  There isn't anything

Julian