consistent view of the information on the Internet. In addition, the
recent popularity of multi-protocol clients such as Mosaic seem to
imply that the information content of the Internet is uniformly
retrievable and manageable. This perception is misleading because
most protocols are used for other applications than they were
originally designed for. In addition, Telnet, which has no concept of
information retrieval and management, is often used to access
information as well, for example in DIALOG and card file accesses.
Since each protocol has different access and management capabilities,
the inconsistencies show up in erratic search and retrieval results,
puzzling error messages, and a basic lack of standard techniques for
dealing with information. A consistent underlying information
architecture will go a long way towards alleviating these problems.
As the information architecture develops we should reconsider the
electronic mail and netnews architecture in terms of the new
architecture.
The group noted that there have been difficulties in scheduling joint
working group meetings and recommends that there be a clearly defined
process inside the IETF to facilitate scheduling such meetings.
6. Conclusions and Recommendations
The workshop provided an opportunity for ongoing conversations about
the architecture to continue and also provided space for focused
examination of some issues and for some new voices and experience
from other areas of Internet growth to participate in the
architectural process.
Part of the conclusion of the workshop is a set of recommendations to
the IESG and IETF community.
Recommendations on research/implementation directions:
1. Caching and replication are important and overlooked pieces of
Internet middleware. We should do something about it as soon as
possible, perhaps by defining an architecture and service model for
common implementation.
2. Within the 'wholesale' layer, i.e. within the layer which provides
a consistent view of the information resources available on the
Internet, the first services that should be provided are:
* Object retrieval,
* Name resolution,
* Caching and replication.
3. There would be quick payoff if the raw materials layer, i.e. the
layer in which information resources are physically transmitted to
computers, could provide the following services:
* Connectivity
* Bandwidth, latency, and reliability or a service envelope
* Security constraints on communication and transactions
4. Develop security modules usable by the implementors of information
clients and servers - reusable across many different, heterogeneous
applications and platforms
Recommendations to the IESG, IETF, and IANA
1. Numbers that are formally defined and kept in documents in
distributed information systems (for instance, Assigned Numbers)
should be available in some kind of database for use by applications.
2. Develop and communicate a security model usable by designers of
information applications - current models are not considered usable
or are not widely accepted on the Internet.
3. RFCauthors should be given advice on how security considerations
need to be written. The IESG security area should prepare guidelines
for writing security considerations.
4. Proposed Standards should not be accepted by the IESG unless they
really consider security. This will require recommendations 2 and 3
to be implemented first.
5. Make clear what security services you can expect from the lower
layers.
6. Make sure that the key distribution infrastructure is reviewed for
usability by information applications.
7. There needs to be a process inside the IETF for scheduling a joint
meeting between two working groups - for example, so that the key
distribution WG can meet jointly with IIIR.
APPENDIX A - Workshop Organization
The workshop was held at MCI's facility in Tyson Corners, Virginia.
The workshop organizers and attendees wish to thank MCI for the use
of their facilities to host the workshop.
All attendees met in joint session for the first half of October 12.
They then split into three groups. The first group considered the
"distributed database" problem which has arisen over and over again
in the design of parts of the Internet. The two other groups met to
consider a list of issues pertaining to the information
infrastructure. The groups ran independently until the morning of
October 14, when they met again in joint session.
The following people attended the workshop:
Abel Weinrib abel@bellcore.com
Barry Leiner BLeiner@ARPA.MIL
Cecilia Preston cpreston@info.berkeley.edu
Chris Weider clw@bunyip.com
Christian Huitema Christian.Huitema@SOPHIA.INRIA.FR
Cliff Lynch calur@uccmvsa.ucop.edu
Clifford Neuman bcn@isi.edu
Dan LaLiberte liberte@ncsa.uiuc.edu
Dave Sincoskie sincos@THUMPER.BELLCORE.COM
Elise Gerich epg@MERIT.EDU
Erik Huizer Erik.Huizer@SURFnet.nl
Jill Foster Jill.Foster@newcastle.ac.uk
John Curran jcurran@near.net
John Klensin klensin@infoods.mit.edu
John Romkey romkey@asylum.sf.ca.us
Joyce Reynolds jkrey@isi.edu
Karen Sollins sollins@lcs.mit.edu
Larry Masinter masinter@parc.xerox.com
Lixia Zhang LIXIA@PARC.XEROX.COM
Mark McCahill mpm@boombox.micro.umn.edu
Michael Mealling Michael.Mealling@oit.gatech.edu
Mitchell Charity mcharity@lcs.mit.edu
Mike Schwartz schwartz@cs.colorado.edu
Mike St. Johns stjohns@DARPA.MIL
Mitra mitra@pandora.sf.ca.us
Paul Mockapetris pvm@zephyr.isi.edu
Steve Crocker Crocker@TIS.COM
Tim Berners-Lee tbl@info.cern.ch
Ton Verschuren Ton.Verschuren@surfnet.nl
Yakov Rekhter yakov@WATSON.IBM.COM
Security Considerations
This memo discusses certain aspects of security and the information
infrastructure. It contains general recommendations about security
enhancements required by information applications on the Internet.
Authors' Addresses
Mark McCahill
University of Minnesota
room 190 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
EMail: mpm@boombox.micro.umn.edu
John Romkey [Editor]
1770 Massachusetts Ave. #331
Cambridge, MA 02140
EMail: romkey@apocalypse.org
Michael F. Schwartz
Department of Computer Science
University of Colorado
Boulder, CO 80309-0430
EMail: schwartz@cs.colorado.edu
Karen Sollins
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139-1986
EMail: sollins@lcs.mit.edu
Ton Verschuren
SURFNet
P.O. Box 19035
3501 DA Utrecht
The Netherlands
EMail: Ton.Verschuren@surfnet.nl
Chris Weider
Bunyip Information Systems
310 St. Catherine St. West
Suite 300
Montreal, PQ H2A 2X1
CANADA