Subject: Re: Thoughts on relation to WebDAV

From: Werner Baumann <[email-masked]>
Date: Fri, 23 May 2008 22:56:54 +0200

Julian Reschke wrote:
 > There are many ways how a server can refuse to do MKCOL. It can
 > always claim "forbidden", it can say "not implemented" etc.
 >
 > In practice it means the client won't be able to create collections.

So we need only two status codes in HTTP: success, no success.
Ever occurred to you, that an error code should inform about the reason 
of the failure and that this reason makes a difference in practice?

403 says, the server can create collections, but it will not create 
*this* collection.
501 says, the server is not able to create collections at all.

Can't you imagine, that clients and users might react differently in 
this two cases? Never seen a windows-user, completely mixing up the 
system configuration, just because of an idiotic, misleading error message?

RFC 4918 has silently removed the requirement for servers to support 
MKCOL. This (together with compliance class 3) has lead to confusion 
(see this thread). But it does not matter in practice?
Will it not effect the development of clients, whether they can trust in 
support of MKCOL by all compliant servers? They can always decide to not 
support badly broken servers, but they can hardly explain why they will 
not support compliant ones.
If you buy a WebDAV-server from a vendor and later notice it does not 
support MKCOL. Does it matter whether this is standard compliant?

Was the requirement for supporting MKCOL removed by intention or by an 
editorial mistake. RFC 4918 lists three contributors and one author. One 
of them (Julian Reschke) says "It wasn't intentional". There is an 
Errata document with three entries, all by Julian Reschke. But 
unintentional removal of a WebDAV-method from the requirements is not 
worth an entry in Errata, because it does not matter in practice.

I believe internet standards should be taken more seriously.

Werner

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 23 May 2008 14:32:41 -0700

Hi,

The omission of a MUST or REQUIRED statement for MKCOL itself was  
unintentional as far as I can remember.  There was certainly no intent  
to make MKCOL optional -- I think that other sections, luckily, make  
that obvious even if it's not explicit.

BTW, I like summary sections that list every major feature which is  
required to be implemented, and every major feature that is optional  
-- they make it easy to ensure that the document is clear about every  
feature.  We did that in  CalDAV <http://tools.ietf.org/html/rfc4791#section-2 
 >.

If I entered an errata I could probably also approve it as document  
author AND as AD, but that might be in bad taste.

I appreciate your injunction to take Internet standards more  
seriously, but I'm afraid you really are preaching to the choir!

Thanks,
Lisa

On May 23, 2008, at 1:56 PM, Werner Baumann wrote:

> Ever occurred to you, that an error code should inform about the  
> reason of the failure and that this reason makes a difference in  
> practice?
>
> Will it not effect the development of clients, whether they can  
> trust in support of MKCOL by all compliant servers? They can always  
> decide to not support badly broken servers, but they can hardly  
> explain why they will not support compliant ones.
> If you buy a WebDAV-server from a vendor and later notice it does  
> not support MKCOL. Does it matter whether this is standard compliant?
>
> Was the requirement for supporting MKCOL removed by intention or by  
> an editorial mistake. RFC 4918 lists three contributors and one  
> author. One of them (Julian Reschke) says "It wasn't intentional".  
> There is an Errata document with three entries, all by Julian  
> Reschke. But unintentional removal of a WebDAV-method from the  
> requirements is not worth an entry in Errata, because it does not  
> matter in practice.
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 24 May 2008 09:48:12 +0200

> So we need only two status codes in HTTP: success, no success.

No, we need many more.

> 501 says, the server is not able to create collections at all.

Yes.

So I'd say that it's better if a server actually states 501 when it 
can't create *any* collections.

> system configuration, just because of an idiotic, misleading error message?

Is this a rhetoric question?

> not support compliant ones.

The point is that it's not the spec language that will influence the 
decision whether to allow creation of collections or not.

If a server has a data model that supports collections, it will 
implement MKCOL. Otherwise it won't. No matter what the spec says.

So if you want to expose a set of HTTP resources for authoring, and you 
can support all of WebDAV L2 and L3, *except* creating new collections, 
what would you return in the DAV: response header upon OPTIONS?

