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

Since this statement of "what protocol extensions I understand" is
a generically interesting one, including for requests that do not have
an extensible body (e.g. PUT), I suggest we marshall this information
in the form of a header, not as an XML tag in the body of the request.

Other than that, your proposal is fine with me.  This is clearly something
which should eventually find its way into a successor of 2518, but I'm
happy to introduce it in the binding protocol first.

I'd like to see more folks comment on this though, before moving in that
direction.

WRT to the 208 approach vs. the alternative you described, I believe that
the 208 approach is the simplest approach, and I do not think
it is a benefit to try to couple two very different kinds of situations, 
i.e. how
to marshall a recursive structure vs. how to report on an access 
restriction.

Cheers,
Geoff 


"Julian Reschke" <julian.reschke@gmx.de> wrote on 08/04/2003 04:52:20 PM:

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