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

v6: external members

From: Jim Davis <jdavis@parc.xerox.com>
Date: Sat, 24 Jan 1998 14:22:19 PST
Message-Id: <>
To: w3c-dist-auth@w3.org
Like several others, I register my objection to the new treatment of
external members of collections.  

I object to the externalmembers property, and I object to the limitation of
PROPFIND to only returning information about *internal* members of the

In my opinion, if the semantics of PROPFIND with regards to external
members remain as they are, it would be better instead to REMOVE ADDREF,
DELREF, and external members.  The current definition is so weak as to be
useless, and so why clutter WebDAV with it?

In my opinion, the only distinction between internal and external members
of a collection should be that internal members have a URI relative to that
of the collection.

Behavior I would like to see, briefly illustrated:

on server www.foo.com


PUT /c1/lesh.html


PUT /c2/phish.html    ; create internal member of c2

ADDREF /c2            ;create external member of c2
Collection-Member: /c1/lesh.html

ADDREF /c2             ; also create external member of c2 
Collection-Member: http://www.media-lab.mit.edu/nicholas.gif

Depth: 1


There should not be an externalmembers property.  It serves no purpose, and
adds a burden to the server.

It is acceptable to me to simply drop the entire concept of external
members, and it is acceptable to me to adopt the semantics I describe
above.  The current semantics are not acceptable.

Note that the semantics I call for mean that you'd also have to support
PROPFIND and PROPPATCH on external members, e.g. on www.foo.com it would be
okay to do

PROPFIND http://www.media-lab.mit.edu/nicholas.gif
Host: www.foo.com

Lest anyone claim this is hard to do, I can tell you that I have already
implemented it on my prototype WebDAV server.  If you have to support an
arbitrary property store anyway, it's no harder to store properties on URIs
that are non-local to the server.

Received on Saturday, 24 January 1998 17:24:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC