- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Wed, 21 Apr 1999 08:17:31 -0400
- To: w3c-dist-auth@w3.org
As another server vendor, I vigorously support all of Greg's points. Like Greg and Jim, although very interested in any errors or lack of clarity in the current WebDAV RFC, I have little sympathy for attempts to change the semantics for anything short of a major interoperability problem. The time for fiddling around the edges has passed. Major vendors are coding against this specification. It is *far* more important that it be stable, than that it be "improved". There are at least three WebDAV extension working groups (Advanced Collections, Versioning, DASL). If you think that your extension/modification is important, you are free to propose it to one of those working groups, or start your own working group. But you will be held to the standard of maintaining interoperability with the existing WebDAV protocol. Cheers, Geoff From: Greg Stein <gstein@lyra.org> On Wed, 21 Apr 1999, Yoram Last wrote: > > A client can depend > > on a MUST requirement, but it cannot depend on SHOULD or MAY requirements. > > Furthermore, SHOULD and MAY requirements often lead to feature discovery, > > which complicates a protocol. MUST requirements generally increase > > interoperability, since they are features which can be expected to be > > present. > > In theory. More precisely, in the theory which is built on the axiom > that applications get implemented in a fully compliant manner. But, this > is almost never the case. Now in practice, a client (or server) designed > for maximum interoperability should make the minimal possible set of > assumptions about "good behavior" of the other side. It is usually both As a server implementor, I am going to code to the spec. If you have a broken client, then TFB. From my point of view, the theory that servers build to spec is absolutely valid. Several times people have pointed out conformance issues with mod_dav. That is definitely a bug, so I fix them. There is absolutely no way that I am going to help to propagate bad client programming practices. If a client doesn't interoperate with mod_dav and it is the client's fault, then I won't raise a finger. Your argument above seems to presume that implementors should compensate for buggy clients. That is simply Bad and Wrong. There is no justification for it. > I don't agree that this is an "undocumented feature" or a "side-effect". > It is a functional feature that includes the functionality of WebDAV PUT > along with MKCOL in one command. One could argue, in fact, that MKCOL is > not necessary, because one can implement it by PUTing a null (zero size) > file and then DELETEing it. (Some applications actually tend to do that The definition of PUT does **NOT** state that intermediates must be created. Therefore, I won't do it. What will you do now? Your clients better be able to deal with that fact. Any number of other servers will respond similarly, and those clients should be able to deal. [please excuse the belligerance here, but I feel that you're not sufficiently backing up your claims... Jim has asked for real-world examples of problems and you have not yet provided them. From my point of view, you have not shown that anything must "be fixed".] > implicitly, because they do a "write test" of this type before uploading > a file to a new location.) Issues like mis-types of intermediate collection This is just bogus. DAV at least defines a specific behavior for conformance. That absolutely helps the situation. Clients don't need to "test" what will happen. They will simply know. > saying it is the best way of doing things, but it is there. Now since > the simpler way of implementing PUT (on the server side) is to not have > it create collections, the fact that some server implementors made the > effort to enable it says that *they*, at least, considered it a feature > that is worthwhile implementing. Goody for them. That does not dispell the fact that clients that have not handled the situation for servers that have **NOT** implemented PUT this way. As long as those clients do not compensate, then they are broken. This is all quite valid per the HTTP/1.1 specification. > 1) Is it a bug that should have been avoided had it been thought of before? > > 2) Is it so huge a problem that it justifies by itself re-issuing the protocol > (or should play a major role in a decision to do so)? > > 3) Is it something that should be fixed in later revisions of the protocol? > > My answers are: > > 1) Yes it's a bug. A conflict of this type with HTTP/1.1 should not have been > introduced into the protocol. This is your subjective opinion. I do not believe this behavior is a bug. The HTTP/1.1 specification supports my server behavior (that of refusing to create intermediate collections). > 2) Most probably not. I believe that the actual interoperability problem here > is overall quite mild. As long as the actual *fact* is that the problem is mild, then this whole issue is totally moot. As Jim has asked, please demonstrate where this "issue" causes problems. What clients are *dependent* on the create-intermediate-collection behavior? The basic fact here is that RFC 2518 specifies a behavior that you do not agree with. From what I have seen, the consensus opinion seems to disagree with you. IETF is consensus based, and the issuance of an RFC creates a yet another bar for you to overcome. I certainly don't want to discourage you, but I *do* desire to make it clear that some objective facts will go a long way to help your case. > 3) Probably. It really depends on what happens between now and then. I think > that the probability of the current prohibition becoming really important > to any application is small, and so unless things turn out differently, > it should be fixed in the future. This is presumptive on the belief that a problem exists. I maintain none exists, so this point is moot. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Wednesday, 21 April 1999 08:17:48 UTC