Re: Thoughts on relation to WebDAV

Werner Baumann wrote:
>  > The problem arises when clients use in-band information for the wrong
>  > purpose; for instance refuse to use PROPFIND, just because OPTIONS
>  > doesn't return a DAV header.
> 
> They use the information just for the purpose it is intended for. A 
> WebDAV-client checks the DAV-header to see, whether the server is a 
> WebDAV-server (at what are the capabilities).

But most of the time, a client doesn't need to know that. For instance, 
when displaying folder contents. Either PROPFIND is there or not. What 
other parts of WebDAV are there is just irrelevant for that.

> Your idea of partial implementation of WebDAV isn't mentioned in the 
> spec and it was probably unknown to the implementers of WebDAV-clients. 
> When you come up with a new idea, you will have to ask implementers for 
> support.
> What you propose is: fool the clients by sending wrong information in 
> the DAV-header and then misuse status code 403 to reject what the 
> clients can expect to succeed. If this really is done, one element of 
> RFC 4918, the DAV-header is rendered useless.

I happen to believe that it is not really useful, yes.

> I can see, that you think it useless anyway. But RFC 4918 was released 
> just one year ago and you are one of the 4 creators of this document. 

No, I'm not. The "creator" is the working group in total, or, if you 
wish, the Editor acting on behalf of the working group.

But even if I was, I wouldn't have removed or changed it; maybe I would 
have pointed client implementors to smarter ways to detect functionality.

What the WG did was looking at all issues that had been raised against 
RFC2518, and trying to resolve as many as possible in RFC2518bis.

Usage patterns for compliance levels were IMHO never discussed, so 
changing this was never on the table, at least not as far as I recall.

What was discussed and fortunately rejected was a requirement to return 
the DAV header upon "OPTIONS *", btw.

And, for the record; I tried to stop the addition of another compliance 
level (L3), because, after all, RFC4918 is meant to be 
backwards-compatible, and all the extensions we did can be detected in a 
smarter way anyway.

> Undermining this specification the way you do, is what does not fit in 
> my world and what I call "not taking standards seriously".

I think you read much more into the compliance levels than it was intended.

Getting back to what got us here (I think): are you saying that a server 
that exposes a flat collection of items (such a set of vcards) is not 
allowed to say "I'm doing WebDAV" because it doesn't allow creating 
child collections?

Do you have evidence of a server that actually *does* support 
arbitrarily deeply nested collections? What am I missing here?

BR, Julian

PS: I note that you still didn't followup on 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2008AprJun/0046.html>:

> In practice, there are many things that RFC2518 and RFC4918 do not even 
> talk about, but will affect conformance and interoperability:
> 
> - the set of characters allowed in path segments (think Unicode 
> normalization)
> - the maximum length of a path segment
> - whether or not path segments are case-sensitive
> - the maximum number of path segments
> - the maximum total lenth
> - size constraints for property values
> - ...
> 
> One key feature of HTTP and protocols based on HTTP is that messages and 
> responses are self-descriptive, and that close coupling (as in WS-*) is 
> avoided. Yes, it's always nice to know upfront if a server is going to 
> allow something (being it out-of-band by spec, by introspection 
> (OPTIONS), whatever...). But in practice, a client will have to deal 
> with unexpected errors (and yes, good status codes help with that).

Let me add a few more:

- whether path segments are stored as is (using URI escaping), byte 
sequences (Unix/Posix file IO) or character sequences (Windows, HFS+)

- how trailing blanks are handled (ignored vs stored)

- how trailing dots are handled

- whether or not content written with PUT can be rewritten by the server

and so on...

PS2: Again, for the record: I totally agree with you that a server needs 
to implement things in a consistent, meaningful way. Such as, HEAD and 
GET need to work as required by HTTP/1.1, and PROPFIND responses should 
be consistent with HEAD/GET responses.

Received on Sunday, 25 May 2008 19:22:00 UTC