Subject: [Bug 217] GULP integration

From: [email-masked]
Date: Wed, 25 Jan 2006 17:22:22 -0800

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From [email-masked]  2006-01-25 17:22 -------
I've integrated the lock model into a new subsection within the first section on
locking.  I tried working with normative statements in a new way, not all or none:
 - normative statements about one METHOD, e.g. LOCK or UNLOCK, belong in those
methods' sections
 - normative statements about any method that might affect locks, can stay here.

 - Found text on write lock that is duplicative.  Realized that part of the lock
model is ONLY applicable to write locks, so I moved that to the beginning of the
write lock section.  Realized that not only must lock token be submitted, but
also principal must be correct, so rearranged section.  Suggestions welcome, of
course.

 - Duplicative text removed in 6.2, Exclusive vs. Shared Locks
 
 - Discovered that section 7.1 (Methods Restricted By Write Locks) is redundant
with the new, more careful wording on what operations require a write lock token

While working on the lock text and integration of the lock model, I noticed
these side issues:
 - Timeout is never defined or introduced, I notice, so I created this
 - There is a section in LOCK on "locking unmapped URLs", I notice, but the
first few paragraphs are implicitly about "creating locks on existing
resources".  I think this section would help readability but I welcome comments.
 - Noted that our existing text actually conflicts with the idea of shared locks
-- it says only that a lock request to an *unlocked* resource creates a new lock.
 - Section 7.2 "Write Locks and Lock Tokens", is really about shared locks, and
is applicable to write or other locks according to our model.  The rest of the
section is stuff that's already been said.  Moved the part about 5 lock tokens
to the shared locks section.

Changes I *didn't* make:
 - I notice that the section on "Write Locks and Unmapped URLs" really isn't
specific to write locks.  We'd probably want any kind of lock to an unmapped URL
to create a resource.  But I left this section where it is.
 - The section on required support and capability discovery would seem to belong
together, but oh well.

Finally, I'm posting this draft to the web site, with I think no other changes,
so people can easily compare this set of changes as a whole.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.