Message-Id: <9402242358.AA13016@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Thu, 24 Feb 1994 18:58:13 -0500
In-Reply-To: Mitra's message as of Feb 24, 21:32
To: mitra@pandora.sf.ca.us (Mitra), <uri@bunyip.com>
Subject: Re: Finding URN->URL servers
[ Mitra wrote: ]
> Sopmeone mentioned the problem of "well defined ports", personally I'd like
> to see whois++ and URN->URC resolution on different ports, the URN->URC spec
> is going to be much simpler, than I expect whois++ will become as it grows.
> If they turn out to be the same then we havent lost anything putting the
> same services on two ports is easy, but if we turn out to want the defaults
> on the URN->URC server to be different, i.e. default to returning a URC in
> an appropriate format for it, then we will have lost if we put them
> on the same port.
A little alarm bell goes off here in that it seems you're
tending towards making the decision on whether to issue a
new port number based upon information content, not the
protocol to be spoken and I think that can lead to
problems (there's measurably more services than
protocols).
Say we wanted to have several WHOIS++ services for serving
several different types of IAFA file (we might be looking
at a Services Description directory, a Software
Descriptions directory, a White Pages service, etc). Would
each of these use a different port? Now, also make each
available through X.500, just to be fair. What have we
gained in issuing 10 ports, rather than two? There is
already a mechanism in WHOIS++ for querying the defaults
for a particular server, if you want to make them
different and need to find out.
I can see the advantage of having ports tied to services
(it's certainly simpler for the client) but I think in the
long run, it's better to define a single protocol and have
a port-mapping mechanism for asking if a particular
service is supported, with an appropriate redirect to the
actual port number and even protocol to use where needed.
As far as I can tell this is all doable now.
Of course, I've only thought about this for a couple of
minutes and I might be wrong... :-) Also, if you're right
and the protocol that evolves for serving URN->URL
conversion ends up being different than WHOIS++ of course it
should have its own port. I think what we have to decide
is whether there's any particular need for Yet Another
Protocol for this right now. The answer may well be yes,
but I'd like to hear what sort of characteristics this new
protocol will have.
- peterd
--
---------------------------------------------------------------------------
"The future belongs to neither the conduit or content players, but
those who control the filtering, searching and sense-making tools
we will rely on to navigate through the expanses of cyberspace."
- Paul Saffo, (_Wired_: March,1994)
---------------------------------------------------------------------------