I bet you'd claim support for MKCOL, return level 3, and then fail the 
request if somebody tries to MKCOL anyway.

> support MKCOL. Does it matter whether this is standard compliant?

So how exactly is it an improvement to the client when the server claims 
it can do MKCOL, but always returns 403? That would be compliant with 
RFC2518, but not helpful it all.

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

> worth an entry in Errata, because it does not matter in practice.

I did say it should be in the errata. Please raise it.

> I believe internet standards should be taken more seriously.

Nit: RFC4918 is a Proposed Standard. Not an "Internet Standard", at 
least not in RFC speak.

I totally agree that IETF specs should be taken seriously. Believe me, 
if I didn't I certainly wouldn't spend so much time trying to revise them.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 24 May 2008 09:56:34 +0200

Lisa Dusseault wrote:
> ...
> I appreciate your injunction to take Internet standards more seriously, 
> but I'm afraid you really are preaching to the choir!
> ...

Speaking of which, it would be nice if the errata that *have* been 
reported previously would get verified at some point of time (for now, 
only of of the three at 
<http://www.rfc-editor.org/errata_search.php?rfc=4918> was).

BR, Julian

---

From: Helge Hess <[email-masked]>
Date: Sat, 24 May 2008 12:37:10 +0200

> 501 says, the server is not able to create collections at all.

Just for completeness, I think 501 just says that the collection MKCOL  
was called on does not support MKCOL. Other collections on the same  
server might support that method.

I think Werner's point is that 403 has specific semantics and I would  
agree. To me 403 implies that the user could potentially create  
collections with better credentials. While 501 signals that the server  
really can't support MKCOL.
That _is_ relevant for the error message reported by the client.

IMHO the confusion started when Julian suggested that a server should  
return 403 if its a "read-only CardDAV implementation". Note the 'read- 
only _implementation_'. I think returning 403 would be quite wrong in  
this case, it should definitely return 501.

As mentioned, practial consequences which immediatly come to mind are:
- misleading error message towards the user
- pointless retries with other (higher level) credentials

As far as I can see levels are just a really minor optimization on the  
operations a client might attempt (never attempt to LOCK if we already  
know its not level2, but then we have the method info in OPTIONS  
anyways?!).
Maybe the spec puts too much emphasis on levels.

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

---

From: Werner Baumann <[email-masked]>
Date: Sat, 24 May 2008 14:16:51 +0200

> request if somebody tries to MKCOL anyway.
What was the bet about? A barrel of beer? You lost the bet.

> RFC2518, but not helpful it all.

It is not an improvement at all. In my opinion it would be fraud.
A server that does not support creation of collections is *not* 
compliant with RFC 2518 (and, I hope, with RFC 4918 neither) and must 
not send a DAV-header at all. Hiding this none-compliance by misusing 
403 makes things worse.

This does not mean, that it is not allowed to create and use servers and 
clients, that do not meet all requirements of the standard (or the 
proposed standard), and therefore are not compliant. But these needs to 
be documented and server and clients will need out of band information 
about their capabilities to be set up properly. There will be no 
guarantee for interoperability with other clients or servers. These 
cases are outside the spec.

Werner

---

From: Petr Tomasek <[email-masked]>
Date: Sat, 24 May 2008 15:20:39 +0200

> not send a DAV-header at all. Hiding this none-compliance by misusing 

But every webdav client I've seen REQUIRES the DAV-header to operate on
an URL as on a WebDAV collection. So it means You would practically disalow
any partial (e.g. a read-only) WebDAV implementation, even if it works
correctly and the full-fledged functionality is not needed at all!

> cases are outside the spec.

So the spec is wrong and insane if it doesn't allow for a partial implementation.
Sorry.

-- 
Petr Tomasek <http://www.etf.cuni.cz/~tomasek>
Jabber: [email-masked]
SIP: [email-masked]

---

From: Jack Cleaver <[email-masked]>
Date: Sat, 24 May 2008 15:01:10 +0100

Petr Tomasek wrote:
> 
> But every webdav client I've seen REQUIRES the DAV-header to operate
> on an URL as on a WebDAV collection. So it means You would
> practically disalow any partial (e.g. a read-only) WebDAV
> implementation, even if it works correctly and the full-fledged
> functionality is not needed at all!

I don't see it that way.

A partial implementation is one that doesn't implement the spec.
A read-only implementation is one that implements the spec, but doesn't
permit write operations.

There is a variety of reasons why write operations might not be
permitted by a compliant server. The client might not have sufficient
privileges, or the operation might be permitted at some other location,
or the repository might forbid all write operations for whatever reason.
Or the server software might *by design* not allow write operations.

It seems perfectly reasonable to assert that one supports MKCOL, but to
then refuse to perform this operation in every case, giving an
appropriate status-code. After all, if one *really* didn't support the
operation, then one would return a 501. Supporting an operation doesn't
imply performing it when it "should not" be performed. What "should not"
means is determined by the implementor.
> 
> So the spec is wrong and insane if it doesn't allow for a partial
> implementation. Sorry.

This is silly. A partial implementation of a spec is not an
implementation at all (unless the spec explicitly provides for optional
elements - in which case the implementation is arguably not a partial one).

L1 (2518) says you MUST support MKCOL. That implies that a 501 is always
an incorrect response from an L1(2518)-compliant server.

Incidentally, there's nothing wrong with borrowing those parts of a spec
that you need, and ignoring the rest; this will only cause problems if
your software is expected to interact with other software that relies on
proper compliance with that spec, and furthermore your software claims
to be compliant when it isn't.

-- 
Jack.

---

From: Werner Baumann <[email-masked]>
Date: Sat, 24 May 2008 18:13:54 +0200

> correctly and the full-fledged functionality is not needed at all!

What the hell is a "read-only WebDAV implementation"? WebD*A*V is about 
*Authoring*. There is no read-only authoring. Enabling write-operations 
is at the very heart of WebDAV. If any server cannot support it, it 
should not claim to do WebDAV.

What you are talking about is an HTTP-Server with some extensions taken 
from WebDAV or maybe others. But what WebDAV-methods from RFC 4918 could 
a read-only server implement? PROPFIND, and nothing else.

Please do not mix up two things:

- servers that do not support certain required methods at all:
   they are simple not WebDAV-servers and should respond with
   status code 501 to such requests.

- refusing requests on certain resources or under certain
   circumstances:
   this is allowed and treated with in the spec. Usually 4xx status
   codes are appropriate. But this implies, that the same kind of
   request can be successful for another resource or under other
   circumstances.

BTW: 403 Forbidden is *not* related to authorization; that's 401.

Werner

---

From: Petr Tomasek <[email-masked]>
Date: Sat, 24 May 2008 22:13:38 +0200

On Sat, May 24, 2008 at 06:13:54PM +0200, Werner Baumann wrote:
> *Authoring*.

Sorry, but this is silly! According to such an interpretation one
couldn't use e.g. the HTTP protocol for anything else, than a hypertext!

Rather, the WebDAV is most commonly used as a network filesystem
implemented over HTTP and as such it makes much sense to have
a read-only filesystem.

---

From: Helge Hess <[email-masked]>
Date: Sun, 25 May 2008 10:11:01 +0200

> BTW: 403 Forbidden is *not* related to authorization; that's 401.

You are right! Weird, I always got this wrong. (RFC 2616,  
10.4.2/10.4.4 explicitly states what you say).

Summary: even if the user is authenticated, one would reissue a 401 if  
access is denied to a resource. Which makes me wonder in what (real  
world) situations one would use 403 then.

Actually in the real world having to send a 401 for access-denied will  
probably confuse almost any client. It will _clear_ authentication in  
almost any (in fact many webapps rely on that for the 401-logout-hack).

Also: RFC 3744 contradicts with that? Eg it says (3. Privileges):
   http://webdav.org/specs/rfc3744.html#privileges

   'Servers must report a 403 "Forbidden" error if access is denied'

The whole RFC goes like this.

I'm confused ;-/

Thanks,
   Helge

---

From: Werner Baumann <[email-masked]>
Date: Sun, 25 May 2008 11:14:38 +0200

> implemented over HTTP and as such it makes much sense to have
WebDAV is not a network file-system and never was intended to be. Please 
read the documents, e.g.
ftp://ftp.rfc-editor.org/in-notes/rfc2291.txt and
ftp://ftp.rfc-editor.org/in-notes/rfc4918.txt

I am maintaining a WebDAV-file-system (davfs2, which is not a network 
file-system but an intermediate solution for authoring tools without 
built-in WebDAV-support). My experience with this work tells me:
It is impossible to cleanly map WebDAV-resources into a 
Unix-file-system. Though I am not really happy with RFC 4918, this point 
is not the fault of the specification, because it was never intended for 
this use.

It has become common practice, to reuse existing protocols for new 
applications. That's OK. But when it turns out, that the chosen protocol 
does not really meet the requirements of this application, there is the 
bad habit of tweaking the original protocol, up to the point where it 
gets unusable for its original intention. This must stop.

"preaching to the choir" again
Werner

---

From: Werner Baumann <[email-masked]>
Date: Sun, 25 May 2008 11:54:56 +0200

> world) situations one would use 403 then.
Access restrictions based on IP-address might cause a 403, for instance. 
Basically:
- 401 says: authenticate and the request will succeed
- 403 says: denied, and authentication will not help.

