FWD: [Geoffrey Clemm] RE: Issue: comment in UNCHECKOUT

Ralph R. Swick (swick@w3.org)
Mon, 24 May 1999 09:07:33 -0400 

Message-Id: <3.0.5.32.19990524090733.02b03540@127.0.0.1>
Date: Mon, 24 May 1999 09:07:33 -0400
To: ietf-dav-versioning@w3.org
From: "Ralph R. Swick" <swick@w3.org>
Subject: FWD: [Geoffrey Clemm] RE: Issue: comment in UNCHECKOUT

>Date: Fri, 21 May 1999 22:49:55 -0400 (EDT)
>X-Sender: gclemmw@tantalum.atria.com (Unverified)
>Old-Date: Fri, 21 May 1999 18:31:24 -0400
>To: ietf-dav-versioning@w3.org
>From: Geoffrey Clemm <geoffrey.clemm@rational.com>
>X-Diagnostic: Not on the accept list
>Subject: [Moderator Action] RE: Issue: comment in UNCHECKOUT
>
>At 10:16 AM 5/20/99 -0700, Chris Kaler (Exchange) wrote:
>>There are version control systems that track these sorts of things.  It
>>seems reasonable for the protocol to support the "action oriented" comments
>>and allow servers to ignore this information.  We could provide a way to
>>discover it.
>
>I agree that version control systems track these sorts of things (my
>company's product certainly does).  My main point was that it is important
>to distinguish a "resource description" (i.e. the comment you give when
>you create a new resource) from general event descriptions.
>
>A resource description is something that would be very reasonable to
>standardize (although I personally would rather leave these "semantic free"
>dead properties out of the core specification).  An "event" description is
>far more problematic to standardize, since each system usually has a very
>constrained set of event data it is capable of recording.
>
>>The alternative is that these stores will have to create custom extensions
>>to meets these needs and that seems bad.
>
>I believe each store will have to create its own custom extension to represent
>its particular kind of event data anyway.
>
>Cheers,
>Geoff
>
>
>>From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
>>I believe this draft of the spec inappropriately merges the concept
>>of a "resource creation comment" (something I would support)
>>with that of an "event comment" (something I would not support).
>>
>>A CHECKIN creates a new resource (a new revision), which provides an
>>appropriate place to put a resource creation comment.  An UNCHECKOUT
>>does not create a new resource, which then leaves you with the
>>problem you raise of where to store that "comment".
>>
>>So I will propose that only resource creation requests can take
>>such a header (and I suggest it be called a Description, not a Comment).
>>
>>   From: "Jim Davis" <jdavis@coursenet.com>
>
>>   3.3 says that the client can provide a comment as part of an UNCHECKOUT.
>>
>>   The source control systems I have used don't store any history for an
>>   uncheckout.
>>
>>   MUST the server store this comment?  If it does not, MUST it return an
>>error?
>>
>>   I'm new to this list, apologies if it's already been discussed.