Notes from WebDAV Collections Breakout Session

Here are my notes from the Collections Breakout Session at the Orlando IETF:

The breakout session on advanced collections discussed several issues
related to referencing: (1) whether we need to provide backpointers from
target resources to the references that point to them, (2) whether we should
reconsider our earlier decision to exclude referential integrity from our
scope, (3) how to allow clients to operate on references as well as on their
targets, (4) whether we really need both direct and redirect references, (5)
whether to drop a requirement to be able to hide the location of a target
resource, and (6) the relationship between the versioning spec and
referencing.

Attending:
 
Jim Whitehead (University of California / Irvine)
Judy Slein (Xerox)
Ken Coar (IBM, Apache)
Manoj Kasichainula (IBM, Apache)
Geoff Clemm (Rational - ClearCase)
Yuri Demchenko (TERENA)

BACKPOINTERS

There has been a lot of controversy about whether to expose in the protocol
a property (DAV:references) that lists the references to a given resource.
An alternative is to perform a DASL search for resources that have
DAV:reftarget equal to the URI of the resource in question.  (Since
DAV:reftarget is a structured property, this strategy is only possible if
DASL includes search on structured properties.)

Performance considerations are not decisive between the two strategies.
Search could be efficient.  This particular query could be optimized to
examine a property (not exposed through the protocol).  A DAV:references
property might be implemented as a list, or might be computed on the fly by
scanning the file system.

Clients need to know whether the search will be optimized before they
request the search.  There is no way to find out.  DASL does include a
mechanism for clients to limit the resources a server spends on a given
query.

Clients need to know whether the property is computed on the fly before
requesting it.  There is no way to find out.  The impact of computing on the
fly is especially significant when a client requests allprop.  There may be
other properties that are computed on the fly as well.  DAV:getetag is
computed, and some versioning history properties may also be computed.

We could include an implementation note for clients, warning them not to
assume that examining DAV:references will be more efficient that searching
on DAV:reftarget.
 
We could include an implementation note for servers, warning them to use
computed properties with care, because of their potential impact on allprop.
Servers that are built on file systems may be unable to provide
backpointers.  In a Unix environment, if references are aliases it is easy
to discover the references to a given resource; but if references are
symbolic links it is difficult or impossible.  Servers that are based on
file systems are unlikely to implement backpointers.

From a client's point of view, since many servers will not provide
backpointers, only advanced clients will take advantage of them. Clients
that are tailored for use with document management systems are the most
likely to make use of backpointers.
  
DAV:references includes both direct and redirect references to the target
resource.
 
Systems that provide strong references (e.g., systems that provide versioned
collections) use backpointers internally to keep DAV:reftargets up to date.
Users do want to be able to find out which versions and collections ever
contained this resource.
  
Versioned collections need backpointers.  If backpointers are not provided
in the collections protocol spec, the versioning spec will extend the
semantics of some sort of reference to get this functionality.
 
Conclusion: The attendees favor a DAV:references property, optional at the
resource level.  There should be an implementation note addressed to
servers: Be cautious about implementing DAV:references as a computed
property, because of the possible impact of computation on allprop.  Be
clear about the semantics of DAV:references: when it gets created, deleted,
and updated.  If servers do implement backpointers, we want them to use the
same name for the property, and the same semantics.

STRONG REFERENCES
 
Geoff Clemm is interested in reopening the issue of strong references.  He
believes that support for strong references may not require much more than
backpointers. He believes that strong references will be important for
versioning / configuration management systems.  If the collections spec does
not provide strong references, the versioning spec may have to.

Geoff will send a mailnote on this subject at least to the attendees of this
meeting.
  
We need to try to recreate and capture for the record the considerations
that led to ruling strong references out of scope in the first place.

RE-DIRECT VS. NO-PASSTHROUGH HEADER

The new Re-Direct header applies only to direct references, and makes them
behave like redirect references just for the request that includes the
Redirect header.  It asks the server to apply the request to the reference
itself, rather than to its target.

Jim Whitehead suggests that we really need a header like this for both
redirect and direct references.

