[Bug 23] lock discovery vs shared locks

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=23





------- Additional Comments From julian.reschke@greenbytes.de  2005-11-20 11:57 -------
Furthermore:

"When a LOCK operation creates a new lock, the new lock token is returned in the
Lock-Token response header defined in Section 9.6, and also in the body of the
response."

I don't think we need that sentence here at all. It's just an introduction to
locks, and naturally people looking for details should read the definition of
the LOCK method. That being said; *if* we want to keep the forward reference
here, please simplify not to repeat text from somewhere else (that's generally a
good way to create inconsistent specs), and just say something like

"When a LOCK operation creates a new lock, information about the newly created
lock is returned in the HTTP response (see Section x.y)" (where x.y is the
subsection number for the section where LOCK creation is defined).

Then...:

"This specification encourages servers to create UUIDs for lock tokens, and to
use the URI form defined by A Universally Unique Identifier (UUID) URN Namespace
[9]. However servers are free to use another valid URI so long as it meets the
uniqueness requirements. For example, a valid lock token might be constructed
using the "opaquelocktoken" scheme defined in an appendix of this document."

1) s/to use another valid URI/to use any other valid URI scheme/

2) s/defined in an appendix/defined in Appendix xyx/






------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Received on Sunday, 20 November 2005 19:57:37 UTC