[Bug 220] Do status codes belong into pre/postcondition definitions?

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





------- Additional Comments From ejw@cs.ucsc.edu  2006-02-10 09:44 -------
Discussed during the Feb. 10, 2006 teleconference.

Agreed during the teleconference that listing the status codes in section 16 (formerly section 15) is a 
good idea. We then went through the status codes to make sure that they were appropriate and correct.

Agreed that lock-token-matches-request-uri should not be used with 400, since this code is for syntax 
errors, and instead it should be used with 409, since the state of the resource potentially could change, 
allowing resubmission of the request.

Section 9.11.1 :: 400 - no lock token provided, strike reference to precondition for this case (lock-
token-submitted) The rationale is that lock-token-submitted is specifically for the case of lock tokens 
in the If header, and here we're talking about lock tokens passed in the Lock Token header.

Section 9.11.1 :: The lock-token-matches-request-uri should now be moved down to 409 (Conflict) to 
be consistent with the defintion of this precondition. 

Agree that lock-token-submitted should only be used with 423 Locked, and not with 400, since 400 is 
for syntax errors, which this is not.

In lock-toke-matches-request-uri, in the second sentence, "doe" should be "does".



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

Received on Friday, 10 February 2006 17:44:34 UTC