W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Versioning TeleConf Agenda, 4/6/01 (Friday) 12-1pm EST

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 8 Apr 2001 00:04:06 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B102944902@SUS-MA1IT01>
To: "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
Attending: Peter(Merant), Boris(IBM), Geoff(Rational)

   Agenda:

   Discuss the changes proposed at the Minneapolis IETF

   - split Variant into separate spec (no objections so far)

No objections in con-call.

   - merge Fork-Control into Checkout (no objections so far)

No objections in con-call.

   - define four "feature-sets" or "option-sets" (defined in earlier
message)

Ok with con-call participants.

   - defer label header, but keep LABEL method

Example of reason why you don't want human meaningful strings in a
header:  The Label value needs to be matched against values stored 
on the server.  For some languages, the encoding is not enough to
decide whether or not there is a match ... you need something like
a language attribute.  With labels in XML, that's no problem ... you
add the language information as an optional element or attribute.
With a header, there is no good way to provide this info.

Consensus of con-call: Label header can be removed.

   - defer UPDATE method

We spent some time discussing the motivation for this.  The consensus
of the con-call was that there was sufficient support for it in the
working group to keep it in the protocol.  

   - should version-controlled configurations always be in the
     checked-out state?

One more topic was raised, which was a proposal that a
version-controlled configuration should always be in the checked-out
state.  In particular, it would be initialized to be in the
checked-out state, and that DAV:keep-checked-out is implicitly
applied whenever it is checked in.

The motivation for this proposal is that being "checked in" means
that the state of the resource should be the same as that of the
DAV:checked-in version of the resource, and that it must first be
checked out before this state can be changed.  But it is always
possible to change the state of a version-controlled configuration,
therefore it is inconsistent to ever have a version-controlled
configuration in the DAV:checked-in state.

The consensus of the con-call was that this change should be made.
Does anyone object?

Cheers,
Geoff
Received on Sunday, 8 April 2001 00:03:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT