Open Issues

At present, one of the primary activities before this group is the review
and refinement of the draft WebDAV protocol specification.  To provide a
framework for this discussion, I have developed a list of current open
issues.  If you feel I have omitted an issue, or prefer a different
ordering/wording of an issue, please let me know.

I have also provided a short description of each issue, which in many cases
does not convey the full complexity of the issue involved.  This short
description is intended to recall the issue, not trivialize it, or
exhaustively describe it.  It is my hope that follow-on posts will
flesh-out these issues, and lead discussion which will resolve them.  In
some cases, there has been recent discussion on the list about an issue,
which is referenced at the end of the issue.

- Jim


CLIENT/SERVER FUNCTIONALITY SPLIT

1. Simple client/server adapts to client or Complex client adapts to
server.  In any client/server system there is a question about where to
assign functionality: to the client, or to the server.  The design team
assumed a model where a more complex client would adapt to the underlying
server.  Participants at the Irvine meeting expressed a desire for a model
where there was a simple client with servers adapting to the interface
model which makes simple clients possible. (Ref: WEBDAV strategy questions
(from Irvine))

PACKAGING

1. Request parameters.  At present, the WebDAV specification specifies
several new methods, most of which take request parameters.  How should
these parameters be packaged?  (Ref: app/foo, app/fooresult thread).

2. Response data.  At present, the WebDAV specification packages all
response data (which are basically attribute-value pairs) into a Web
Collection.  The view of attendees at the Irvine meeting was that Web
Collections had technical flaws, and should not be used in the WebDAV
specification.  Since the Irvine meeting, there has been significant work
on Web Collections (currently under review at the W3C).  Should response
data be packaged into a Web Collection?  If not, how should response
information be packaged?

3. In HTTP/On HTTP.  Are the capabilities of WebDAV orthogonal to HTTP,
with HTTP providing simply a convenient protocol to map to?  Or is WebDAV
interwoven into HTTP?  The answer to this question may affect packaging
decisions, and may affect the choice of methods.  It also has scope
implications.  (Ref: WEBDAV strategy questions (from Irvine))


LINKS

(Section 3 of WebDAV specification).

1. Link model extensibility.  An issue raised at the Irvine meeting was the
need to be able to extend the LINK request body so that the creation,
manipulation, and deletion of HTTP/1.1 style links can be supported.

2. Link hosting.  The design team assumed that a link should have either
its source URI or its destination URI be the URI of the resource providing
storage for the link.  However, this does not support annotation
applications.  The specification needs to be changed to allow a resource to
store a link which does not begin or end on that resource.

3. Name space administration.  By having a typed link model, WebDAV creates
a type name space.  Who should administer this name space?  Should it be a
single authority (like IANA), or should it be distributed (like PICS)?


DAV SCHEMA LINKS

(Section 4 of WebDAV specification.)

1. Source link.  Due to editing error, a predefined link on a resource,
called (DAV.Source), whose destination can be retrieved to get the resource
without processing by the server, was omitted.  This model doesn't cover
access to resources which may have multiple sources, or which may have more
than one processing stage between a source and the destination resource.
Is this model good enough, or does it need to be extended to cover more
source access cases?  This issue may affect the semantics of copy/move.


LOCKING

(Section 6 of WebDAV specification.)

1. Lock types.  What types of locking should be supported by WebDAV?  The
requirements list three types of locks (write, read, no-modify), while the
current specification only allows exclusive write locks, since it greatly
simplifies the specification.  Should the lock specification syntax be
easily extended to support other lock types?

2. Sub-resource locking.  How should ranges within a resource be specified?
Currently, the draft has created a new range specification syntax.  Is the
HTTP/1.1 range syntax usable here?  Are ranges other than byte ranges
useful?

3. Lock time-outs.  Currently the specification provides for a watchdog
timer style timeout on a lock: if no activity takes place on a resource
within N seconds, the lock expires.  Should lock time-outs be provided at
all?  If so, how should they be reset?  What time granularity should they
have?

4. Lock owners.  It is often useful for a user to have contact information
about the owner of a lock, so they can contact the lock owner to coordinate
their activity.  However, since WebDAV does not prescribe an authorization
model, there is no standard user name which can be stored.  How should
optional, supplemental lock ownership information be specified?

5. Lock token uniqueness.  A lock token's bound of uniqueness was raised at
the Irvine meeting.  The present view is that a lock token should be
globally unique.  Should this be relaxed?

6. Locking replicated resources.  What are the implications on the locking
interface for locking a resource which is replicated?


NAME SPACE MANIPULATION

(Section 7 of WebDAV specification.)

1. Semantics of copy and move.  At the Irvine meeting there was a detailed
discussion of whether a copy (move) is an octet for octet copy (move), a
manipulation of the namespace, or both.  One suggestions was to have a copy
(move) be an octet for octet copy (move) of the source of a resource.

