From: mitra@path.net (Mitra)
Date: Fri, 29 Oct 1993 13:38:24 PDT
In-Reply-To: Peter Deutsch <peterd@bunyip.com>
To: peterd@bunyip.com, marca@ncsa.uiuc.edu
Subject: Re: Single protocol for UR*?
Message-Id: <9310291338.aa10437@pandora.sf.ca.us>
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.
} > Xyz server sends a URN of the form urn:anamespace/pubid:123456
} > Client looks up "namespace.urn" in regular (unmodified) DNS
} > DNS returns ip address of the whois++ server for namespace.urn
} > lets assume this is urns.path.net
}
} 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.
The "anamespace" server would just add regular DNS records that point at
servers for the pubid's its given out.
} 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.
}
} Perhaps more serious, this approach means there is no way
} to put a WHOIS++ URN server on anything except the default
} port. I think the ability to do this might be of use, so I
} suggest we consider the addition of a new DNS data type,
} which would allow us a bit more flexibility.
}
This becomes a tradeoff, its a huge advantage not to implement DNS in
clients, and just call gethostbyname. We should NOT use the whois++
port, anything on that port is committed to the whole whois++ protocol,
as opposed to the URN->URL subset.
} > Client sends "Template=URM,URN=urn:anamespace/pubid:123456" to
} > urns.path.net on port 987 (registered as URN port with
} > iana)
} Hmmm, interesting idea - we register a new port for URN
} work, but have it use the same protocol as on port 43.
I think we have it use a SUBSET of the protocol on port 43. Any URN
specific extensions would end up on this port.
} 1:URN: anamespace/pubid:123456
} 2:Author: mitra
} Here, clever clients could pick up the token (the first
} number) and convert the name field into the local
} language.
} 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 - 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.
} > Yes - lets have some more input ..... is this the kind of idea people
} > like or are Peter and I off base?
} Good question. I've received several supportive notes from
} people who identified with my "let's just do it" approach,
} but none from developers of other systems or protocols yet.
} Does this approach sound like it will fly, or should we
} kick it around some more?
I've had several supportive messages as well. I seem to remember Marca
saying something about wanting a single protocol as well.
- Mitra