Actually, RFC 2616 says:
401 Unauthorized
it is *not* "401 for access-denied"

> almost any (in fact many webapps rely on that for the 401-logout-hack).
I only know about HTTP-Basic- and HTTP-Digest-authentication. In this 
cases the client will include authentication information with every 
request. A 401 response includes information about the realm of 
authentication. A client will either repeat the request with 
authentication information included, or give up, if it can't 
authenticate for that realm. In practice: servers may require different 
authentication for different parts of their resources. A new request 
from the client may leave one realm of authentication and enter another 
one (e.g. some directory is only allowed for authenticated users; within 
this is an area only allowed for administrators).

> The whole RFC goes like this.
I never cared about RFC 3744. But at first sight, this looks like not 
being related to HTTP-authentication, but to be specific to privileges, 
ACEs and whatsoever defined in RFC 3744. It probably only makes sense 
when read within this context.

Werner

---

From: Julian Reschke <[email-masked]>
Date: Sat, 24 May 2008 18:38:52 +0200

> server might support that method.

Yes. So would that collection be "WebDAV compliant"?

Yes.

> That _is_ relevant for the error message reported by the client.

So it's better to say 501 than 403. But are you allowed to say 501 and 
be compliant to RFC2518 at the same time?

> return 403 if its a "read-only CardDAV implementation". Note the 
> 'read-only _implementation_'. I think returning 403 would be quite wrong 
> in this case, it should definitely return 501.

