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

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 25 Nov 2001 12:12:48 -0500

Clearly a situation of trying to pick the least bad alternative ...

I also agree that Julian's alternative appears to be the least bad.
There is no "error" in any of the underlying specs (URI, XML
namespace) that would support requesting a change.

Declaring WebDAV processing to be incompatible with URI or XML
namespaces would be worse.

For Julian's issues, it would be up to the server to pick a NS if the
client request does indicate that the client understands the new NS,
but the conservative thing to do would be to use the DAV: namespace.
The other issue is not really an issue, but rather a point that would
need to be made in the revised spec.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Friday, November 23, 2001 11:28 AM
To: Jason Crawford
Cc: [email-masked]
Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency

Thanks, Jason.

We'd probably need to cover some more issues:

- how does a server decide which NS to use in a reply if the request didn't
contain a body (PROPFIND for instance),
- clarification, that <foo xmlns="DAV:"/> and <foo xmlns="newuri..." /> map
to *identical* properties,
- and probably some more details...

Julian

> -----Original Message-----
> From: Jason Crawford [mailto:[email-masked]]
> Sent: Friday, November 23, 2001 5:06 PM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
>
>
> I think Julian is right.
>
> The specs conflict.
> It  sounds like the other specs are not going to change.  At least not
> 2396.
> It does sound like some of us feel that what 2518 specifies isn't really
> what should have been specified.
>
> I'll support the suggestion that
>
> 1) We pick a second URI for our namespace.  I'll suggest
> http://webdav.org/base.
> 2) We update the spec to use this new URI in the examples.
> 3) We deprecate  DAV: as the namespace URI in the spec.
> 4) ASAP implementors start accepting the new URI in addition to DAV:
> 5) Later implementors can start transmitting the new URI.
>
> J.
>
> ------------------------------------------
> Phone: 914-784-7569,   [email-masked]
>
>
>
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 24 Nov 2001 22:54:42 -0800

The pragmatic arguments: I don't think it's really feasible to change the
bits on the wire now.  Obviously, it hasn't been a problem in the past, and
it hasn't harmed interoperability.  I've never heard of XML parsers that
object to that namespace, and I'm not clear why the single tool that does
object to that namespace is required for DAV servers/clients.

Changing the namespace DAV uses in all its bodies would be a tremendous
change -- and I don't see what the need is for such a major change.

Besides, even if we tried to "fix" RFC2518 on this issue, that's not the
only place where it crops up.  I know of other namespaces used in shipped
software products where the namespaces look like a string of characters
ending in ':'.   Changing the "DAV:" prefix won't fix those, whereas a
loosening of either the XML namespaces requirements or the URI requirements
would.

The theoretical argument I haven't heard yet:  If the definition of this
type of URI is "<scheme>:<scheme-specific-part>", why can't the
scheme-specific part string be the null string -- as long as that's legal
for the declared scheme?

lisa

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Sunday, November 25, 2001 9:13 AM
> To: [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 25 Nov 2001 23:20:48 +0100

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, November 25, 2001 7:55 AM
> To: [email-masked]
> bits on the wire now.  Obviously, it hasn't been a problem in the

We can't change them now, but we can define a migration path to a format
that conforms to the underlying specs.

> past, and

It isn't.

But it *is* an example of a newly written piece of code that rejects the
namespace name, and we have found out that it's correct in doing that. So we
have to consider the fact that this may apply to newly written XML
processors as well.

> change -- and I don't see what the need is for such a major change.

Because the standard as it's written today isn't well-defined? It says that
you must use an XML-NS aware processor to parse the bodies, yet the bodies
as defined by the spec do not conform to XML 1.0 (+ namespaces).

> ending in ':'.   Changing the "DAV:" prefix won't fix those, whereas a

Well. Obviously these need to be fixed as well.

> scheme-specific part string be the null string -- as long as that's legal

I was wondering about this as well.

Fact is the grammar doesn't allow it, and it doesn't seem that anybody is
going to touch RFC2396 "just" for WebDAV.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 26 Nov 2001 09:06:43 +0100

It isn't.

Julian