RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt

Hi,

I just reviewed the current draft, checking the issues I raised for draft 02
in September 2002:

	http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0372.html

Unfortunately, it seems that almost all the issues I raised haven't been
addressed. Below is an updated list:


1) References to RFC2616

References have been updated to point to RFC2616 rather than RFC2068, but it
seems that all (most?) section numbers still need to be updated.


2) Section 4.4

Replace "MUST not" by "MUST NOT"


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"


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

(If it's not IETF-registered, I don't see how it can possibly meet the
uniqueness criterium).


6) Section 8.1.1 (use of XML)

Replace

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML].  All XML used in either requests or responses
MUST be, at minimum, well formed.  If a server receives ill-formed XML in a
request it MUST reject the entire request with a 400 (Bad Request)."

by

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML] and [REC-XML-NAMES].  All XML used in either
requests or responses MUST be, at minimum, well formed and
namespace-well-formed.  If a server receives ill-formed XML in a request it
MUST reject the entire request with a 400 (Bad Request)."


7) Section 8.1.2 (required bodies)

says...: "In cases where a request body is present but would be ignored by a
server, the server MUST reject the request with 415 (Unsupported Media
Type)."

I don't understand this requirement. If a body isn't defined, it should be
ignored, right? (isn't MKCOL a special case?)


8) Section 8.1.4 (required headers)

"Note that HTTP 1.1 requires the Date header in all responses." -> not
true - clockless origin servers are treated as a special case


9) Section 8.2

"URLs for collections appearing in the results MUST end in a '/'
character." -> I don't think we have consensus on this.

Furthermore, this section seems to attempt to define a subset of relative
URI resolution -- I think this is a VERY bad idea. Clients should properly
resolve URIs against the request URI -- if we must, we can simplify this
requirement by restricting the set of allowed relative URIs to those
starting with an absolute path.


10) Section 8.2.2

"The resource http://www.foo.bar/container/index.html, a member of the
"container" collection, has nine properties defined on it,
http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname,
DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified,
DAV:resourcetype, and DAV:supportedlock." -> bad syntax for property names.

Also: the example for propfind/allprop is missing.


11) Section 8.3

"All DAV compliant resources MUST support the PROPPATCH method and MUST
process instructions that are specified using the propertyupdate, set, and
remove XML elements of the DAV schema" -> What is the "DAV schema"???

Also, replace

"Instruction processing MUST occur in the order instructions are received
(i.e., from top to bottom)"

by

"Instruction processing MUST occur in document order" (standard XML
processing term)


12) Section 8.7

Replace

"424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status)."

by

"424 (Failed Dependency) errors SHOULD NOT appear in the 207
(Multi-Status)."


13) Section 8.11, refreshing locks

"A locks is refreshed by sending a new LOCK request to the resource which is
the root of the lock."

Question: does it really need to be the root?


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.


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.


16) Section 8.11.2

Replace

"Lock-Token: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)"

by

"Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>"


17) Section 8.12

Replace

"A successful response to an UNLOCK method does not mean that the resource
is unlocked."

by

"A successful response to an UNLOCK method does not mean that there are no
locks left on the resource."

(at least I think this is the intent of the sentence, otherwise it needs to
be rephrased differently)



18) Section 9.1

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


19) Section 9.3

Language describing the process of relative URI resolution should go.


21) Section 11.4

Replace

" - The server does not ever accept this method on this kind of resource.
For example, a PUT is not accepted on a collection."

by

" - The server does not ever accept this method on this kind of resource.
For example, if a PUT is not accepted on a collection."


22) Section 11.5

I think that there are *many* more cases that can cause a 409 (see RFC3253)


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.


24) Section 12.1

Proposal: add an example.


25) Section 13.4 (lockroot)

Proposal: only require it for deep locks.


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


27) Section 13.16

Remove

"May contain additional elements not defined in this document."

That's true for *all* XML in request/response bodies (also reccurs in other
places)


28)  Section 13.24

Replace

"Language tagging information in the property's value (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."

by

"Language tagging information in scope of the property (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."


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


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.


31) Section 18.6, Reduction of Security due to Source Link

can be removed


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.




33) Editorial note

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





--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 13 March 2003 10:50:35 UTC