What I tried to say is that the "MUST support MKCOL" requirement may 
lead an implementor to return 403 instead of 501, which has zero value 
to a client which is trying to figure out why the request failed.

Yes.

Levels are problematic.

+ Clients can rely (sometimes) on specific feature sets (for instance, 
with DeltaV's compliance levels)

+ It's easier to communicate what a server can do

- When clients refuse to do something because the right compliance level 
is missing, server implementors may be tempted to lie (as far as I 
recall, the MS Webfolder client never will try PROPFIND unless OPTIONS 
says level 1 is reported -- so you can't enhance a "simple" HTTP server 
with just PROPFIND support for browsing).

In general I would advise clients to pay attention to the OPTIONS Allow 
response header and to status codes, not compliance levels (and, for 
modern servers, to DAV:supported-live-property-set and 
DAV:supported-method-set).

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 24 May 2008 18:44:36 +0200

Werner Baumann wrote:
>> So if you want to expose a set of HTTP resources for authoring, and 
>> you can support all of WebDAV L2 and L3, *except* creating new 
>> collections, what would you return in the DAV: response header upon 
>> OPTIONS?
>>

So, what would you do instead then?

Sell a server or service that doesn't work with several popular clients?

>> So how exactly is it an improvement to the client when the server 
>> claims it can do MKCOL, but always returns 403? That would be 
>> compliant with RFC2518, but not helpful it all.
>>
> 

Well, sorry. It seems we live in different worlds then.

If you insist on that ideal world you'll probably never find a fully 
compliant server (not because of MKCOL, but because of the more subtle 
problems I mentioned -- I noticed you didn't follow up on these...).

> cases are outside the spec.

That's true.

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.

In reality you need to deal with these kinds of clients, at least if you 
don't have the luxury to tell the customers just to get a different client.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 24 May 2008 18:47:53 +0200

All true.

Consider this: you can have a fully compliant implementation that 
exposes a single WebDAV compliant resource, which is empty, has no 
custom properties, and returns 403 to MKCOL/LOCK/MOVE/COPY etc.

Not useful, but compliant.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 May 2008 18:12:09 +0200

Helge Hess wrote:
> You are right! Weird, I always got this wrong. (RFC 2616, 10.4.2/10.4.4 
> explicitly states what you say).
> 

That's incorrect.

401 means you need to authenticate. 403 means, you're not allowed to do 
what you want to do.

> The whole RFC goes like this.

The RFC is right. 403 means "forbidden".

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 May 2008 18:16:31 +0200

> ftp://ftp.rfc-editor.org/in-notes/rfc4918.txt

I would rephrase this as "it's not its single purpose".

> gets unusable for its original intention. This must stop.

There's nothing wrong with tweaking/extending a protocol for things it 
wasn't designed for. It would be wrong to do something like that if it 
negatively affected existing usage.

Could you be a bit more specific of where you think this is happening?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 May 2008 18:18:24 +0200

> - 401 says: authenticate and the request will succeed

Nope. It means: "authenticate, and the request will not fail again with 
401. But potentially in a different way".

> - 403 says: denied, and authentication will not help.

Exactly.

BR, Julian

---

From: Helge Hess <[email-masked]>
Date: Sun, 25 May 2008 20:43:49 +0200

On 25.05.2008, at 11:54, Werner Baumann wrote:
> Helge Hess wrote:
>> Summary: even if the user is authenticated, one would reissue a 401  
>> if access is denied to a resource. Which makes me wonder in what  
>> (real world) situations one would use 403 then.
>> Access restrictions based on IP-address might cause a 403, for  
>> instance. Basically:

'might' succeed. Since it can't know the credentials in advance, it  
can't say that any authenticated credentials will be authorized.

> - 403 says: denied, and authentication will not help.

Yes, thats what the spec is saying :-/

> it is *not* "401 for access-denied"

I was surprised, but the RFC actually says that: "If the request  
already included Authorization credentials, then the 401 response  
indicates that authorization has been refused for those credentials."

This is access-denied (the user is authenticated, but not authorized).

>> Actually in the real world having to send a 401 for access-denied  
>> will probably confuse almost any client. It will _clear_  
>> authentication in almost any (in fact many webapps rely on that for  
>> the 401-logout-hack).
>>
> I only know about HTTP-Basic- and HTTP-Digest-authentication. In  
> this cases the client will include authentication information with  
> every request.
[cut]

Yes. The problem is that according to the spec 401 is to be used for  
access denied. Most (all?) clients will ignore that the user is  
already authenticated and prompt him for new credentials instead of  
saying 'access denied'.

> I never cared about RFC 3744. But at first sight, this looks like  
> not being related to HTTP-authentication, but to be specific to  
> privileges, ACEs and whatsoever defined in RFC 3744.

Can't follow you.

Thanks,
   Helge

---

From: Helge Hess <[email-masked]>
Date: Sun, 25 May 2008 21:01:43 +0200

On 25.05.2008, at 18:18, Julian Reschke wrote:
> Nope. It means: "authenticate, and the request will not fail again  
> with 401. But potentially in a different way".

Why? It explicitly states that it may fail again with 401, if  
*authorization* fails for the *authenticated* user:
---snip:10.4.2---
If the request already included Authorization credentials, then the  
401    response indicates that authorization has been refused for those
credentials.
---snap---

>> - 403 says: denied, and authentication will not help.

It says: "Authorization will not help".
http://www.duke.edu/~rob/kerberos/authvauth.html

Anyways, not really relevant.

So what to do, there is resource /addressbook/donald.vcf. User  
'mickey' is authenticated for the relevant domain but is not  
authorized to access that specific resource. User 'dagobert' *is*  
authorized to access donald.vcf, so (re-)authentication with different  
credentials would help.

Given that 403 says "Authorization will not help" and 401 says "If the  
request already included Authorization credentials, then the 401  
response indicates that authorization has been refused", I would  
derive that mickey should get a 401.

It seems a bit weird to me from a practical point of view, but can it  
actually be read in a different way?

Thanks,
   Helge

---

From: Werner Baumann <[email-masked]>
Date: Sun, 25 May 2008 21:11:20 +0200

Helge Hess wrote:
> I was surprised, but the RFC actually says that: "If the request already 
> included Authorization credentials, then the 401 response indicates that 
> authorization has been refused for those credentials."
> 
NO! It isn't. it is still "Unauthorized" and nothing else.
The server does not accept the credentials and wants the proper ones. As 
HTTP is stateless, the server server will repeat this until the user 
finally gets either the proper credentials or tired. Whether the client 
stops this at some point or waits for the user to get tired is a client 
issue, not a protocol issue.

>> request.
> access denied.
Where does the spec say this?

Werner

---

From: Helge Hess <[email-masked]>
Date: Sun, 25 May 2008 21:16:37 +0200

On 24.05.2008, at 18:44, Julian Reschke 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.

I was wondering about that. I think the issue is that PROPFIND is only  
defined by the WebDAV RFC. Just having an Allow: PROPFIND doesn't  
necessarily imply that its the PROPFIND method with the payload as  
specified in WebDAV?

Hm, maybe we really need WebDAV level -1, which just specifies  
PROPFIND? :-)
I think it really doesn't matter for interoperability in the real  
world though.

Greets,
   Helge

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 May 2008 21:29:08 +0200

> necessarily imply that its the PROPFIND method with the payload as 

That's a good point, considering the lack of an HTTP method registry.

Which, as a matter of fact, is an open issue for HTTPbis.

> Hm, maybe we really need WebDAV level -1, which just specifies PROPFIND? 
> :-)

