W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 188] PROPFIND include-dead-props

From: Cullen Jennings <fluffy@cisco.com>
Date: Tue, 13 Dec 2005 15:32:45 -0800
To: Julian Reschke <julian.reschke@gmx.de>, Lisa Dusseault <lisa@osafoundation.org>
CC: WebDav <w3c-dist-auth@w3.org>
Message-ID: <BFC49A1D.653A0%fluffy@cisco.com>

On 12/4/05 4:29 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> 
> Lisa Dusseault wrote:
>>> But if a server implements "bis", it MUST also support lots of other
>>> unrelated features. This is a question of granularity, and optimally,
>>> we won't need "bis" at all because all the things we add can be
>>> discovered individually (such as support for DAV:lockroot, for example).
>> 
>> This isn't my idea of optimality.  Servers should implement all of
>> RFC2518bis, not cherry-pick bits and pieces.
> 
> On the other hand, putting a set of totally unrelated changes into one
> single bag, and hoping that server implementors will be thrilled to
> implement all of this or nothing at all isn't realistic either. In
> particular if this set contains stuff that can't be implemented by some.
> 
> Best regards, Julian

IETF has long tried make its protocols such that if you have a FOO server
and a FOO client, they will work together. Clearly the easiest for the
server would be to provide very few things, and the easiest for the client
would be for the server to provide a lot of things. It's fine to say that my
client requires a server that does version 4 of the protocol but most people
seem to  have a pretty dim view of places where a server fully compliant
with RFC XXXX can't work with a given client while all that client uses are
things defined in RFC XXXX.

I'd encourage the group to try and meet that sort of goal - I realize this
has some tradeoff at points, and thus the compliance class and other
profiling mechanism but realize they do have many problems and use
sparingly. 
Received on Tuesday, 13 December 2005 23:32:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT