RE: Issues, Issues, ???

> Currently, I still have some stuff to write up for the revised
> protocol, but the only thing left on my "unresolved issue" list is:
>
> (1) Should version history URL's be in core (i.e. be required)?
No.
As I elaborated in my last mail, CORE should only require a URL for each
"version resource" plus a URL for the original resource, now a
"version-controlled resource".  I can't see any features in CORE that aren't
easily done by addressing one of these.

> (2) Should version URL's be stable (i.e. cannot later refer to
> something else)?
No to what I think you mean.

I think you mean reusable, not stable. ( You can require version URLs to be
stable: as long as a version exists, it will have the same URL.  It's when a
version goes away that one starts to worry whether its URL may be reused.)

My plea is to let us manage our own namespaces.  Although it is not
technically difficult to add a GUID to a URL, we consider that to be really
ugly in a URL that we expect will be visible.

What if this requirement is dropped from the spec? Reuse may happen, but it
will not be frequent.  The client can use ETags.  Interoperability is not
threatened.

A client must deal with versions the way it deals with any resource:
 - if it has never before retrieved the body, it has NO WAY of knowing
whether the body has changed, and has NO REFERENCE POINT against which to
compare that anyway!  It's meaningless to say that the content "shouldn't
have changed" since a client which has never before seen the content can't
tell the difference.
 - When it does retrieve the body, it should retrieve the ETag.
 - When it wants to see if the body has changed, it should compare the ETag.

Lisa

> Any other unresolved issues that I've missed?

The related issue about how to get a list of versions.

Received on Wednesday, 20 December 2000 23:28:31 UTC