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

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 21 Oct 2002 18:27:56 -0400

From: Julian Reschke [mailto:[email-masked]]

   > From: Jim Whitehead
   >
   > Perhaps what's lying at the core of this issue is a difference in
   > assumption over who controls the namespace. The binding
   > specification assumes that in WebDAV-compliant portions of the
   > namespace, the client has a large degree of control over naming
   > and deletion. Resources are created at locations the client
   > specifies, can be moved to places the client wants, and rebound
   > to new names at will.
   >
   > The non-movable resources in DeltaV are typically created by the
   > server, at names the server chooses. Often these resources won't
   > be represented the same way as "file-like" resources, and will
   > instead be acting as the handle for a computational process that
   > queries the versioned repository to return property data. That
   > is, they act more like a servlet or a CGI.  In this case, it's
   > important for the server to have these resources at the place
   > where it created them, since that's where its software expects
   > queries against those

   nobody is saying that this is a non-compliant way to implement
   RFC3253. The point is -- just because some servers choose to
   implement RFC3253 this way, should this prevent other implementors
   to implement "full" namespace control (except of re-use of assigned
   version and VHR URIs)?

Yes, I believe that is precisely what RFC3253 should say.  To refer to
my earlier analogy, just because some clients want immutable content,
should this prevent implementors from implementing "full" content
control (i.e. allowing modification to checked in versions).  The
answer here is also, "yes".

   > resources to be directed. (It's additionally important that they
   > stay in the same place for the indentification usability issues
   > Geoff outlined).

   Again, no.

I disagree.

   It's important that a URI that has once been assigned to a version
   or VHR never is assigned to anything else.

We all agree on that.  But the fact that a stable URI should have this
characteristic, does not imply that it should not also have the other
characteristic we are discussion in this thread.

   However, for a client it is clearly not relevant whether it's
   getting a 404 because the resource was destroyed or because it was
   moved away (or for that matter, just the binding was deleted and
   the resource was moved to non-accessible storage). I'd like to hear
   why this is relevant, because it demonstratibly causes a conflict
   between the RFC3253 and the BIND spec.

The fact that a particular resource has additional restrictions
in no way "conflicts" with the BIND spec.  There will be a variety
of reasons why a DELETE request will fail (authorization, locking,
etc.).  This is just another reason that applies to this particular
binding.  The condition is easy to specify and easy to understand
(i.e. the DAV:parent-set must have only one member for DELETE to
succeed on this URI).

   > IMO, accommodating this difference requires explicitly
   > acknowledging the two different classes of resource binding
   > behavior (fixed vs. free) and then explicitly adding language
   > describing the behavior of fixed types to the binding
   > specification (something similar to Stephan's language would
   > probably work). Revisions to DeltaV can indicate, for all DeltaV
   > resource types, what kind of binding behavior they exhibit.

   Yes, the BIND spec should say something about these kind of
   resources. No, RFC3253 should not require implementors to actually
   restrict themselves to this kind of implementation.

I disagree.  It is not an implementation issue,
it is a client visible semantics issue.  Is another client allowed to
"hide" the resource at some other URL?  No, and neither should it
be able to change the "stable URL" for a version or version history.

   Trouble is, RFC3253 already talks about bindings to non-movable
   resources (for instance, a working collection contains bindings to
   version history resources). So we need to define what happens when
   you apply DELETE to a VHR-URI while another binding still appears
   somewhere else. Stefan's proposal works fine if your VHR resources
   are restricted in the way you explained. However, I'd strongly
   object to *requiring* this kind of implementation.

This is a client semantics issue, not an implementation issue.

   Again, the primary and uncontroversial goal is that a version or
   VHR URI is never assigned to a different resource. This takes care
   of all the use cases I heard. I've yet to hear why it would be a
   problem if it's moved away. Why would it matter to a client?

This is only one of the goals, and the additional goal
we are discussing in this thread is consistent with this other goal.

   > As for why we should add this language -- the idea is to make it
   > so that a client, when encountering resources of both types, can
   > behave intelligently, without having to perform trial and error
   > to accomplish useful tasks.

   Sure. Whatever a server implements, a client should be able to
   discover.

