- From: <bugzilla@soe.ucsc.edu>
- Date: Wed, 8 Feb 2006 12:18:58 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=217 ------- Additional Comments From ejw@cs.ucsc.edu 2006-02-08 12:18 ------- Discussed during the Feb. 8 2006 teleconference" Section 6.1., para. 3: Agreed to change resource to URL. Section 6.1., para. 9: Agreed that the new text is better, since the information about it applying to a specific resource is already covered in the UNLOCK method definition. Section 6.2., para. 2: No change needed here. Potential ambiguity noted. However, changesd in the next section address the ambiguity. Section 6.2., para. 7: Already entered in a suggested text change, see above. Section 6.4., para. 1: Agreed that use of the usage was imprecise, and that the text needs to refer to the DAV:unlock privilege in the ACL specification. Section 6.4., para. 2: Already entered in suggested text, see above. Section 6.5., para. 1: Agreed that the general definition of a state token belongs in the definition section. Also agreed that we need to be consistent with whether a state token is a URI, or is represented by a URI. Then, need to change text to refer to the definition, and not redefine state token elsewhere in the draft. Section 6.5., para. 4: Lisa will work on this paragraph. In particular, there should be a statement someplace that having a write lock does not necessarily mean you have dav:write priveleges. It's possible to get a write lock, and not have dav:write privelege. These are distinct. This statement may or may not belong in this paragraph. Section 6.6., para. 2: Julian was assigned the issue of creating a new bug for this issue. There was disagreement over how and whether to create a more optimal organization for the Timeout information. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
Received on Wednesday, 8 February 2006 20:19:06 UTC