Message-Id: <9310062312.AA16991@mocha.bunyip.com>
To: "Rob Raisch, The Internet Company" <raisch@internet.com>
Subject: Internet directory services (was: MTV and Panix .plan file dispute?)
In-Reply-To: Your message of Wed, 06 Oct 1993 07:21:34 -0700.
<Pine.3.03.9310060733.B10429-d100000@hmmm.internet.com>
Date: Wed, 06 Oct 1993 19:11:32 -0400
From: John Curran <jcurran@nic.near.net>
--------
] From: "Rob Raisch, The Internet Company" <raisch@internet.com>
] Subject: Re: MTV and Panix .plan file dispute? --Panix replies.
] Date: Wed, 6 Oct 1993 07:21:34 -0700 (PDT)
]
] I would like to suggest that this problem goes away by deploying a
] scalable, distributable mechanism to share the load.
I agree with the above; we've reach the point in time where we need a
generalized mechanism for multiple servers per application for load-sharing
and reliability. Some Internet applications or services already incorporate
such functionality: DNS, mail, and news are good examples.
] We need some mechanism in place -now- to allow a user to make an informed
] retrieval decision. And in the best case, to make this decision for
] the user. Some of the questions we need answered are:
] ..
] (We were making a stab at this problem in the URI working group, but got
] seriously sidetracked when it became clear that various people had
] different fish to fry. And this problem is vastly larger than most are
] willing to admit.)
The IETF's URI working group is still working on the components (such as
resource locators and names) to allow interoperability between information
discovery and retrieval applications. Uniform resource locators (URLs)
are already being successfully incorporated into clients and servers for
wais, gopher, and www. We need to get operational experience with these
locators before building additional functionality in other layer above them.
Uniform names are more going to more contentious, since multiple competing
and cooperating folks will want to provide the service to map resource names
into pointers to particular services.
I don't think that the URI WG effort in this area has been "sidetracked":
the issues of how to resolve resource names into references to particular
servers/services has simply been deferred so we could make progress on the
basic elements. Once the elements have been proven, it will be possible
for the URI group (or another WG chartered to handle service architecture)
to work on a generic Internet service architecture. Once that has been
completed, we will need the mechanism to allow a single resolution query to
multiple competing _services_ (unless the user has specified preferences.)
I feel that we can separate the issues of robust service architecture from
the issues of how open-ended resource queries will be handled.
/John