Querying a server to find out what it implements is the trial and
error that we want the client to not have to do in this case.

   To start with, BIND will need a precondition such as
   DAV:member-name-available - the member name to be created is
   available for use (because although not in use, it may be unusable
   because it already identified a VHR or a version)

It is more likely that the server will not support a BIND into
that version or version history namespace, since as Jim pointed out,
commonly this namespace is a computation based on the state of the
resource, and not an actual directory or folder.  But we could
certainly add such a precondition if that error code is important.

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 22 Oct 2002 01:16:10 +0200

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Clemm, Geoff
> Sent: Tuesday, October 22, 2002 12:28 AM
> To: WebDAV
> Subject: RE: BIND vs. non-movable resources in RFC3253
>
>

The answer is yes, but for a different reason. It is a stated goal of the
spec that versions have stable URIs and that they are immutable. Nobody
wants to change that.

> characteristic we are discussion in this thread.

And I didn't say that. I'm just saying but both goals are independant of
each other, or, more precisely, that the first one doesn't require the
second one.

>    between the RFC3253 and the BIND spec.

So again -- why is this relevant? I'd really like to understand this.

> (i.e. the DAV:parent-set must have only one member for DELETE to

It's not the resource that has additional restrictions, it's a particular
binding to that resource. And this IMHO clearly contradicts the BIND spec.

Quoting:

"A BIND request does not create a new resource, but simply makes available a
new URI for submitting requests to an existing resource.  The new URI is
indistinguishable from any other URI when submitting a request to a
resource."

BTW: this sentence doesn't take into account that access rights may depend
on the collection containing the binding, and on the fact that different
bindings to the same resource may be subject to protection by different
locks. So we may need to rephrase this anyway.

"Bindings are added and removed by a variety of existing HTTP methods.  A
method that creates a new resource, such as PUT, COPY, and MKCOL, adds a
binding.  A method that deletes a resource, such as DELETE, removes a
binding.  A method that moves a resource (e.g. MOVE) both adds a binding (in
the destination collection) and removes a binding (in the source
collection).  The BIND method introduced here provides a mechanism for
adding a second binding to an existing resource.  There is no difference
between an initial binding added by PUT, COPY, or MKCOL, and additional
bindings added with BIND."

So MOVE should be the same as BIND/DELETE. If you can BIND/DELETE, you
should be able to do MOVE as well.

> be able to change the "stable URL" for a version or version history.

Again, I didn't say that.

But: if clients are allowed to DELETE a version, I fail to see why moving it
to somewhere else is a problem. It won't be available anymore at it's
"stable" URI in both cases. Both the BIND spec and HTTP clearly say that a
client can not rely on the resource actually being destroyed:

http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.7:

"The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or other means) on the origin server. The client cannot be
guaranteed that the operation has been carried out, even if the status code
returned from the origin server indicates that the action has been completed
successfully. However, the server SHOULD NOT indicate success unless, at the
time the response is given, it intends to delete the resource or move it to
an inaccessible location."

and BIND...:

"Once a resource is unreachable by any URI mapping, the server MAY reclaim
system resources associated with that resource. If DELETE removes a binding
to a resource, but there remain URI mappings to that resource, the server
MUST NOT reclaim system resources associated with the resource."

And no, I didn't say that the stable URI may be changed. Only the URI
assigned at resource creation time has the "stability" property, and the
fact that the resource can be moved away doesn't conflict with this more
than the resource being deletable. The client-observable will be the same:

1) The resource at the stable URI is gone and
2) The stable URI will never be mapped to a different resource.

> This is a client semantics issue, not an implementation issue.

So please state what should happen when the VHR is deleted while a working
collection exists that contains a binding to the VHR.

> we are discussing in this thread is consistent with this other goal.

Yes. And again, for client-observable stability of the original URI the
second goal is not required. If you have a use case in mind where this
really makes a difference to a client, please state it.

> error that we want the client to not have to do in this case.

Yes. I didn't say that. In particular, I proposed a precondition name (which
is used in response bodies). It still allows the client to discover what
went wrong when it attempted the BIND.

> certainly add such a precondition if that error code is important.

I think we need it for completeness. A server may very well allow bindings
into this part of the namespace.

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

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 22 Oct 2002 10:04:29 +0200

