rfc2518-bis-05 issues (part 3)

Hi.

Below is a list of issues I raised against draft04 which IMHO have not 
been adequately addressed in the latest draft (see [1] for the original 
message).


04-C01 attributes on properties

Section 4.5: "Attributes on the property name element may convey 
information about the property, but are not considered part of the value."

As far as I can tell, we haven't reached consensus on this. The latest 
discussion I'm aware of is at
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0309.html>.


04-C02 lock discovery and tokens

Section 6.3: "Finally, the lockdiscovery property can be queried using 
PROPFIND and the token can be discovered that way. Each lock has only 
one unique lock token."

- the token can only be discovered this way if there aren't multiple 
tokens (due to shared locks)
- clarify "has only one" by "has exactly one"


04-C05 sect 7.4, p2

"The lost-update problem is not an issue for collections because MKCOL 
can only be used to create a collection, not to overwrite an existing
collection.  In order to immediately lock a collection upon creation,
clients may attempt to pipeline the MKCOL and LOCK requests together."

There's no guarantee that this will be atomically, thus in the best 
case, it just makes a race condition less likely. As you can't rely on 
this to always succeed, I'd recommend not to say anything at all.


04-C06 sect 7.4, p3

"A lock request to an unmapped URL should result in the creation of a
resource that is locked.  A subsequent PUT request with the correct lock
token should normally succeed, and provides the content, content-type,
content-language and other information as appropriate."

If this is supposed to be normative text, it should use "SHOULD" instead 
of "should" (same problem with many places where text was added). 
Besides, what is "should normally succeed" supposed to mean?


04-C09, sect 8.1.3

...speaks of "consistent" usage of addresses without precisely defining 
what that means.


04-C11, sect 8.1.5 p 2

This requirement will make both IIS and Apache/moddav non-compliant. 
Before I can agree to this, I'd like *at least* see the Apache/moddav 
developers committing to this change.


04-C11, sect 8.1.5 p 3

This will make IIS non-compliant.


04-C13, sect 8.2

"Clients expect the fully-qualified URLs of members of a collection to 
have a common prefix which is the fully-qualified URL of the parent 
collection itself."

If this is meant to define a normative requirement on server behaviour, 
it should be worded accordingly.

"URLs in a PROPFIND response body MAY be represented as fully-qualified
URLs, in which case they must all contain the full parent collection URL
(scheme, host, port, and absolute path).   Alternatively, these URLs MAY 
be absolute paths (not containing scheme, host or port), but in this 
case they must all still contain the full parent collection path."

I'd strongly suggest to remove all of this and to clearly state using 
the RFC2396 productions what is allowed.


04-C17, sect 8.9, Copy for properties

"If a property cannot be  copied live, then its value MUST be duplicated,
octet-for-octet, in an identically named, dead property on the destination
resource."

No! That would be a desaster. Make this "SHOULD NOT". Otherwise clients 
will see the dead property (such as DAV:checked-in) and make wrong 
assumptions about the resource.


04-C20, sect 8.10.1

"Live properties described in this document MUST be moved along with
    the resource, such that the resource has identically behaving live
    properties at the destination resource, but not necessarily with the
    same values.  If the live properties will not work the same way at
    the destination, the server MUST fail the request (the client can
    perform COPY then DELETE if it wants a MOVE to work that badly).
    This can mean that the server removes a live property if that's the
    most appropriate behavior for that live property at the destination."

The second sentence implies that the MOVE must fail if the live 
properties can't be moved as well, while the last sentence says that the 
server may remove the live properties.

Update -05: this now reads:

    This can mean that the server reports the live property as "Not
    Found" if that's the most appropriate behavior for that live
    property at the destination, as long as the live property is still
    supported with the same semantics.

I'm not sure I understand what that means. The contradiction is still there.

"A MOVE can be a rename operation, so it's not appropriate to reset
    live properties which are set at resource creation. For example, the
    creationdate property value SHOULD remain the same."

So can a MOVE be something else then a rename operation? If yes, how 
does the second sentence then applies? If it doesn't apply always, and 
the client won't know, why are we mentioning it?


