Re: Revision names
Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Sun, 24 Oct 1999 08:59:50 -0400
Date: Sun, 24 Oct 1999 08:59:50 -0400
Message-Id: <9910241259.AA24241@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <FD7A762E588AD211A7BC00805FFEA54B041DD97E@HYDRANT>
Subject: Re: Revision names
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
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.
URI's can be trivially encoded into a legal URL segment,
so this requirement should impose no constraints on how a
server allocates its revision id's (it just says how to
encode them when putting them on the wire).
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.
The advantage of this approach is that it makes the information
available to users that are using versioning-unaware clients.
Given the likelihood that these clients will be in use, I believe
it is essential that we try hard to ensure this scenario is supported.
I'd need to see a strong argument for why it is hard for a
server to provide this service, before giving it up. We could
make it a "MAY", but this significantly complicates the protocol.
This approach will limit servers from providing ids that are
optimized to their store's.
It just says how to encode them, not what they look like before
encoding.
Cheers,
Geoff