On invitation from Larry Masinter at PARC, I attended a meeting of the WG on
Distributed Authoring and Versioning on the World Wide Web (WEBDAV). This
group is primarily working on various issues associated with document
repositories.
It turned out that this group was grappling with some of the same issues as
we will face in the Internet Printing Protocol (IPP) project. In
particular, the following areas seem to be of common interest:
- Use of Attributes
- Need for a Search/Lookup capability
- Need for a Notification service
- Use of current HTTP features vs. new extensions
WEBDAV is currently seeking to become a WG in the IETF, and is also trying
to become a recognized WG of the W3C. A WEBDAV meeting will be held during
the upcoming IETF meeting in San Jose. This is the kind of group in which
the "real players", Microsoft, Netscape, and Novell are active.
I held a short verbal presentation about the current plans for the IPP
project in IETF.
Several participants expressed interest to start following the activities of
the IPP project.
Below follows a write-up from the meeting by the chair - Jim Whitehead from
UC Irvine.
Carl-Uno Manros
--------
WEBDAV Palo Alto meeting overview
>From: Jim Whitehead <ejw at ics.uci.edu>
>Sender: w3c-dist-auth-request at w3.org>Resent-Sender: w3c-dist-auth-request at w3.org>>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.
>>This message should not be construed to be the official minutes of the
>meeting (these are still under preparation). However, this document will
>likely form the core of the official minutes of the meeting, and as such,
>if you find any errors, or misrepresentation of the events which took
>place, please let me (Jim Whitehead, ejw at ics.uci.edu) know so the error
>will not propagate into the official minutes.
>>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. I will be polling the working group soon for new
>dates.
>- 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.>>Day 1 (Thursday, November 14)
>>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:
>>o naming (e.g. URL munging?)
>o search/lookup
>o attribute discovery
>o one round-trip lookup of an attribute's value
>o is an attribute's value a resource, a pointer to a resource, or part of a
>resource?
>o should attributes be versioned individually, or with the resource they
>describe?
>>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.
>>Day 2 (Friday, November 15)
>>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 <lassila at w3.org> on the
>scenarios document. Ora should submit the scenarios document by the Nov.
>26 IETF deadline.
>>= 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:
>>o 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.
>o 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:
>>o 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.
>o 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). I'll leave it to Carl-Uno to summarize
>this discussion.
>>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:
>>o Database: A more direct mapping of database concepts into the DAV
>protocol. Consensus: out of scope.
>o Proxy: Should DAV capabilities can accessible from proxies and the origin
>server, or only the origin server. Consensus: minimal proxy support, most
>operations must go to origin server.
>o Disconnected operation: To what degree should the DAV protocol consider
>disconnected editing and operation. Consensus: much disconnected operation
>is already possible, and more can be enabled by allowing for queuing of
>requests, but the DAV group will assume that such queueing only takes
>place
>within the client and not within external proxies.
>o Distributed filesystem: it might be a good idea to consider the related
>work on distributed filesystems. Some related systems are: Coda, CMU;
>Ficus, UCLA; and Bayou, PARC.
>>- Jim Whitehead <ejw at ics.uci.edu>
----
Carl-Uno Manros
Xerox Corporation
701 S. Aviation Blvd.
M/S: ESAE-231
El Segundo, CA 90245, USA
E-mail: manros at cp10.es.xerox.com