Re: Revision names
Chris Kaler (ckaler@Exchange.Microsoft.com)
Tue, 12 Oct 1999 11:16:27 -0700
Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD986@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'Tim_Ellison@oti.com'" <Tim_Ellison@oti.com>, ietf-dav-versioning@w3.org
Date: Tue, 12 Oct 1999 11:16:27 -0700
Subject: RE: Revision names
I'm not aruging that URL construction is bad, just that
it shouldn't be madatory. Forcing revision ids to be
valid URL segments means:
1) Servers must constantly map and unmap
2) Not being URIs, there are conflicts with cross server
3) You limit the stores ability to create its own URLs
I don't understand your point about REPORT. You can report
multiple revisions of the same resource regardless of how
you represent the URL.
If you want to have a separate "revision name" that can be
used for this, that would be better.
We still have the notion of a "revision-specific URL". This
should be something that the server is free to construct
however they want. That is, it shouldn't be a requirement
that clients can parse this and navigate to previous
revisions. We are getting very close to URL munging....
Chris
-----Original Message-----
From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
Sent: Tuesday, October 12, 1999 10:56 AM
To: ietf-dav-versioning@w3.org
Subject: RE: Revision names
I think that there are good reasons to be able to construct a URL to a
particular revision. These include creating links to a particular revision,
and being able to identify multiple revisions of the same resource in
methods (e.g. REPORT).
Virtually all store id's can be accommodated in a valid URI segment (using
hex encoding if necessary.)
Tim
----------
>From: jamsden
>To: ietf-dav-versioning
>Subject: RE: Revision names
>Date: Tuesday, October 12, 1999 1:22PM
>
>If the revision name (id or label) is provided in a separate header, then
>would
>we still need to construct these URLs? I think we should avoid this if we
can.
>
>
>"Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com> on 10/12/99
01:00:35
>PM
>
>To: Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org
>cc:
>
>Subject: RE: Revision names
>
>
>
>I am strongly opposed to the specification describing what a
>revision id must look like. I know Jim only said that they
>should be valid path segments, but, in retrospect, I think
>that is too severe. If my sever wants to use a URI to refer
>to a revision, then I should be allowed to. However, this
>may not be a "valid" URL segment.
>
>As well, the specification shouldn't require the ability for
>a client to be able to "glue" these with other information and
>expect to have a URL that works. Now if a server supports
>property resource collections, then they better conform to this.
>But a server that doesn't, shouldn't have to.
>
>This approach will limit servers from providing ids that are
>optimized to their store's.
>
>Chris
>
>-----Original Message-----
>From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
>Sent: Tuesday, October 12, 1999 7:53 AM
>To: ietf-dav-versioning@w3.org
>Subject: Re: Revision names
>
>
>
>
>We can think of the server as another collaborator in distributed authoring
>systems, one that provides a set of services. In particular, there can be
>little
>distinction between a revision name (something that distinguishes one
>revision
>from another in this context) specified by some other client and one
>specified
>by the server. In both cases there is the possibility for collisions, and
in
>both cases, there is the desire to use the revision name to select a
>revision.
>As Tim points out below, there is also a desire for the syntax of label
>names to
>be consistent with URLs, and to be able to marshall revision names in
>request
>and response entity bodies (in XML) as well as in headers. The only
>difference I
>can see is that the server's revision name, the revision id, can't be moved
>or
>reused - its an immutable or fixed label that ensures revisions can always
>be
>distinguished. Any attempt to move or reuse the label id results in an
>error.
>This makes potential client/server collisions even safer than client/client
>collisions as there is no possibility of some other client getting an
>unexpected
>revision because some other client or the server moved the label id.
>
>The only reason to separate id and label name spaces seemed to be to avoid
>client/server label name collisions. But it is clear that client/client
name
>collisions are much more likely to happen, and have greater consequences
(as
>measured by the principle of least astonishment). I continue to find it
hard
>to
>justify the complexity separate label namespaces adds to the protocol vs.
>the
>problems it solves. Does anyone else see other issues that separate
>namespaces
>would avoid?
>
>
>
>
>
>Tim_Ellison@oti.com (Tim Ellison OTT) on 10/12/99 10:26:17 AM
>
>To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
>cc:
>
>Subject: Revision names
>
>
>
>
>As mentioned by both Jeff (by phone) and Geoff (in an earlier positing),
>revision id's must be legal URI path segments if we envisage the ability to
>refer to a revision by a URL (i.e. DAV:history's revisions collection "/"
>DAV:revision-id).
>
>Maybe we will also want to refer to a particular labelled resource by a URL
>in a similar fashion.
>
>If we choose to differentiate labels and revision id's by extra syntax
>surrounding the value this would lead to bizzare looking URLs.
>
>
>Having listened to the discussions, I think that the argument for avoiding
>collisions between labels & revision ids has been largely debunked; and the
>protocol would undoubtably be simpler if there was not requirement to
>separate namespaces. However, labels and revision ids have different
>characteristics from the client's perspective and it would be immensely
>reassuring to know which you are dealing with at all times. I just don't
>see yet how this would fit into the protocol.
>
>Tim
>