Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 14:18:30 -0800

Accidentally caught by the spam filter.

- Jim

-----Original Message-----
From: Mark Baker [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 7:52 PM
To: Jim Whitehead
Cc: [email-masked]; [email-masked]
Subject: [Moderator Action] Re: RFC2518 (WebDAV) / RFC2396 (URI)
inconsistency

Hi Jim,

> As a result, I recommend that the XML namespace recommendation be modified
> to allow the use of just the URI scheme name as a namespace identifier,
> perhaps limited to just members of the set of non-hierarchical URIs. It
> seems clear to me that the XML namespace recommendation was written with
> only the class of hierarchical URIs in mind,

I can't see why you'd believe that.  Namespaces are often URNs, for
example.

> and as a result it's not too
> surprising that a glitch arose in the first use with non-hierarchical
URIs.
> Based on Julian's experience, and our experience with multiple WebDAV
> implementations, accepting a URI scheme name as a namespace identifier
would
> codify existing, interoperable, practice.

IMO, a URI scheme has identity, and so should be able to be identified
by a URI reference.

Perhaps a compromise here would be to treat "DAV:" as a relative URI
reference.  A 2518 revision could include the use of XML Base, or its
own base-declaring mechanism, allowing future DAV specifications and
processors to use URIs to evolve, while existing processors could be
seen to be assuming a base URI.  Thoughts?

MB
--
Mark Baker, CSO, Planetfred.
Ottawa, Ontario, CANADA.
[email-masked]

---

From: "Stefan Eissing" <[email-masked]>
Date: Thu, 22 Nov 2001 10:11:09 +0100

Unfortunately, "DAV:" is no legal URI reference either. RFC 2396
explicitly forbids ':' in relative path's first segment...

//Stefan

---

From: Mark Baker <[email-masked]>
Date: Thu, 22 Nov 2001 09:51:43 -0500 (EST)

> explicitly forbids ':' in relative path's first segment...

Darn, I thought I checked this.  I assume the reason for this is to
allow disambiguation between absolute and relative URI references.
But, "dav:" isn't a valid URI reference of any kind, so what if we
<holds-breath/> updated 2396 to allow ":" as the last character of
the relative path's first segment?  Would that break anything?

A change to 2396 is obviously a serious thing, but so is not
breaking WebDAV, despite its quirkiness wrt namespaces.

MB

---

From: Martin Duerst <[email-masked]>
Date: Sat, 24 Nov 2001 18:49:32 +0900

>the relative path's first segment?  Would that break anything?

In terms of specs, probably not. In terms of implementations,
we would have to test quite a few to be able to claim that
all (or a sufficiently large subset of) current implementations
already process foo: relative.

Regards,    Martin.

---

From: Mark Baker <[email-masked]>
Date: Sun, 25 Nov 2001 02:37:44 -0500 (EST)

> already process foo: relative.

Right.

And BTW, my proposed correction above was incorrect.  It should be that
rel_path should be able to end with a ":", not rel_segment.

Here's my "I'm not at all familiar with the intricacies of the BNF
production rules, but here goes anyway" attempt at patching it up;

rel_path      = ( rel_segment [ abs_path ] | rel_segment ":" )

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

---

From: "Larry Masinter" <[email-masked]>
Date: Sun, 25 Nov 2001 00:15:51 -0800

It seems like people have noted the following possibilities:

* Change the URI spec to allow "DAV:" as a URI
* Change the WebDAV spec to use something other than "DAV:" as
   the namespace name

but have left out the following possibilities:

* Change the XML namespace spec to allow "scheme-name:" as
  a namespace name, even though it isn't a legal URI
  (This isn't such a big deal, since XML namespace names allow
   IRIs with non-ASCII characters anyway, not really URIs)

* Declare that WebDAV bodies aren't really XML, because
  the WebDAV spec has this little problem with the "DAV:"
  namespace.

The latter is the closest approximation to the 'truth', requires
no incompatible changes to any specs or any other software, but
means that (as happens to be true) anyone trying to apply generic
XML software to WebDAV requests or responses has to be careful
because of the use of the "DAV:" namespace.

Larry
-- 
http://larry.masinter.net

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 25 Nov 2001 10:46:42 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Larry Masinter
> Sent: Sunday, November 25, 2001 9:16 AM
> To: 'Mark Baker'; 'Martin Duerst'
> Cc: 'Stefan Eissing'; 'WebDAV'; [email-masked]
> Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
>

I mentioned this.

>    IRIs with non-ASCII characters anyway, not really URIs)

