- From: Greg Stein <gstein@lyra.org>
- Date: Tue, 26 Oct 1999 15:38:31 -0700 (PDT)
- To: w3c-dist-auth@w3.org
On Tue, 26 Oct 1999, John Stracke wrote: > "Yaron Goland (Exchange)" wrote: > > > My user's explicit goal is to prevent anyone, anywhere from have any ability > > to manipulate their "private data worlds" in anyway. > > Uh...isn't that what access control is for? I don't think so. Access control is long-term, locks are shorter/transitory. I totally agree with Yaron here: if I'm editing a document (with a lock), then it sure as hell better not move on me. That is just annoying and wrong. This whole business about the server retaining redirects after a move of a locked resource seems really and arbitrarily complex. Why support something like that? Just say a server MUST refuse a move of a locked resource rather than "well, it might or it might not, but you really won't know unless you try." And if this nonsense does go thru as a "consensus change" to the move/lock behavior, then the default should be to refuse the move. There was a suggestion that an app should set a flag to state that it can't support locked resources that may move -- that's backwards since the current behavior is "I lock it and it stays there until I unlock it." In other words, an app should say "I can support you [the server] moving this locked resource on me and sending me a 301 response." (I still don't like it though because of the additional complexity on the client, which people seem to be ignoring, much to Yaron's dismay; who on this list is actually writing client software/tools/apps?) Personally, I'll refuse the darn move. I'm not going to start recording all these redirects on the server. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Tuesday, 26 October 1999 18:37:39 UTC