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

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).


C02-10) Section 8.2.2

(...)

Also: the example for propfind/allprop is missing.



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.

[In general I'd like to have the latest GULP as normative appendix, and
remove some of the prose about lock behaviour from the various sections; I
think this is also we agreed upon in January]



C02-18) Section 9.1

I'd like to see the rational for the "extend" production.


C02-24) Section 12.1

Proposal: add an example.



C02-26) Section 13.6

Replace:

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST have this value"

by

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST contain this element."



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.



E02-01) Editorial note

I think that removing the section numbers from the 3rd-level section names
is a bad idea.





[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0372.html>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 30 July 2003 10:01:41 UTC