Re: Stable URLs

From: Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Date: Thu, Apr 06 2000

  • Next message: jamsden@us.ibm.com: "RE: Questions on activities" 

    Date: Thu, 6 Apr 2000 14:59:20 -0400 (EDT)
Message-Id: <200004061859.OAA03868@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Stable URLs

   From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>

   <geoff>
   So the bottom line is that I agree with most of your
   description, except for requiring a special header be
   used to access stable URL's, ...
   </geoff>

   So I will assume that we shall drop the requirement to specify
	Workspace:
   to mean that the URL is stable.

That works for me (i.e. dropping Workspace:).  Anyone object?

   I agree that having the ability to have a link to a stable URL is
   desirable.  Therefore we must introduce the concept of a metadata area of
   the URL namespace so that the server knows a URL is stable.
   I'm not sure that using virtual hosting will be acceptable, it would
   clearly be strange to be told that a resource's stable URL is on a
   different host.

That will probably be the least strange part of a stable URL (:-).

   <geoff>
   ... and that the effect of a method on a stable URL to
   a resource will always be the same as the operation on
   a dynamic URL to a resource.
   </geoff>

   Then we have different views of what a stable URL is<g>
   I see them as unique identifiers of a resource.

I'm with you there.

   With this view, whether
   you got to the resource via its unique identifier, or via a dynamically
   resolved graph walk is immaterial.

For a method like PROPPATCH that only affect the state of the
the resource at the request URL, I agree.  But for methods like
MOVE that primarily affect some other resource (e.g. the collection
containing the resource in the case of MOVE), the URL matters
a lot, since it is what determines which collection is being
affected.

Cheers,
Geoff