Subject: RE: BIND vs. non-movable resources in RFC3253

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 25 Oct 2002 17:19:17 -0400

Note: This precondition actually violates the requirement
earlier in the text that a server support cyclic bindings.
But probably a server should be allowed to reject cyclic
bindings, so I'm happy to add this pre-condition (and remove
the current requirement), if nobody objects.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Friday, October 25, 2002 4:55 PM
To: Clemm, Geoff; DeltaV (E-mail); [email-masked]
Subject: RE: BIND vs. non-movable resources in RFC3253

Geoff,

thanks. I think I've got at least one other precondition:

DAV:bind-loops-allowed

(explanation: we don't want the server to produce a 5xx error code for this
case)

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Clemm, Geoff
Sent: Friday, October 25, 2002 10:46 PM
To: DeltaV (E-mail); [email-masked]
Subject: RE: BIND vs. non-movable resources in RFC3253

It looks like we have finally narrowed down this thread to 
one issue for 3253, which I've added as 14.4_CLARIFY_VH_DELETE_2 
(i.e. can you delete the stable binding to a version history 
or version, if there are other bindings).  Any discussion of 
14.4_CLARIFY_VH_DELETE_2 should be mailed to the deltav mailing 
list, not to the general webdav mailing list. 
For the binding spec, Julian asks for two new preconditions 
for BIND, which I will go ahead and add, unless someone objects 
(they both seem reasonable to me).  Any discussion of these two 
new preconditions for BIND should be mailed to the general 
webdav mailing list. 
Cheers, 
Geoff 
  
-----Original Message----- 
From: Julian Reschke [mailto:[email-masked]] 
... 
The issue here is that if we allow a DELETE to fail because other bindings 
exist, a client may never be able to delete a binding (because due to race 
conditions, there will always be additional bindings left). I'm not saying 
that this can be avoided, however it *really* sounds ugly. As I said, I 
haven't seen a convincing argument why we need this restriction in RFC3253 
(and yes, this discussion should be moved to the other mailing list). 
> Can we agree that servers can reject DELETE/MOVE requests and move the 
> versioning specific discussion to the versioning mailing list? 
Yes. Still, we may have to define additional precondition values for 
- resource does not support additional bindings 
- new member name can't be used (in deltav: because it was already used for 
a stable URI) 
Julian 
-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 26 Oct 2002 11:07:17 +0200

> Sent: Friday, October 25, 2002 11:19 PM
> To: [email-masked]

I wasn't aware off that being a requirement. I see why a server that *does*
support cyclic bindings need to signal them upon depth infinity operations
(-> 506), but why would you want to require support for their creation?

Actually, I'm tempted to require servers to detect cyclic bindings upon
creation and to reject those requests. What's the use case for cyclic
bindings?

> the current requirement), if nobody objects.

BTW: this precondition applies to all namespace-manipulating operations (a
MOVE of a collection may fail for the same reason).

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 26 Oct 2002 18:59:03 +0200

Hi.

We recently submitted our internet draft ([1]) to the RFC editor for
publication as Informational (non-working-group) RFC. From the abstract:

"Recent specifications extending the "Web Distributed Authoring Protocol"
(WebDAV, [RFC2518]) like "Versioning Extensions to WebDAV" [RFC3253] and
"WebDAV Access Control Protocol" [ACL] restrict the set of properties
returned automatically upon a PROPFIND/allprop request in order to avoid the
expensive computation of properties that the client in many cases isn't
interested in.

However, this change from the behaviour defined in WebDAV can lead to
situations where clients need to perform two requests to retrieve all
properties they are interested in (one using PROPFIND/allprop, then
PROPFIND/prop enumerating the new properties that weren't reported upon the
first request). This specification defines a backward-compatible extension
to add specific properties to the set of properties returned upon
PROPFIND/allprop, thus saving at least one PROPFIND request."

The proposed solution is to use a backward-compatible extension to the
PROPFIND marshalling (old servers if compliant to RFC2518 MUST ignore this
element, because it's not define in RFC2518):

<?xml version="1.0" encoding="utf-8" ?>
<propfind xmlns="DAV:" xmlns:in="http://sapportals.com/xmlns/cm/webdav">
  <allprop/>
  <in:include>
    <checked-in/>
    <checked-out/>
  </in:include>
</propfind>

This instructs the server to return all dead properties, the RFC2518 live
properties, and additionally the RFC3253 properties DAV:checked-in and
DAV:checked-out.

This protocol extension has been implemented in both our client and server
for over a year now and solves the issue stated in the abstract for us (when
communicating with our own servers, that is). As the Internet Draft has been
stable for several months, we feel it is ready for publication as RFC.

At this point, we are looking for opinions from the working group about
*how* this should proceed in the standards process. I'm aware of the
following alternatives:

1) Decide that the problem as stated does not require a generic solution
backed by a working group document. In this case, the Internet Draft (after
possibly minor editorial changes) should proceed on it's path to publication
as Informational RFC (the IETF standards process is defined in RFC2026,
[2]).

2) Decide that this problem indeed should be resolved by a change/extension
defined by a working group document.

2a) ...for inclusion into RFC2518bis, or

2b) ...to be published as a separate document (probably then as a "proposed
standard", as defined in RFC2026, section 4.1.1).

Feedback appreciated.

Julian

[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-02.ht
ml>
[2] <http://www.ietf.org/rfc/rfc2026.txt>

---

From: Elias <[email-masked]>
Date: Mon, 28 Oct 2002 08:53:33 -0800

Good morning all,

Perhaps you're already aware of this, but... The detection of cyclic 
bindings is reducable to the problem of finding a Hamiltonian Path in a 
graph, which is NP-Complete. I strongly object to placing any 
requirements upon a server which are NP-Complete problems.

Since detection of cycles is NP-Complete, it shouldn't be a MUST level 
requirement that servers detect them. Perhaps they SHOULD detect them, 
but even that seems too strong for my tastes... It's clear that cycles 
may be caused inadvertently by other namespace operations such as MOVE, 
so disallowing them also has the effect of making a server detect them.

The problem is analogous to that of having cyclic links in the *nix 
filesystem, is it not? Is there any reason we cannot follow the same 
approach taken there? The simplest way to avoid the whole mess is to 
specify that namespace operations do not follow BINDed (bound?) 
resources since they could end up in a cycle...

I'd be interested in seeing a use case for cyclic BINDings that cannot 
be satisfied with the judicious use of properties...

Elias

Julian Reschke wrote:

> [...] I see why a server that *does*