The WEBDAV Working Group held a meeting at the 38th IETF, in Memphis, TN, on April 7, 1997. There were 49 people in attendance throughout the duration of the meeting. The meeting was chaired by Jim Whitehead, and minutes were collected by Del Jensen. These minutes are reported by Jim Whitehead due to the unavailability of Del Jensen for medical reasons.
The meeting began with a poll of the audience to determine how many people in attendance were familiar with the WEBDAV WG. Since approximately on third of those in attendance were being exposed to WEBDAV for the first time, the session began with a brief overview presentation on WEBDAV. This presentation was followed by a discussion, led by Judith Slein, on open issues in the requirements document.
During these first two presentations, questions were asked about the scope of the WG's activities with respect to security, authentication, and access control. The stated response, that WEBDAV was planning on using existing security and authentication schemes, but was not planning on implementing new schemes specifically for WEBDAV, met with some scepticism. Several parties expressed the opinion that distributed authoring in absence of good security, authentication, and access control was potentially dangerous, creating a hackers paradise. Another participant stated that expressing the WEBDAV requirements for security, authentication and access control was a necessary first step, even if the WEBDAV WG does end up using existing schemes for this functionality. One participant urged caution when considering these issues, stating that they were very complex (a.k.a. "pits of infinite depth"), while another viewed authentication and access control as server configuration issues, and hence out of scope for the WG. At the end of the discussion, Judith Slein took an action item to bring up a thread on the discussion about security, authentication, and access control.
Jim Whitehead next gave a presentation of several topics and preliminary proposals for their implementation, which were discussed in the Design Team meeting of April 1-4, 1997, held at U.C. Irvine, specifically locking, metadata, versioning, and partial write. Discussion of locking centered on a description of the characteristics of a proposed lock method, which can be used to provide two types of lock semantics: an exclusive write lock, where only the principal who owns the lock may modify the state of the resource (body and metadata), and a shared write lock, where only the principal(s) who own/share the lock may modify the state of the resource. There was some discussion about whether it should be possible to lock a deleted or non-existent resource in order to avoid a race condition between creating a resource (reserving its name) and then taking out a lock on the resource. This led to the need to define a new requirement to make it possible to reserve a name in the namespace controlled by a server.
Also discussed during locking was whether the proposed locking interface was sufficient for specifying a lock for replicated systems which employ a golden copy replication system. While no counter examples were found by the participants, one asked about non-golden copy systems. This raised the issue of whether locking capability should be a SHOULD requirement, rather than a MUST requirement, since non-golden copy replicated storage systems cannot implement a lock as defined.
Metadata facilities were described in terms of a "mixed" model, where small chunk metadata is expressed using attribute-value pairs stored with a resource, using new methods GETMETA, PUTMETA, DELMETA, and large chunk metadata is expressed using a link on the described resource which points to another resource which contains the metadata description. Referential integrity can be assured for small chunk metadata, but cannot be assured in the general case for large chunk metadata.
A proposal for versioning was introduced where instead of using special checkout and checkin methods, versioning would be performed using the lock, unlock, and a new "save" method which would update the predecessor and successor relationships and store an updated resource. A poll of participants found that they did not understand the new proposal well enough to tell whether it would work.
The old patch method was resurrected in the proposal for partial write capability which was presented. The notion of patch is that the body of the method request contains instructions for how to update the resource specified by the request URI. It was recommended that multipart/byte-ranges be used as the default update instruction format which must be supported in the patch method is supported. This choice was viewed as strange by some participants. Other update formats suggested were VTML and Unix diff.
*** End of meeting ***