WEBDAV Palo Alto meeting overview

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@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@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@ics.uci.edu>

Received on Wednesday, 20 November 1996 00:28:49 UTC