Subject: COPY and bindings

From: "Nevermann, Dr., Peter" <[email-masked]>
Date: Thu, 10 Jul 2003 10:13:45 +0200

Suppose the following:
- a resource R
- a collection C1 with a binding x to R
- a collection C2 with a binding y to R
- a collection C mapped to URI-1 containing C1 and C2

i.e.:

    C
   / \
  C1 C2
   \ /
    R

Now I issue a COPY on URI-1 with destination URI-2 and depth infinity.

How many copies do I get for R, one or two?

i.e.:

    C'
   / \
 C1' C2'
   \ /
    R'

or

    C'
   / \
 C1' C2'
  |   |
  R'  R"

??

I suspect that 2 copies is correct ... or at least, the server is allowed to
duplicate R at destination.

Thanks,
Peter

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 10 Jul 2003 09:09:40 -0700

Excellent question. I'd say that the current language in bind-02 doesn't
sufficiently cover this case, and we should clarify it.

Another possible outcome for your scenario is that you get zero additional
copies of R, that only C is duplicated, but all its bindings stay the same.
I don't think these are the semantics we want (i.e., I'm not advocating
them), but they are another possible reading of the current specification
(and hence another reason why we need to clarify the semantics of copy for
depth infinity).

I have a slight leaning towards preserving the bind structure of the source
at the destination, and hence in your scenario I'd choose:

    C'
   / \
 C1' C2'
   \ /
    R'

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Nevermann, Dr., Peter
Sent: Thursday, July 10, 2003 1:14 AM
To: [email-masked]'
Subject: COPY and bindings

Suppose the following:
- a resource R

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 10 Jul 2003 12:20:25 -0400

Good question.  I would argue that 1 copy is the more desireable
behavior, but 2 copies will be easier for many servers to implement
(for example, that is what "cp -r" does on Unix).

So my preferences would be (from high to low):
1- require 1 copy
2- leave it up to the server
3- require 2 copies.

Any votes?

Cheers,
Geoff

Peter wrote on 07/10/2003 04:13:45 AM:

> I suspect that 2 copies is correct ... or at least, the server is 
> allowed to duplicate R at destination. 
> Thanks, 
> Peter

---

From: Chris Knight <[email-masked]>
Date: Thu, 10 Jul 2003 10:18:58 -0700

>2- leave it up to the server
I'd definitely go for 1 (maintaining bindings with a copy) but I 
understand the server implementation implications are a bit of a 
challenge, especially for fs-backed servers. I'd strongly discourage 2 
(maybe make the behavior a SHOULD instead of a MUST.)

Moreso, I'd vote that it should be encouraged to maintain consistent 
behavior from the server (for intra-server copies) and the client (for 
inter-server copies). Certainly 3 is easier for clients to perform 
*unless you have loops*. I'm currently researching some implementation 
implications (using an RDBMS-backed server) of looping binds and it's 
not perty.

It should be possible for a client (using the DAV:resourceid property) 
to identify if it's encountered a loop...But it would have to do copies 
step-wise as a PROPFIND Depth: infinity would result in a 506 Loop 
Detected error and incomplete/no information. Actually, it'd have to do 
this anyways whether it recreated bindings or "split on copy".

8^O

---

From: Chris Knight <[email-masked]>
Date: Fri, 11 Jul 2003 14:24:54 -0700

Reading this discussion has brought up another point of confusion that 
may need clarification in the spec. If you have a binding loop and you 
are doing a Depth: infinity PROPFIND, you either (correct me if I'm 
wrong, 'course):

a) return a 506 Loop Detected error
b) return a 207 Multistatus containing responses and when you come 
across loops, identify them as such with a 506 Loop Detected

What's unclear to me (perhaps due to the example given in the spec) is 
that, in the second case, do you continue traversing the tree when a 506 
is encountered or do you terminate traversal?

For example, if you had the following example:
             --C-
            v      |
1-A->2-B->3
   -D->4

Sorry for the poor ASCII graphics and it's probably unreadable. The 
numbers represent unique resources (think of them as resource id's.) The 
textual description is that the root collection "/" contains two members 
"/A" and "/D". "/A" contains one member "/A/B" and "/A/B" contains one 
member "/A/B/C" which is bound to "/A" (resource id 2).

Now, presuming we do a depth-first search and we go down "/A/B" first, 
we would report a 200 for "/A", a 200 for "/A/B", a 506 for the loop 
"/A/B/C", and a 200 for "/A/D". Correct? Or do I report a 200 for 
"/A/B/C" and then a 506 for the fact that "/A/B/C" created a loop?

How would I tell where the loop connected to? (i.e. how do I tell the 
loop goes back to resource id 2 and not 1?) Would I do a followup 
PROPFIND on "/A/B/C" to determine the resource id? What if I got back 10 
506 responses?

Would it be possible (correct) to either report a 200 for "/A/B/C" 
(containing the resource-id property) and then a 506? Or perhaps a 
"Resource-ID" HTTP header in the 506 response?

This is important if we want clients to be able to replicate loops 
across servers.

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 11 Jul 2003 23:48:15 +0200

Chris,

you are right that this probably should be explained a bit better.

My p.o.v. (which seems to be compatible with the example) is that the 506
should be reported once the depth:infinity processing encounters a resource
that already has been traversed/reported. So, in your example, you'd report
a 506 for "/A/B/C" -- note that you can't report the same resource twice.

It's also correct that this means that a client that wants to replicate
bindings will need an additional PROPFIND against "/A/B/C" to get the
DAV:resource-id.

However, this *only* applies to depth:infinity processing, which is sort of
deprecated anyway (meaning servers are allowed to reject these requests, and
I think moddav does this by default).

So my understanding is that a "modern" client would only do depth:1
PROPFINDs, and thus never see a 506.

Regards, Julian

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

> From: Chris Knight [mailto:[email-masked]]
> Sent: Friday, July 11, 2003 11:25 PM
> To: Julian Reschke
> Cc: [email-masked]'
> Subject: Binding loops and PROPFIND clarification needed (was Re: COPY
> and bindings)
>
>

---

From: Chris Knight <[email-masked]>
Date: Fri, 11 Jul 2003 15:06:19 -0700

>you are right that this probably should be explained a bit better.
First/easiest thing would be to change the example to have the 506 
followed by a 200. (The example implied to me that processing stopped at 
the first 506.)

>bindings will need an additional PROPFIND against "/A/B/C" to get the
Fair enough. In environments where the may be many many loops, following 
up with multiple PROPFIND requests might be time consuming. Is it 
expected that Delta-V environments (particularly with some of the 
advanced features) might have (many) loops? (Elias implied that bindings 
are prettymuch necessary and I think I remember him saying that loops 
are necessary as well.)

>I think moddav does this by default).
Yes, mod_dav does reject Depth: infinity propfinds by default. I am 
working on a server that has a client that very much prefers to use 
Depth: infinity but perhaps I'll just respond with the first case (a 506 
response) and make him do Depth: 1 whenever there're loops.

>PROPFINDs, and thus never see a 506.
:^> Being a server developer, I would love to see Depth: infinity 
disappear...But I'm sure client developers would say the opposite.

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 12 Jul 2003 00:15:08 +0200

> Sent: Saturday, July 12, 2003 12:06 AM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: Re: Binding loops and PROPFIND clarification needed (was Re:
> COPY and bindings)
>
>
> Julian Reschke wrote:
>
> >Chris,
> >

That would break the multistatus format - every URI may only appear once.

What we should do is clarify that the processing only stops *for the
resource that is part of the bind loop*. So maybe just change the example to
have the "looping child" appear first in the collection.

> ...

Well, how does this client handle the case where (a) the server either
rejects depth:infinity, or the the response to depth:infinity gets *really*
big? I think it's better just not to use it...

> disappear...But I'm sure client developers would say the opposite.

Maybe, maybe not. So which clients *do* require PROPFIND/depth:infinity? The
Microsoft webfolder client doesn't.

Julian

---

From: Chris Knight <[email-masked]>
Date: Fri, 11 Jul 2003 15:24:09 -0700

>have the "looping child" appear first in the collection.
Sorry for being unclear, that's what I meant (having a different URI in 
the 200 after the 506.)

>Microsoft webfolder client doesn't.
You're right, no client requires it and could do the same by recursively 
PROPFINDing down the tree.

Are you going to make it to the Interop? Hope to see you there! (We 
might even have a first pass at a BIND-capable server. :*)

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 19 Jul 2003 12:02:06 -0400

How about the following alternative:

For PROPFIND, define a new 2xx status code that means "resource already 
reported".

