Re: Versioning TeleConf Agenda, 10/6/00 (Friday) 11-12 EST

Attending: Tim Ellison, Brian Bokowski, Jim Doubek, Geoff Clemm

Note: When I mention "agreement" and "consensus" in this message, I'm
just talking about the participants of this call, not the design team
or working group as a whole.

   Agenda:

   - moving LABEL to advanced

We had a combination of weak preferences to leave it in core, and a
strong preference (from Geoff) to move it into advanced.  Geoff's
rationale was that Lisa had effectively provided an existence proof
that useful versioning behavior can be provided without labels, and
that although core should be designed to be compatible with the
advanced versioning features, the actual contents of core should be
focused on common or essential versioning features in both document
and configuration management sytems.

Those with a weak preference to leave it in core stated that
they would not object to it being moved to advanced, and agreed
to report the consensus of the call as being that labels should
be moved to advanced, but with a "label" value defined for the OPTIONS
DAV header, so a server can easily advertise support for labeling.

Geoff will make a pass through the -10 draft, to verify that labeling
can easily be moved as a bundle to advanced, without disrupting the
other core features.  He will also followup specifically to JimW's
(passionate :-) defense of keeping labels in core.

   - new methods vs. PROPPATCH of live properties

There was unanimous agreement that a method with significant
side effects should be marshalled as a method, and not as 
a PROPPATCH of a live property.

We also discussed a couple of topics not on the original agenda:

   - case insensitive label comparison

The consensus of the group was that we would like to keep the
requirement that label comparison not involve any case folding.
But we also felt that for compatibility with certain existing
repositories, we should weaken that requirement from a MUST to
a SHOULD (just as appears in 2616 when it talks about URL comparison).

   - the Workspace header

Tim has created a thread on this topic on the mailing list, indicating
problems with both the current and previous definitions of the
semantics of the Workspace header.  In particular, what URL's in
the request does the Workspace header apply to, and what URL's in
the response does the Workspace header apply to.  The consensus
of the group was that the Workspace header causes more problems
than it solves, and the protocol would be significantly improved if
the Workspace header were just deleted.

The only person I know of that would object to that is Chris
Kaler, so I've left him some voice mail asking him to define
what he would like the semantics of the Workspace header to be,
and to be prepared to defend its continued presence in the
protocol.  Anyone else that is in favor of the Workspace header
is encouraged to to so (i.e. define it carefully, and defend it)
also.

Received on Friday, 6 October 2000 17:10:22 UTC