Message-Id: <9310292227.AA06460@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Fri, 29 Oct 1993 18:27:56 -0400
In-Reply-To: Mitra's message as of Oct 29, 13:38
To: mitra@path.net (Mitra), marca@ncsa.uiuc.edu
Subject: Re: Single protocol for UR*?
[ Mitra wrote: ]
> On Oct 29, 11:41am, Peter Deutsch wrote:
> } <Various stuff about another DNS record>
>
> The advantage of NOT adding another DNS record, is that people dont have
> to implement DNS - or obtain libraries that do - in order to get to the
> whois++ server. They can do it all with a single "gethostbyname" call.
I'll acknowledge that this is a win. If it goes this way
and everyone's happy, then I'm happy, too.
. . .
> } The following looks pretty good to me, although I'd add
> } one more step to separate the naming authority server from
> } the specific pubid server (I'm sure ISOC doesn't want to
> } run a service for every member, although they might be
> } willing to run a server pointing to each member's server).
>
> Sounds good, in which case modify it to look up "pubid.anamespace.urn"
> in the DNS, standard DNS mechanisms already handle decentralising that.
I'd have to ask a DNS guru how this approach would scale
if the naming authority has to list thousands of entries?
After all, I suspect that the fanout might exceed anything
we currently see with existing practice. Still, if nobody
sees a problem, this approach means that it can be brought
up real fast once the powers-that-be agree to the new top
level domain and we find someone to operate the top level
servers.
I _am_ still wondering if we shouldn't have the top level
be ".uri", with the "urn" one level down, to avoid a
plethora of new top level domains. Maybe we even want a
".service" domain, with "urn.server"? We do need input from
the DNS community here.
> The "anamespace" server would just add regular DNS records that point at
> servers for the pubid's its given out.
Okay, you convinced me. I vote we try it your way, default
to WHOIS++ as the resolution protocol and if we really feel
the need for more info from DNS, we go for a new record
type later.
> } Your approach has the advantage that there is essentially
> } no change to DNS, but does require universal acceptance of
> } the WHOIS++ protocol for this task (stranger things have
> } happened) so it might be okay.
>
> Not even that Peter, it requires acceptance of a specific subset of
> Whois++ to achieve a few very limited tasks. If the server provides
> other features of whois++ that is an advantage, but we dont have to
> agree on that in order for this scheme to work.
I addressed this concern in an earlier posting, but I'll
repeat - I'm not sure how we'd use a "subset" of WHOIS++,
since the protocol is pretty minimalist now. Suggestions
for specific commands that could be omitted??
There's really not that much to chop...
. . .
> } Some may see this as an unneeded distraction, but I know
> } there's a lot of people who'd appreciate it and I'm sorry
> } I didn't have this idea in time for the original IAFA
> } work.
>
> Yes - its a distraction - I also dont think its an issue, there are
> already email systems that translate the tag part into their own words
> for Author etc. We dont gain anything by tokenising this -
I'd have to disagree here. If I'd like to find all author
names, it would be nice to look for "token 10", not
"author, auteur, whatever_it_is_in_German" and so on. More
importantly, it recognizes that there are lots of people
coming onto the net in the next couple of years for whom
English is not in the default language set.
Having said that, I agree that it doesn't affect the URN
dereferencing architecture.
> . . . but we do
> (as a seperate process) need a way to register tags, and define rules
> for what can come with them. I dont think we need to hold the URN->URL
> process up for this, since there are already a lot of data elements that
> are standardised on (IAFA, Mime etc) which we can start using already.
Actually, I'm not proposing we hold things up on this, I
just tossed it out as a stream-of-consciousness idea.
Still, I do hope that we don't ignore the issue as we
progress, although I recognize that it's really a data
elements issue and doesn't have to be solved for the rest
of this stuff to work (nor do I have any idea where they
data element SWAT team is on this topic right now, since
they've been pretty silent of late. I suspect they're all
up to something, but Alan wont tell me what! ;-)
- peterd
--