The WebDAV WG met on Thursday, December 10, 1998, from 1300-1500, with 42 people in attendance. The meeting was chaired by Jim Whitehead, and meeting notes were recorded by Rohit Khare. Final minutes were prepared by Jim Whitehead.
Three main topics were discussed: advanced collections goals and protocol (<draft-ietf-webdav-collection-protocol-02> and <draft-ietf-webdav-collection-reqts-03>), versioning (<draft-ietf-webdav-versioning-00>), and issues from the distributed authoring protocol (<draft-ietf-webdav-protocol-10>). There was a brief discussion at the end of the meeting on additional properties (draft was not submitted in time for the meeting). Prior to the main meeting, two informal breakout sessions were held on the topics of Access Control and Advanced Collections.
Jim Whitehead began the meeting with an agenda overview. He also announced that the WebDAV Distributed Authoring protocol specification was approved as a Proposed Standard by the IESG on November 25, 1998.
ADVANCED COLLECTIONS:Judith Slein led discussion on Advanced Collections, discussing the issues:
Judith announced that Jim Davis's sandbox.xerox.com test server on
8080 has redirect and direct references working according to the
current protocol specification,
What mechanism should be used to disable the referential capabilities of reference resources:
Judith described a proposal from the advanced collections brekout
session to have a header, tentatively called "No-Passthrough", which
would disable the passing-through of method invocations to the target
of a direct reference, and the issuance of a 302 for a redirect
reference.
There was discussion on what happens if you send a No-Passthrough
header to a resource that's a hardcoded redirect - a 302 from the
server/CGI-script; rather than being a 'redirected reference'. In this
case, a client might find it difficult to disambiguate between the
hardcoded 302, and a redirect reference. Due to this, a client might
expect the hardcoded 302 to respect the semantics of the No-Passthough
header, operating on the false idea that the hardcoded 302 was
actually a redirect resource. The hardcoded 302 (especially those
from a downlevel CGI script) would very likely not respect the
semantics of the No-Passthrough header. One possible solution is to
use the proposed Mandatory header (the Mandatory header lists other
headers which MUST be understood, or the method invocation fails). It
was unclear how this would address the downlevel CGI script case,
which would presumably not understand the Mandatory header either. It
was noted that a client can tell whether the 302 redirect it receives
is a 'normal' (hardcoded) 302, or a 302 from a redirect resource,
since the 302 response message from a redirect resource must contain
the Ref-Type header. This allows a WebDAV-aware client to know what
kind of resource is causing the 302 response.
It was noted that the proposed No-Passthrough header needs to be
clear about the effect of the No-Passthrough header on non-redirect
references.
A working group member noted that we should be more precise about reference vs resource: in some sense, every URI is a redirect to an actual resource.
This issue will be taken to the list for further discussion.
Optional backpointers:
Several working group members had problems with the optional
backpointers proposal. One noted that if clients can't depend on the
backpointer property being there, and even if it is there, users can't
be sure what it means since there is no guarantee it contains all
backpointer references (since some references to this resource might
be located on other servers, hence outside the realm of control of the
server managing the resource which has the backpointer property).
Hence, this is not the business of DAV or a DAV client; this is what
(server-specific) live properties are for.
It was noted that if backpointers are an arbitrary property, there
won't be as much interoperabilty. This was countered by noting there
isn't any interoperability in this scenario to begin with, due to the
fact the property might not be present, and might not contain all
possible backpointers.
One working group member suggested that the original rationale for
having backpointers was to use them as a mechanism for navigating to
the parents of a resource, especially when the containing collection
includes members which are not lexically/syntactically related to the
URL of the collection. However, working group members disagreed with
this.
There was a suggestion that if anyone is going to provide
backpointer capability, it is important that we reserve a property
name which will be used for this, or preserve a name which is
reserved for future use. There no support for this idea. As another
working group member noted, there is no point to having standardized
properties in this case. If the property is optional and
server-specific, it can be interoperable and it can be handled in a
separate draft at later time and go to Proposed separately.
There was another suggestion to establish some principles about
what are the responsibilities of the client, the server, and the
repository.
Discussion of optional backpointers will be taken to the list.
Should it be possible to hide the target of a direct reference:
There was brief discussion on whether it should be possible to hide
the target of a direct reference. One working group member seconded
the idea that this be handled as a security right, and not handled in
the advanced collections protocol.
Enforcement of referential integrity:
Discussion on referential integrity began by noting the following
scenario. At creation time, it should be possible to suspend
referential integrity. This would allow you to create a template
collection of pointers and realize the contents later.
One working group member moved to strike all mention and discussion
of referential integrity. However, another working group member noted
that their configuration management product does support strong and
weak references, and they will expose it on our own if not
standardized. They would like to have interoperabilty with other
configuration management vendors. Another member noted that in their
document management system, they initially tried to enforce integrity
at the front end, but now the just warn the user, and do not provide
any back-end integrity.
Judith stated that she will start weekly phone calls on
Adv. Collections to bring these issues to resolution. Jim, as chair,
stated that these discussions have been proceeding for too long and
he's looking for progress or hatchets.
VERSIONING:
Geoff Clemm led discussion on versioning. He announced that a
versioning goals document will appear soon. During the meeting these
issues were discussed:
Data model for a versioned resource:
Geoff presented from hand-written slides. His presentation was on
the data model of a versioned resource, and differed slightly from the
data model discussed at the versioning and variant authoring design
team meeting held a week before the IETF meeting.
Geoff's presentation, paraphrased in sentences is:
There is a resource under version control. A versioned resource is
a set of (or potentially a collection of) working resources. A working
resource supports the CHECKOUT operation, which returns a new working
resource. A working resource supports a LABEL, which is a reference
to another working resource, which may take the value of "stable",
"current", "mine", etc. A working resource also supports the CHECKIN
operation, which creates an immutable revision. A configuration has a
selection rule (perhaps an XML description) to describe a
configuration of working resources.
Working group discussion ensued.
A concern was raised about server limits. Does the server have to
provide storage space for lots of client checkouts? What are the
risks associated with rogue clients - could versioning be used as a
form of denial of service attack? Geoff stated that there is an
implicit put/creation of working resources. But, the working resource
does not have to live on the same server - it could live in the
client until checked in.
Are checked-in resources mutable or immutable:
There was some discussion on terminology. One member asked about
the difference between a working resource, revisions, and resources.
Answer: there is a set of working resources associated to every
versioned resource. Mutability is the base case; immutable checked-in
revisions are layered on top. A revision is an immutable working
resource. Checking out a working resource to create a new working
resource takes a snapshot of the contents.
A concern was raised with this approach. The advantage of thinking
of revisions and revisions-which-can-be-thawed (the
revisions-which-can-be-thawed approach was discussed at the design
team meeting - in this approach, a checked-in resource may be edited
if it supports the THAW method, and the client invokes THAW on the
checked-in resource) is that a versioning client would do a checkout,
perform their edits, then checkin. There is a tradeoff between client
and server complexity. Having resources be immutable by default, with
a thaw operation used to edit checked-in resources, would allow a
client to use the same interaction style for all versioned resources
(checkout, edit, checkin); now, it would need to do some repository
discovery to see whether it needs to perform a checkin operation. It
was noted that if you only have mutabilty, the client can employ a
checkout-only protocol. Another member noted that they have
scalability concerns - for their system, a checkout is a mutex
operation, and no one else can branch or checkin from there.
Use of lock as a mechanism for checkout:
There was a discussion on use of the LOCK method for performing
checkout/checkin capability, perhaps with a versioning lock.
Arguments in favor of this approach are the ability to reuse an
existing method, rather than creating new methods, which is asserted
to be more simple for clients to support, especially clients which
understand WebDAV, but do not understand the versioning
extensions. There was concern that we are not accomodating the
simplest kinds of clients. It was noted that it is an explicit goal
of the versioning design team to accomodate "automatic versioning", or
versioning for HTTP/1.1 or WebDAV aware, but versioning unaware
clients.
The following locking capabilities are needed:
Arguments against using LOCK for checkout and checkin operations:
One working group member noted that there are certain versioning
clients that would be very displeased if revisions were
mutable. However, they suspect that most clients wouldn't care, and
would prefer the freeze-thaw approach vs. checkin/checkout approach.
Another member wanted a clarification of mutable
vs. immutable. They wondered whether immutable means the bit-pattern
is fixed for all time, or that administrators still have root-like
priviliges. The sense of the working group was that they mean the
former (bit pattern is fixed for all time). Clients must be able to
depend on caching and repeatability of configurations.
Another working group member noted that HTTP has strong and weak
e-tags (bit-by-bit equality or usable-equivalent, respectively). It
would make some sense to support these semantics in the web authoring
protocol.
ISSUES FROM LIST DISCUSSION:
Jim Whitehead next led discussion on issues from the discussion
list. Issues discussed were:
Issues for revising the document going to Draft Standard:
One working group member asked for formal interoperabilty testing
and continued tuning of the drafts as they progress from Proposed to
Draft Standard. Jim Whitehead stated that he is working on an HTTP
WG-style issues list, and sees this as his responsibilty as chair.
Jim also suggested that, based on email he has received, a mailing
list specifically for implementors seems to be a good idea. Working
group members disagreed: in other groups, it's been strongly suggested
that reports from implementors should be kept on the main list.
Implementors will be encouraged to submit their interoperability
reports to the main list.
Another working group member suggested that the WebDAV working
group should develop a canonical test suite. There was a lot of
disagreement - the IETF does not perform branding. There was a
suggestion to spin out the branding to another organization.
Jim Whitehead stated that he is in the planning stages for an
interoperability event in Feb/Mar 99.
Another working group member noted that client testing has its own
special set of concerns, and can be more difficult than server
testing. Client testing takes lots of instrumentation, and may
introduce bugs into the client. The HTTP model worked well, using the
bakeoff model with feature-by-feature pairwise testing. Furthermore,
it is an IETF requirement to perform feature-by-feature tracking to
advance to Draft Standard.
Disambiguating between URI and URL:
It is believed that draft-ietf-webdav-protocol-10 now correctly
disambiguates between URI and URL, and uses them correctly. Larry
Masinter noted that if you could find an implementation detail which
actually disambiguates URI vs URL, he would be very surprised indeed.
Storing attributes submitted in XML properties:
The specification is currently silent on the topic on what a server is
required to do with XML attributes submitted as part of a PROPPATCH
"add" request. One working group member expressed quite strongly that
he feels the specification IS clear, that any XML element - which
includes attributes, must be stored. Yaron Goland stated that the
spec was intended to be silent, as a compromise. Another member
argued for storing the entire element, especially since there are
legitimate uses of XML attributes. However, some repositories would
have to be changed to accomodate storage of XML attributes. Yaron
Goland stated that WebDAV uses XML as a transport format, not for its
object model. The use of attributes was not required. Another member
noted that we should not define our own variant of XML for use in
properties.
This issue will be taken to the list for more discussion.
Namespace consistency:
One member noted that it is hard, on the face of it, to identify
the benefits of the namespace consistency requirements in
draft-ietf-webdav-protocol-10. The server has to work harder; what
efficiencies do clients rely on? Others noted that without
consistency, our collection semantics fail. This was rebutted: how
does that help? What is the utility of requiring namespace
consistency of collections? It was noted that some rationale was
provided on the list.
This discussion is being taken to the list.
COLLECTION PROPERTIES:
Lisa Lippert led a very brief discussion on a proposal that was not
submitted as an Internet-Draft before the Orlando IETF submission
deadline.
The proposal is to have a set of optional properties on collections,
these properties being:
There was some concern over whether these properties were already
implemented. The specter of "infinite implementation complexity" was
raised.
One member raised the issue of having an IANA registry of properties.
*** Meeting Adjourned ***
hassubs / nosubs - Does the collection have collections as children?
childcount - The number of members of the collection
reserved
ishidden - Is the resource hidden (like a "." file in Unix)
id
visiblecount - The number of visible members
defaultdocument
isfolder
isstructureddocument - The collection is modeling a compound document
objectcount