- From: Jason Crawford <nn683849@smallcue.com>
- Date: Thu, 13 Mar 2003 19:26:14 -0500
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: w3c-dist-auth@w3.org
> 4) Section 6.3, p1 > > Replace > > "A lock token is returned by every successful LOCK operation in the > lockdiscovery property in the response body, and can also be found through > lock discovery on a resource." > > by > > "A lock token is returned by every successful LOCK operation in the > lock-token header of the response, and can also be found through lock > discovery on a resource" If we go with this wording, could we include a reference to the section that defines what "lock discovery" is. I did a quick search of the 2518bis and I don't think that's clear. We don't need to redefine it, but a pointer to the definition we're refering to would be good. > 5) Section 6.3, p3 > > Replace > > "However resources are free to return any URI scheme so long as it meets the > uniqueness requirements." > > by > > "However servers are free to use any IETF-registered URI scheme so long as > it meets the uniqueness requirements." I'd vote for leaving the old text. > 14) Section 8.11, The Effect of Locks on Properties and Collections > > "This means that if a collection is locked, its lock-token is required in > all these cases: > - DELETE a collection's direct internal member > - MOVE a member out of the collection > - MOVE a member into the collection, unless it overwrites a pre-existing > member" > > I think the latter is not really consistent with RFC3253. I think Lisa pointed it out, but the spec doesn't talk about URI protection. This section is probably a good place to mention it. Geoff came up with some wording that I don't have handy now. He and I disagreed with whether we should say that lock protection is for write locks or just locks. Anyway... The Effect of Locks on URL Mappings The resource located at the request-URI of the LOCK request MUST remain at that URI until the lock is removed via UNLOCK or until an operation with the proper lock-token header alters or destroys that mapping. This contraint insures that the principal that locked the resource will be able to find that resource at the same location as long as it holds the lock. Feel free to offer a better wording. > 15) Section 8.11, Locking unmapped URLs > > "A server MUST respond successfully to a GET request to an empty resource, > either by using a 204 No Content response, or by using 200 OK with a > Content-Length header indicating zero length and an server-determined > Content-Type." > > Do not mention the content type at all. No content type is fine as well. Interesting. Has this been discussed and resolved? (It just seems a bit odd.) > 19) Section 9.3 > > Language describing the process of relative URI resolution should go. I actually like it telling me (the reader) this explicitly. > 23) Section 12 > > Again, an attempt to define relative URI resolution. Don't do that, just > refer to RFC2396 and say that URIs in a multistatus response are resolved > against the request URI. I do agree that it should not be described more than once in 2518. A reference to a single place in the same document is fine with me. > > > 24) Section 12.1 > > Proposal: add an example. We might as well also say what 303 is just so that folks don't have to go searching for it. "302 (Found) and 303 (whatever)..." > 25) Section 13.4 (lockroot) > > Proposal: only require it for deep locks. I have no preference... unless we have a reason to want to know what URI mapping is protected. If we do, then it should apply even to depth 0 locks. FWIW... there is some sort of quotation marks around "rooted" in that section on that html page that don't show up right on my browsers. > 29) Section 13.26 > > Replace > > "The allprop XML element specifies that all property names and values on > the resource are to be returned." > > by > > "The allprop XML element specifies that all names and values of all dead > properties and the live properties defined by this document on the resource > are to be returned." I guess this is fine, although I think "this document" might be ambiguous. Perhaps, "this spec". > 30) Section 14.7 > > "A change in a property SHOULD NOT cause the last-modified date to change, > because clients MAY rely on the last-modified date to know when to overwrite > the existing body." > > I think this is a new requirement that hasn't been discussed. BTW: it's > inconsistent with the attempt to make ETags a MUST -- if you have Etags, you > don't have to rely on the last modified date anyway. I support what Lisa has added until we show that saying this is a bad idea. > 31) Section 18.6, Reduction of Security due to Source Link > > can be removed I tend to think 18.6 isn't necessary. I'm not heavily in to a lot of this sort of thing any more, but even to me it seems obvious. > 32) Section 19, IANA consideration (old text) > > "URIs are used for both names, for several reasons. Assignment of a URI does > not require a request to a central naming authority, and hence allow WebDAV > property names and XML elements to be quickly defined by any WebDAV user or > application. URIs also provide a unique address space, ensuring that the > distributed users of WebDAV will not have collisions among the property > names and XML elements they create" > > This is wrong. Properties are NOT identified by URIs. They are identified by > XML QNames. I tend to think the first part of section 19 is no longer necessary. It's not quite accurate and the information isn't really important and it's well known to anyone that has had to deal with XML namespaces... which will be everyone reading this. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com
Received on Thursday, 13 March 2003 19:28:43 UTC