W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

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

From: Lisa Dusseault <lisa@xythos.com>
Date: Sat, 24 Nov 2001 22:54:42 -0800
To: <w3c-dist-auth@w3.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKAEJFDBAA.lisa@xythos.com>
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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, November 25, 2001 9:13 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: RFC2518 (WebDAV) / RFC2396 (URI) inconsistency
>
>
> 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:julian.reschke@greenbytes.de]
> Sent: Friday, November 23, 2001 11:28 AM
> To: Jason Crawford
> Cc: w3c-dist-auth@w3.org
> 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:ccjason@us.ibm.com]
> > Sent: Friday, November 23, 2001 5:06 PM
> > To: Julian Reschke
> > Cc: w3c-dist-auth@w3.org
> > 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,   ccjason@us.ibm.com
> >
> >
> >
> >
Received on Sunday, 25 November 2001 13:56:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT