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

Geoff,

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

In particular:

> As for the other topic, i.e. which URL appears in property values,
> I'm inclined to leave that up to the server for now, until we get
> more experience with these alternative URLs.

No way! 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 (just in case: silence means "no"!)?

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

>> is still mapped (so a client can get a 404...), 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 :-).

Regards, Julian



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

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
> Sent: Tuesday, November 12, 2002 7:13 PM
> To: Julian Reschke
> Subject: FW: 14.4_CLARIFY_VH_DELETE_2, was: BIND vs. non-movable
> resources in RFC3253
>
>
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, November 11, 2002 6:46 PM
> To: DeltaV (E-mail)
> Subject: RE: 14.4_CLARIFY_VH_DELETE_2, was: BIND vs. non-movable resources
> in RFC3253
>
>
> Currently, we have 3 votes (Stefan, Geoff, Jim) in favor of Stefan's
> resolution (i.e. disallow a delete on the stable URL of a resource if
> there are any other bindings to that resource), and 1 vote (Julian) in
> favor of Julian's resolution (have DELETE handle the stable URL the
> same as any other URL).  Since there appear to be no compatibility or
> implementability issues here (just "usability" ones), unless we get
> some more feedback, it looks like Stefan's proposal is the winner.
> As for the other topic, i.e. which URL appears in property values,
> I'm inclined to leave that up to the server for now, until we get
> more experience with these alternative URLs.
> Cheers,
> Geoff
>
>
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
> Sent: Sunday, October 27, 2002 2:00 PM
> To: DeltaV (E-mail)
> Subject: 14.4_CLARIFY_VH_DELETE_2, was: BIND vs. non-movable resources
> in RFC3253
>
>
>
> > From: ietf-dav-versioning-request@w3.org
> > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> > Sent: Friday, October 25, 2002 10:46 PM
> > To: DeltaV (E-mail); w3c-dist-auth@w3c.org
> > 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.
> > ...
> Actually, I think there are *two* issues, one of which is the one above
> (where I clearly disagree with the current resolution), and...
> For all live properties that refer to version resources or version history
> resources, which one of possibly multiple bindings should be reported? (I
> think we all agree that the stable binding should be reported).
> As we also have agreed (months ago) that the fact that the a deltaV live
> property points to a specific URL does *not* guarantee that the
> reported URL
> is still mapped (so a client can get a 404...), 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 :-).
> Julian
>
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>



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

Received on Tuesday, 12 November 2002 13:22:55 UTC