Re: Thoughts on relation to WebDAV

Julian Reschke wrote:
> 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.
>
Whether the server believes it is irrelevant does not matter. When the 
server announces full support for WebDAV, using the DAV-header, the 
client is allowed to interpret it according to the specification. When 
this causes trouble, the responsibility is on the side of the server 
that intentionally sent wrong information.


> 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.
>
Now, as you would not have removed the DAV-header anyway, you ought to 
respect it, as defined in the specification. If you want to deprecate 
it, say it loud and *clear*. What I oppose is your suggestion to 
intentionally misuse it (Send DAV: 1 and not support required methods) 
and this way render it useless.


> 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?
>
Looks like a CardDav (?) problem, and they really seem to be in trouble 
here. If they really want to restrict to flat collections, which means 
no MKCOL, they are not compliant to WebDAV and should not use the 
DAV-header (you don't like it anyway). But as they intend to create an 
extension protocol, there surely is way to handle this properly.


> Do you have evidence of a server that actually *does* support 
> arbitrarily deeply nested collections? What am I missing here?
>
Not allowing arbitrarily deeply nested collections is not the same as 
not allowing the creation of collections at all. This looks like a use 
case for 403, according to the specs.


>> 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)
As far as I know unicode is allowed in pathsegments and there is a rule, 
how to escape them. The practical issue seem to me different reserved 
characters on different operating systems. I have know solution, but 
education. Perhaps servers should reject pathnames that cry for trouble.


>> - whether or not path segments are case-sensitive
Neither servers nor clients should change the case.


>> - the maximum length of a path segment
>> - the maximum number of path segments
>> - the maximum total lenth
>> - size constraints for property values
Are these real problems today. As long as people have a minimum of good 
taste, there should not be a problem. In most other cases servers are 
allowed to simply reject such request.


>> 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).
>
This could be arguments, when you start an *open* discussion to remove 
the DAV-header from the spec.


> 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
>
I think "store" or not "store" is not in the scope of the spec. But 
neither a server nor a client is allowed to silently change the URL of a 
resource (and expect it to work) (with the exception when the server 
forgot about the trailing slash of a collection-URL). If a server does 
not like a new URL created by a client, it should reject it.


> - whether or not content written with PUT can be rewritten by the server
>
It is out of the spec what a server is allowed to do with its resources. 
But in my opinion: regarding distributed authoring, co- and 
anti-authoring by the server is the last think we need.

BTW: Is anybody, who refuses to accept clear misuse of protocol 
elements, obliged to answer this - quite unrelated - questions? Is this 
a test, whether I am allowed to open my mouth when important people are 
talking about standards?

Werner

Received on Sunday, 25 May 2008 21:21:09 UTC