Subject: I-D ACTION:draft-ietf-webdav-acl-07.txt

From: [email-masked]
Date: Tue, 13 Nov 2001 07:09:26 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: WebDAV Access Control Protocol
	Author(s)	: G. Clemm, A. Hopkins, E. Sedlar, J. Whitehead
	Filename	: draft-ietf-webdav-acl-07.txt
	Pages		: 59
	Date		: 12-Nov-01
	
This document specifies a set of methods, headers, and message bodies 
that define Access Control extensions to the WebDAV Distributed 
Authoring Protocol. This protocol permits a client to read and modify 
access control lists that instruct a server whether to allow or deny 
operations upon a resource (such as HTTP method invocations) by a given 
principal.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-acl-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-acl-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 19 Nov 2001 22:32:39 +0100

(copy of post to <mailto:[email-masked]>).

Hi.

(1) RFC2518 (WebDAV) is based on XML + namespaces and has chosen to use the
namespace name "DAV:" to identify it's elements. Note that "DAV:" *is* a
properly registered URI scheme (see [1])

(2) The XML namespaces recommendation says that an XML namespace is
identified by a URI reference as defined in RFC2396.

(3) RFC2396 gives the following grammar for absolute URIs:

absoluteURI   = scheme ":" ( hier_part | opaque_part )
opaque_part   = uric_no_slash *uric

"DAV:" doesn't seem to be a valid "opaque_part", because "opaque_part" MUST
start with "uric_no_slash", thus it may not be empty.

(4) I became aware of this mismatch when trying to develop a RELAG NG schema
for WebDAV. James Clark's JING validator rejects the namespace name "DAV:"
as invalid URI. So this has become a real-world problem (maybe it was "just"
academic before).

I think this means that either RFC2396 or RFC2518 need to be fixed.

Feedback appreciated.

Julian

[1] <http://www.iana.org/assignments/uri-schemes>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 19 Nov 2001 17:51:27 -0800

On Mon, Nov 19, 2001 at 07:17:46PM -0500, Matt Timmermans wrote:
> Wow, that's annoying!
> 
> It seems to me that fixing RFC2396 to allow an empty opaque_part would be
> best, unless someone can recall any rationale for disallowing it in the
> first place.  It looks quite arbitrary.

More arbitrary than defining a new URI scheme *and* using xmlns just to
replace DAV: with D:?  Just choose one, please.  Why on earth would we
want to change the definition of URI in 2396 to allow

   scheme:

to be a valid URI?  It isn't a valid URI.

As you said, RFC 2518 was based on an early draft of XML namespaces, and
it will need to be updated for that in any case (or stop using xmlns).

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 19 Nov 2001 17:54:16 -0800

Just stop using xmlns in the WebDAV examples.  No other changes are
necessary.

....Roy

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 19 Nov 2001 16:43:25 -0800

> I think this means that either RFC2396 or RFC2518 need to be fixed.

As Julian pointed out in an off-list message, it is unlikely for all DAV
applications to change just to add a (in this context) semantically
meaningless "/" or "//" sequence of octets. So, changing RFC 2518 doesn't
seem likely.

On the other hand, Larry Masinter points out in another off-list message
that the DAV URI scheme has rightly been criticized for being a flat
namespace. So, attempts to chance RFC2396 to institutionalize what many
perceive to be a poor design choice, is also likely to not be successful.

Larry Masinter pointed out that adding some language to RFC 2396 pointing
out that the DAV: URI scheme has some known quirks, and should not be
considered as good example, might fly. Whether such text would then cause
tools such as James Clark's JING validator to accept the DAV URI scheme is
unclear.

But, since WebDAV clients and servers are going to keep exchanging DAV:
scheme URIs across the wire for the forseeable future, from my perspective
the easiest change you can make to address your immediate problem, is to
modify the JING validator tool.

Frankly, compared to other items on the WebDAV plate, such as:

* addressing all the items on the RFC 2518 issues list
* finishing the bindings protocol
* finishing DASL
* finishing redirect references

This issue comes in a *very* distant last.

- Jim

---

From: "Matt Timmermans" <[email-masked]>
Date: Mon, 19 Nov 2001 19:17:46 -0500

Wow, that's annoying!

Note that even if IETF changed the DAV namespace, you still couldn't write a
meaningful schema for WebDAV, because schema languages don't recognize the
odd naming convention that RFC2518 adopts in 23.4.2 (Meaning of Qualified
Names).

