Re: Summary of ETag related issues in RFC2518bis

Cullen Jennings wrote:
> 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

As of now (RFC2616 + RFC2518), we don't know. A server is free to reject 
whatever it feels to. If anybody thinks this is not the case, please 
back that up with references to normative specification text.

But is it good that a client won't know until it tries, potentially 
getting a 415 status code? No, thus the proposal to make that feature 
discoverable.

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

Nobody is saying that, as far I can tell.

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

Nope.

> 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 want servers to be able to do (1). I want clients to be able to detect 
(3). I want as many clients as possible to talk to servers that do not 
guarantee (3).

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

Yes.

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

I think there's a broad consensus that Calendaring servers and Atom 
servers should be able to be WebDAV servers as well.

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

How does this make a difference to the client? It may either have to 
manage to live with a 4xx upon PUT, or with content being different from 
what he thought he stored. Yes, that's an edge case, but it's VERY 
similar to the case where a Calendaring server or an Atom server drops 
parts of the content that was PUT because it didn't fit with the 
servers's internal data model.


Best regards, Julian

Received on Monday, 19 December 2005 23:05:15 UTC