Hi,

as the W3C is finishing these specs, I'd like to make the WG aware of the
questions we'll have to answer about how these changes impact WebDAV.

Changes that are IMHO relevant to WebDAV are:

1) The set of characters that can appear in an XML name has been extended
(it now includes more Unicode characters).

2) The set of characters that can be marshalled as text data has been
extended to include the control characters 1..31 (although only as character
reference; null is still forbidden)

3) XML 1.1 processors may reject documents if they contain non-normalized
Unicode (yers, this is optional).

4) Namespaces 1.1 allows IRIs rather than only URIs as namespace names.

One possible position would be that we just ignore it. Nothing would change
immediately. However we lose the ability to marshall "any" kind of XML
through WebDAV properties.

Allowing XML 1.1 request bodies for PROPPATCH *will* have a big impact. For
instance, properties are identified by QNames, and with XML 1.1 both the
valid character sets for the namespace name (can now be a IRI and thus
contain non.quoted non-ASCII characters) and the local name (just a bigger
subset of Unicode) will change. It may not be possible to marshall these
"extended" property names back to a client that only understands XML 1.0.

Similar problems appear with control characters in property values -- once
they appear in a property value, the property can only be marshalled back to
clients with XML-1.1 compliant parsers.

At this point, I don't have a recommendation how to treat this, but maybe
some more WG members should take a look at the current drafts.

Julian

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 22 Oct 2002 11:03:56 +0200

As I interpret RFC 3253, the "stable URL"'s purpose is
a) to give each version and VHR a permanent identifier
b) to allow clients to retrieve content and properties with
    this identifier.

The BIND resourceid could be used for (a). To achieve (b), the
resource id needs to be a URL.

Similar to the BIND spec, where the resource id is never altered
or lost, the "stable URL" is never altered or lost for a given
version/VHR.

Therefore:
The "stable URL" can only go away, when the resource ceases
to exist (from RFC 2518/3253 point of view).

Otherwise:
Allowing DELETE/MOVE to succeed on the "stable URL" would
allow the following case:

A client DELETEs/MOVEs a "stable URL" successfully, although
other bindings like 'xxx' to the version still exists.

A client PROPFINDs 'xxx'. Will it see a version resource?

Assuming 'no' is not to be considered.
A client makes a version tree REPORT on the VHR of 'xxx'. Under
which URL will the version be reported? The "stable URL" is
gone. However, 'xxx' cannot be used:

If you use 'xxx' for reporting that version in the version tree, clients
will assume that 'xxx' is a "stable URL" and, possibly, embed 'xxx'
into documents or mails as pointing to *the* version. But 'xxx'
is not specially protected and can be bound to any resource in
the future.

Summary:
URLs for versions/version histories, etc., when placed in deltav
live properties and reports *must* be "stable URL"s. They are
http identifiers which are bound to the lifetime of the resource.

//Stefan

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 22 Oct 2002 11:53:58 +0200

That's an interesting issue.

To answer that, we'll have to finally decide which URIs an RFC3253 server
should report (for instance for DAV:version-history) when there are multiple
bindings. Possible answers are:

a) any
b) all
c) the stable

If the answer is a) or b), this isn't an issue. If the answer is c), then
just continue to report it. It's perfectly legal to return a URI that isn't
mapped anymore (for instance, VHRs and versions may be stored on a separate
server, and there's no way to guarantee consistency with the server the VCR
is on).

Proposal: let's try to clarify how the bindings introduced by RFC3253
actually work (DELETE semantics, reporting of URIs in live properties, ...).
Then we'll have to figure out whether this is compatible with the current
BIND draft.

Julian

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stefan Eissing
> Sent: Tuesday, October 22, 2002 11:04 AM
> To: [email-masked]
> Subject: Re: BIND vs. non-movable resources in RFC3253
>
>
>

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 27 Oct 2002 14:02:27 +0100

Another precondition BIND should specify:

DAV:bound-resource-is-mapped: The URL specified by the DAV:href is mapped to
a resource.

(Explanation: we don't want to return a 404, because that would indicate
that the request URL for BIND wasn't mapped).

Julian