If anything is going to be done to change the basic XML structure of WebDAV,
it would be a good time to fix 23.4.2 as well.

What I really _don't_ want to see is everyone doing <dp:ropertyupdate
xmlns:dp="DAV:p"> to get conformance to all 3 specs.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Monday, November 19, 2001 4:33 PM
> To: [email-masked]
> Subject: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 09:21:17 +0100

> [mailto:[email-masked]]On Behalf Of Matt Timmermans
> Sent: Tuesday, November 20, 2001 1:18 AM
> To: 'Julian Reschke'; [email-masked]
> Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
>
> Wow, that's annoying!
>

Yes, it does.

> odd naming convention that RFC2518 adopts in 23.4.2 (Meaning of Qualified

That's on the list of known and resolved WebDAV issues. This section is
going to be deleted.

> xmlns:dp="DAV:p"> to get conformance to all 3 specs.

That would be a mess. The only sane position is that the XML namespaces
recommendation processing rules apply.

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 09:35:14 +0100

> [mailto:[email-masked]]On Behalf Of Roy T. Fielding
> Sent: Tuesday, November 20, 2001 2:51 AM
> To: Matt Timmermans
> Cc: 'Julian Reschke'; [email-masked]
> Subject: Re: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
>

With all due respect, I think this shows a misunderstanding of the role of
XML namespaces in WebDAV. There are a lot of reasons for WebDAV to use XML
namespaces - it's not just a syntactic matter whether to write
DAV:multistatus or D:multistatus.

First of all, without namespace declaration, an element named
DAV:multistatus wouldn't be NS-wellformed. In addition,

- WebDAV messages can be extended with "arbitrary" new extension elements,
preferrably from other namespaces (just like other XML applications do),
- WebDAV has a resource property model where a property is identified by the
pair (namespace, element name).

So, having XML namespaces in WebDAV has really nothing to do with the syntax
for the prefix.

Of course I do agree that choosing "DAV:" as namespace name was a bad idea.

> to be a valid URI?  It isn't a valid URI.

(Side remark: good old Microsoft is even using namespace names like "xml:").

Not according to the current grammar, right.

However, if you look at [1] you'll find that although TBL made his comments
about the DAV: URI scheme himself, he didn't catch the greater problem if
not being a URI at all. I think this says something about the *intent* of
RFC2396 :-)

> it will need to be updated for that in any case (or stop using xmlns).

Again, this is on the list of known and resolved issues.

