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

From: Lisa Dusseault <[email-masked]>
Date: Fri, 2 Dec 2005 14:09:44 -0800

I finally paged in enough context to be able to consider this set of 
changes.
In particular, the justification, from bug text:
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188>

"The difference here is that with the originally proposed extension, 
the client
can tell whether the server evaluated the extension, while with the 
definition
in RCF2518bis, it can't (it has no way knowing whether the server just 
ignored
the extension, or happens to have no dead properties)."

That's not quite true, the server MUST support dead-props if it 
advertises
support for 'bis'.   Besides, a smaller fix could be for the server to 
return an
extra element saying "no-dead-props".

That said, has anybody at all implemented this?  If not, then I guess 
the change is
harmless even if the justification isn't quite true.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Dec 2005 23:16:04 +0100

Lisa Dusseault wrote:
> "The difference here is that with the originally proposed extension, the 
> client
> That's not quite true, the server MUST support dead-props if it advertises

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).

> harmless even if the justification isn't quite true.

We have implemented it but found we're not using it in our own client 
for the reasons given above. So the new revised proposal isn't based on 
theory, it's based on running code. This is the approach we find is 
working, and we've been using it since 2002 when we initially proposed it.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 4 Dec 2005 09:15:44 -0800

On Dec 2, 2005, at 2:16 PM, Julian Reschke wrote:

>> in RCF2518bis, it can't (it has no way knowing whether the server 
>> just ignored
>> support for 'bis'.   Besides, a smaller fix could be for the server 
>> to return an
> 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.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Dec 2005 01:29:40 +0100

Lisa Dusseault wrote:
>> discovered individually (such as support for DAV:lockroot, for example).
> 

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 15:32:45 -0800

> particular if this set contains stuff that can't be implemented by some.

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.