At the moment the collections spec requires servers to respond to HTTP
requests on redirect references with a 302.  This makes it possible for
plain HTTP clients to take advantage of redirect references.  In fact, we
should require servers to respond with a 302 to WebDAV requests as well as
to HTTP requests, so that non-referencing WebDAV clients can take advantage
of redirect references.   Once we have made this change, there is no way to
operate on the redirect reference itself.
  
So we need a header that can be applied to both redirect and direct
references, asking the server to apply the request to the reference itself,
not to its target.  Let's call it No-Passthrough.  The more common case is
for the client to want the request to be applied to the target.  So the
header will just be used for the less common case.

REDIRECT + DIRECT

Judy Slein asked whether we really need both redirect and direct references.
They started out being very different from each other.  In the first draft,
redirect references were just resources with no content and a DAV:reftarget
property that a client could retrieve to locate the target resource, and
then perform operations on that resource.   But over time redirect and
direct references have become more similar.  First the semantics of redirect
references changed to accommodate plain HTTP clients: responses to HTTP
requests got a 302 response accompanied by the DAV:reftarget property in the
Location header.  Now if we take Jim Whitehead's advice, all requests on
redirect references will use this semantics, so that non-referencing WebDAV
clients can be accommodated.  For both direct and redirect references, if
the client wants to operate on the reference itself, it must use the
No-Passthrough header.  At this point, is the distinction between redirect
and direct references significant?

There is still an important difference in the difficulty of the server
implementation.  We need redirect references for cases where the target is
on a different server from the reference.  Direct references could not work
across servers unless the server had proxy capabilities or used some
server-to-server protocol.
 
We might want to let direct references respond with 302 if the target is on
a different server.

The direct / redirect distinction mirrors Apache's internal / external
redirects.  Both are useful.
 
We may want redirect references to allow clients to update their tables. 
Conclusion: We need both redirect and direct references.
  
DELETE, MOVE, AND COPY

Delete and move are special cases.  They always get applied to the
reference, not to its target.  Why?
 
They amount to editing the collection containing the reference, not the
object being referenced.   In some systems performing a delete or a move
only requires a permission on the directory, not on the object.  This is a
common semantics.  It is Unix semantics.

MOVE: We need to define the semantics for what happens to the backpointers
when a reference gets moved.
 
What about MOVE requests from non-referencing clients?  Should these
requests ever result in the target being moved?  Would you ever want to do
move with pass-through?  In many systems it would be literally wrong to do a
move with pass-through semantics.  We don't want other references to the
target to get broken.  We should not allow a pass-through move.
 
Conclusion: Stay with the status quo - DELETE, MOVE, and COPY are always
applied to the reference, never to its target.
 
HIDING THE TARGET
 
The requirement to be able to hide the location of a target resource was
motivated by a scenario.  Sue has a collection full of highly confidential
information.  She doesn't want anyone to know about it.  But she needs to
give Tom access to one resource in the collection to get his comments on it.
So she would like to create a reference to it for him, but prevent him from
knowing the location where it and all the other confidential resources
reside.
  
Another motivation: Tilde-name directories provide point of attack by
revealing a user name.

This is "security through obscurity."  Security through obscurity is rarely
the right answer.
  
Don't keep things in directory structures that reveal information you want
to hide.

If we have access control, we don't need this.  We would need access control
on properties, so that we could prevent clients from seeing DAV:reftarget.  
In any case, this is not very important.  The security exposure is limited. 
We can add this capability later if it really looks as if people want it.
Wait and see whether people implement it with properties.

Add a discussion of the risk to security considerations rather than add a
header.
  
Conclusion: Drop the requirement that it be possible to hide the location of
a target resource.

VERSIONING AND REFERENCES

Versioning of collections is being implemented on top of referencing.

Judy Slein requests that before extensions to referencing capabilities are
put into the versioning spec, the team consider whether they would be more
generally useful.  If so, they should be added to the collections
(referencing) spec instead.

Do we need to extend the syntax of DAV:reftarget, to allow it to contain
more than just a URL?  Versioning may need it to include the URL of a
version graph, together with information about which member of the graph to
select.
 
We may want to make the syntax of DAV:reftarget extensible by using
attribute-value pairs. The Ref-Target header would also have to become more
flexible, and might need to be incorporated in an xml body.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Wednesday, 6 January 1999 10:52:41 UTC