- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 11 Sep 2004 18:34:31 +0200
- To: w3c-dist-auth@w3.org
Hi.
Below is a list of issues I raised against drafts 02, 03, and 04 which
IMHO have not been adequately addressed in the latest draft -06 (see [1]
through [6] for the original messages).
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-10) Section 8.2.2
(...)
Also: the example for propfind/allprop is missing. Why was it removed?
C02-18) Section 9.1
I'd like to see the rational for the "extend" production.
03-C03
4.4: “Note that the use of a new top-level URI identifier as a namespace
is considered by many to be a bad thing…”
[as of draft 04 this now reads: "Note that ”DAV:“ is a top-level URI
identifier that was defined
solely to provide a namespace for WebDAV XML elements and property
names. This practice is discouraged in part because registration of
top-level URI identifiers is difficult. "DAV:" was defined as the
WebDAV namespace before standard best practices emerged, and this
namespace is kept and still used because of significant existing
deployments, but this should not be emulated. "]
Rewrite as:
“Note that both defining a new URI scheme just for the purpose of
identifying protocol elements, and using just the scheme name as a
namespace name is to be considered a bad practice, and should not be
copied”.
[draft 05 now says...]
Note that “DAV:” is a scheme name defined solely to provide a
namespace for WebDAV XML elements and property names. This practice
is discouraged in part because registration of new scheme names is
difficult. "DAV:" was defined as the WebDAV namespace before
standard best practices emerged, and this namespace is kept and
still used because of significant existing deployments, but this
should not be emulated.
Well. The practice is not discouraged because registering new schemes is
hard. It's the other way around: registering new schemes is hard because
the IETF suggests using existing schemes whenever possible, and in this
case, defining a new scheme was not necessary at all.
Also, the *other* issue is using just a URI scheme name as a namespace
name. This does not conform to RFC2396 (the character sequence "DAV:" is
not a legal URI and thus should not have been used as namespace name).
So I still think my proposed rewrite is more precise.
03-C05
4.5: “The value of a property appears inside the property name element.
The value may be any text, including valid XML. When the value is
structured as XML, namespaces that are in scope for that part of the
XML document apply within the property value as well, and MUST be
preserved in server storage for retransmission later. Namespace prefixes
need not be preserved due to the rules of prefix declaration in XML.”
1) I think this needs to rephrased to use proper XML terminology, also
2) I think that namespace prefixes within the property value do need to
be roundtripped.
Proposal:
“The value of a property appears inside the property name element and
may be any kind of well-formed XML content, including both text-only and
mixed content. When the property value contains further XML elements,
namespaces and namespace prefixes that are in scope for that part of the
XML document apply within the property value as well, and MUST be
preserved in server storage for retransmission later.”
Update draft -05/06:
Issue 2 still needs to be resolved, the current text says: "Namespace
prefixes need not be preserved due to the rules of prefix declaration in
XML. This is incorrect because namespace prefixes *are* significant for
certain XML vocabularies, such as XSLT and XML Schema. So independantly
of what we decide for WebDAV, we should add an accurate statement about
what that means for arbitrary XML content in properties.
03-C12:
8.1.1.: “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].”
Add “…and [REC-XMLNS]”.
We also need allow servers and clients to rejects a certain set of
request/response that are indeed well-formed, in particular:
- when it exceeds some predefined size or
- when expansion of internal entities may cause a denial of service.
Update draft -05/06
the last issue still needs to be adressed
03-C14:
8.1.3: “When the Location header is used in a response, it is used by
the server to indicate the preferred address for the target resource of
the request. Whenever the server has a preferred address, it should
use that address consistently. This means that when a response contains
a Location header, all the URLs in the response body (e.g. a
Multi-Status) should be consistent.”
If we keep this paragraph, we’ll have to define what “consistent” means
here.
03-C16:
8.1.5: “If ETags are supported for a resource, the server MUST return
the ETag header in all PUT and GET responses to that resource, as well
as provide the same value for the 'getetag' property.”
Note that this breaks the “etag promotion” strategy used both by IIS and
Moddav (PUT usually returns weak etags which later are promoted to
strong etags when there was no other change to that resource within a
specific time window). Therefore I’d make that a SHOULD (at least for PUT).
03-C17:
8.1.5.: “Because clients may be forced to prompt users or throw away
changed content if the ETag changes, a WebDAV server MUST not change the
ETag (or getlastmodified value) for a resource when only its property
values change.”
Some servers do, and I don't think we can change that. Therefore I think
this change at least needs explicit consensus on the mailing list.
As a minimum, I'd suggest changing MUST not (which should be "MUST NOT"
anyway...) to "SHOULD NOT". Reason: there's a risk of making otherwise
compliant servers non-compliant. All we gain in exchange is a possible
(!) small improvement in ETag reliability.
03-C19:
General comment re: 8.1.6: I really like that change (actually, I like
it so much that I’d like to have condition names for all frequently
signalled problems….). However, if it uses the same format as RFC3253,
it should be consistent with it. In particular, the names should
identify conditions that must be met. For instance, use
“allow-external-entities” rather than “forbid-internal-entities”. We may
also want to note that one DAV:error element can hold multiple elements
identifying failed conditions.
03-C22:
8.2: “URLs for collections appearing in the results MUST end in a slash
character.”
I don’t think we have consensus for this being a MUST.
03-C24:
8.2.2: “This example also demonstrates the use of XML namespace scoping,
and the default namespace. Since the "xmlns" attribute does not contain
an explicit "shorthand name" (prefix) letter, the namespace applies by
default to all enclosed elements. Hence, all elements which do not
explicitly state the namespace to which they belong are members of the
"DAV:" namespace schema.”
Change to:
“This example also demonstrates the use of XML namespace scoping, and
the default namespace. Since the "xmlns" attribute does not contain a
prefix, the namespace applies by default to all non-prefixed enclosed
elements. Hence, all elements which do not explicitly state the
namespace to which they belong are members of the "DAV:" namespace.”
(Actually I'd rather prefer to get rid of this. RFC2518bis shouldn't try
to give XML lessons).
Update re: -05: the spec still uses the term "namespace schema" which
isn't a well-defined technical term. Just say "namespace".
03-C29:
9.1 (DAV header) allows coded URLs in the DAV header. I’d like to see
the rationale for that.
03-C30:
9.4 (force-authenticate): is this the consensus we reached in January?
Ilyas, did you take notes?
03-C31:
9.5 defines “<no-lock>” as a new special state token. I think this is
unneeded – any URI which is known not to identify a lock MUST work as
well, so we can simply recommend using something like “<DAV:no-lock>”
(which is something that RFC2518-compliant servers already support).
[This text changed, but it now makes "DAV:no-lock" a special feature of
the grammar. This is not necessary. Just state that DAV:no-lock by
definition never identifies a valid lock (because the WebDAV WG says so :-)]
Update -05: the grammar was fixed, but the text still reads as if
there's something special about DAV:no-lock. Just state that DAV:no-lock
is an *example* for a URI that definitively will never identify a WebDAV
lock, just like any other URI using the DAV: scheme.
03-C32:
(old text) The example in 9.5.2 uses an invalid lock token (the URI
scheme “locktoken” isn’t IETF-registered, so it can’t claim conformance
to the uniqueness requirements). Just use a sample token using the
“opaquelocktoken” scheme instead).
[this now uses the right scheme, but an illegal token value]
03-C34:
Section 13: XML element definitions
I don’t like the syntax change in the DTDs. For instance, activelock now
is defined as:
<!ELEMENT activelock ANY>
ANY value: Any number of elements, including one of each of
(lockscope, locktype, depth, owner, timeout, locktoken, lockroot)
It used to be:
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
locktoken?) >
For consistency with RFC2518, RFC3253 and the ACL spec we really should
stay with the old notation.
Update -05: the old notation is back, this is good. The spec now defines
extensibility case-by-case, IMHO it should only define it when it's not
the standard extensibilty. Also:
"Extensibility: MAY be extended with additional child elements or
attributes which SHOULD be ignored if not recognized."
s/SHOULD/MUST/
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?
Update -06:
Still says "should normally succeed". Recommend leaving this out; it
just behaves like any other empty resource.
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-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.
Update -06: this text still is in, now in 8.9.2.
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?
Update -06: this has been reworded again, but I still think it's
misleading. MOVE may or may not create a new resource (as RFC2518
explicitly allows COPY/DELETE semantics). When it does, the creationdate
will change. When it doesn't, it won't.
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."
Update -06: now in 8.11.1. Please update the first sentence as proposed.
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>
Update -06: now in 8.11.7.
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-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?
Update -06: now in section 14.2.
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-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).
Update -06: now in section 18.
Editorial notes:
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-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/0040.html>
[2] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0041.html>
[3] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JulSep/0049.html>
[4] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0146.html>
[5] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0148.html>
[6] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0149.html>
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 11 September 2004 16:35:24 UTC