Last Modified: 2003-02-04
When the WebDAV working group was initially formed, it was reacting to experience from circa-1995/96 HTML authoring tools that showed they were unable to meet their user's needs using the facilities of the HTTP protocol. The observed consequences were either postponed introduction of distributed authoring capability, or the addition of nonstandard extensions to the HTTP protocol. These extensions, developed in isolation, are not interoperable. The WebDAV Distributed Authoring Protocol, RFC 2518, addressed these concerns by providing facilities for overwrite prevention (locking), metadata management (properties), and namespace management (copy, move, collections).
Despite their utility, several important capabilities were not supported in the initial Distributed Authoring Protocol. It is a goal to create protocols to support these capabilities:
* Referential Containment (Bindings): The WebDAV Distributed Authoring Protocol has unusual containment semantics where multiple containment is allowed, but not supported by any protocol operations, yet container deletion assumes inclusion containment, deleting the container and its members. Most object management systems provide full support for referential containment, and have delete semantics that only remove the container without affecting contained objects.
* Ordered Collections: Collection contents have a persistently maintained ordering.
* Namespace Redirection (Redirect References): HTTP, via its 301 and 302 responses, supports namespace redirection where a request on one URL is returned to the client with instructions to resubmit the same request to another URL.
* Access Control: Remote management of access permissions on Web resources.
Experience to date with WebDAV properties has suggested that interoperability of these properties would be improved by the creation of a voluntary, central registry of WebDAV properties. Procedures for registering new properties, updating existing property descriptions, and the contents of each registry item need to be detailed.
As with most application layer protocols, implementation and field experience on the WebDAV Distributed Authoring Protocol has highlighted many issues that should be addressed as the protocol is advanced from proposed to draft standard status. Some of these issues will require additional deliberation within the WebDAV working group.
NOT IN SCOPE:
The following items were initially identified as being out of scope for the WebDAV working group, and continue to be such:
* Definition of core attribute sets, beyond those attributes necessary for the implementation of distributed authoring and versioning functionality
* Creation of new authentication schemes
* HTTP server to server communication protocols
* Distributed authoring via protocols other than HTTP and SMTP
* Implementation of functionality by non-origin proxies
The WebDAV working group initially had a goal of supporting remote versioning operations as well. However, when this scope was found to be too broad, the DeltaV working group was formed. As a result, development of a versioning protocol is currently not in scope for WebDAV, though discussions related to compatibility between versioning and remote authoring are still in scope.
The final output of this working group is expected to be these documents:
1. A Bindings Protocol, providing a specification of operations supporting referential containment for WebDAV collections. [Proposed Standard]
2. An Ordered Collections Protocol, providing a specification of operations for manipulating and listing persistent orderings for WebDAV collections.[Proposed Standard]
3. A Redirect References Protocol, providing a specification of operations for remote maintenance of namespace redirections, and the interaction of these redirections with existing HTTP and WebDAV methods. [Proposed Standard]
4. An Access Control Goals document, providing a list of goals the access control protocol should meet, and not meet. [Informational]
5. An Access Control Protocol, providing extensions to WebDAV that allow remote control over the access rights for Web resources. [Proposed Standard]
6. A Property Registry, describing a process for registering WebDAV properties, and the contents of each registry item. [Informational]
7. An updated version of WebDAV Distributed Authoring Protocol that resolves known issues with the protocol. [Draft Standard]
At present, the Binding Protocol and Redirect Reference protocol have both been through a working group last call for comments process, and are very close to completion. The Ordered Colletions protocol has also had significant review, and is also close to completion. The access control, and property registry documents are new work, as is the revision of the WebDAV Distributed Authoring Protocol.
In addition to the IETF Internet-Draft repository (http://www.ietf.org/ID.html), the most recent versions of these documents are accessible via links from the WebDAV Home Page, (http://www.ics.uci.edu/pub/ietf/webdav/), and on WebDAV Resources, (http://www.webdav.org/).
|Done||Revise Access Control Protocol document. Submit as Internet-Draft.|
|Done||Meet at Pittsburgh IETF. Discuss Access Control Goals and Protocol documents. Discuss issues in WebDAV Distributed Authoring Protocol|
|Done||Revise Access Control Protocol document. Submit as Internet Draft.|
|OCT 00||Revise Binding Protocol document, submit as Internet-Draft. Begin working group last call for comments.|
|NOV 00||Revise Access Control Protocol, and Access Control Goals documents. Submit as Internet Draft. Begin working group last call for comments.|
|NOV 00||Revise WebDAV Distributed Authoring Protocol. Submit as Internet-Draft|
|DEC 00||Revise Redirect References Protocol. Begin working group last call for comments.|
|Done||Meet at San Diego IETF. Hold a review of the Access Control Goals and Protocol documents. Discuss comments raised during working group last call for comments. Discuss issues in WebDAV Distributed Authoring Protocol.|
|JAN 01||Revise Access Control Protocol and Goals documents. Submit as Internet Draft. Submit Access Control Protocol to IESG for approval as Proposed Standard. Submit Access Control Goals to IESG for approval as Informational RFC.|
|FEB 01||Submit revised Redirect References protocol as Internet-Draft. Submit to IESG for approval as Proposed Standard.|
|FEB 01||Submit revised Ordered Collections protocol as Internet-Draft. Begin working group last call for comments.|
|MAR 01||Submit initial WebDAV properties registry document as Internet-Draft|
|MAR 01||Submit revised Distributed Authoring Protocol as Internet-Draft.|
|MAR 01||Meet at Minneapolis IETF. Discuss issues in WebDAV Distributed Authoring Protocol, and WebDAV property registry.|
|APR 01||Submit revised Ordered Collections protocol as Internet-Draft. Submit to IESG for approval as a Proposed Standard.|
|MAY 01||Submit revised WebDAV properties registry document as Internet-Draft|
|JUN 01||Submit revised WebDAV properties registry document as Internet-Draft. Submit to IESG for approval as Informational RFC.|
|JUN 01||Submit revised Distributed Authoring Protocol as Internet-Draft. Begin working group last call for comments.|
|AUG 01||Submit revised Distributed Authoring Protocol as Internet-Draft. Submit to IESG for approval as Draft Standard.|
|RFC2291||I||Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web|
|RFC2518||PS||HTTP Extensions for Distributed Authoring -- WEBDAV|
WebDAV Working Group Meeting San Francisco IETF, March 18 Co-Chairs: Lisa Dusseault, Jim Whitehead Notetaker: Jim Whitehead ----------- A meeting of the IETF WebDAV Working Group was held at IETF-56, held in San Francisco. Approximately 25 people attended the meeting over its duration. Lisa Dusseault began by going over the agenda. She noted that DASL discussion was dropped since there were not enough people present to discuss the issues in depth. Lisa then led a discussion of 2518bis. * Discussion of locking issues in 2518bis. Slide "Agreed text so far" - Discussion of the content type of the resource created by a LOCK when the content type doesn't exist. One thought: pick one type. Another choice: do whatever a server does when you send a PUT with no Content-Type header, and a non-empty body. Rough consensus: be silent on the issue (most likely defaulting to what happens when a PUT with no Content-Type header). * Discussion of the definition of a collection. Should we use binding terminology in 2518bis, or keep internal member terminology. Tempest in a teakettle over internal member terminology. In the end, decided to keep using internal member term. * Discussion of "First problem" slide. What should be the behavior on an UNLOCK on an indirectly locked resource (that is, an UNLOCK request issued to any resource in a locked hierarchy other than the one the original LOCK request was issued to)? Should the lock remove the entire depth lock, or should it be redirected, or should it fail? Rough consensus for failure, error code to be determined later. * Discussion of "Second problem" slide. When an If header is submitted against a depth locked resource, must a client use the lockroot URL, or is any URL in the locked tree OK? If the untagged If header's referred to resource is the same as the request URL, will this break any existing clients? One approach is to better identify interoperability failures in lock token handling. Need to make the text in the specification in 2518bis on the If header more clear. No consensus. Lisa will write a message to the mailing list summarizing both sides of the issue, and explicitly solicit feedback from Dan Brotsky, Julian Reschke, and Max Dunn on this, as well as generally from the mailing list. * Discussion of "what is locked" draft. Discussed effect of locks on live properties. Agreement of lock affecting dead properties. Also tentative agreement that a lock should affect all PROPPATCH operations on all properties, live and dead. Briefly noted that locks do not prevent live properties from updating their values (e.g., getcontentlength updating after a PUT -- this is OK, even when the resource is locked). * The "Last Piece" slide. No disagreement. Refined lock-root to "lock root URL" to avoid ambiguity over what "mapping" means. * "Allprop replacement proposal." Agreement in the room that the proposal listed on the slide was fine. Some concern over interoperability implications of adding new XML tag into PROPFIND prop requests to ask for all dead properties. * Discussion on whether there should be an additional 4xx or 5xx status code for multistatus cases. Several viewpoints. Aesthetic: 207 is for complete success, while a 207 can have 4xx inside it, so this is a contradiction. Interoperability: clients may not know how to correctly handle a new 4xx that expresses a multistatus case, or only use the new 4xx for cases where it is OK for the client to treat the entire response as a failure. Functional: some tools may not understand WebDAV, but still come into contact with 207 responses. An example is an HTTP logging tool that might be trying to tally success and failure, and won't properly handle 207. Rough consensus to *not* make any changes to 2518bis. Keep current semantics of 207, do not add new status codes. Main motivation is to not break current implementations, or add a new status code that might cause interoperability problems. * Discussion of entity tags, and support level. Not strong support for moving to SHOULD. Roy Fielding argued that there is already strong motivation for supporting entity tags, since they provide significant caching benefits. But, there is experience that many DAV servers do not support entity tags at all, and hence interoperability might benefit from language in the specification recommending, or giving a SHOULD level requirement on support of entity tags. Some agreement that use of entity tags should be RECOMMENDED (defined in 2119 to be the same strength as SHOULD) on all PUTable resources. Also makes sense to add an implementation note providing rationale for why entity tags are a good thing to implement. ----------- Brian Korver, discussion of Quota specification. Brian began with an overview of the latest draft of the quota specification. Some questions on the semantics of the new properties. Brian mentioned that the definitions were taken from the definition of the NSF quota system. The quota properties are strictly live. Quotas are defined on resources -- there is no mechanism to ask about the quota for a particular user. People who volunteered to read and review the specification. Jim Whitehead, a grad. student of Jim's. Jim stated that the specification is close to WG last call, look for this in a few months, after a few people in the WG have read and provided feedback on the quota specification. ----------- Brief discussion of the ordering specification. Geoff Clemm overviewed recent changes. Jim asked whether there were any objections to moving this to a working group last call. None surfaced. ----------- Geoff Clemm then led discussion on the binding protocol. Geoff began with a brief overview of the binding protocol. Discussion of copy language in the binding specification. No objections on the language in the specification. Some discussion on Copy, Depth infinity case. *** Need to add description of the behavior of Copy, Depth infinity case, since it's not currently covered in the specification. Discussion of delete and bindings. Will take this to the list -- raised the issue. Binding specification is at a point where, if you have issues with the specification, they should be surfaced now. Will work to resolve open issues soon, want to drive specification to closure in the near future. --------- Geoff then led a brief discussion of the ACL protocol. Brief review of IESG feedback on the recent last call. There is a new draft in preparation, and will submit this as an I-D in the near future. Like binding specification, want to quickly move to closure on this. --------- **end of meeting*** ----------------INTERIM MEETING---------------- Monday ------ 1. Datatypes for WebDAV properties The basic idea is that a PROPFIND would provide type information for dead and non-RFC2518 live properties. PROPATCH would similarly allow one to specify data types in conjunction with setting property values. The approach uses the W3C XML schema type library and instance type attribute to indicate types. This has the advantage of using a standard and extensible type library (also used in many other vocabularies). Additional property information to be considered includes: * 'hidden' flag * 'protected' flag * 'display name' attribute Open issues to be resolved: * marshaling of display name * relationship to document types and schema definitions of required property sets Discussion on how best to proceed: initially develop the high-level requirements, then move further discussion to a separate (new) mailing list. 2. ACL discussion led by Lisa Dusseault and Eric Sedlar Lisa Dusseault presented feedback received from the IESG on ACL: * Basic authenticaiont over SSL/TLS is a MUST level requirement * Methods should be mapped to specific permissions (in a table) * Flexibility in te secification is a source of risk. Humans will err and poorly written clients will help them. Eric Sedlar then led further discussion on the spec. The semantics of ordering wrt granting/denying permissions needs to be worked out. Proposal to use the NFSv4 approach. Also need to specify how custom priveleges are expressed. The spec will be clearer and easier to implement correctly if the language is stronger - use MUST level requirements wherever possible. 3. Property registration, Dennis Hamilton There is a recognized need to record authoratative info on properties and namespaces such as where to go (spec., company, etc.) for more detail. There is also a desire to reduce the complexity of the spec as much as possible. The focus of this effort is not machine-readable discovery of properties, but future work may address this. On namespace registration and authority: * Namespaces SHOULD be registered and * namespaces SHOULD be resolvable. * Just anyone should not be able to register a property within a given namespace. 4. DASL discussion led by Julian Reschke. Current issue list: * Error marshaling - proposal to align the sepc with RFC3253 * 'next n' results * type handling in query literals - proposal to add DAV:typed-literal operad carrying xsi:type attribute * language handling for queries on txt props - proposal not to do this * Collation sequence for text comparisons On 'next-n' results: - Currently various DBs do this very differently. Some save state, some redo the query and throw away the first n results. - Next n results is something we want in the spec. - servers should be allowed to generate static results at some URL, but should not be required to do so. DASL type handling: - QSD needs to handle DAV:typed-literal. - Attendees agreed to add DAV:typed-literal and make QSD a MUST level requirement. On language handling: (Summary) - If a user wants a language sensitive comparison, then they should specify that with a language operator. Spec. should be silent on this when discussing other operators. On collation sequence: - Not completely solved by Unicode - In DBs, collation sequence can be set with lang+territory but has impact on performance, and one may need multiple indices. - Java allows a collation to be specified - Intend to use language from XPath/XQery, allowing lang to be passed in and a URL to refer to collation info. Proposal to change name of casesensitive comparison operator to caseinsensitive, which describes the behavior more accurately. No objections from those present. On dates: - DASL spec only supports ISO dates. This is fine. RFC2518 supported other formats, but only for compatibility with RFC2616. Contains operator: The contains operator should work on properties... it is the most frequently used search. To support that we would need to relax wording in the definition of 'contains'. Maybe extending basicsearch is the correct way to accomplish this? Other items: - No conclusions on typing operands vs. typing operators. - Error marshaling will follow RFC3253 approach/definitions. - What does lte mean? can we be more specific in the spec? - Why is the use of "_ _" prohibited in a query? It shouldn't be a problem to implement. The like syntax should conform to SQL'92 definition. - Ordering on mixed-content is undefined. Action item: Julian will be submitting another draft of the DASL spec. Tuesday - RFC2518 bis issues ---------------------------- 1) If header - Model needs to be fixed, so that servers behave more similarly - New syntax may not be necessary -- may be workaround. - Concern that the workaround "If (<locktoken> [and] NOT <locktoken>)" will not work because of poorly implemented servers - Clients still want ability to send a PUT with a lock token, and if the lock token is now gone, the request should not fail. - Jim proposed an "aggregate of locks" token, semantically the same as Lisa's proposal to do "Locktokens-provided" header (non-conditional) - Action item: Julian will research whether the workaround actually can be used with deployed servers. 2) Requiring support for strong ETags - ETags are absolutely needed to prevent the lost-update problem. - WebDAV gateways (exposing a repository using WebDAV) can't easily support strong ETags. - "Last one wins" behavior is what happens without strong ETags, but that seems to be what users expect anyway. - Servers MUST return Not Found on the getetag property if they don't support ETags properly. Servers MUST NOT return empty or constant ETag values. - Require Strong ETags on static resources supporting PUT, and must be returned on GET 3) Compliance testing - Some desire for more formal compliance testing suite - Litmus could be refined and publicized 4) Clients forcing authentication - Servers don't send authentication challenge until authentication fails on an operation (sometimes not until client has already sent credentials) - Clients can't authenticate until they see the challenge - Clients need to authenticate to do a PROPFIND and see all resources that user has permission to see, rather than only see publicly readable resources - Will put Force-Challenge header in RFC2518bis - To solve other unauthenticated problems like PUT: Add information to rfc2518 bis about how to use Expect header and how it must be supported by servers 5) Walk through issues in http://www.webdav.org/wg/rfcdev/issues.htm - CONSISTENCY: Note in 2518bis that all children of a WebDAV collection are WebDAV resources. However, the parent of a WebDAV resource may not be a WebDAV resource. - IMPLIED_LWS: will note in 2518bis that the rules in 2616 *do* apply - PUT_AND_INTERMEDIATE_COLLECTIONS: resolved "won't fix" - OVERWRITE_DELETE_ALL_TOO_STRONG: Needs more research - XML_LANG_CLARIFY: add notes to properties in 2518 which support language. - 302_AND_MULTISTATUS: Julian will make specific syntax recommendation - MKCOL_AND_302: Add note reminding that any method can respond 302 - WHEN_TO_MULTISTATUS_FOR_DELETE_*: No need to change spec. ATTENDEES Peter Tran, Ilya Kirnos, Julian Reschke, Stefan Eissing, Elias Sinderson , Raghu Pai, Jim Whitehead, Lisa Dusseault, Dennis Hamilton, Eric Sedlar, Chris Knight - NASA Ames Research Center, Guozheng Ge, Brian Korver, Jenessa Lin, Kai Pan, Tracy La, Andrew Sieja, Greg Stein, Jim Luther, Ryan Parks