No, discovering Allow: PROPFIND should be sufficient, just as it is for 
header names and status codes defined in WebDAV (these have IANA 
registries).

> I think it really doesn't matter for interoperability in the real world 
> though.

Right, it doesn't matter in practice (*smiles and ducks*).

But as it matters in theory, and we take internet protocols seriously, 
we'll be adding the missing registry (see 
<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/72>).

BR, Julian

---

From: Werner Baumann <[email-masked]>
Date: Sun, 25 May 2008 22:08:31 +0200

> necessarily imply that its the PROPFIND method with the payload as 
As I read RFC 2616, it indeed allows the use of methods not defined in 
RFC 2616, and it proposes to announce this in an Allow-header in 
response to OPTIONS. No need for the DAV-header, when you only want to 
support PROPFIND.
Your concern it might not be the PROPFIND defined in RFC 4918. Now it's 
may part to ask: does that really matter in practice? WebDAV is around 
for some years. Do you expect there is another HTTP-PROPFIND-method?

But Julian's concerns seem to be WebDAV-clients written before somebody 
came up with the idea of implementing only parts of WebDAV. They will 
not use this. In my opinion you have to be patient, talk to client 
implementers or write your own client. Fooling older clients, by using 
protocol elements in a way, that clearly contradicts the specification 
(and that's what we are talking about), must not be done.

Werner

---

From: Helge Hess <[email-masked]>
Date: Sun, 25 May 2008 23:02:29 +0200

On 25.05.2008, at 22:08, Werner Baumann wrote:
> Fooling older clients, by using protocol elements in a way, that  
> clearly contradicts the specification (and that's what we are  
> talking about)

Thats what _you_ are talking about ("clearly contradicts the  
specification"?!). So far I have seen no one who supports your  
arguments.
(though please, there is no need to reiterate your claims, I think  
everyone understood what your position is)

BTW: I do not even agree that it is invalid to return 501 in response  
to MKCOL. For me a requirement to support MKCOL just means that the  
server knows what implementing MKCOL implies according to WebDAV, that  
it expects to receive a MKCOL request and can then respond with any  
valid HTTP code (given that WebDAV is a strict HTTP superset).
But that is just how I read the combination of the specs.

Thanks,
   Helge