Re: rfc2518-bis-04 issues (part 1)

I don't have the spec handy, so I can only comment on the items that 
include
enough comment...

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

The previous text seems clearer.  I'd not rewrite this.


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

I have no opinion on prefix preservation. 


> 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
Sounds fine, but it's just one of several reasons to reject
a request.  If possible, I'd like to declare these as out of
scope as long as we're clear how the server should respond
to problems of this class.  Is it clear how server writers
should respond to problematic situations that we don't
explicitly mention?



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

I vote for the wording that is in there.  I think we've already reached 
consensus
that changing property values should not be changing etags.


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

All dead properties must be returned?  I didn't pick that up in our 
discussions.