RE: Binding loops and PROPFIND clarification needed (was Re: COPY and bindings)

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Geoffrey M Clemm
> Sent: Monday, August 04, 2003 5:40 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Binding loops and PROPFIND clarification needed (was Re: COPY
> and bindings)
>
>
>
> "Julian Reschke" <julian.reschke@gmx.de> wrote on 08/04/2003 08:52:26 AM:
>
> > ... old clients that treat 208 as success will incorrectly assume
> > that a collection was empty, while old clients that treat 208 as
> > error will fail to display additional bindings to a resource.
> >
> > I think that there is no easy way to marshall this information in a
> > way compatible with old clients. We've spent a lot of time
> > discussing this, but still don't have a solution. Therefore my
> > alternate proposal just to forbid this very special case.
>
> My counter proposal is that servers who are concerned about this can
> return 506 on the request as a whole, while servers that are not
> concerned about old client behavior in this regard can take advantage
> of 208.

OK, but let's please be clear about what we're doing. Both your "208"
proposal and my old proposal suffer from old clients possibly
misinterpreting the response. In general, a server has no way to know what a
client will understand, so -- as Lisa just pointed out -- we really
shouldn't send possibly misleading information to the client.

But fortunately, this can be fixed:

1) For PROPFIND/depth:infinity on a collection containing bind loops, always
return 506 *unless* the client clearly indicates that it knows about the
protocol extension.

2) Extend PROPFIND such that the client can indicate that it knows about our
new-style responses, such as:

<propfind xmlns="DAV:"><allprop/><understand-208/></propfind>

This would settle the issue about not confusing old clients. We thus would
have the freedom to express the "new" conditions we want to marshall. There
seem to be two approaches:

a) (your 208 proposal): allow the server just to report a 208 for a resource
that was already mentioned in the response. A smart client would need to
PROPFIND DAV:resource-id to actually process these, but that's easy enough.

b) (my proposal): allow the server to indicate somehow that the resource was
reported ok, but members were omitted from the result. I like this one more
because it would also resolve the other issue (PROPFIND not being able to
report that the client didn't have the *right* to list the members of a
collection -- I think you missed this one from my previous reply).

Regards, Julian

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

Received on Monday, 4 August 2003 16:52:41 UTC