W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2003

RE: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 22 Jun 2003 16:22:19 +0200
To: "Joe Orton" <joe@manyfish.co.uk>, <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEDKHKAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton
> Sent: Sunday, June 22, 2003 1:08 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Reconsidering DTDs and validity (was RE: I-D
> ACTION:draft-ietf-webdav-rfc2518bis-03.txt)
> I think it's important to retain some of the ordering constraints given
> by the DTD fragments in 2518 - specifically it is useful that a client

I really don't care much about the issue. However, we really really need to
decide this, and then stay consistent. The current situation obviously is

*If* we decide that ordering *is* relevant, we should clarify that both
servers and clients must reject messages that do not comply. I don't want to
end up in a situation where some clients work with non-compliant servers,
while others don't.

However, my feeling is that *currently* almost everybody ignores the
ordering, and that server behaviour is *not* consistent. Thus from a
standards progress point of view, it would make sense for RFC2518bis just to
state that the ordering is irrelevant.

> can assume that in the response element, a propstat MUST be preceded by
> an href.
> Since a propstat cannot be interpreted without knowing which URI it
> applies to, if this constraint is missing, the client is required to be
> able to batch propstats in memory until the href arrives.  With this
> constaint, propstats can always be processed on the fly.

Stream processing of response bodies is a very interesting problem. However,
I think even if you can rely on ordering, it is still hard. For instance,
how do you process:

   <D:multistatus xmlns:D="DAV:">
               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
                         <R:BoxType>Box type A</R:BoxType>
                         <R:Name>J.J. Johnson</R:Name>
               <D:status>HTTP/1.1 200 OK</D:status>
               <D:status>HTTP/1.1 403 Forbidden</D:status>
               <D:responsedescription> The user does not have access to
   the DingALing property.
    This is malformed: &

A compliant client must reject this reponse, because the body is malformed.

BTW: you will need to batch the propstat element until you've reached the
DAV:status element (confirming it's a "200") anyway. I don't see a big
difference to waiting for the closing response tag.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 22 June 2003 10:22:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:29 UTC