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

Adv. Coll. items from the 42nd IETF

From: Jim Davis <jdavis@parc.xerox.com>
Date: Mon, 31 Aug 1998 16:16:52 PDT
Message-Id: <>
To: w3c-dist-auth@w3.org
This message summarizes discussions about Advanced Collections Resources
from the 42nd IETF in Chicago.  It includes items from the BOF for Advanced
Collections Protocol and the WebDAV WG meeting itself.  The items are
grouped into three categories:

I. Requirements for references
II. Protocol for references
III Ordered collections.

I solicit the opinions of the list on these points.  When replying, should
you choose to include the body of this message in your reply, please edit
it to have only as little text as necessary to show the context.

I. Requirements for references:

1. Possible Requirement for hiding information.

Steve Cousins suggests possible requirement, that creator of a
reference be able to hide the location of the target.

2. ref. integrity requirement.

Roy Fielding thinks that there should be choice about whether deleting
the target of a direct reference deletes all (direct) references.  

3. Issue: Should access control of references be distinct from those
of target?

4. Issue: Should the owner of a resource should be able to prevent creation of
references to it via ACL?  This would affect requirements for ACL, not ACR.

5. Mike Oliver (Open Text) thinks there might be a need for references that
pass some but not all operations.  This would certainly affect the
requirements.  He will send an example to the list.

6.  Larry Masinter thinks the documents are not clear about whether
references are to resources or to URIs

II. Protocol for references

1. Define new property dav:references which provides backpointers from
a target to all resources that refer to it.  (This was actually first
proposed in email just prior to the meeting, see

  This property would be live on those servers that choose to support
  it, and dead on others.  Even when the property is dead, it is useful
  to provided a well known standard name for this property. 

  Add under "Security considerations"

  Applications should not operate on the references property without
  ensuring either that it is live on the server, or ensuring that only
  trusted applications write this property.  For example, a program
  that tried to enforce referential integrity by deleting references
  to targets that are to be deleted could be tricked into deleting a
  resource that should not be deleted by an attacker who set the
  backpointer on a resource to point to the to-be-deleted resource.

2. Redefine DAV's semantics for MOVE to insert a step between the COPY
and the DELETE.  This inserted step, called UPDATE, updates any
references to the resource, if possible, changing the ref-target
property to reflect the new location.  This is an optional step, the
server is not required to provide it.  The update is not affected by
locks, because reftarget is a live property.

  Issue: moving a directory tree could be expensive (must update many

  Issue: possible security exposure: Suppose resource R, owned by
  principal P is a reference to a target T which was initially in a
  public place but is now moved to a private place that P can't access.
  Does the reftarget on R get updated?  Yes, that doesn't mean P can
  still read T, but P still can see the location of T, which is perhaps
  an exposure.  On the other hand, it's not anything new, since P had to
  know that T existed when the ref was first created.  but it means P
  knows the private location.   

   Solution: owner of target should COPY the resource, then delete the
   old one.

3. Get rid of "passthrough" property, instead, just define a
dav:reftype which can be either dav:direct or dav:indirect.

  Rationale:  passthrough would have allowed client to create
  paradoxical references, e.g. which passed through GET but not HEAD.
  For a useful direct reference, there seems to be only one sensible set
  of values for what should be passed through, and what not, namely

  affect target:
  affect reference:

  except that the returned headers from GET and HEAD include extra
  headers (Ref-Type and Ref-Target) added by the reference itself,
  which thus allow the client to discover that the reference is a

4. Question: Can a direct ref point to a direct ref?  Yes.  All the
Ref-Type and Ref-Target headers are returned.  This is sufficient for
the client to determine where the reference points to.

5. Editorial:  

The protocol document, section 3.1 should say that a direct reference
enables *different* efficiency tradeoffs, not that it is strictly
*better*.  This is because when a direct reference is used, clients (and
proxies) are not aware that two references have the same content, and
hence caching is duplicated.

6. Get rid of DELREF

Since DELETE deletes a reference no matter what type we don't need

III. Ordered collections

1. The LOCK method must also take headers for assigning initial
position in ordering, because LOCK creates (at least temporarily) a
new item in the collection.

2. Change the protocol document to tell clients that they SHOULD NOT
dereference this property.

3. Rename dav:arbitary to dav:custom

 Some feel that the name dav:custom better reflects the meaning of a
 collection that is ordered, but where the ordering is ad-hoc and
 known only to a human.

 It allows for four possible conditions of ordering
   1) not supported on server.  No orderingtype prop
   2) supported, but this collection is not ordered.  dav:unordered
   3) dav:custom
   4) some other URL

4. Question: What was the objection to supporting ORDERPATCH with more
than one argument?
Received on Monday, 31 August 1998 19:16:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC