- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 25 Feb 2001 01:41:32 -0500
- To: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
From: Lisa Dusseault (lisa@xythos.com) I've noticed that there is a "rationale" for versioning options, but not for core versioning. I think something is needed more than the no-op definition of "the set of stuff defined in section 3". Core is specific enough that we should be able to describe, in a few brief paragraphs, precisely what it accomplishes. Thus, I've suggested some text which can serve as an introduction to, overview of, and explanation of Core Versioning. It's important to frame and position technical requirements, because readers understand technical specifications much better if they understand what its for, and what it does, first. Lisa: Sorry I didn't get to this in time for version 14, but I'll get these changes made during the IESG last call period. "Core versioning" is the set of properties and method semantics defined by Section 3 of this document. Core versioning serves to establish a common model to organize and understand constructs which exist on any versioning server. Core versioning makes a number of requirements on how servers must handle version-controlled resources, so that clients have a reasonable model for what effect a command will have. Core versioning makes requirements on servers but not on clients. The intent of this choice is that clients be able to rely on a minimum level of functionality when they contact a DeltaV-capable server. Since all HTTP actions are initiated by the client, the server has no need to know a priori what functionality the client supports. TO the extent to which the server needs to know, the client can tell it in its requests. In Yaron Golan's review, he vehemently objected to statements that are generically true for all HTTP protocol extensions. I believe that the previous paragraph suffers from this problem, i.e. these statements are true, but have nothing in particular to do with versioning. What do other folks think? A server which implements Core Versioning can interoperate successfully with a client which is completely ignorant of DeltaV. Unless the client requests versioning functionality, a Core-compliant server will automatically behave like an non-versioning WebDAV server. Thus, a versioned resource automatically behaves in an unsurprising way when operated upon by WebDAV or HTTP methods. Yes, this definitely needs to be said! I'll make this point in the "Relationship to WebDAV" section. A client can use OPTIONS to find out if a server supports core versioning. If the server does support core versioning, the client can then be assured that it can: - Browse version-controlled resources and differentiate them from non-versioned resources, good - Use VERSION-CONTROL method to put resources under version control, good - Browse past versions of version-controlled resources, good - View some basic information about these resources, that seems a bit vague to me. - Find out whether and how new versions will be created automatically by the server (auto-version) good - Predict what effect HTTP/WebDAV operations will have on a given resource with a given version history that also seems a bit vague to me. If nobody objects, I'll add this enumeration of core versioning features to the Introduction. Cheers, Geoff
Received on Sunday, 25 February 2001 01:42:12 UTC