- From: Jason Crawford <nn683849@smallcue.com>
- Date: Wed, 30 Jul 2003 12:35:40 -0400
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: w3c-dist-auth@w3.org
- Message-ID: <OFC92BA1BE.06FAE70A-ON85256D73.00590F8B@us.ibm.com>
On Wednesday, 07/30/2003 at 03:42 ZE2, "Julian Reschke" <nnjulian.reschke___at___gmx.de@smallcue.com> wrote: > Hi. > > Below is a list of issues I raised against draft 02 which IMHO have not been > adequately addressed in the latest draft (see [1] for the original message). > > > 02-C05 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." > > (If it's not IETF-registered, I don't see how it can possibly meet the > uniqueness criterium). I'd vote to leave the text as it is. > C02-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. Perhaps I misunderstand the existing text, but I also suspect the "unless it overwrites..." part is wrong. If you do a MOVE and it's actually a different resource in that slot, I think you do need the parent collection's lock token. It's only a PUT that doesn't require it. > C02-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 don't know if we discussed it or not, but the wording that is there seems fine. I do lack any compelling test cases to drive this issue in a particular direction though. I will rhetorically ask what non-WebDAV browsers do with ETags and lastmoddate.
Received on Wednesday, 30 July 2003 12:36:23 UTC