W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2004

Re: edits on BIND draft

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 12 Jan 2004 09:56:04 +0100
Message-ID: <40026124.6030900@gmx.de>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Cc: webdav <w3c-dist-auth@w3.org>

Geoffrey M Clemm wrote:

> I believe the previous wording of the 208 section
> was better, and should be restored.

Well, we found it to be confusing. Obviously neither is good enough, and 
we need to work on it :-)

> In particular, I don't see why status 208 should be
> restricted to collections (if you have multiple bindings
> to a non-collection, a server should be able to generate
> 208's for that as well).

Why would it do that? It could generate a 200 as well.

The confusing thing (to us) was not entirely clear about what it means 
to be "already reported" and when it occur. The intent of the change was 
to clarify that.

> Also, I don't see why it should be restricted to Depth:infinity
> (it can arise for Depth:1).

Not the way it is defined now.

OK, before we discuss the wording, let's try to agree on what it should 
mean:

The intent of the 208 code was to allow PROPFIND to handle bind loops.

BIND loops are relevant only for Depth: Infinity operations (for Depth: 
0, no bindings are enumerated anyway, for Depth: 1, enumerating another 
binding to a previously reported collection is harmless).

Thus, to achieve this goal in the most simple way, I'd say that the 
current description is the best one:

A 208 is reported instead of a 200 whenever the server decides not to 
enumerate the children of a particular collection because they have 
already been reported. This situation (as discussed above) IMHO can only 
occur for Depth: infinity.

> The new sections on the DAV header are good.

Thanks,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 12 January 2004 04:05:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:51 UTC