Re: Revision names
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Tue, 12 Oct 1999 13:25:54 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Oct12.132513.1250.1349409@otismtp.ott.oti.com>
Date: Tue, 12 Oct 1999 13:25:54 -0400
Subject: RE: Revision names
No one is talking about the ids as the server sees/uses them but rather
how their server exposes the ids to the client. Saying that it has to be
a URI means sticking 'dav:' or some such on the front of the string
before sending it out. Saying that it has to be a valid URL segment
means ensuring that the chars are URL encoded before sending. Have I
missed a case here?
I believe it would be a tremendously good idea to allow construction of
revision-specific URLs from constituent parts. Again, no one is saying
that your server has to actually store things in any particular way.
Think of the fully-qualified URL as you would think of a servlet or .asp
URL. There server does not blindly go off and return whatever is at the
end of that path. Heck, some servers don't require any resources at all!
The server interprets the path. All we should be concerned about here
is that the URL contain sufficient data to allow the server to figure out
what actual set of bytes are needed. How it does that and how it
accesses the bytes are entirely up to it.
Can you clarify what it you mean by "property resource collections" and
what it would mean for a server to not support them?
Jeff
> -----Original Message-----
> From: Chris Kaler Exchange [mailto:ckaler@Exchange.Microsoft.com]
> Sent: Tuesday, October 12, 1999 1:04 PM
> To: 'jamsden@us.ibm.com'; ietf-dav-versioning
> 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
>
>
>
>