RE: Basic Versioning Packages

The purpose of the SHOULD is to make live easier for an interoperable
client writer.  In particular, the presence or absence of a particular
combination of features can significantly affect what kind of model
should be presented to a user in order to give them simple, intuitive
access to supported functionality.  For an interoperable client
writer to optimize that model for all possible
feature combinations would be prohibitively complex, so after much
debate, we settled on 5 packages that seemed to best balance what
existing versioning systems actually supported and what the
known DeltaV server writers were planning on implementing.

So in this case, the "known implications" of supporting a set of
features that does not exactly correspond to one of the recommended
sets is that interoperable clients are likely to just take advantage
of the subset of the features that do correspond to a recommended set,
and only clients specifically written for your server will use the
extended features.

So the valid reasons include:
- these are important features for clients written specifically for your
server
- this set of features is one that you hope to be considered as a "standard
set" in the next draft of the specification
- there are interoperable clients that have been written to take advantage
of feature combinations other than those defined as a standard package (and
that therefore will expose all the features your server is providing).

Cheers,
Geoff

-----Original Message-----
From: Jeff Thompson [mailto:Jeff_Thompson@CoCreate.com]
Sent: Monday, March 24, 2003 1:37 PM
To: ietf-dav-versioning
Subject: Basic Versioning Packages



  Another question regarding basic versioning packages.

Section 2.1 of the spec states:

> Although a server MAY support any combination of versioning features, 
> in order to minimize the complexity of a WebDAV basic versioning 
> client, a WebDAV basic versioning server SHOULD support one of the 
> following three "packages" (feature sets):
>
> - Core-Versioning Package: version-control
>
> - Basic-Server-Workspace Package: version-control, workspace, 
> version-history, checkout
>
> - Basic-Client-Workspace Package: version-control, working-resource, 
> update, label
>

In reviewing the features, it seems to me that a combination of 
version-control and checkout-in-place would meet our needs very well and 
provide a minimalist yet complete package. Yet, the spec states that we 
SHOULD not provide this combination. I'm trying to get a feeling for 
this statement from the spec.

What is the rationale behind this restriction?

The referred spec, RFC 2119, defines SHOULD as,

>This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.
>
The full implications of ignoring this SHOULD are not at all clear to 
me. My proposed combination seems reasonable. Can someone please 
enlighten me?

Jeff Thompson

Received on Monday, 24 March 2003 14:05:46 UTC