RE: Proposed Simplifications to the DeltaV protocol

This isn't exactly what I understood from the meeting.  I was very excited
about the "feature sets" idea because I understood that these would be a
normative part of the specification, not merely an informative thing.
Language is always so slippery....

My assumption: If anybody can create a new "feature set" and inform the
world what their set is, then there's no value to feature sets.

I do, however, understand that some servers will want to support a feature
set plus an extra feature or two.  So I propose that there be some way to
name each feature set, plus to name features on top.  Then the OPTIONS
response for my server would indicate:
 - I support BASE feature set
 - I also support features X and Y (which are not part of BASE)

Another server might support BASE, feature X, Y and also Z.  If BASE + X + Y
+ Z == FEATURE_SET_1, then the OPTIONS response would only have one string
for this server:
 - I support FEATURE_SET_1

Also, I would propose that BASE replace the concept of CORE.  It's way too
confusing to have a difference.  BASE should be the set of features that all
servers must implement:  the old concept of core, plus checkout, plus
fork-control parsing (even if disallowed).

Taking these steps puts few actual restrictions on the servers.  They can
still decide to support an arbitrary set of features.  There is only a
psychological pressure (which I think is a good thing) to implement a
defined package rather than a random set of features.  The next value of
this is that it's much easier for a client to identify their supported
feature sets.

lisa


> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, March 27, 2001 3:05 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Proposed Simplifications to the DeltaV protocol
>
>
> No, we would not propose that the "feature sets" have defined
> "compliance level" tags.  The intent is to allow
> new "feature sets" to be created,
> without requiring a new "tag" to be defined for compliance checking.
>
> In particular, suppose you define a new feature set that is
> some old feature set (e.g. "a", "b", "c") plus features "x" and "y".
> Instead of having to add another tag, you can just publish that
> "a", "b", "c", "x", "y" is now a "package", and then a server
> that supports that package would return:
> "a", "b", "c", "x", "y".
>
> The old clients will check if "a", "b", "c" are all in
> the supported feature set of a server,
> and if so, they will talk to it.
>
> The new clients will check if "a", "b", "c", "x", "y" are all in
> the feature set.
>
> And for non-standard clients that just care about "do you support
> feature x", they will be able to find that out as well.
>
> Cheers,
> Geoff
>
>
> -----Original Message-----
> From: Steve K Speicher [mailto:sspeiche@us.ibm.com]
> Sent: Tuesday, March 27, 2001 2:51 PM
> To: ietf-dav-versioning@w3.org
> Subject: Re: Proposed Simplifications to the DeltaV protocol
>
>
>
>
> >The fifth (and final) proposed simplification was to define a set of
> >four feature "packages", and to state that a versioning server SHOULD
> >support at least one of those packages.  This then allows a versioning
> >client to look for one of the four defined feature packages, rather
> >than worrying about all possible combinations of features.  Note: a
> >server still exposes its functionality as a set of features.
>
> Are these "packages" going to be represented as "DAV Compliance Classes"?
> For example, classes 3, 4, 5 & 6.
>
> Just curious.  Thanks,
> Steve

Received on Friday, 30 March 2001 12:51:20 UTC