IETF-51 DeltaV WG meeting minutes

Delta-V Working Group Meeting (1pm Wednesday August 8th, 2001)
IETF'51 London, England

Introduction by Jim Amsden, including status of working group document.
IETF-wide last call imminent and well on the path to Proposed Standard.
Geoff presented the changes made to the draft since versioning-16:
- Overview of DAV:auto-version values.  Noted that DAV:locked-checkout
implies unlock checkin.
- The supported live properties are marshalled as XML attributes, the
proposal is to switch them back to name elements.  However, method names
may contain characters that are not valid as XML element names, so they
will stay as attribute values, and there is no namespace to report.
- Remove DAV:ok as a defined value for the check-out fork and check-in
fork, and just leave the DAV:forbidden and DAV:discouraged values.  Servers
should just check for these flags.  This means that forking is ok if the
value is empty (or DAV:ok).
- Similarly, an empty value for DAV:auto-version means that there is no
auto-versioning happening for that resource.
- Change the specification to say that servers SHOULD implement the expand
property report, and move the description of the report earlier in the
document to illustrate that it is not an advanced feature.
- Should clarify the relationship between the DAV:supported-method-set and
the Allow: header.
Should it report for the current state of the resource ? or for any state
of the resource?  Current consensus is that 'supported' means for any
state.  Should we clarify what the Allow: header means?  E.g. for a
version-controlled resource, does Allow: include both CHECKIN and CHECKOUT
or only ever just one of them?
Note that we still require the supported-methods property to permit depth
queries.
Call for consensus within the room on what "allow" and "supported" means ?
agreed that they should mean the same thing.  Proposed that it means will
succeed on some state of the resource, and not necessarily the current
state.
- When a version-controlled resource is auto-checked-out, an explicit
UNLOCK request will fail if the version-controlled resource cannot be
auto-checked-in.  However, when the server removes the lock (when the lock
expires) what is the server allowed to do on CHECKIN failure?  (a) leave
the resource checked-out and unlocked, (b) fail the lock timeout, and leave
the resource checked-out and locked, (c) something else?
Discussion of coupling UNLOCK and CHECKIN ? how can a versioning aware
client do the UNLOCK if the CHECKIN will fail?  No resolution in the
meeting.
- Discussion of adding extra data to the error conditions.
- Replace locate history
- Remove the PROPFIND semantics from UPDATE and MERGE (or justify its use
in the specification).
- Discussion of procedure for IESG last call.  Ned stated that there
appears to be no major issues outstanding with the latest draft of the
document, so Geoff will put produce versioning-17 sometime next week and
let that go forward for IESG last call.
- Lisa presented a proposal for identifying a subset of DeltaV for document
versioning without forking.  It would include core, in-place check-out and
maybe working resources package.  It will be DeltaV compliant.
- Lisa stated that she has outstanding issues with
supported-live-properties.  The group agreed to compromise by stating that
the specification will state that DAV:supported-live-properties MUST
include the supported DeltaV and WebDAV live properties and SHOULD include
other server-defined live properties.
- Lisa also requested an UNVERSION capability to remove the history
resource and versions and working resources and leave the
version-controlled resources as regular versionable resources.  Maybe even
leave working resources as versionable resources.
- Question: What happens to version-controlled resources when a history
resource is DELETEd?  Should say in the spec?
- Future work should consider variant management and document work flow and
change request management.  Put out a request for participants in the
WebDAV working group.
- WebDAV inter-op events should include DeltaV (rather than have a separate
DeltaV event).
- Expected progression from here:  Geoff writes versioning-17; one week to
get through queue into draft; Ned gives Steve the ok to send versioning-17
to IESG last call; last call period is two weeks (min.); then it goes onto
the IESG agenda for becoming a Proposed Standard (IESG meets every two
weeks).  The RFC editor output requires careful author review.  Close down
the working group.  After six months consider going for draft standard
which requires two clients and two servers with distinct code bases to
inter-op.  Finally go for full standard some time after that.
- Meeting closed at 2:45pm

Regards,

Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

Received on Tuesday, 14 August 2001 05:30:45 UTC