# Re: URC usage scenarios

rdaniel@acl.lanl.gov
Wed, 28 Sep 94 12:14:38 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ronald E. Daniel: "Re: URC usage scenarios"
- Previous message: Michael Mealling: "Re: URC usage scenarios"
- In reply to: Nigel Edwards: "Re: URC usage scenarios"

    Message-Id: <199409281814.MAA29467@idaknow.acl.lanl.gov>

    To: Nigel Edwards <nje@ansa.co.uk>

    Subject: Re: URC usage scenarios

    In-Reply-To: Your message of "Wed, 28 Sep 94 16:42:11 BST."

                 <9409281542.AA12257@socrates.ansa.co.uk>

    Date: Wed, 28 Sep 94 12:14:38 -0600

    From: rdaniel@acl.lanl.gov

> > Publishing a new version of a resource

> 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.

Nigel,

Thanks for bringing this up. Although it is not in the usage scenarios,
this is something I have considered. To answer it, let me define some
terminology, since what you call the "definitive URC" seems to mix
couple of concepts.

Authoritative vs. Cached
For speed, the URC service will be distributed and will make extensive
use of caching. Cached information will typically be a subset of the
information available. For example, if I try to resolve a URN for
something published by eng.cam.ac.uk, my local URC server will only ask
for the locations (and perhaps signature info if I am paranoid). It
will cache that stuff in case someone else who shares the URC server
with me wants to look at the same resource.

Since this info is a subset of the available info, and since it is cached
and can go out of date, it is marked as non-authoritative.

Default URC
More than one place may want to put up a URC for some resource. I do not
think that the URC service can (or should) guarantee that you see every
URC for a resource, but you should see whatever the publisher puts up.
The publisher's URC for a resource is the "default" URC. If someone else
has URC info on a resource, those are "additional" URCs.

Note that these are orthogonal. I can have a non-authoritative default
URC on the same URC server that holds the authoritative version of an
additional URC.

Also, let me state an assumption I have about the architecture of the URC
service. I think that publishers will frequently have multiple servers
providing the authoritative default URC. Whenever a URC is changed,
the server will notify its mirrors to update their records. This will
happen very quickly. Whenever a server goes down, as it comes back up it will
talk to its mirrors to get updated before it starts answering general
queries.

OK, with that out of the way, here is a usage scenario.

1) Author creates version 2 of an existing resource.
2) Author puts it up an a server, so it now has a URL
3) Author sends a message to the URC server of the publisher to
update the authoritative version of the default info. The message
is something like:
lock the URC for URN foo
add the new version info
remove the old location info
unlock the URC -- notifying mirrors is part of this stage
4) Future queries will be answered against the new URC.
5) The author deletes the old version of the resource from its
http, gopher, or whatever server.

A) An user wants to find the resource.
B) The old info is in the cache of their local URC server.
C) They send a query to their local URC server, it responds with
cached info.
D) The browser tries the old URLs and fails. The user had configured
the browser to "retry on non-authoritative failures". Since the
URC info was cached, it is non-authoriative.
E) The browser tells the local URC server to try to get new info.
F) The local URC server gets new info from one of the publisher's
URC servers. It passes it to the browser with the "authoritative"
bit set, then stores it in the cache with the bit cleared.
G) The browser tries the URLs again.
H) If it still can't grab the resource, it tells the user "Sorry".

> 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.

Yes, moving a resource is a combination of two operations - establishing
a new location (which adds a URL to the URC) and deleting the old
location (which removes the old URL from the URC).

Ron

- Next message: Ronald E. Daniel: "Re: URC usage scenarios"
- Previous message: Michael Mealling: "Re: URC usage scenarios"
- In reply to: Nigel Edwards: "Re: URC usage scenarios"