RE: Process for moving to Proposed Standard

I agree with Tim.  The changes proposed since version 15
have been minor marshalling changes, editorial changes,
or changes with generic WebDAV impact
(and therefore are more appropriately handled in the
rev of 2518 and not in the DeltaV spec).

I've been keeping this list
just as a folder of email messages,
but I'll try to get it posted in summary form to the website
this weekend or next week.

Cheers,
Geoff

-----Original Message-----
From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
Sent: Thursday, May 24, 2001 4:54 PM
To: ietf-dav-versioning@w3.org
Subject: RE: Process for moving to Proposed Standard




"Larry Masinter" <LMM@acm.org> wrote:
> Jim,
>
> 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.

Agreed -- though I suspect this will be uncontrovertial.

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

Agreed -- ideally it would be sent to the WebDAV WG so that it may apply to
ACLs and friends equally well.

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

I believe that this was agreed as a non-issue, or rather that Stefan wanted
to know when VERSION-CONTROL had affected a resource and when it had not.

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

Again, a trivial change that I believe will be non-controvertial.

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

Editorial change.

> # 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.

Editorial change.

> although perhaps you have a different (longer) list?

I'm kicking myself for not keeping the list, but I guess I was expecting
Geoff to do so.  I have asked him to make it generally available as I
believe that there are other issues that were raised (but don't ask me to
name them without searching<g>)

Your point is well taken, but I don't think it is as bad as you make out.

Tim

Received on Thursday, 24 May 2001 18:30:57 UTC