Re: Significant changes to protocol draft

Asad,

	In the name of general dissent, I respectfully oppose a modification to the method names.  Changing the holy trinity of COPY, MOVE, and DELETE to DUPE, RENAME, and DELETE seems clusmy.  I also agree with Jim Davis that using RESERVE/UNRESERVE instead of LOCK/UNLOCK is semantically confusing.  I find no good reason to change the spec now in its latter stages simply to conform to some prototype Netscape extensions.  AOLPress and IIS have non-standard proprietary extensions as well but I don't think WebDAV should go out of its way to prevent method name collisions.  WebDAV already has enough to worry about by making sure its methods and status codes don't conflict with HTTP 1.1 (actually some status codes conflict but that's another email...).

\\Marc Eaddy

At 10:56 AM 12/4/97 -0800, you wrote:
>The proposal to change the name of the these methods was put by me in
>the last DAV Design meeting, and accepted graciously by fellow designers
>from Microsoft, Novell, and our chair Jim Whitehead, with a an
>undestanding that, in HTTP paradigm, method names are mere opaque tokens
>and has no real meaning attached to them (case in point POST), and are
>the most insignificant part of the design exercise, specially for those
>who are "DOING THE RIGHT THING" by not implementing anything till the
>spec finalizes.
>
>It is not a technical issue, not even a matter of backwards
>compatability for Netscape, since there are many ways to implement DAV
>with or without names conflicting with previous versions of Netscape's
>Web Publishing servers. It only makes it cleaner for people to implement
>it both on the server and client sides, with almost no cost or impact to
>WEBDAV design.
>
>Having said that, the last thing Netscape wants to do is try to shove
>anything down the throat of WEBDAV community. As much as I believe that
>method names are completely insignificant, opaque tokens, with no real
>meaning attached, if there is general dissent in WEBDAV community, I am
>very much willing to withdraw my proposal. Believe me this will not make
>or break Netscape.
>
>As far as hitting the roof is concerned, I don't know about that. I
>don't recall hitting the roof anytime Microsoft proposes changes to the
>design which have far bigger impacts on WEBDAV than some method name
>changes. Now,  when they start messing with the Java Virtual Machine!!!
>that's when I hit the roof  (same to you Yaron)  ;-))
>
>Asad Faizi
>-----------------------------------------------------------------------------------
>
>Jim Davis wrote:
>
>> At 02:29 PM 11/25/97 PDT, Jim Whitehead wrote:
>> >...[a forthcoming change in v6]
>>
>> >6. Rename methods:
>> >   COPY -> DUP, MOVE -> RENAME, LOCK ->RESERVE, UNLOCK -> UNRESERVE.
>> >
>> >The rationale for this change is to avoid a method name conflict with
>>
>> >versions 2 and 3 of the Netscape Enterprise Server which contained
>> >prototype versions of these methods. This change will take effect in
>> the
>> >-06 specification.
>>
>> I personally do not see this as a compelling rationale.  I offer two
>> arguments:
>>
>> 1. The current method names seem like the most appropriate ones, given
>> the
>> functionality, while the new names seem less intuitive.
>>
>> I know that names are totally arbitrary, and we could just call the
>> methods
>> FOO, BAR, BAZ, and QUUX (indeed, it would be pleasing to old Lisp
>> hackers)
>> but having meaningful names does seem like a good thing.
>>
>> Consider MOVE.  I can easily explain to someone that when you MOVE
>> something, e.g. from one collection to another, or one server to
>> another,
>> you take it out of the old one and put it into a new one.  It is less
>> clear
>> how to explain RENAME in that way.
>>
>> As for LOCK and UNLOCK, these are exactly the right names, given the
>> analogy with locking in a file system.
>>
>> If you really have to change the name, perhaps PROTECT AND UNPROTECT
>> would
>> be better?
>>
>> RESERVE seems bad to me.  To RESERVE is to set aside for later use.
>> We
>> RESERVE  space (e.g. bits are reserved for future expansion, parkland
>> is
>> reserved for nature and/or drilling, books on reserve may be read, but
>> not
>> removed.)  Also,  in at least some versioning systems, RESERVE has the
>>
>> sense of claiming the right to make the next version of a thing.  And
>> frankly, a "shared reservation" sounds like, well, where the US
>> government
>> forces native people to live or something.  In any case, you should
>> ask,
>> say, the folks at MKS, or some other versioning system, whether *they*
>> have
>> a Web server that already uses RESERVE in some uh, "reserved" way.
>>
>> In any case, if you change them, are you also going to change the
>> Lock-Token header and the opaquelocktoken scheme accordingly?
>>
>> As for DUP, it's not even a word.  "DUPE" is a word, but it has
>> unfortunate
>> connotations of deception and fraud.
>>
>> 2. It's a bad precedent.
>>
>> While your explanation was not very detailed, it seems like you are
>> saying
>> that Netscape implemented an early version of DAV, and the
>> implementation
>> defines methods such as LOCK with semantics incompatible with those of
>>
>> modern DAV.  Is that right?
>>
>> But so what?  Surely their implementation differs in many, many ways
>> from
>> the modern form of DAV, not just in these four methods.  There's no
>> way
>> that a DAV client is going to interoperate with both the Netscape
>> server as
>> it is and the reference (Jigsaw) DAV server, even if we change those
>> four
>> names.
>>
>> The bad precedent is allowing someone to implement an early version of
>> a
>> spec *while it's being designed* and then have them ask the spec to
>> stop
>> changing (or change in otherwise undesirable ways) for the sake of
>> compatibility with the early version.  It's one thing if early
>> adopters
>> come back and say "look, we've already tried this idea, and can tell
>> you
>> it's full of problems".  It's another to say "Don't do this, it will
>> make
>> our customers unhappy".  Early adopters go to market early and take
>> risks.
>> They shouldn't get any extra voice in defining the spec for that
>> reason
>> though.
>>
>> I tell you honestly, if it was Microsoft asking for this, I would have
>> hit
>> the roof, so it seems only fair to hold Netscape up to the same
>> standard.
>>
>> If, on the other hand, I've misunderstood the rationale, I ask that
>> someone
>> explain it a little better, and not flame me.  I can only go on what's
>>
>> stated in the email.
>>
>> Best regards, (and certainly no malice intended, and I hope, none
>> taken.)
>>
>> Jim
>>
>> ------------------------------------
>> http://www.parc.xerox.com/jdavis/
>> 650-812-4301
>
>
>
>
>

Received on Thursday, 4 December 1997 14:47:24 UTC