2. Link behavior on copy/move.  At present, a copy/move will attempt to
keep links with the resource across a copy/move.  However, since predefined
links may vary across a namespace, the links on a source may vary from
links on the destination.  What should the specification say/proscribe
about link properties across a copy/move?

3. Copyhead/Movehead.  These methods were proposed to give a client the
means to discover, prior to performing a copy or a move, what is likely to
happen when the copy/move is performed.  At the Irvine meeting, a counter
model of "the client requests an operation, then discovers from the
response and from querying the state of the server what occurred."  While
this model is currently supported by copy and move, the issue remains
whether this model is sufficient, or needs to be augmented with copyhead
and movehead (and if these methods are kept, what should they be called?)

4. Undelete/Destroy.  Some versioning systems offer the ability to perform
an undelete.  Should DAV expose this capability via an Undelete method?  If
yes, what exactly should be the semantics of undelete?  If a delete can be
undone, there is a need for a method which can *really* delete, without the
capability to be undeleted.  Should DAV provide such capability?


HIERARCHICAL COLLECTIONS (HC)

(Section 8 of WebDAV specification.)

A hierarchical collection is used to model directory trees, and the
hierarchical ordering of resources found in document management systems.

1. Return syntax of a HC.  Specified by the design team using the Web
Collection syntax, then unfortunately omitted from the specification, this
is how a request for a listing of the contents of, for example, an
operating system directory would be packaged.  Should a Web Collection be
used?  What other syntax should be used?

2. How to get a listing of a URL hierarchy level.  The design team felt
that the contents of a directory could be retrieved by following a
predefined link on any URL which maps to a directory, and the contents of
the destination of that link would be a directory listing (e.g. the same
information as a Unix ls -l).  Another alternative is a method, such as
INDEX.  Which is preferred?

3. Add/remove symbolic link.  Many operating systems support the notion of
a symbolic link (a.k.a alias).  Should DAV provide the ability to
manipulate symbolic links? Currently the specification has methods called
ADDRESOURCE and REMOVERESOURCE which perform symbolic link manipulation.

4. Semantics of methods as applied to collections.  Currently the
specification is silent on the semantics of applying method invocations to
HCs.  The header "propagate level" can be used to specify the number of
hierarchy levels a method invocation should be propagated downward in URL
namespaces which have a tree-like structure.  What does it mean to perform
a lock, copy, move, checkout, etc.  on an HC?  Should propagation be
limited just to copy/move?


VERSIONING

(Section 9 of WebDAV specification.)

1. Versioning behavior to accomodate.  In the current WebDAV specification,
the interface for check-out can accomodate the versioning styles of many
existing systems (we used as champion systems: RCS, CVS, SCCS, ClearCase,
Continuus, MKS, Virtual Source Safe).  These systems differ in whether they
perform locking, and when they assign version identifiers.  The
characteristics of each versioning system afford different types of
behavior.  Should the WebDAV specification accomodate several different
versioning styles, or should it specify just a single versioning style
(e.g. the RCS style).  This may impact capability discovery.

2. History graph & replication.  At the Irvine meeting it was pointed out
that the design team had assumed the history graph would be under the
control of a single server, and that this assumption does not hold if the
back end data repository is replicated.  As a result, the version history
graph data model needs modification.  What should the new version history
graph data model be?

3. DefaultPublishedVersion.  Currently, each resource in a version tree has
a predefined link which, if followed, leads to the default version of the
version tree.  This is the resource which a client will receive if it
performs a GET on the version tree handle.  Several issues: should there be
just one default published version?  Or many?  Is it OK to have a implicit
redirection like this?  On which resources should the Default Published
Version link be located?  (Ref. DAV.Versioning.DefaultPublished).

4. Uncheckout.  Discussed by the design team, but never written down in the
specification is an uncheckout method, which provides a way to undo a
checkout without affecting the state of the version tree (as would be the
case with a check-in).  Should the DAV specification have such a method?

5. Freeze.  This proposed method requests the server to freeze the version
tree in the current state.  This is functionality provided by some
versioning systems.  Should DAV expose this functionality through its
interface?

6. Predefined links.  What predefined links, if any, should there be on the
version tree root(s)? Resources in the version tree?  Having predefined
links on members of the version tree prevent these resources from being
easily included in other history trees.

7. Versioning data model.  The versioning data model needs to be changed to
reflect the possibility that a server back-end repository might be
replicated.

8. Server side merge/diff.  There are currently methods in the
specification for server-side merge and diff operations.  What are the
semantics of a diff/merge (and should the DAV spec. define them?)


CAPABILITY DISCOVERY

(Section 2 of WebDAV specification.)

1. What level of support.  At the Irvine meeting, many participants
expressed the opinion that the capability discovery mechanism in the
specification is too powerful, and that WebDAV should ideally not need this
kind of capability.  Others stated that perhaps PEP could be used for this.
What level of capability discovery support should be provided in WebDAV?

Received on Thursday, 6 February 1997 21:23:05 UTC