rfc2518-bis-04 issues (part 1)

Hi.

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



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…”

[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”.



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

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



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.

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



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-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-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-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 :-)]



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.



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

[This has been done, but it still says "three" -- remember the Spanish
Inquisition Sketch?]



Editorial notes:


03-E01

Expiry date is wrong.


03-E04

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






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

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

Received on Wednesday, 30 July 2003 09:18:07 UTC