From: Nigel Edwards <nje@ansa.co.uk>
Message-Id: <9409281542.AA12257@socrates.ansa.co.uk>
Subject: Re: URC usage scenarios
To: rdaniel@acl.lanl.gov
Date: Wed, 28 Sep 94 16:42:11 BST
In-Reply-To: <199409261738.LAA24891@idaknow.acl.lanl.gov>; from "Ronald E. Daniel" at Sep 26, 94 11:38 am
> URC Service Usage Scenarios
> ****************************
>
[stuff deleted]
>
> Publishing a new version of a resource
> +++++++++++++++++++++++++++++++++++++++
>
> When it is time to revise a resource the authors request a development
> version of the URC info. This version object will have restricted access
> so that ordinary users only see the older version while the authors and
> URC server administrator can see the new version. Once the new
> version of the resource is ready, the version object in the URC is made
> publicly accessible. Locations for the new version are established, and
> the locations for the old version should gradually go away.
>
Asumming the URC service is distributed, this change will take time to
propagate to all URC servers. Servers which have not received the
change will hand out stale URLs which may cause browsers to fail to
retrieve a resource.
One way of making such updates transparent to users would be to
include a reference to the publisher's URC server in the URC of the
resource.
When a URC server returns a list of URLs it also includes a reference
to the publisher's URC server. If a browser exhausts the list of URLs
without successfully retrieving the resource, it could ask the
publisher's URC server to do the URN to URL resolution.
This assumes the publisher's URC server is fairly dependable and does
not move. It also makes publishers responsible for controlling the
definitive URC.
The scenarios do not mention moving an existing version of a resource,
but presumably it could be handled by a subset of the functionality
required for publishing a new resource.
Nigel.
-- Nigel Edwards (nje@ansa.co.uk) web: <http://www.ansa.co.uk/>