04-C21, sect 8.11, refreshing LOCKs

"A lock is refreshed by sending a new LOCK request to the resource which 
is the root of the lock.  A LOCK request to refresh a lock must specify 
which lock to refresh by using the Lock-Token header with a single lock 
token (only one lock may be refreshed at a time).  This  request does 
not contain a body, but it may contain a Timeout header.  A server MAY 
accept the Timeout header to change the  duration remaining on the lock 
to the new value."

Replace by

"A lock is refreshed by applying a LOCK request to the URL which is the 
root of the lock. This request must specify which lock to refresh by 
using the Lock-Token header with a single lock token (only one lock may 
be refreshed at a time) and does not contain a body, but it may contain 
a Timeout header. A server MAY accept the Timeout header to change the 
duration remaining on the lock to the new value."


04-C22, sect 8.11.1

Fix the XML response by replacing

            <D:href>http://example.com/workspace/webdav
               /proposal.doc</D:href>

by something like

            <D:href
            >http://example.com/workspace/webdav/proposal.doc<
            /D:href>


04-C24, section 11

I think this section doesn't really help. It doesn't seem to say 
anything normative, so I'd recommend to drop it, and to improve the 
sections for the individual methods.


04-C25, section 12

"When a Multi-Status response does not have a clear scope (e.g. in 
response to MOVE or COPY when the scope could be either the source or 
the destination), URLs appearing in the response body SHOULD be absolute 
and fully-qualified URLs."

Either define "clear scope", or (preferably) improve RFC2518 that there 
is no situation where the scope is not "clear".

Update 05: this now says "single scope". That doesn't seem to be 
clearer. What does it mean?



04-C28, section 14, displayname

"It MAY be attempted to be set in remote COPY operation."

I'd say: it MUST NOT.

"This property is live and MAY be protected."

What's the use case for it being protected?


04-C29, section 14

Uses the term "remote COPY operation" and "cross-server copy". I think 
we need to define what this means.


04-C30, section 14.5

"In a remote COPY operation that is implemented through a GET request, 
the GET request must have the appropriate Content-Type header."

I honestly don't understand what this means.

Update -05: now it says PUT instead of GET. Aha! Anyway, I don't think 
this belongs into a description of a live property.


04-C31, section 14.6

"Refer to RFC2616 for a complete definition of the semantics of an ETag."

Just say: "(see RFC2616, section a.b.c)"


04-C32, section 17

"It is only in the case where the set of properties is not known ahead 
of time that an application need display a property name URI to a user"

There is no such thing as a "property name URI", unless we define it.

(note the term occurs twice, only one instance was changed; also, just 
use "property name" -- this includes both local name and namespace).



04-E01 non-ASCII characters

There are many instances of non-ASCII characters in the document, 
probably caused by a missing conversion step.


04-E02 usage of sample host names not according to IETF recommendations


04-E04 Numbering of appendices

Each appendix should have it's own section number.
draft-rfc-editor-rfc2223bis-06.txt seems to recommand uppercase letters
(such as "Appendix A").


04-E05 wrong reference

Page 7, 2nd paragraph refers to 13.28, I think this needs to be 14.

Update -05: the sentence with the reference was removed. Why not keep it 
and just fix the reference?


04-E06 Terminology

URI/URL: note we should be prepared to update to RFC2396bis when it's ready.


04-E07 usage of property names in surrounding text

I think we should try to use a consistent syntax when referring to DAV:
properties. Currently we have a mix between "foo" and "DAV:foo".


04-E08 section 3: definition of "null resource"

...is gone, yet is still used in later sections.


04-E09 "DAV compliant"

I think we should try to use either "DAV compliant" or "WebDAV 
compliant" consistently.


04-E12 paragraph numbering in sec 9

...is broken. For instance, "Example - No-tag-list If Header" should be 
a subsection of "No-tag-list Production".


04-E13 paragraph numbering in sec 13

...is broken. For instance, 13.2 should be a subsection of 13.1


[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0049.html>


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

Received on Wednesday, 29 October 2003 10:56:41 UTC