The working group on Distributed Authoring and Versioning on the World Wide Web (WEBDAV) held a meeting at Xerox PARC on November 14-15, 1996, in Palo Alto, California. There were 28 attendees from the following organizations: America Online, AmerInd, Canon Info. Sys., Continuus, Dept. of Veterans Affairs, Microsoft, Mortice Kern Systems, Netscape, Novell, NTT, Pure Atria, Saros/Filenet, SoftQuad, U.C. Irvine, Web Tools Int'l, World Wide Web Consortium, and Xerox. The working group thanks Larry Masinter, Xerox PARC for providing food and meeting space as the host of this meeting. Further thanks go to Keith Dawson, Pure Atria, for his meeting notes.
In the following message, a dash "-" denotes a meeting date, an asterisk "*" represents an item of consensus, and and equals "=" denotes an action item.
UPCOMING MEETINGS
- The next meeting of the working group will be at the WEBDAV BOF at the San Jose IETF meeting. The WEBDAV BOF is currently scheduled for Wednesday, December 11, 1996, from 9:30 to 11:30AM.
- The following meeting will be held at U.C. Irvine, in late January 1997. The WG agreed upon the dates January 23-24, but due to a UCI scheduling conflict (the Conference on Software Process Improvement, CoSPI), these dates are not open. The new meeting date is January 27-28, 1997.
- The W3C Symposium, Distributed Authoring: Present and Future, will be held at the Sunnyvale Hilton Inn, December 4-5, 1996. For more details, consult: http://www.w3.org/pub/WWW/Authoring961001/Call.html.
The meeting began with a presentation by Kenji Ota, NTT on the NTT versioning draft. This was followed by a presentation by Yaron Goland, Microsoft, on the major design issues facing this group, as reflected in v0.2 of the Goland/Whitehead draft.
Two issues were primarily considered for the remainder of the day, POST vs. methods, and attributes.
POST vs. METHODS:
The discussion on POST vs. methods centered on whether the DAV functionality should be specified by creating a special purpose MIME type which is then sent to a server using the HTTP POST method, or whether new HTTP methods should be created for this. In the POST approach, the MIME type would specify the functionality (e.g., application/copy), whereas the method approach would use a new method (e.g., COPY). Within the methods approach, there were two choices for where to place request parameters: a) in new, method-specific headers, or b) in the body of the request message.
* The group reached rough consensus that new DAV functionality should be specified with new HTTP methods, with request parameters in the message body. However, this was subject to the caveat that existing HTTP/1.1 headers should be used where appropriate and consistent with existing meaning and usage. Also, this design choice was not meant to preclude the definition of new headers, if they are the best design choice.
ATTRIBUTES:
Discussion of attributes spanned two days. Despite several hours of discussion, the working group did not reach consensus on attribute functionality. Key design issues for attributes are:
One common thread of discussion centered around how much indirection should be provided when looking up attributes. One position held that one round trip lookup of an attribute's value was necessary for efficiency, which argues for a lookup directly returning the attribute's value. Others held that, for generality, attributes could hold a URL, which would point to the resource containing the attribute's value. Yet another proposal suggested that a resource would contain a LINK header pointing to an "attributes" resource, which groups all attribute/value pairs. A URL munge on the URL of the "attributes" resource (e.g., http://foo.bar.com/attrs?Author) would return the value of the attribute (this approach was called, "a license to munge," since the server provides the URL and thus guarantees that it can be munged, much like imagemap URLs, without concern for collision with other valid URLs).
However, there were some points of commonality amid the discussion.
* Trying to develop a set of core attributes, such as the Dublin Core, was considered to be a bad idea. Instead, a means should be provided for using existing attribute sets, and for discovering which attribute sets are being used to describe a resource.
* The LDAP search syntax (RFC 1959) is worth investigating for use as an attribute search syntax.
= Due to the lack of consensus, the group decided to solicit drafts describing attribute functionality for the Web. The deadline for submission of attribute drafts to the working group list is Nov. 26. Authors of drafts are encouraged to submit their drafts as Internet Drafts so they may be considered at the San Jose IETF meeting.
NETSCAPE DRAFT
During the day, Jim Cunningham and Asad Faizi circulated paper copies to all attendees of their draft on how to perform distributed authoring and versioning functionality, titled "Distributed Authoring and Versioning Protocol." The draft circulated was version 0.1. The draft describes how to implement the Distributed Authoring and Versioning requirements using methods. It is currently unclear how open Netscape will be concerning this draft. Asad Faizi will be working with Yaron Goland, Jim Whitehead, and Del Jensen to develop subsequent working group drafts.
The second day began with a discussion of the sponsorship and activities of this working group.
* The group unanimously decided to pursue a path of joint IETF and W3C sponsorship.
= Jim Whitehead agreed to revise and submit the WG Charter to the IETF Application Area Directors in hopes that the WEBDAV group could be an official IETF working group by the San Jose IETF meeting.
* The group agreed that all current drafts of the working group should be submitted as Internet Drafts by the IETF deadline, November 26.
= The group continued to feel that further development and
refinement of the scenarios document was worthwhile, as a sanity check
on our final specification, as a good way for people to understand our
work, and to understand the rationale for our requirements. The
working group was instructed to provide feedback to Ora Lassila
= The group agreed that merging the Distributed Authoring (Whitehead)
and the Versioning (Durand, Vitali) requirements documents was a good
idea. This way the group will produce one DAV spec., and one DAV
requirements document. Durand, Vitali, and Whitehead will work on
producing this merged document.
CONTAINERS
The following issues concerning containers were discussed:
Should a container just be a resource with no special semantics, or should a container resource have special container-specific semantics (e.g. recursion through hierarchy levels). The group tended to think that container-specific semantics would be the most useful, but also more complicated.
It was discovered that there are situations where it is useful to
state whether you are operating on a resource as a resource, or on a
resource as a container. For example, if a container is a collection
of pointers to resources, then making a copy of the container is
similar to making a number of symbolic links (soft links) in a
filesystem. However, copying a container with container semantics
could cause a recursive copy of all the elements of the container,
making duplicates of all resources (hard links). This led to a
discussion of where the "switch" should be placed to specify what kind
of semantics are desired (opaque resource vs. container resource). It
was noted that filesystems have dealt with this issue. o The WebMap
specification was discussed as a potential format for container
resources. Unfortunately, the latest WebMap specification was not
available for thoughful consideration by the working group prior to
the meeting.
= Like attributes, the working group is encouraged to submit drafts on containers to the working group by the November 26, IETF deadline.
VERSIONING
There was a long discussion on versioning. Members of the working
group expressed frustration that the v0.2 Goland/Whitehead draft did
not specify versioning capability in sufficient detail to evaluate it.
Some issues:
The terms, "checkout" and "checkin" as defined in the v0.2 spec.
overload the commonly understood meaning for these terms. It was
agreed that some other term (e.g., edit notification) would be used. o
Since different versioning systems have different definitions of the
meaning of checkout and checkin (e.g., for checkout: edit notification
plus write lock (RCS, SCCS) or edit notification only, no lock (CVS)),
the server should be able to implement whatever versioning style it
wishes, and the client must adapt to it. This raises the issue of how
to specify the checkout style used on a server in a manner the client
can understand.
There seem to be two main points of difference
between versioning styles: write lock vs. no lock, and object create
on checkout or checkin. All versioning styles appear to record the
owner of the checkout (i.e., a notification of intention to edit). o
There was some discussion concerning whether versions of a resource
were resources, or were representations of a resource. The group
tended towards thinking that versions of a resource were themselves
resources. Delta storage mechanisms are not a major concern for this
group since they can be considered a server implementation issue.
There was one important point of consensus:
* All versions of a resource should be addressable (i.e., have a unique URL)
RELATIONS
There was a short discussion of the relationship model in the v0.2
spec. The group agreed that adding peer fields to LINK style
relationships was worth investigating further. There was some concern
that replicating the URL in the (rtoken, URL) peer pairs was not space
efficient.
REPRESENTATION/MANIPULATION
There was a discussion about the interaction between variants of a
resource, and versions of a resource. The group came to the conclusion
that containers, content negotiation and versions are all orthogonal.
* The group came to the consensus that variants can be versioned.
* There was also some discussion of whether method parameters
could be subject to content negotiation. HTTP does not allow the
Accept* request headers to be used for selection of the target of an
action (method); they can only be used for selection of the content of
the response message after the action is taken. As a result, the group
came to consensus that no use of content negotiation should be allowed
on the parameters of a method invocation.
There was also some discussion about the utility of allowing
remote editing of content negotiation information. However, this was
agreed to be pushed off into the next round of DAV activity.
RELATED DISCUSSION
Over lunch, Carl-Uno Manros discussed the work he is doing on the PWG,
Internet Printing Project (ipp). Carl-Uno summarized the direction
being taken by this working group, and their desire to utilize HTTP
as their transfer protocol.
At the end of the day, Mike Spreitzer led a discussion on four
issues, which helped establish the boundaries of what should be
considered by the WebDAV working group:
*** Meeting Adjourned ***
University of California, Irvine
Jim Whitehead <ejw@ics.uci.edu>
Department of Information and Computer Science
247 ICS2 #3425
Irvine, CA 92697-3425