A server that detects a loop in a PROPFIND result, would use this new 2xx 
status
code for the 2'nd (and subsequent) encounters with a given resource.  This 
allows
the client to reconstruct the binding structure based on just a single 
PROPFIND
call.

In particular, we could add the following paragraph to the Binding 
specification:

-----------------------------

7.1   208 Already Reported
The 208 (Already Reported) status code can be used inside a DAV:propstat
response element to indicate that information about the resource has
already been reported in a previous DAV:propstat element in that response.
The members of the 208 status resource are omitted from the response. 
For example, consider a PROPFIND request on /Coll (bound to collection C),
where the members of  /Coll are /Coll/Foo (bound to resource R) 
and /Coll/Bar (bound to collection C).

>> Request:

PROPFIND /Coll/ HTTP/1.1
Host: www.example.com
Depth: infinity
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
   <D:prop> <D:displayname/> </D:prop>
</D:propfind>

>> Response:

HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
   <D:response>
      <D:href>http://www.example.com/Coll/</D:href>
      <D:propstat>
         <D:prop>
            <D:displayname>Loop Demo</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.example.com/Coll/Foo</D:href>
      <D:propstat>
         <D:prop>
            <D:displayname>Bird Inventory</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat>
   </D:response>
   <D:response>
      <D:href>http://www.example.com/Coll/Bar</D:href>
      <D:propstat>
         <D:prop>
            <D:displayname>Loop Demo</D:displayname>
         </D:prop>
         <D:status>HTTP/1.1 208 Already Reported</D:status>
      </D:propstat>
   </D:response>
</D:multistatus>

A client can request the DAV:resourceid property in a PROPFIND request to 
guarantee that they can accurately reconstruct the binding structure of a 
collection with multiple bindings to a single resource.
-------------------------------------

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 20 Jul 2003 18:18:01 +0200

> Behalf Of Geoffrey M Clemm
> Sent: Saturday, July 19, 2003 6:02 PM
> To: [email-masked]
> Subject: Re: Binding loops and PROPFIND clarification needed (was Re: COPY
> and bindings)
>
>
>

OK, this issue has been coming up several times (see
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0081.html> for
the last time).

1) Can we get rid of 506 (loop detected)? No, we can't. 506 can occur as
result of operations other than PROPFIND, for instance COPY.

2) What error condition do we need to really indicate for the documented
example (PROPFIND depth infinity)? The problem is not with the resource
itself or a specific binding to it. In fact, a PROPFIND depth:1 wouldn't
indicate any special condition at all. The problem occurs *only* because
there's a bind loop, yet the request asked for a depth: infinity resource
listing. So there's not a specific resource that can be "blamed" -- instead,
it's the traversal of the collection's children that can't be done, and for
which optimally the response should indicate failure.

3) A similar problem exists with PROPFINDing deph != 0 on collections when
access privileges forbid listing the members.

4) Will clients that aren't aware of the ordering protocol ignore resources
with a status of 208? Not necessarily -- there may be clients that accept
all 2xx status codes as success (and I think those a stricly conforming to
RFC2518 and RFC2616!). This would mean that we can't use a 2xx code, or if
we do use it, we can simply use the approach outlined in
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html>.

I'm not convinced that a new 2xx status code is a good idea -- one approach
that's much more simpler would be just to forbid depth:infinity PROPFINDs on
collections that contain bind loops and to define an according precondition
value.

If we *do* want a new 2xx code, I'd rephrase the status condition. As a
matter of fact, the issue is *not* that the resource already was reported!
In fact, having multiple bindings to the same resource within the same
PROPFIND result is just fine. So, I'd propose:

"208 OK, but children not listed"

We could then extend the response body to indicate *why* children haven't
been traversed:

DAV:no-bind-loop (recursing below this collection would result in a loop)
DAV:need-privileges (you are allowed to see this collection, but not it's
content)

(see
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0080.html> for
a proposal how to marshall that).

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 25 Jul 2003 11:56:05 +0200

Hi,

I just started reviving the old expired redirect references draft. Based on

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-02.
html>

(expired June 2000) and the last call issues list

	<http://ftp.ics.uci.edu/pub/ietf/webdav/collection/redirect-issues.html>

I started a new revision which is currently at

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-lat
est.html>

(basically it includes all open issues in-text, and those issues that were
trivial to resolve have been closed). The current version was also submitted
to the IETF as draft -03.

Regards, Julian