- From: <ccjason@us.ibm.com>
- Date: Thu, 9 Sep 1999 22:04:04 -0400
- To: Greg Stein <gstein@lyra.org>
- cc: w3c-dist-auth@w3.org
<gs> This whole thread (post-Judy's message) seems to be picking out a very minor detail of her post. Personally, I find this nit-picking of detail counter to the goal of her original post: "test its conclusions with the mailing list members." </gs> Sorry Greg. I'm basically in agreement with testing the conclusions, I was just pointing out one place where I as a member of the list feel that it's off the mark. I'm on the fence on most of the other stuff and want to hear more opinions there without comment from me. My "nit-picking" is not meant to be an indictment of the whole proposal. <gs> The second "AGREED" portion does not make a whole lot of sense. The commentary states that the position is too strong [because it might not make sense with other types of locks]. Are there other locks out there? </gs> Not in the spec, but the issues list does hint at suggested approaches which include other lock types. <gs> Do people have concrete, useful examples? </gs> With write locks, shared or exclusive, there is no way to protect a resource without preventing others from protecting it. If there were a "write-block" lock which people usually would use in shared mode, that would be another type of lock. (I guess most people call these "read locks".) I don't think the example itself matters though and I don't want anyone to get hung up on it. The point is the spec provides for other lock types and my statement expresses the opinion that the need to protect a URI goes beyond write locks and applies to all locks. At least as long as we use the lock URI as the sole means of identifying a locked resource or unlocking it. (The use of URI's need not be necessary but other options haven't seriously been discussed.) <gs> I haven't heard of anything besides a write-lock yet. Regardless, I think it should be enforced in the spec that a write-lock MUST have guaranteed protection of the Request-URI. Put in some language that says other locks can define the MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive state: a write lock says that others cannot monkey with your URI. </gs> Sounds paletable. We can speak of this on a case by case basis. We just need to not forget to specify it for each type of lock we devise. I'd feel better if we'd either solve the unlocking problem or just say upfront that all lock URI's are protected. If we solved that problem, I'd feel very comfortable saying that we can define URI protection on a case by case (lcck-type by lock-type) basis. How can we solve it? I can think of several options... 1) One way would be to say that the URI of the unlock method is not relavent. Only the provided lock token is relavent to the request. The complication is that the only way that we have to provide lock tokens right now is via the "Lock-Token" header. And it is my understanding that that header always implicitly or explicitly causes a check that the provided lock token applies to the request URI or some explicitly specified URI. Therefore, in a neat implementation, the lock-token check might tend to be done before the server's method specific code ever gets a chance to execute. 1b) We could specify a different request header for specifying the locktoken to be unlocked. That new header would not involve checking if the lock token applies to a known URI. 2) We could say that a LOCK response provides a pseudo URI that we can use for the UNLOCK request that remains in effect until LOCK goes away. And of course we'd try not to recycle those URI's too rapidly. 2b) We could have the lock request provide a pseudo URI like (2), but this URI would be a URI that essentially specifies the GUID for the resource that was locked. The approach of course is dependent on us not defining any semantics where the root of a lock can drift to another resource. (No null lock reources for example.) 3) We could say that the lock token itself can be specified as the URI of the unlock request. This sounds weird and also seems to preclude the possibility of unlocking multiple locks at once. (The current spec is unclear on this capability.) My preference is (1b). Once we do this, I think we'll have more flexibility to say if a given lock will protect a URI. Then I'd feel very comfortable with your recommendation of just saying that *write* locks protect the lock URI. Cheers, J.
Received on Thursday, 9 September 1999 21:56:50 UTC