Re: Summary of ETag related issues in RFC2518bis

Let's say Alice has a compliant webdav client that stores gif files, and Bob
has a compliant dav server? Will these things work together?

I can imagine a couple answers:

1) we don't know, it might work, it might not - there is really no way to
know

2) no Alice's client is not compliant because the only thing a webdav server
has to store is HTML

3) yes, given it passes policy constraints, such as no virus in gif file,
size of file, total size amount of quota, valid account and password, all is
fine...

I'm confused - which one of these does the WG want. This is actually a
specific instance of a meta issue. The meta issue is are we making things
easy for both client and server side in a way that causes it to be unclear
if the a client and server can actually work together.

I may not understand the issue here and I don't care how we solve it, but it
seems to me that a client and server should be able to work together.


few bits inline ...

On 12/19/05 11:07 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> R4) Require servers to store arbitrary binary content
> 
> There are servers that don't, examples may be Atom servers, Calendaring
> servers, and any kind of server that uses HTTP/Webdav to expose specific
> types of resources with no generic store available.

This seems irrelevant. They are not DAV servers, they are complain to some
other RFC that does use DAV as the protocol but adds additional constraints,
extensions, and semantics such as only iCal files can exists at a given URI.

> 
> Even if this would not be the case, I have to point out that the spec
> currently mentions scenarios where servers may rewrite content without
> notice (see 
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-09.html#rfc.sec
> tion.19.8>).


Again this example is more along the lines of a specific policy modification
that was done to the data to meet certain security requirements.

Received on Monday, 19 December 2005 22:07:51 UTC