Re: FW: Comments on draft-ietf-webdav-versio

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Sat, 23 Oct 1999 21:28:55 -0400 

Date: Sat, 23 Oct 1999 21:28:55 -0400
Message-Id: <9910240128.AA24030@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <1999Oct12.094344.1250.1348981@otismtp.ott.oti.com>
Subject: Re: FW: Comments on draft-ietf-webdav-versio

And here are some of *Tim's* corrections that didn't make it into the -01
draft, but are now in the 01.1 draft.  Thanks for the careful readings and
all the corrections, Tim, and sorry I didn't get them into the 0.1 draft!

   From: Tim_Ellison@oti.com (Tim Ellison OTT)

   1.2 Terms     Predecessor, Successor
   Style: strike 'previous' from first line

done.

   1.2 Terms     Configuration
   Correction line 1: replace 'each of a set of' with 'each member of a set of'

done.

   1.3 Notational Conventions
   Style: Move this section earlier in the document since the key words have 
   already been used by this point.

Removed all prior uses (just two of them).

   3.1.1 Writable/Readonly Properties
   Comment: Is it true that a writable property can only be modified by a 
   client?  I suspect it may be convenient to allow writable properties to be 
   modified by clients or servers.

Done.

   3.3.2 DAV:comment
   Correction: replace 'author' with 'comment'

Done.

   3.4.4 DAV:single-checkout
   Style: May be helpful to state explicitly that this applies across all 
   workspaces.

Since you can never have more than one checkout of a give VR in a
workspace, that's probably redundant.  What do other folks think?

   3.4.9 DAV:history-uuid
   Comment: I was left wondering why the concept of a UUID had been introduced 
   here.  Why does an identifier not suffice with the same provisos as revision 
   identifiers?

Got rid of the GUID.  We'll probably discuss this in Washington.

   3.5.3 DAV:checkin-policy
   Style line 6: replace 'should be copied into' with 'should replace'

I wanted to make sure that people realized that the semantics was
COPY and not MOVE.  (i.e. a new revision is not created, but the
state of the existing revision is modified).

   3.6.2 DAV:revision-selection-rule
   Style line 4: replace 'else the revision' with 'otherwise the revision'

Done.

   3.6.3 DAV:label
   Comment: How are conflicts in labels resolved?  For example, if I attempt to 
   CHECKIN another resource with the same label as an existing revision what 
   happens?

It moves the label to the new revision (this is the desired semantics).

   3.7.2 DAV:required-activities
   Correction line 2: replace 'DAV:needed-activities' with 
   'DAV:required-activities'

Done (actually, I made everything "needed", but I could go the other way
if people prefer).

   3.10.1 DAV:uuid
   Comment: I'm unsure why UUIDs have been introduced here.  They seem to be 
   the same concept as an identifier elsewhere.  What is the distinction being 
   drawn?

Got rid of it.  GUID fans can raise the issue in Washington.

   3.10.2 DAV:revisions
   Comment title: The title should also indicate that the revisions collection 
   is mutable.

Actually, mutability only applies to a property of a revision ... this is
a property of versioned resource.

   Comment: This paragraph introduces the notion of a URL for a revision -- 
   what does the URL for a revision look like?  Can it be 
   interpreted/constructed by the client or is it intended to be an opaque 
   token to identify that revision to that server.

The revision collection URL is determined by the server, but then a client can
construct a revision URL by selecting the member with the appropriate 
revision id.

   4.1.3 PUT
   Style para 1: Clarity would be improved if the two cases were shown in 
   separate paragraphs or as a bulleted list.

Done.

   Comment line 13: Should 'it fails' be replaced by 'it MUST fail'?

Done.

   4.1.7 COPY
   Correction line 3: replace 'it fails' with 'it MUST fail'

Done.

   4.1.8 MOVE
   Correction line 3: replace 'it fails' with 'it MUST fail'

Done.

   4.1.10 OPTIONS
   Style line 1: In the MSWord version 'OPTIONS' is incorrectly formatted.

Done.

   5.1.1 DAV:rsr-configuration
   Style: Saying that the rule never generates a conflict was confusing at 
   first -- this should be tempered with 'if this is the only rule' it never 
   generates a conflict.  Clearly it could be the cause of a conflict when 
   combined with other rules.

Haven't fixed this yet, but I see what you mean.

   5.1.5 DAV:rsr-latest
   Comment: Choosing the 'latest' revision based on chronology may not be the 
   ideal solution.  Maybe the rule should be based on the successor 
   relationships between revisions (i.e. tip of branch)  I guess the main 
   problem that I see with this is based on experience of dealing with real 
   time -- which is decidedly difficult to maintain accurately, track across 
   time zones and daylight savings etc.

This was done for Bruce, who didn't care about predecessor relations but
just wanted a rule for "whatever was created last".

   5.1.7 DAV:rsr-or
   Comment: Should state that there is no conflict generated.

Done.

   5.2.2.1 DAV:compare-report-request
   5.2.2.2 DAV:compare-report-response
   Comment: stating 'of the same type' is unclear -- this should be made 
   explicit since it may imply collection vs. non-collection, or workspace, 
   activity, etc, or MIME type.

Got rid of it.

Cheers,
Geoff