Re: The version element and workspaces

Slightly OT: The DAV-compliance level as defined in RFC2518 is not of 
much use, since it does not offer much granularity. In real life, a 
server is able to support a feature or it is not, and since a server 
should try to support as many features as possible, any combination of 
supported features might occur at the end of the day. So the additional 
resource properties as defined in RFC3253 section 3.1 make more sense.

Regards,
Manfred

Werner Donné wrote:
> If new clients should work with older servers there should be
> a mechanism for a client to detect the compliance level of the
> server. It can then act accordingly. In RFC 2518 the DAV header
> seems to be used for this. I don't find such a mechanism in
> RFC 3253.
>
> Regards,
>
> Werner.
>
> Geoffrey M Clemm wrote:
>   
>> Any new addition to the specification will cause any client that uses
>> that addition to fail against older servers that were implemented
>> before that addition was defined.  To avoid this kind of failure,
>> we do not introduce changes in revisions of the specification unless
>> the benefit provided by that feature outweighs the cost of those failures.
>>
>> Cheers,
>> Geoff
>>
>> Werner Donné <werner.donne@re.be> wrote on 03/31/2006 06:50:00 AM:
>>     
>>> Geoffrey M Clemm wrote:
>>>       
>>>> One would need to identify a significant interoperability or performance
>>>> problem in order for it to merit a revision to the specification.  
>>>> I don't think either would apply to this extension.
>>>>         
>>> Neither interoperability nor performance have anything to do with it. The
>>> proposed extension doesn't break anything and if using a label in this
>>> context could present a performance problem, then it would too in the
>>> contexts where it is used now. It is only a matter of consistency. When
>>> the label feature is supported, labels can be used for version selection
>>> when a VCR is given, only not in all situations, for which I see no
>>>       
>> reason.
>>     
>>> The use-case for workspaces is also very valid. When activities are
>>>       
>> supported
>>     
>>> and used for branching, it is common to define the start of a new branch
>>> based on a label instead of a physical version. Otherwise you can forget
>>> about more advanced configuration management practices.
>>>
>>> Why would interoperability and performance problems be the only reason for
>>> a revision? This implies that the current feature set should be considered
>>> as perfect, because how did the current features make it into the
>>> specification
>>> then? How does the revision process work?
>>>
>>> Performance is a non-issue. There is nothing shocking in WedDAV that would
>>> cause performance problems by definition and I don't see why additions
>>>       
>> would.
>>     
>>> The implementation should be sofisticated enough or simply not implement a
>>> feature.
>>>
>>> I agree that an extension shouldn't break interoperability, unless in a
>>> major upgrade. Note, however, that this is not the same as requiring
>>> that most existing implementations are able to implement it, because that
>>> would mean the specification is not leading but merely consolidating an
>>> existing state of affairs. WebDAV deserves to be more than window dressing
>>> of existing products.
>>>       
>
>