rfc2518-bis-05 issues (part 1)

Hi.

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


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

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

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/





Editorial notes:


03-E04

There are still 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/2003JulSep/0040.html>

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

Received on Tuesday, 28 October 2003 16:02:06 UTC