- From: Yoram Last <ylast@mindless.com>
- Date: Wed, 21 Apr 1999 08:03:31 +0300
- To: w3c-dist-auth@w3.org
> > Why do you think that you must *require* things to be one way or > > the other? > > In general, when we stated a requirement in the specification, we made it a > MUST, and then needed to be argued down from that level, rather than > starting at a MAY or SHOULD, and arguing up to a MUST. This seems to explain why the protocol has so many MUSTs, including some that should really be SHOULDs. I don't think this design approach is necessarily better or worth than any other, but at the end of the day, MUSTs that should be SHOULDs are bugs, and SHOULDs that should be MUSTs are bugs. Both of these things create interoperability problems, and make life more complicated. > 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 safe and inevitable to assume that an application would behave in a compliant manner with respect to functionality that can't possibly be obtained otherwise, but it would be very dangerous to assume compliance with a non-essential protocol requirement just because it is a "MUST". Applications must (in the real sense of must) be compliant with those things that are truly essential because otherwise no partner program will be sufficiently tolerant to work with them. But if they fail to comply with something that is not really essential, then most partners would be sufficiently tolerant to deal with that. So you have this positive feedback dynamics that eventually filters out those things that are real MUSTs from those that are not. Therefore, the ideal thing is if the set of MUSTs in the protocol matches exactly those things that are truly essential, because this is the only way to achieve real-world compliance and to make it possible to write a working application by just looking at the requirements of the protocol. Otherwise things become more chaotic and writing interoperable applications becomes harder. > > Surely, ftp is more > > popular, but given the large number of PUT-enabled applications and the > > convenience of using the same namespace for both viewing and uploading, I > > tend to believe *some* people are using it. If a large hosting operation > > has even a small percentage of its users relying on that functionality, > > they may run into a serious headache if they suddenly disable it. I think > > that breaking existing applications (and even more so breaking people's > > work habits) is something that should be avoided unless it is truly > > necessary or proven to be a non-issue (not the other way around). > > Well I think that most people are completely unaware of this (for the user > population) undocumented feature, and don't use 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 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 names can be fully addressed within this framework, because the client can (if it wants to) check for the existence of target collections (using HEAD), and impose on the user to create collections one by one, etc. I'm not 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. It is also not completely clear to me that WebDAV obsoletes the limited write capabilities of HTTP/1.1, which exists as an independent protocol. In principle, at least, people can keep writing and using pure HTTP/1.1 clients and servers for many years to come, and so having this kind of conflict between the two protocols is not healthy. I believe that you are absolutely right that "most people are completely unaware of this", but this does not contradict having *some* people that rely on it, which suffices to create a problem. In any event, from a practical point of view, I can think of three questions here: 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. 2) Most probably not. I believe that the actual interoperability problem here is overall quite mild. 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. What do you think? > > I agree that this whole thing is not such a "big" issue, but not for the > > same reason as you. The thing that makes it pretty benign is that nothing > > at all will happen to WebDAV interoperability if this requirement would > > be ignored. > > My concern here is if a DAV client is written which depends on the > intermediate collections *not* being made (i.e., it depends on an error > being thrown if a user mis-types an intermediate collection name), then this > client would haev interoperability problems against a server which did > implement the intermediate collections. OK; you got me convinced on this one. A poorly designed WebDAV client may indeed have problems, and in this respect, this is a bigger issue than I thought. Yoram
Received on Wednesday, 21 April 1999 01:04:02 UTC