[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0166.html>

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 09:36:07 +0100

> Sent: Tuesday, November 20, 2001 2:54 AM
> To: Jim Whitehead
> Cc: [email-masked]

Sorry, but *not* using XML namespaces would change the XML infoset of the
messages, so we would have a 100% incompatible specification.

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 12:23:42 +0100

> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Tuesday, November 20, 2001 1:43 AM
> To: [email-masked]
> ...

I agree it's the easiest change. But this is just a workaround -- the
problem stays. As long as the grammar for URIs says that "DAV:" isn't a URI,
and the XML namespace REC says that a namespace name must be a syntactically
correct URI reference, then we'll face the problem again -- for instance if
developer's of XML processors decide to do proper namespace name checking.

So this definitvely needs to be put onto the issues list.

Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 20 Nov 2001 10:57:54 -0800

> DAV:multistatus or D:multistatus.

Well, that's the only example I've seen in use.

> DAV:multistatus wouldn't be NS-wellformed. In addition,

Should I take that to mean only namespaces can have ":" in the tag name?
That would explain a lot.

> preferrably from other namespaces (just like other XML applications do),

Yes, but those will presumably be in another (well-formed) namespace.

> pair (namespace, element name).

Isn't it reasonable to have a default namespace in the property model?

> So, having XML namespaces in WebDAV has really nothing to do with the syntax

I didn't say it did.  I said that treating DAV: as both a namespace and a
URI scheme is wrong (and confusing).  The reasons for doing so at the time
were because xmlns was being developed (slowly) at the same time as WebDAV.

> Not according to the current grammar, right.

Then it sounds to me like the xmlns attribute does not contain a URI.
It contains a URI prefix.

> not being a URI at all. I think this says something about the *intent* of

Yeah, it says that we never considered that someone would try to use the
grammar incorrectly within a specification.  We naturally assume that
people want the value to be a URI if they say it contans a URI.

> [1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0166.html>

I don't see that as being resolved, unless the WG is going to bite the
bullet and follow Tim's recommendation.

....Roy

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 20:43:07 +0100

> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 7:58 PM
> To: Julian Reschke
> Cc: Matt Timmermans; [email-masked]; [email-masked]
> ..

No.

Colons in element names are allowed in XML 1.0 ([1]). Otherwise XML
namespaces wouldn't have been possible (in the current syntactic form).
However, if you use a namespace-aware XML processor, there are special rules
once you put the a colon into an element name. These are expressed in the
XML namespaces recommendation.

Using "DAV:elementname" without declaring "DAV" as namespace prefix would
have made WebDAV incompatible with XML + Namespaces. This would be a
desaster, for instance we wouldn't have a defined XML Infoset for WebDAV
messages ([2]).

> Yes, but those will presumably be in another (well-formed) namespace.

Yes. But to do so, the WebDAV message itself (unextended) needs to be
NS-wellformed as well.

> Isn't it reasonable to have a default namespace in the property model?

Yes. That's why RFC2518-defined properties are in the DAV: namespace.

> were because xmlns was being developed (slowly) at the same time

May be. But then both the URI RFC and working drafts of XML namespaces had
been around months earlier, and even the 1998 september version of XMLNS
([3]) speaks about the namespace being an URI. So this *could* have been
noticed back then. The fact that it was only noticed a few days ago IMHO
simply shows that what many people think is a valid URI just isn't true
(according to the grammar).

So maybe the grammar needs to be blamed (and updated).

For instance, RFC2396++ could allow empty schema-specific parts, but the URI
registration process could reject new URI schemes which allow empty
scheme-specific parts.

> It contains a URI prefix.

Well, the XML namespaces recommendation says it's a URI reference. RFC2518
uses "DAV:". RFC2396 says "DAV:" is not a valid URI reference. So the set of
specs (RFC2396, RFC2518, XML/NS) is inconsistent right now.

> > [1]
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0166.html>
>

Tim's recommendation was based on the fact that RFCs shouldn't *invent* URI
schemes without compelling reason. At that point of time there already was a
big number of RFC2518 based code, and "DAV:" already *was* a registered URI
scheme. Back then I was saying to myself: "technically correct, but
impractical to change".

Now the situation is a bit different: using "DAV:" as namespace name is not
only considered "bad practice", it's plain wrong. In a perfect world, the
WebDAV WG could now just pick a better namespace name, everybody would be
updating their servers and clients... But this isn't a perfect world, and I
feel that we need a less intrusive solution.

Regards, Julian

[1] <http://www.w3.org/TR/2000/REC-xml-20001006#sec-common-syn>
[2] <http://www.w3.org/TR/xml-infoset/#intro.namespaces>
[3] <http://www.w3.org/TR/1998/WD-xml-names-19980916>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 20 Nov 2001 13:02:51 -0800

> feel that we need a less intrusive solution.

How is making a normative change to an Internet Draft Standard a less
intrusive change?  I can rewrite all of the W3C's recommendations and
pass them through that process faster than I can change 2396 and all
of the implementations of URI references.  In any case, I wouldn't
change the definition of URI -- at most, the definition of URI-reference
would change, and even then only if it were warranted by implementations
that are believed to be correct.

If the XML namespaces spec is broken, fix it.  If it isn't broken,
then fix WebDAV.  Both of those communities are miniscule in comparison.
What matters to URI is whether or not "DAV:" is believed to be a valid URI
reference, and the fact is that it is not and therefore the standard
for URI references should not be changed.  XML namespaces needs to decide
if the xmlns value is actually a URI-reference or something more like a
URI prefix, and if the latter is true they should update that spec.
Otherwise, WebDAV is broken and must be fixed on its own.  That is the
nature of one immature standard depending on other more mature standards
for its specification.

....Roy

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Nov 2001 22:16:18 +0100

> Sent: Tuesday, November 20, 2001 10:03 PM
> To: Julian Reschke

By relaxing the rules (why does the scheme-specific part have to be
non-empty, besides common sense :-), (almost) nobody would be hurt. We can
still discourage or even forbid *new* URI schemes with empty scheme-specific
parts, but this wouldn't really affect anybody else.

However, changing RFC2518 breaks *all* WebDAV clients and servers.
Immediately.

> If the XML namespaces spec is broken, fix it.  If it isn't broken,

It isn't broken.

> nature of one immature standard depending on other more mature standards

Technically correct. But extremely expensive and likely to be ignored by all
major companies with existing code out there. So I don't think this is
practical.

If you insist that RFC2396 can't change and others insist that XNL
namespaces can't change (I bet there'll be many!), then there are two
possible outcomes:

- The issue is ignored just like it was before. This is now a bit harder now
that it's documented.
- RFC2518++ is changed accordingly, and *all* software would need to be
updated (basically throwing WebDAV back years).

Whose choice is it, actually?

Julian

---

From: Martin Duerst <[email-masked]>
Date: Wed, 21 Nov 2001 09:53:27 +0900

>non-empty, besides common sense :-),

