W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: rfc2518-bis-04 issues (part 2)

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT