- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 25 Nov 1997 16:23:27 -0800
- To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Hyphenation? I'm sorry, I don't know what you are referring to. Could you please provide an example? opaquelocktoken - I believe section 5.3 addresses all of your concerns. I repeat it here: A lock token is a URI that identifies a particular lock. A lock token is returned by every successful LOCK operation in the lock-token response header, and can also be discovered through lock discovery on a resource. Lock token URIs are required to be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion. This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements. However, at the author's meeting, we discussed the problem with the GUID draft having expired. Alex Hopmann will be writing up appropriate language. Basically, however, opaquelocktoken is just one scheme, as specified above, ANY scheme may be used, so long as it is unique across all resources for all time. However the IESG gets unhappy when you make a requirement like that without providing at least one mechanism that someone can use to meet the requirement, hence the introduction of opaquelocktoken. Yaron > -----Original Message----- > From: Jim Davis [SMTP:jdavis@parc.xerox.com] > Sent: Tuesday, November 25, 1997 12:12 PM > To: w3c-dist-auth@w3.org > Subject: comments on v5 > > I've read the new draft. it's great. I have sent all the minor comments > (typos) to the editor. I have two that are at least somewhat substantial. > > property naming > > There is still some inconsistency in choice of property names, although > much improved. Some names are formed by concatenation (e.g. lockscope) > and > some by hyphenation. The latter are easier to read and if you could use > these uniformly it would be great. > > opaquelocktoken (5.4) > > It seems kind of weird to me that opaque lock tokens *require* the GUID > mechanism. Surely it sufficies to just say that the tokens must be > unique, > and leave it to servers to figure out how to do this. GUIDs are certainly > one way, but there are surely others. > > Let me put this question another way. Suppose One wanted to use a lock > token that was not based on GUID. I see two ways to do it > 1) Define a new URI scheme (foolocktoken) and extend Lock-Token to return > and accept these kind in addition to opaquelocktoken > 2) Make opaquelocktoken itself extensible by adding a scheme to the front > e.g. opaquelocktoken:guid for the ones in the DAV spec. > > If opaquelocktoken really just means GUID, why not call it GUID and be > done > with it? > > Also, the GUID internet draft is expired. What is the status of it? > > > > Jim > > > ------------------------------------ > http://www.parc.xerox.com/jdavis/ > 650-812-4301
Received on Tuesday, 25 November 1997 19:41:55 UTC