Very much for the reasons that Tim explained in his mails.
An URI scheme is not something you define lightly, just for
a single resource. Of course the restriction on 'at least one
character' is technically very arbitrary, but I'm very sure
that when the syntax was worked out, there was a clear feeling
that having schemes without anything after them didn't make
sense. The 'dav:' thingie is the only case we know so far,
and we know it was a bad idea, so we know that the original
rules were a good idea.

In his mail, Tim didn't talk about the syntax because that's
just a detail. If you don't get the principles right, you don't
have to be surprised if you get the syntax wrong.

>(almost) nobody would be hurt. We can

Well, I guess you should think about how to upgrade WebDAV to make
this a workable update path.

> > If the XML namespaces spec is broken, fix it.  If it isn't broken,

I agree.

>major companies with existing code out there. So I don't think this is

What Roy is saying is that there are much more implementations out there
that work with URIs than there are implementations that work with WebDAV.
This is quite obvious. So he is saying that it's much easier to change
WebDAV than URIs.

There might be some slack here, in that most URI implementations do not
actually check much of the URI syntax, because if they don't include
scheme-specific knowledge (which a generic URI processor shouldn't), there
is very few things that you can actually check. This may be supported
by the fact that this is the first time this issue is comming up.

>updated (basically throwing WebDAV back years).

I suggest that for the short time, you ask James Clark to close an eye
and tweak his implementation, and that for the longer term, you work
on an upgrading strategy for WebDAV. Fixing WebDAV would now actually
get rid of two problems, namely both the problem of unnecessary URI
scheme registration and the problem of not conforming to URI syntax.
So there is all the more motivation for doing it. It does not at all
have to throw back WebDAV by years.

Regards,   Martin.

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 20 Nov 2001 18:29:01 -0800

Let me reconstruct how we got here.

* WebDAV uses the "dav:" URI scheme for the name of XML elements used in
protocol messages, and for the name of properties.

* While the BNF for "dav:" URIs has never been explicitly defined (something
we should do when we revise RFC 2518), if we had, its definition would be as
follows:

davuri = davscheme ":" davvalue
davscheme = "dav"
davvalue = opaque_part

From RFC 2396 we know that the opaque_part is defined as:

That is, the "dav:" URI scheme can be considered a member of the class of
non-hierarchical URIs described on page 12 of RFC 2396. In particular, it
was never the intent that just the string "dav:" would be considered a full
URI. The string "dav:" is a URI scheme name, not a URI. The string "dav:"
plus a string matching the production "opaque_part" is a URI.

* WebDAV marshals "dav:" URIs that are the name of XML elements as a
{namespace} + {opaque_part} pair.  So, for example, "dav:creationdate" is
<D:creationdate xmlns:D="dav:">.

* The XML Namespace recommendation requires that the namespace identifier be
a URI.

* Since "dav:" scheme URIs are members of the class of non-hierarchical
URIs, the only constant part is the URI scheme name itself, "dav:". From the
definition of non-hierarchical URIs given in RFC 2396, ALL non-hierarchical
URIs will share this quality. Since "dav:" is the only constant part, it is
the only part of a "dav:" scheme URI suitable for use as the namespace
identifier.

To summarize:
* The "dav:" URI scheme is perfectly legal according to RFC 2396. Therefore,
no change is needed to RFC 2396.
* It is only the use of the "dav:" URI scheme name as an namespace
identifier that is violating any specification. Either RFC 2518 or the XML
Namespaces specification could be changed to rectify this.

In my opinion, it is natural to want to use the URI scheme name as the XML
namespace identifier.  That is:

<D:getcontentlength xmlns:D="DAV:">

is more natural than:

<D:getcontentlength xmlns:D="http://www.webdav.org/">

Not to mention that it uses fewer bytes on the wire (not a huge
consideration these days, but those bytes add up over millions of daily
users).

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

- Jim

---

From: Martin Duerst <[email-masked]>
Date: Wed, 21 Nov 2001 15:52:01 +0900

At 22:57 01/11/20 -0500, Mark Baker wrote:
>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?

Well, it's not WebDAV's business to mess around with bases for
namespaces. Namespaces don't currently use XML Base, and probably
they won't in the future. There was an extensive discussion of
whether namespace uris could be relative uris, and the conclusion
as far as I remember was that it should be discouraged.

Regards,    Martin.

---

From: "Stefan Eissing" <[email-masked]>
Date: Wed, 21 Nov 2001 10:46:25 +0100

> protocol messages, and for the name of properties.

I try to summarize my knowledge of XML element names, so either
Julian can correct me, or everyone knows what we are talking about:

Unfortunately, the name of XML elements in XML 1.0 ist just the name
of the element as written in the document. So, the name of the elements
in
  <D:creationdate xmlns:D="DAV:"/>
  <x:creationdate xmlns:x="DAV:"/>
is "D:creationdate" and "x:creationdate". These two _names_ are not
equivalent for XML parsers!

In namespace-aware parsers, the name does not change. However such
parsers subdivide a name in two parts: namespace-prefix + localname.
This gives in our example:
    nsprefix        localname
    D               creationdate
    x               creationdate
NS-aware parsers require that each namespace-prefix be defined in
 a namespace declaration (as it is the case in the example). Note
that the names of the elements are still unchanged and they are still
not equivalent!

Now, XML-NS does a trick and defines equivalence for a new thing
called an expanded element type, consisting of localname and the
belonging namespace-URI. This gives in our example:
    localname       namespace-URI
    creationdate    DAV:          (which is no URI, unfortunately)
    creationdate    DAV:
which indeed are equivalent.

Coming back to WebDAV:

It is misleading to say that the name of the property
creationdate in WebDAV is DAV:creationdate. Because when you
serialize it to <D:creationdate xmlns:D="DAV:"/> the name
of the XML element is "D:creationdate".

Another misleading thing is to assume that the localname of
an XML element is appended to the namespace URI. As Julian pointed
out, this is neither defined, nor always possible, since allowed
character sets for XML element names and URIs differ. Example:
<D:prop-A xmlns:D="DAV:"/> would give DAV:prop-A which is not
a valid URI either.

And finally as for Jim's recommendation to XML-NS: requiring XML-NS
to accept DAV: in namespace URIs, means to give up the notion that
the namespace is an URI. Instead the namespace-thingie would be
an unstructured sequence of characters.

//Stefan

---

From: "Stefan Eissing" <[email-masked]>
Date: Wed, 21 Nov 2001 10:56:28 +0100

Correction: my mailer (or someone?) discarded my umlaut A. So
the example below
> <D:prop-A xmlns:D="DAV:"/> would give DAV:prop-A which is not
should be read with two dots above A...

> [mailto:[email-masked]]On Behalf Of Stefan Eissing
> Sent: Wednesday, November 21, 2001 10:46 AM
> To: Jim Whitehead; [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 11:12:15 +0100

> Sent: Wednesday, November 21, 2001 3:29 AM
> To: [email-masked]; [email-masked]

Correct so far.

> <D:creationdate xmlns:D="dav:">.

RFC2518 says *nothing* about URIs in the DAV: URI scheme. RFC2518 itself
never says that an element name or a property "has" a URI.

<D:creationdate xmlns:D="dav:"> must be read according to the specs that
exist, and this means: an XML element with name "D:creationdate", local name
"creationdate" and namespace name "dav:". BTW: this should have been "DAV:",
right?

If you claim that any element or property in WebDAV has a URI, you'd have to
answer:

- do WebDAV element names and properties share the same namespace?
- what are the URIs (identifiers!!!) for: <cd xmlns="http://a/b/" /> and <d
xmlns="http://a/b/c" />?

> * The XML Namespace recommendation requires that the namespace

Correct.

> the only part of a "dav:" scheme URI suitable for use as the namespace

Why would that be? "DAV:deltaV" and "mailto:[email-masked]" are
perfectly valid URIs and therefore useable as namespace names.

> To summarize:
> * The "dav:" URI scheme is perfectly legal according to RFC 2396.

Yes.

> Therefore,

Guess what will be asked to be changed then :-)

> <D:getcontentlength xmlns:D="http://www.webdav.org/">

It's shorter, but it's invalid (according to the XML NS rec), while the
other one is perfectly valid.

> consideration these days, but those bytes add up over millions of daily

OK, let's tell the W3C to use "xhtml:" instead of
"http://www.w3.org/1999/xhtml".

> surprising that a glitch arose in the first use with

I doubt that anybody is going to touch XMLNS, but I'd still be interested
how you come to this conclusion. The issue is not with non-hierarchical
URIs, the issue is that RFC2518 is using "DAV:" as URI where it shouldn't.

> codify existing, interoperable, practice.

*Lack* of interoperability with James Clark's code in JING exactly is the
reason why we have this discussion. I think we should thank him for actually
*using* the grammer in RFC2396 for validation, so this was finally
uncovered.

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Nov 2001 10:06:32 -0800

> > {namespace} + {opaque_part} pair.  So, for example,
> "dav:creationdate" is <D:creationdate xmlns:D="dav:">.
>

Section 18 clearly states that "The property names and XML elements in this
specification are all derived from the base URI DAV: by adding a suffix to
this URI, for example, DAV:creationdate for the 'creationdate' property."

Now, we've had discussion on the WebDAV list to move away from this
position, and more towards the {namespace identifier} + {name} position
embedded within the XML namespace draft. This strikes me as a good thing.

> exist, and this means: an XML element with name "D:creationdate",
> local name "creationdate" and namespace name "dav:". BTW: this should have
> been "DAV:", right?

URI scheme names are case insensitive (see Section 3.1 of RFC 2396). So,
"DAV:" and "dav:" are equivalent.

> If you claim that any element or property in WebDAV has a URI,
> you'd have to answer:
>

Yes.

> - what are the URIs (identifiers!!!) for: <cd xmlns="http://a/b/"
> /> and <d xmlns="http://a/b/c" />?

Following WebDAV concatenation rules:

<cd xmlns="http://a/b/" />  => http://a/b/cd

<d xmlns="http://a/b/c" />  => http://a/b/cd

Again, let me stress that this is what RFC 2518 says, and we have discussed
on the WebDAV list that this is probably not the best path to take going
into the future.

> other one is perfectly valid.

OTOH, I haven't heard a compelling reason why the XML NS rec couldn't be
changed. Certainly this change would have far fewer interoperability
implications, especially since most namespace implementations already allow
just a URI scheme.

> "http://www.w3.org/1999/xhtml".

I have no problem with this.

> reason why we have this discussion. I think we should thank him
> for actually *using* the grammer in RFC2396 for validation, so this
> was finally uncovered.

Frankly, I have found this discussion to be incredibly moot, and of little
value.

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 19:18:30 +0100

> Sent: Wednesday, November 21, 2001 7:07 PM

I admit I missed that because it's under "IANA" considerations :-)

> embedded within the XML namespace draft. This strikes me as a good thing.

The XML namespace recommendation doesn't specify a specific representation.

> "DAV:" and "dav:" are equivalent.

Yes, but XML namespace names are case-sensitive. So <multistatus
xmlns="DAV:"/> and <multistatus xmlns="dav:" /> are different things, and
the latter isn't in the "DAV:" XML namespace (assuming for now that the
notion of "DAV:" XML namespaces exists at all).

> on the WebDAV list that this is probably not the best path to take going

Ok.

> implications, especially since most namespace implementations

I understand why one would prefer to have a "small" change on somebody
else's spec, but from the feedback I've seen so far I don't think it's going
to happen.

> Frankly, I have found this discussion to be incredibly moot, and of little

I don't think it's moot.

Whether you like it or not, RFC2518 as it's published is broken because it
doesn't conform to what to other (earlier and more basic specifications)
say. It's a pity that this wasn't discovered earlier, but ignoring the issue
won't make it go away.

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 21 Nov 2001 21:45:15 +0100

> embedded within the XML namespace draft. This strikes me as a good thing.

I just notice that the ACL spec says:

14	IANA CONSIDERATIONS
This document uses the namespace defined by [RFC2518] for XML elements.  All
other IANA considerations mentioned in [RFC2518] also applicable to WebDAV
ACL.

So maybe this needs to be clarified. We don't want a new spec to normatively
refer to a deprecated section of RFC2518, right?