- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Thu, 6 Feb 1997 18:20:30 -0800
- To: w3c-dist-auth@w3.org
- Cc: ejw@ics.uci.edu
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