# URN2URC mapping service related issues

Joaquim Macedo (macedo@uminho.pt)
Sat, 3 Dec 94 18:48:51 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Walt Lazear: "Re: going too far"
- Previous message: Eliot Christian: "GILS Announcement 12/7 at DOI Auditorium"

    Date: Sat, 3 Dec 94 18:48:51 +0100

    From: Joaquim Macedo <macedo@uminho.pt>

    Message-Id: <9412031748.AA12723@sameiro.uminho.pt>

    To: uri@bunyip.com

    Subject: URN2URC mapping service related issues

Hi,

Since some time ago, we attend uri and iiir mailing lists and read
related internet-drafts.

Perhaps it is arrived the time for some modest contribution . We
intend to do some work in URN2URC mapping service related issues.
For the issues presented in this message, we will attend comments,
hints and even pointers for related work. The lack of any feedback ,
will mean for us to be "reinventing the wheel" or even "off-side"...

1. URC Database updating

------------------------

In our understanding, the proposed protocols (already used in
prototype basis) for urn2urc service (e.g whois ++,solo, dns)
don't actually support distributed adds and updates in URC database.
This approach was intentionally made (we suppose) with the purpose of
to get simpler protocols, without the complexity of OSI X.500
Directory, for instance.

But it brings up the need for a different protocol for URC database
updating. This protocol will be used to register new resources (add
new URC) and replicated ones (add URL) and for update the associated
meta-information (modify URC fields, remove URL,...).

2. A format for URI broadcasting
--------------------------------

People actually use Usenet News and Mailing Lists to inform other
users about interesting URLs. A pre-defined format for URC broadcast

allows the automatic incorporation of new resources (pointers) in the
information servers. In some situations, this method can be used for
indirect registration of replicated resources (which URN is unknown,
for instance).

The broadcasted information about replicated resources can be
collected by some kind of urn2urc secondary servers using
localization criteria. So, different servers may keep and provide
different locators for the same resource.

3. MX like RRs and urn2urc
------------------------------

We think that there are functional superposition between DNS MX

(and more recently proposed IXs) records and urn2urc mapping service.
Both are name to locator functions...

What one need to do for use this mapping service in MX like
functions? We think that the requirements are:

- Define standard names for the existing network services in
each domain

- Define URCs for each service within a domain (with several URLs)
- Have defined URLs for each used service protocol

Suppose that the standard name for electronic mail is email and there
are URLs for SMTP and X.400. An example URC for email at uminho.pt
is:

URN: uminho.pt:email
URL: smtp://nunes.uminho.pt
URL: smtp://viriato.uminho.pt

URL: x.400://viriato.uminho.pt
URL: x.400://zeca.uminho.pt

Clients (mail servers, for instance) may use urn2urc mapping service
to get URLs of uminho.pt mail entry points and choose one of them
based on server availability and used mail protocol...

Thank you for the answer.

Regards,

Joaquim Macedo

- Next message: Walt Lazear: "Re: going too far"
- Previous message: Eliot Christian: "GILS Announcement 12/7 at DOI Auditorium"