RE: comments on v5

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