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

I'd like to thank Julian for this excellent and careful review!

I agree with all of his points.  The only one I was tempted to
question was "Section 13: XML element definitions", where he
suggested going back to the old syntax for DTD's.  But upon
further reflection, although I believe the new more flexible
notation should be used when defining all new elements,
for compatibility with old servers, we should probably maintain
the element order defined by 2518, so I actually agree with that
point as well (:-).

So I vote that all of the changes suggested by Julian be made
to the next draft of 2518bis.  Note: I have no good idea about
how to deal with the 5 author limit question (:-).

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Tuesday, March 18, 2003 7:52 AM
To: w3c-dist-auth@w3.org
Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt



Here's a set of both -bis03 and generic RFC2518 comments:

Content:

03-C01

Paragraph 1: "A DTD is provided..." -> "An informational DTD is provided..."


03-C02

4.4: "...or when they may be shown to a human user and hence require
encoding
in..."

I'm not sure what the requirement "may be shown to a human user" is supposed
to mean here. Proposal: just write:

"...or when they require encoding in..."


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

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


03-C04

4.5: "The value of a property when expressed in XML MUST be well formed."

The value of a property always is expressed in XML (or more precisely: an
XML fragment). XML by definition is well-formed.


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
round.tripped.

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


03-C06:

6.3: "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. Each lock has only one unique lock token."

Change to:

"A lock token is returned by every successful LOCK operation in the
lock-token header, and can also be found through lock discovery on a
resource. Each lock has exactly one unique lock token."


03-C07:

6.4: "All resources MUST recognize the opaquelocktoken scheme and, at
minimum, recognize that the lock token does not refer to an outstanding lock
on the resource."

(old text) I think this is misleading. Any resource must recognize any valid
URI. If a URI uses a scheme it doesn't know of, this simply means it doesn't
identify any particular lock assigned by this server. So I'd recommend to
get rid of this sentence, and possibly add a clarification to 6.3 instead.


03-C08:

7.4: "However, interoperability and compliance problems have been found with
lock-null resources.  Therefore, they are deprecated.  WebDAV servers
compliant with this document SHOULD create regular locked empty resources,
which behave in every way as if they were a normal resource."

This sort of suggests that lock-null resources indeed are still something
different than a normal resource, which isn't true.


03-C09:

7.4: "Can be downloaded, deleted, moved, copied, and in all ways behave as a
regular resource, not a lock-null resource."

I think the term "downloaded" is misleading here. From a WebDAV protocol
p.o.v., it probably should be "read".


03-C10:

7.4.: "SHOULD default to a content-type of "application/octet-stream". "

No. I don't think there's consensus for that, and requiring a specific
content type seems to have no value at all to clients (see also 8.11,
"Locking Unmapped URLs").


03-C11:

7.8: "If an error is received in response to a refresh LOCK request the
client SHOULD assume that the lock was not refreshed."

I think we should make that a "MUST".


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.

03-C13:

8.1.2: "Some of these new methods do not define bodies.  Servers MUST
examine all requests for a body, even when a body was not expected.  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).  This
informs the client (which may have been attempting to use an extension) that
the body could not be processed as they intended."

I'd like to understand whether this affects methods other than MKCOL.


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-C15:

8.1.4.: "Note that HTTP 1.1 requires the Date header in all responses."

That's not true. HTTP 1.1 specifically supports clockless servers.


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.


03-C18:

8.1.6: "HTTP and WebDAV did not use the bodies of most error responses until
DeltaV introduced a mechanism to include more specific information in the
body of an error response (section 1.6 of [RFC3253])."

That's not really true. HTTP indeed recommends to send error descriptions in
the response bodies as well.


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-C20:

8.2.: "DAV compliant servers MUST support the "0", "1" and "infinity"
behaviors."

Change to:

"DAV compliant servers MUST support the "0" and "1" behaviors and MAY
support the "infinity" behavior."


03-C21:

8.2.: "Note that 'allprop' does not return values for all properties."

Change to:

"Note that 'allprop' does not return values for all live properties."



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-C23:

8.2: "Note that URLs and URIs in XML must always be fully legal URIs. For
example, it is illegal to use a space character or double-quote in a  URI
[RFC2396].  URL-escaping is commonly used (e.g. replace a space with a
sequence such as %20). The URI must not appear in XML "unescaped", it must
be in its legal URI format."

This is misleading. Of course URIs must conform to the URI syntax - that's
the whole point, right? In particular, there's no such thing as a "unescaped
form" of a URI. URIs do not allow the space character, and therefore a URI
never ever contains a space character.

What we should say here is how servers should behave when their internal
implementation model of collections allow member names that aren't legal URL
path segments (answer: encode as UTF-8 octet stream, then URI-escape).


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


03-C25:

8.7: "If the DELETE method is issued to a non-collection resource whose
URIs are an internal member of one or more collections, then during  DELETE
processing a server MUST remove any URI for the resource identified by the
Request-URI from collections which contain it as a member."

I think we want to get rid of this statement. Does anybody implement this
right now?


03-C26:

8.11: "The LOCK request may have a Timeout  header."

"may" -> "MAY".


03-C27:

8.11, "Interaction with other Methods": "However, independent of lock type,
a successful DELETE  of a resource MUST cause all of its locks to be
removed."

(old text) I think this is misleading. A DELETE on a resource only removes
those locks that aren't inherited.


03-C28:

8.12: "A successful response to an UNLOCK method does not mean that the
resource is unlocked.  At most, it means that the specified token no longer
identifies a lock on the resource."

Change to:

"A successful response to an UNLOCK method does not mean that the resource
is unlocked.  At most, it means that the specified token no  longer
identifies a lock on any resource."


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


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


03-C33:

9.5.5: "The not production is used to reverse that value."

Change to:

"The 'Not' production is used to reverse that 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.


03-C35:

Section 17: "which has explicit provisions for character set tagging and
encoding, and requires that XML processors read XML elements encoded, at
minimum, using the UTF-8 [UTF-8] encoding of the ISO  10646 multilingual
plane."

Unless we get rid of this section, we'll have to add UTF-16.


03-C36:

Section 17: "Names used within this specification fall into three
categories:  names of protocol elements such as methods and headers, names
of XML elements, and names of properties."

We may want to add a new category (condition names).





Editorial notes:


03-E01

Expiry date is wrong.


03-E02

IETF wants a maximum of 5 authors.


03-E03

Paragraph 1: "marshall"  -> "marshal"


03-E04

There are many places where example URLs do not use the set of example host
names allowed by the IETF.


03-E05

8.1.5 uses the term "etag". HTTP uses "etag" only as header names, and talks
about "entity tags" everywhere else. So should we.


03-E06

8.2.2 uses the term "progeny", which I haven't seen before in this context.
Maybe replace by something more common, such as "members".


03-E07:

8.2.2. still uses concatenation of namespace names and element names to
identify property names.






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

Received on Thursday, 20 March 2003 23:30:14 UTC