I don't think they do.

"[Definition:] The attribute's value, a URI reference, is the namespace name
identifying the namespace. ..."

>   the WebDAV spec has this little problem with the "DAV:"

WebDAV could also define that the message bodies do not use namespaces, and
re-declare the namespace syntax so that "DAV:" is valid. However, I doubt
that anybody would want *that*. It would basically mean that on the long
run, an non-namespace aware XML processor is required, and that WebDAV
servers/clients would need to do namespace checking and mapping on their
own.

> because of the use of the "DAV:" namespace.

I think you just argued for changing the WebDAV namespace (or to deprecate
it and add an alternative one).

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 25 Nov 2001 15:26:40 -0800

>    IRIs with non-ASCII characters anyway, not really URIs)

In case anyone is wondering, "scheme:" is not allowed in the URI syntax
because Web browsers and client libraries do interpret it as a form of
relative URI due to a loophole in CERN's original partial URI algorithm.
People never used it, but the loophole makes it impossible for such an
identifier to be interoperable.

OTOH, I have found at least one other example -- the "about:" URL in
Netscape Navigator -- so I guess this could be changed in a future revision
of 2396.

....Roy

---

From: Mark Baker <[email-masked]>
Date: Sun, 25 Nov 2001 20:28:52 -0500 (EST)

Roy,

> Netscape Navigator -- so I guess this could be changed in a future revision

Interesting.  Just to clarify, what are you suggesting be changed?
That "foo:" be a valid absolute URI reference, or a valid relative
one?

MB

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 26 Nov 2001 10:25:48 -0800

Roy Fielding writes:
> Netscape Navigator -- so I guess this could be changed in a
> future revision of 2396.

A very principled case can be made for viewing the scheme namespace as a set
of URIs. This URI space identifies URI/URN/URL scheme names.

A scheme identifies a resource, the abstract concept of the particular
identifier of locator space. For "http" scheme URLs, the URI "http:"
identifies the abstract notion of locators for Web resources accessed via
the HTTP protocol. The "dav:" URI identifies the abstract concept of
property and XML element names used in the WebDAV family of protocols.

Put another way, there is a set of resources:

{{The abstract notion of locators for Web resources accessed via the HTTP
protocol},
{The abstract concept of property and XML element names used in the WebDAV
family of protocols},
{The abstract concept of locators for directory resources accessed via the
LDAP protocol},
{The abstract concept of identifiers for people's email inboxes}}

These resources map to the following URIs:

{"http:", "dav:", "ldap:", "mailto:"}

Once you accept that these are all valid URIs, then RFC 2396 can be viewed
as needing revision to remove the (artificial) constraints on URI syntax
that prevent the use of scheme name URIs.

- Jim

PS - So, yes, I am reversing my earlier opinion that RFC 2396 does not need
revision.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 26 Nov 2001 11:18:00 -0800

> of URIs. This URI space identifies URI/URN/URL scheme names.

I understand that case, but don't think it is a good idea.  URI namespaces
are a form of protocol, and like all protocols they are occasionally subject
to revision.  I prefer to identify such protocols with a separate URI, not a
construct of the syntax.  But that is not just my preference -- it is also
demonstrated by that silly "about:" URI in Netscape Navigator.  That does
identify a resource, not the naming scheme.  The basic problem is that,
given the ability to define their own namespace, most developers think it is
"safer" to create their own world of names.  And they may even be right.

In other words, I think that "scheme:" is only a valid identifier for the
namespace if the scheme defines it as such.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 26 Nov 2001 15:27:33 -0800

> That "foo:" be a valid absolute URI reference, or a valid relative

An absolute URI -- otherwise, the parsers would have to be changed.

....Roy

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 26 Nov 2001 15:40:54 -0800

Roy Fielding writes:
> I understand that case, but don't think it is a good idea.
> URI namespaces are a form of protocol, and like all protocols
> they are occasionally subject to revision.  I prefer to identify
> such protocols with a separate URI, not a construct of the syntax.

I agree that it makes sense to have a different identifier for each revision
of a URI scheme. BUT, these identifiers do not identify the same resource as
the scheme URI.

For example, "http:" identifies

    The abstract notion of locators for Web
    resources accessed via the HTTP protocol

which is a different resource than

    The set of locators for Web resources
    accessed via the HTTP protocol and defined
    specifically by RFC 2616.

and different still from

    The set of locators for Web resources
    accessed via the HTTP protocol and defined
    specifically by RFC 2068.

even though the actual URL space in question could be the same (that is, the
abstractions are different, even if, by chance, all these abstractions refer
to the same set of URLs).

So, you could still have "http:" and two additional URI/URL/URNs for the
version-specific definitions of the http URL space.

>  But that is not just my preference -- it is also
> identify a resource, not the naming scheme.

Actually, since it does consistently return a resource, doesn't that make it
a URL?

> namespace if the scheme defines it as such.

This would only be for pragmatic reasons, not for philosophic ones.

- Jim

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 26 Nov 2001 15:59:23 -0800

>     resources accessed via the HTTP protocol

No, it does not!  The http scheme defines a namespace with a hierarchical
syntax for which the naming authorities are defined by DNS/IP address and
TCP port.  The protocol used to access those names will change over time,
just as it has already done so twice.  Whether or not all such protocols
are called HTTP depends on the IETF, which doesn't move anywhere near as
fast as we develop new protocols that use the http namespace.

> version-specific definitions of the http URL space.

Yes, but only if we defined it to be such a thing, which we won't do because
Web browsers still discard the scheme name if it is the same as the scheme
of the referring document.

> Actually, since it does consistently return a resource, doesn't that make it

*shrug*  It isn't a relevant distinction.

> This would only be for pragmatic reasons, not for philosophic ones.

Hey, I'm a very pragmatic philosopher.  I don't care for philosophies
that don't work in practice.

....Roy

---

From: Martin Duerst <[email-masked]>
Date: Tue, 27 Nov 2001 15:38:40 +0900

> >    IRIs with non-ASCII characters anyway, not really URIs)

Just a moment: IRIs are carefully defined so that they can be
mapped to URIs. Therefore, 'scheme-name:' isn't an IRI.

>identifying the namespace. ..."

Julian is correct, currently the namespace Rec doesn't mention
anything IRI-like, as opposed to XML, XML Schema, XLink, and
many others.

Regards,    Martin.

---

From: Mark Baker <[email-masked]>
Date: Thu, 29 Nov 2001 23:17:41 -0500 (EST)

(sorry for the delay, I've been out of email range)

> An absolute URI -- otherwise, the parsers would have to be changed.

Ok, thanks.

But I'd point out that "about:" appears to me to be designed to be
a relative URI; if IE supported "about:", it wouldn't pop up
Communicator's info screen, it would pop up one about IE.

That's not the case for "dav:", though.

MB

---

From: Martin Duerst <[email-masked]>
Date: Fri, 30 Nov 2001 20:59:00 +0900

>Communicator's info screen, it would pop up one about IE.

And if you use about: on a Japanese version of Netscape,
it will turn up in Japanese. Content negotiation.
There is nothing saying that an URI with absolute URI syntax
but resolve to exactly the same bytes every time.
'about:' would just be defined as 'information about the
tool I'm just using'.

Regards,    Martin.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 30 Nov 2001 13:09:38 -0800

> Communicator's info screen, it would pop up one about IE.

Ditto what Martin said -- that is confusing the terminology.  A relative
URI is a syntax construct (one name relative to another name), not a mapping
construct (one location relative to another location).  A URI like

   news:comp.infosystems.www

identifies the newsgroup even though the representation retrieved by
accessing that newsgroup will depend on context (configuration of NNTP
host and the amount of that news feed that has propagated to that host).

....Roy