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

RE: Loop Detected

From: Tim Ellison/OTT/OTI <Tim_Ellison@oti.com>
Date: Thu, 16 Mar 2000 09:48:20 -0500
To: w3c-dist-auth@w3.org
Message-ID: <OF1F6AE3C1.1AC99147-ON852568A4.00510723@ott.oti.com>

I think the simplest solution is to say that the server answers the
property values in a Loop Detected propstat.  This is probably simpler for
the server anyway (not having to strip out values because it is a loop
detected status).

A note in the spec can point out that if clients want to reconstruct the
graph they can deep propfind the dav:urn.

I don't think it is a good idea to return a property the client didn't ask
for.


Tim




                                                                                                        
                    "Slein, Judith A"                                                                   
                    <JSlein@crt.xerox.        To:     "'Clemm, Geoff'" <gclemm@rational.com>,           
                    com>                      w3c-dist-auth@w3.org                                      
                    Sent by:                  cc:                                                       
                    w3c-dist-auth-requ        Subject:     RE: Loop Detected                            
                    est@w3.org                                                                          
                                                                                                        
                                                                                                        
                    16-03-00 09:35 AM                                                                   
                                                                                                        
                                                                                                        



We can make it that the property values get returned for the 506 resource,
but as you say that will not in general be helpful to the client in
reconstructing the graph.  It would just be a matter of luck if the
properties requested allowed you to identify the resource bound to the
href.
As you say, the only property that allows this is DAV:urn.

So it's not just a matter of changing the example to one where DAV:urn was
requested.

I know you will hate this suggestion, but we could have servers always
return DAV:urn, whether it was requested or not, for all the resources if
there is a 506 anywhere in the response.

Or we could add a note suggesting to clients that if they want to
reconstruct the graph, they should submit another PROPFIND Depth: infinity
to the same resource, requesting DAV:urn.

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Wednesday, March 15, 2000 4:29 PM
To: w3c-dist-auth@w3.org
Subject: RE: Loop Detected


I agree with Tim.  Furthermore, I would suggest that the example use
the DAV:urn property (aka DAV:resource-id), since that illustrates the
value of the DAV:urn property (the DAV:display-name is not a reliable way
of identifying a resource).

Cheers,
Geoff

-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com]
Sent: Wednesday, March 15, 2000 3:29 PM
To: w3c-dist-auth@w3.org
Subject: Loop Detected


The example given in section 12.1 of draft-ietf-webdav-binding-protocol-02
of a PROPFIND depth infinity in the presence of a loop implies that the
propstat for the loop detected resource only contains the property names
and not their values (again).
Although I can understand the point of this in the majority of cases, it
does prevent the client from reconstructing the graph of resources since
they cannot determine the destination of the binding.  If the properties
were returned the client could PROPFIND depth infinity on the resource
identifier and reconstruct the graph.

Tim
Received on Thursday, 16 March 2000 09:51:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT