Subject: Loop Detected

From: "Tim Ellison/OTT/OTI" <[email-masked]>
Date: Wed, 15 Mar 2000 15:28:30 -0500

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

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 15 Mar 2000 16:29:00 -0500

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:[email-masked]]
Sent: Wednesday, March 15, 2000 3:29 PM
To: [email-masked]
Subject: Loop Detected

Tim

---

From: "Slein, Judith A" <[email-masked]>
Date: Thu, 16 Mar 2000 09:35:45 -0500

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:[email-masked]]
Sent: Wednesday, March 15, 2000 4:29 PM
To: [email-masked]
Subject: RE: Loop Detected

Cheers,
Geoff

-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:[email-masked]]
Sent: Wednesday, March 15, 2000 3:29 PM
To: [email-masked]
Subject: Loop Detected

Tim

---

From: "Tim Ellison/OTT/OTI" <[email-masked]>
Date: Thu, 16 Mar 2000 09:48:20 -0500

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"                                                                   
                    <[email-masked].        To:     "'Clemm, Geoff'" <[email-masked]>,           
                    com>                      [email-masked]                                      
                    Sent by:                  cc:                                                       
                    w3c-dist-auth-requ        Subject:     RE: Loop Detected                            
                    [email-masked]                                                                          

                    16-03-00 09:35 AM                                                                   

properties requested allowed you to identify the resource bound to the
href.

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]
Sent: Wednesday, March 15, 2000 4:29 PM
To: [email-masked]
Subject: RE: Loop Detected

Cheers,
Geoff

-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:[email-masked]]
Sent: Wednesday, March 15, 2000 3:29 PM
To: [email-masked]
Subject: Loop Detected

Tim

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 16 Mar 2000 11:18:59 -0500

As you probably saw from my response to the "Loops II" thread,
I believe that we should have a new status code called "Duplicate Detected",
and that the Duplicate-Detected status MUST indicate the DAV:urn property
(but no other property) of the duplicate resource. 

So this isn't quite what you propose below (since the client still has to
explicitly request the DAV:urn property for non-"Duplicate-Detected"
members,
but I think it gives you the desired functionality.

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:[email-masked]]
Sent: Wednesday, March 15, 2000 4:29 PM
To: [email-masked]
Subject: RE: Loop Detected

Cheers,
Geoff

-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:[email-masked]]
Sent: Wednesday, March 15, 2000 3:29 PM
To: [email-masked]
Subject: Loop Detected

Tim

---

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 16 Mar 2000 11:29:57 -0500

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

If the server is going to generate a "Duplicate Detected" status, I don't
think
it would be any problem for it to stuff a DAV:urn in there instead of the
properties list.  If the client cares what those properties are, it can use
the DAV:urn value to find them in the PROPFIND result body.  I think that it
is important that binding not introduce unnecessary duplication of property
values
in PROPFIND responses.

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

Yes, but that doesn't help them avoid having to parse all those redundant
property
entries in the PROPFIND response.

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

I agree that we shouldn't force a server to return DAV:urn for normal status
responses, but I think it reasonable to require the DAV:urn appear for the
"Duplicate Detected" status responses.

Cheers,
Geoff 

	                    "Slein, Judith A"

	                    <[email-masked].        To:     "'Clemm,
Geoff'" <[email-masked]>,           
	                    com>                      [email-masked]

	                    Sent by:                  cc:

	                    w3c-dist-auth-requ        Subject:     RE: Loop
Detected                            
	                    [email-masked]

	                    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:[email-masked]]
	Sent: Wednesday, March 15, 2000 4:29 PM
	To: [email-masked]
	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:[email-masked]]
	Sent: Wednesday, March 15, 2000 3:29 PM
	To: [email-masked]
	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

---

From: [email-masked]
Date: Thu, 16 Mar 2000 17:31:28 -0500

Or we could have structured status codes that might include parameters with
the details of the status.  Yaron is always mutting about us doing this
some day.  :-)