W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: response to comment ...

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 5 Mar 2003 09:38:17 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEICGKAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Wednesday, March 05, 2003 3:39 AM
> To: Webdav WG
> Subject: FW: response to comment ...
>
>
>
>
>
> > From: "Julian Reschke" <julian.reschke@gmx.de>
> > Date: Tue Mar 4, 2003  1:17:18  PM US/Pacific
> > Subject: RE: bind draft issues
> [snip]
> > Yes. Clearly they aren't. RFC2518 never talked about "URL properties".
> > DAV:displayname is a property of the resource, and therefore it must
> be
> > independant of the URL through which the property is accessed.
> >
> > BTW: I'm not aware of implementations that actually support multiple
> > bindings and show this behaviour.
>
> Here's an example.  WFS used to support bindings, but we pulled them out
> because they were hard to maintain and nobody was using them, and the
> standard wasn't going anywhere at the time.
>
> Now, as then, WFS sets the display name to be the base name from the
> path part of the URL.  So for us resourcename is a property which is
> constant as long as the resource's URL is constant, and changes when the
> URL changes.  I don't know if we'd change this if we did support
> bindings.

Well, I consider this a bug. It's not supported by the spec.

> I have some vague memory that some Microsoft WebDAV client expects the
> resourcename to change to be equivalent to the last path segment of the
> URL, and that client behaves badly if that's not true.  However, I'm
> afraid I can't substantiate this as I've forgotten all the details.
> Does that ring a bell for anybody else?

The Webfolder client indeed displays the displayname instead of the last URI
segment when present (and even uses in in the "href" column instead of the
real URI). This works well when

- the last part of the displayname consistently is identical to the last URI
segment (mod. URI escaping) (IIS)
- DAV:displayname is just a dead property that most of the time isn't set
(moddav)

The easiest fix is not to return a DAV:displayname when there is no specific
one. Apache/moddav shows that this works, and I'm not aware of any Microsoft
client failing in this case.

If we consider this an interop problem, we should deprecate DAV:displayname
(because that's the only way to "fix" the webfolder client) and come up with
a new property with the same semantics.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 5 March 2003 03:38:28 GMT

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