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

RE: Process for moving to Proposed Standard

From: Jim Amsden <jamsden@us.ibm.com>
Date: Thu, 24 May 2001 17:09:46 -0400
To: ietf-dav-versioning@w3.org
Message-ID: <OF0D452246.B3BF3582-ON85256A56.0073ADC2@raleigh.ibm.com>
I didn't mean to imply that we would wait for IETF last call to address 
issues. Only that issues that come up in that last call would need to be 
addressed, potentially resulting in the need for spec revisions and an 
additional last call. I expect to address issues as soon as they come up, 
refresh the internet draft, and re-submit to the area directors as needed. 
So I think we're in agreement.

"Larry Masinter" <LMM@acm.org>
05/24/2001 02:29 PM

        To:     "Jim Amsden" <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
        cc:     <ned@innosoft.com>, <paf@cisco.com>, "Geoffrey Clemm" <gclemm@atria.com>
        Subject:        RE: Process for moving to Proposed Standard



I think that trying to do too much "pipelining" in the process
may actually slow you down. I don't think it is appropriate
to wait until "during IESG last call" to respond to the 6-7
issues that have been raised on the mailing list since the
-15 draft of 4/17/01. 

An IESG last call is appropriate when you have a document that
you believe has "resolved known design choices". Not revising
the document now means that you're asking people to review
something when you expect to change it.

The issues I see on the mailing list are:

>  add a DAV:updated-set
> and DAV:ignored-set in the UPDATE response body.

# should use
# <dav:resourcetype> to indicate multiple pieces of type information 

# The response to a VERSION-CONTROL request does not carry
# a Location header similar to CHECKIN (Draft 15).

# Cache-Control: no-cache is not
# needed for the VERSION-CONTROL response. 

#   "A collection has all the properties of a version."
#   should say "A collection version has all the properties of a version."

# both the "checkout" and the "working-resource" features
# introduce a CHECKOUT method that is affected by these properties,
# the fork-control properties should be identified in
# both features. 

although perhaps you have a different (longer) list?

Received on Thursday, 24 May 2001 17:10:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC