RE: 14.4_CLARIFY_VH_DELETE_2, was: BIND vs. non-movable resources in RFC3253

   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   I have to say that I completely disagree, and I would have really
   hoped that the arguments in my previous mail would actually be
   considered (I've seen no reply -- does this mean nobody had
   anything to say about it???).

I didn't see any new arguments in your previous mail, just a
restatement of your orginal argument.  I thought that Jim and Stefan
both gave good reasons for why they prefer requiring the stable URL to
be mapped to a resource as long as there are any bindings to the
resource.  I will summarize those reasons below.

   DeltaV has the concept of stable bindings, but if there's no
   interoperable way to discover them, the whole concept is
   *completely* useless. So if we wan't agree that live properties
   such as "DAV:checked-in" *always* identify the stable binding, it
   makes no sense whatsoever to keep this concept. So we *really* need
   to write that down. Does anybody have a problem with this?

That's fine with me.  I'm guessing most folks are not especially
concerned because they are not planning on implementing multiple
bindings to either version histories or versions (but for the same
reason, would have no problem if this is made explicit).

   And if we get *that* issue resolved, I'd really like to see a
   *discussion* of the argument I made:

   >> I hereby ask again to consider the following alternate
   >> resolution to 14.4_CLARIFY_VH_DELETE_2: Bindings to version
   >> resources or version history resources may be deleted in any
   >> order. Removing the stable binding does not affect which URL
   >> will be reported in the live properties -- the resource just
   >> itself isn't accessible through the stable URL anymore. This
   >> relaxes the "stable URL" requirement such that clients still can
   >> rely on the stable URL when being mapped to be mapped to the
   >> initially created resource (it won't be reused). Upon
   >> encountering a 404, they would however not be able to conclude
   >> that the resource itself is gone (I'd still like to hear why
   >> that would be a problem).  This model is completely
   >> deterministic and avoids special-casing DELETE and BIND for
   >> these resources, therefore it would be a protocol simplification
   >> (a hopefully shared goal of the WG :-).

The only argument I see here for this alternative resolution is that
avoids special-casing DELETE (there is no special casing needed for
BIND).  The reason given in favor of special-casing DELETE is that it
guarantees that a client can store away a stable URL with confidence
that it will be usable for operating on the resource as long as that
resource is accessible by any other URL.  Jim, Stefan, and I believe
that this behavior is more important than avoiding the special-casing
for DELETE. You believe the opposite.  It seems appropriate to mark
this issue as resolved until you can provide an argument that at least
one other person finds compelling.

Cheers,
Geoff