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

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Jason Crawford
> Sent: Wednesday, July 30, 2003 6:20 PM
> To: Julian Reschke
> Cc: w3c-dist-auth@w3.org
> Subject: 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
anamespace
> > name is to be considered a bad practice, and should not be copied".
> >
>
> The previous text seems clearer.  I'd not rewrite this.

It may "seem" clearer, but it isn't. Mainly

1) usage of the term "top-level URI identifier" -- this isn't documented
anywhere. We're talking about the URI scheme name, and thus should use that
term.

2) the issues are exactly what I wrote: a) defining a new URI scheme without
actually needing one, and b) using just the scheme name as namespace URI
(which is illegal according to RFC2396).

Therefore, this section should be rewritten accordingly.

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

It was pointed out that the prefixes are irrelevant, *unfortunately* this is
not true, as they also may appear in attribute values (for instance in XSLT
and XML Schema datatypes).

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

First of all, we should clarify that servers may reject requests for a
number of reasons we don't specify, such as to prevent DoS attacks.

In this particular case, I think the spec should actually *recommend* these
requests because they are a known XML protocol vulnerability.

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

a) When and where?

b) Just for etags or for the last-modified date as well?

I just want to make sure that everybody is aware that this requirement will
make existing servers non-compliant, and it's unclear whether they'll be
able to become compliant. So we'll either see servers not being upgraded to
RFC2518bis, or servers claiming compliance to RFC2528bis but breaking it. I
don't see this as improvement.

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

It never was discussed. RFC2518 guarantuees this and there never has been
any discussion about changing this (why?).

Julian

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

Received on Wednesday, 30 July 2003 14:16:30 UTC