Preliminary Orlando IETF minutes

Below are preliminary minutes from the WebDAV WG meeting held during the
Orlando IETF, on December 10, 1998.  I have to submit these minutes on
Jnauary 6, so if you have comments or corrections, please submit them to me
by end-of-day on January 5.

- Jim

-------------------

WEBDAV WORKING GROUP

Meeting Minutes
IETF-43, Orlando, Florida
December 10, 1998


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:
 - What mechanism should be used to disable the referential capabilities of
reference resources
 - Optional backpointers
 - Should it be possible to hide the target of a direct reference
 - Enforcement of referential integrity

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, <draft-ietf-webdav-collection-protocol-02>.

** 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
 - Are checked-in resources mutable or immutable
 - Semantics of checkout
 - Use of lock as a mechanism for checkout

** 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:
1) Locking a versioned resource as a whole.
2) Locking a particular working resource.
3) Locking an entire branch (for branch-based CM)

Arguments against using LOCK for checkout and checkin operations:
1) Separation of concerns: the protocol is more simple by leaving locking
alone.
2) Locking is optional and hence cannot be depended upon to be present.
3) When the design team explored using lock, the resulting protocol was
complex, and added a lot of new headers.
4) The lock approach does not scale up to handling configuration management.
5) If all you want is temporary ability to write-protect, lock it; if you
want it PERMANENTLY write protected, another operation needs to be used.

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
 - Disambiguating between URI and URL
 - Storing attributes submitted in XML properties
 - Namespace consistency

** 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 hsa 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:

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

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 ***

Received on Wednesday, 30 December 1998 11:29:25 UTC