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

RE: new issue: DAV:displayname

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 17 Aug 2003 22:25:53 +0200
To: "Jason Crawford" <ccjason@us.ibm.com>, "Julian Reschke" <nnjulian.reschke___at___gmx.de@smallcue.com>
Cc: "'Webdav WG'" <nnw3c-dist-auth___at___w3c.org@smallcue.com>
Message-ID: <JIEGINCHMLABHJBIGKBCGEBPIDAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Sunday, August 17, 2003 10:01 PM
> To: Julian Reschke
> Cc: 'Webdav WG'
> Subject: Re: new issue: DAV:displayname
>
>
>
> On Sunday, 08/17/2003 at 01:03 ZE2, "Julian Reschke"
> <nnjulian.reschke___at___gmx.de@smallcue.com> wrote:
> > Hi,
> >
> > looking at our recent discussion, I feel that we clearly have a problem
with
> > the usage of DAV:displayname.
> >
> > The current situation seems to be:
> >
> > 1) Some servers implement DAV:displayname as protected live property
that
> > just reflects the last name segment of the request URI (Microsoft IIS)
> >
> > 2) Other servers implement DAV:displayname as dead property that by
default
> > is not set until it get's explicitly set by a client (Apache moddav)
>
> I tend to agree with you that among these two choices (2) is superior. But
> that seems obvious.  What's more interesting is whether
>
> (3) A server can treat it as a dead property but initialize it to the
segment
> name.

If I understand you correctly the server would set an initial value, and
then treat the property as dead. The result would be that unless a client
resets the DAV:displayname, it will always be the last segment of the
request URL where the resource was initially created (even if it was MOVEd
later). I think that sounds even worse than (1).

> My impression is that (2) is still a better approach.

Yes.

> Are there issues for mapping this to a file system?

Not really. A server that supports setting of dead properties (such as
Apache/moddav) doesn't have any issue. A server that does not support dead
properties on a certain resource will just reject the PROPPATCHH attempt.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 17 August 2003 16:27:03 GMT

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