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

Comments inlined below...

Cheers,
Elias


Jason Crawford wrote:

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

The existing text seems a bit 'heavy' (for lack of a better word), while 
the suggested replacement seems a bit 'light'. At the least, it makes 
sense to include some justification for the approach that was taken 
while making the case for others to not follow in suit. Further, saying 
something is 'bad practice' or discouraged without explaining why simply 
begs the question...

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

My feeling is that while a server is allowed to rewrite XML as long as 
it preserves the semantics, dropping namespace prefixes is likely to 
cause problems. For example:

Storing
<Foo:bar>
</Foo:bar>
as
<Foo:bar/>
to save space is perfectly fine, while storing the above as
<bar/>
is not. The issue at hand is that namespaces serve to qualify the 
semantic interpretation of a given XML element, hence dropping that 
qualification can only lead to interoperability problems between clients 
which respect or, alternately, expect namespaces. Without the namespace 
qualifier, a client may not be able to know what is meant by an element. 
I would be happy to construct a more meaningful example to illustrate 
this, but I hope the above is sufficient. This is an important issue 
that we need to reach a concensus on.

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

I agree, adding the suggested text is a good idea. Re: Jason's comment, 
I think the best we can do is define a common response mechanism, as 
what qualifies as exceeding 'some predefined size' and what constitutes 
a denial of service attack will likely change from one server to another 
and over time as server hardware improves.

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

I also believe that there was already concensus re: property values not 
affecting ETags... Since doing a PUT of a resource doesn't affect 
properties and a GET doesn't retrieve properties, the ETag should not 
change when properties on a resource do. That is to say that ETags 
should only be modified when the enitity, itself, is modified (hence the 
name entity tag). We may want to consider, however, introducing an 
equivalent property tag, or PTag, which could be used to determine if 
properties on a given resource have changed. An argument with a (set of) 
use case(s) would have to be developed to make this a compelling idea.