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

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

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 4 Aug 2003 17:46:57 -0400
To: w3c-dist-auth@w3.org
Message-ID: <OFDAE4431B.82096012-ON85256D78.0075ED4B-85256D78.0077A80E@us.ibm.com>
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

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 


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

> > From: w3c-dist-auth-request@w3.org 
> > 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: 
> > and bindings)
> >
> >
> >
> > "Julian Reschke" <julian.reschke@gmx.de> wrote on 08/04/2003 08:52:26 
> >
> > > ... 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, 
> 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 
> new-style responses, such as:
> <propfind xmlns="DAV:"><allprop/><understand-208/></propfind>
> This would settle the issue about not confusing old clients. We thus 
> have the freedom to express the "new" conditions we want to marshall. 
> seem to be two approaches:
> a) (your 208 proposal): allow the server just to report a 208 for a 
> 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 
> b) (my proposal): allow the server to indicate somehow that the resource 
> reported ok, but members were omitted from the result. I like this one 
> because it would also resolve the other issue (PROPFIND not being able 
> 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 17:47:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC