- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 30 Jul 2003 23:05:37 +0200
- To: <w3c-dist-auth@w3.org>
Here's a set of new issues (that is, issues I didn't raise earlier, they may
have been present for longer or even in RFC2518):
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-C03 opaquelocktoken syntax
Section 6.4, last p.:
"Extension = path ; path is defined in section 3.2.1 of [RFC2616]"
...should say "3.3 of RFC2396"
04-C04 sect 6.5, access control
I find the mixing of lock capabilities and access control capabilities
confusing. Maybe we should remove or rewrite this in the light of the ACL
spec.
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-C07 sect 7.4, p4
"Historically, a lock-null resource: ...
- Disappears (becomes once more an unmapped URL) if its lock goes
away before it is converted to a regular resource. (This must..."
The lock-null resource becomes unmapped, it doesn't become an unmapped URL.
04-C08, sect 8.1.1
"illformed" isn't defined in REC-XML. Propose to use "non-wellformed".
04-C09, sect 8.1.3
...speaks of "consistent" usage of addresses without precisely defining what
that means.
04-C10, sect 8.1.5
"HTTP 1.1 suggests the use of the ETag header in responses to GET and PUT
requests"
Make this more precise (maybe "recommends"?). Also directly reference the
section in RFC2616.
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-C12, sect 8.2 p 2
'A client may submit a Depth header with a value of "0", "1", or "infinity"
with a PROPFIND on a collection resource with internal member URLs.'
Remove "with internal member URLs". It's irrelevant whether the collection
has members.
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.
"URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML
marshalling defined in this specification) must also be legal URIs."
This somehow suggests that there's something like an "illegal" URI. Either a
text string conforms to the RFC2396 requirements (then it is a URI) or it
doesn't (then it's not a URI at all). Recommend to drop this paragraph, but
do add normative language somewhere else (for instance, when defining legal
contents for DAV:href).
"In the case of allprop and propname, if a principal does not have the right
to know whether a particular property exists then the property should be
silently excluded from the response."
s/should/MAY/
04-C14, sect 8.4
"For example, if a request to create collection /a/b/c/d/ is made, and
either /a/b/ nor /a/b/c/ exists, the request must fail."
I think it must fail if and only if /a/b/c/ does not exist. It's irrelevant
whether /a/b/ exists.
04-C15, sect 8.4 status codes
"The collection or structured resource was created in its entirety."
What is a "structured resource" and where was it defined?
"405 (Method Not Allowed) - MKCOL can only be executed on a
deleted/non-existent resource."
HTTP methods are applied to URLs, not resources. Say "can only be executed
on an unmapped URL"
04-C16, sect 8.7
"Thus, after a successful DELETE operation (and in the absence of other
actions) a subsequent GET/HEAD/PROPFIND request to the target Request-URI
would return 404 (Not Found)".
s/would/MUST/
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-C18, sect 8.9.3
"Either the source context does not support copying to the destination
context, or the destination context refuses to accept the resource."
If we use the term "context", we'oll have to define it somewhere.
04-C19, sect 8.10
"If a resource exists at the destination, the destination resource will be
DELETEd as a side-effect of the MOVE operation, subject to the restrictions
of the Overwrite header."
s/DELETEd/deleted/
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.
"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-C23, section 9.8
Do we have interoperability for status "102" and the Status-URI header? I
don't think so, so I'd recommend to remove them from the spec.
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".
04-C26, section 13, "lockroot"
"Purpose: The resource where the lock is orootedo, which is the resource
that was addressed in the LOCK request."
This is not purpose. Say
"Purpose: contains the root of the lock, i.e. the URL to which the LOCK
request was applied."
04-C27, section 13, "deadprops"
During the January meeting we agreed upon "dead-props". We already implement
that. Why change it?
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.
04-C31, section 14.6
"It MUST NOT be set in PROPPATCH during a cross-server copy."
It seems that we assume here that the reader is aware of implementations
that implement cross-sever copies using GET/PROPFIND/PUT/PROPPATCH. If we
want to keep this, we need to expand this (probably in the section about
COPY). Alternatively drop it.
"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.
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
For instance:
04-E03 undefined reference
in last paragraph on page 6
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.
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-E10 sect 7.5, 2nd last para
Closing ")" missing.
04-E11 section 8.1.4
Indentation off.
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
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 30 July 2003 17:06:26 UTC