Current Meeting Report
2.1.12 WWW Distributed Authoring and Versioning (webdav)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
Jim Whitehead <firstname.lastname@example.org>
Applications Area Director(s):
Ned Freed <email@example.com>
Patrik Faltstrom <firstname.lastname@example.org>
Applications Area Advisor:
Patrik Faltstrom <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: Subject of subscribe
Description of Working Group:
The goal of this working group is to define extensions to the Hypertext
Transfer Protocol (HTTP) that enable remote collaborative authoring of
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
* 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
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
* 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
1. A Bindings Protocol, providing a specification of operations
supporting referential containment for WebDAV collections. [Proposed
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.
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,
Goals and Milestones:
|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.|
Request For Comments:
|RFC2291|| ||Requirements for a Distributed Authoring and Versioning
Protocol for the World Wide Web
|RFC2518||PS||HTTP Extensions for Distributed Authoring -- WEBDAV
Current Meeting Report
52 IETF WebDAV meeting notes
Started with agenda bashing...
Agreed the agenda should be:
1) look at the charter and see where we are and if it needs revising.
2) Report from the online interop
3) Look at open issues with 2518
What's the status of deltav...
waiting for RFC editor, perhaps will submit NROFF to try and accelerate.
Will working group close?
Jim A wants it kept open...for interrop discussions, extensions etc
We are behind on property registry, revised RFC2518, ordered collections and bindings...
We need to update all dates in the charter. There may be things we can drop from the charter. Eric - focus our efforts, people not interested in crossing the t's and dotting the i's, feels interop would be improved if we concentrate on webdav, acl and bind. We should prioritize we can't do all at once.
Lisa says she needs help/guidance in editing RFCs. Not enough drafts are moving forward. Might take out of RFC2518 the source property and put into a separate spec. Geoff suggests we should remove stuff that hasn't been implemented, bindings and ordered collections are in the charter but not complete...
A show of hands was taken, 3 people expressed interest in bindings, nobody expressed interest in ordered collections.
Property registry not delivered...silence on email nobody wants a property registry..perhaps this was before namespaces or perhaps it is important but people didn't want to drive this through IETF
Web folders propertys were ones people were interested in.
Do clients really need a registry of properties?
Larry - WebDAV properties and external metadata...Adobe working on it (properties on the wire versus metadata embedded in content).
Discussion of live properties...Eric wants info RFC on live property propogation in versioning. Lisa suggests a draft should be done by Eric.
Last call finished
No known open issues
Peter has some issues/questions he will post to the group ASAP.
Servers exist and the mailing list now has some traffic
Geoff - Change Management will really need DASL
Specification to define Quota limits etc
How does binding effect quota...it is server dependent
Properties on collections.
Teamstream instead of attaching files put links into email and tries to get tickets. Recipient uses the ticket to get the document. No user auth...so must be over a secure channel.
Eric - similar to ACL...why ot put ACL on the resource before emailing
Lisa says this is to support users outside the organization who don't have user accounts. Tickets can be forwarded.
Example is that idrive is being used to share docs....passwords on a document etc.
Password IETF standards should be mandatory to use a secure channel.
SSL to webdav and SMIME in the mail...this should be a MUST.
Successful face to face interop in July.
The virtual event also took place.
We haven't really got reports from attendees of the virtual event so it is harder to figure out what happened.
Larry asked the group what bugs did you find etc?
Lisa - 3 clients tested against Xythos...5/6 issues/bugs found but none with the protocol...digest now being used by clients.
MERANT went well...more than two clients worked. Was more successful that the July interop.
We need to ensure EVERY feature is tested so we propose a feature checklist for future interrop events. As well as requiring some kind of status report from participants.
Late Feb perhaps a good time for another online interrop. With feature checklists and reports.
Every feature tested should be tested against 2 servers. Travel policy may effect ability to have face-2-face so virtual seems like a good choice.
We will only make changes agreed on the mailing list...the open issues discussed were:
Copy error reporting description from deltav to RFC2518
Eric - allow for additional info to come from server... issues regarding XML vs HTML being returned in error responses.
There's no list of codes for 2518...wouldn't want to list them (maybe a separate draft is needed to list error codes)
Geoff suggests it's an appendix to 2518.
Next rev of deltav might remove this stuff after adding to 2518 we don't want it defined in many documents.
A vote was taken and 4 people wanted the error code appendix added, nobody objected.
Use of DAV: as a namespace
Is DAV: a URI in it's own right?
2396 URI syntax disallows just using DAV: at least one char must follow but this depends on the definition of BNF that you use!
Larry - Maybe we should revise 2396.
Validating webdav bodies requires valid namespaces, it checks the validity of the URIs.
So perhaps in 2518 we should make a note that XML processors don't like this.
Adding a slash or something would cause interrop problems.
Another issue with DAV: is that We can't revise the namespace if the URI is just DAV: if we add new props, perhaps we should do something like add a year/month. But we can't change namespace of existing elements, that would break clients.
Eric - Would only do this if really necessary.
Try and fix this when we actually need to.
Geoff - new props can be new namespace but changing old props is troublesome.
Larry - Add a historical note about DAV: URI..say that it's a bad example.
Geoff - says RFC2396 might be interpreted as meaning DAV: IS valid.
Lisa - should new drafts eg Tickets use a new namespace? Group says no.
What 'allprop' means....
MUST include all 2518 props and all dead props to maintain interrop. However new live props in ACL DASL etc are being defined as NOT returned by allprop. Property dead on one server may not be dead on another server. allprop is historical. Promote using propname. Is it legal for Xythos to use the adobe namespace? You could have a property that is defined dead on one server be live on another!
allprop must return all properties required for interrop.
Eric - property should be defined dead or non-nead...you can't mix and match.
Should we deprecate allprop?
Perhaps use allprop-include or other mechanism to save roundtrip and deprecate allprop. Sitecopy properties would not be the same. Is deprecate something we can do in IETF? Take it out and reference them back to the old draft. Geoff - Short description plus reference back to old spec. We took a vote and 3 people would like it to become a info note, nobody objected.
Consensus was to delete paragraph on lock refresh.
Eric - clients seem to be expecting locks to hang around, when they expire it causes problems.
Unlock by non-lock-owner....
Can anyone unlock, can the creator unlock, can anyone with privs can unlock.
ACL privileges could control this...
Lisa - Clients wouldn't know if it's allowed
Geoff/Eric - Lock and Unlock privileges should be standardized.
This should not hold up ACL draft but Lisa will think about adding them
Eric - What about other deltav required privs?
Moving locked resources...
Lisa - Why does move remove locks?
Eric - Because they are locks on URLs/namespaces, you are changing the namespace so you loose the lock.
Renaming a collection looses all locks on collection members!
It's predictable...you are locking URLs. Windows filesystem works this way.
Chris - Add paragraph on namelocking versus object locking.
To test interrop would need to move collections without locks, collections with locks, collections beneath locked collections.
Chris - interrop should be finding all MUST and SHOULD and write tests for them.
Joe Orton has a test suite, perhaps we should add tests to it.
Getting source code...
DAV:source too complex?
Take out of 2518, put in it's own spec if people need it.
Translate only does 1:1
We took a vote and 4 people were in favour of removing DAV:source,
#nobody opposed this.
Translate header works well because it's Microsoft and because most servers have one-2-one mapping...eg they edit JSP but not CGI (eg C code)
Larry - Why not use a proxy that translates the Translate header into a DAV:source request??
Geoffs objection to translate is that it needs defining for all methods not just a few as it is today.
Clients put the translate header on every request if it is working on the source (eg in authoring mode).
Tagged if-list production...
if the header is on resource A but operation is on resource B the if header should be ignored?
Lisas example - I want to delete A only if the lock on B is valid
Was bad to mix lock matching and state matching.
Entity tag (etag) can be used in a tagged if...
Lisa draws an example...
If: <http://foo/mycoll/bar.doc> ([etag-bar] <locktoken-bar>)
There are many issues with the If header, but nobody willing to take ownership.
Perhaps invent a new header and use commas and not spaces so multiple headers can be used. Geoff - sounds like a separate draft.
Poll the list on simplifying the If header...two new headers, one for locking, one for state.
When sending a move you can specify a body saying you want to keep properties alive.
Deltav properties must be kept alive on move but not on copy.
Should keepalive be a property of a property.
Nobody uses it. Give a deadline for implementing/testing it, if nobody uses it then remove from the specification.