# Re: URC usage scenarios

Michael Mealling (Michael.Mealling@oit.gatech.edu)
Wed, 28 Sep 1994 16:45:45 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: rdaniel@acl.lanl.gov: "Re: URC usage scenarios"
- Previous message: Ronald E. Daniel: "FYI"
- In reply to: Nigel Edwards: "Re: URC usage scenarios"
- Next in thread: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Reply: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"

    From: Michael.Mealling@oit.gatech.edu (Michael Mealling)

    Message-Id: <199409282045.QAA14460@oit.gatech.edu>

    Subject: Re: URC usage scenarios

    To: nje@ansa.co.uk (Nigel Edwards)

    Date: Wed, 28 Sep 1994 16:45:45 -0400 (EDT)

    In-Reply-To: <9409281542.AA12257@socrates.ansa.co.uk> from "Nigel Edwards" at Sep 28, 94 04:42:11 pm

Nigel Edwards said this:
> > 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.

The method I like is that what we do is each resolution server has
a unique id (what it is doesn't matter). We then have a directory of
services server that holds all the description URCs for each resolution
server. This description URC holds the Publiber Id that is contained
within the first two fields of a URN. We can then take these fields, hand
it off to the direcotry of servers to find out which resolution server
is 'authoritative' for that URN at which point we can find the 'correct
as correct can be' response for the given URN.

-MM

    --
    ------------------------------------------------------------------------------
    <HR><A HREF="http://www.gatech.edu/michael.html">
    <ADDRESS>Michael Mealling</ADDRESS>
    <ADDRESS>michael.mealling@oit.gatech.edu</ADDRESS></A>

- Next message: rdaniel@acl.lanl.gov: "Re: URC usage scenarios"
- Previous message: Ronald E. Daniel: "FYI"
- In reply to: Nigel Edwards: "Re: URC usage scenarios"
- Next in thread: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"
- Reply: Daniel W. Connolly: "No "TOP" of the docuverse [Was: URC usage scenarios ]"