The RFC Archive
 The RFC Archive   RFC 1775   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 1775

To Be 'On' the Internet

Last modified on Monday, March 20th, 1995

Permanent link to RFC 1775
Search GitHub Wiki for RFC 1775
Show other RFCs mentioning RFC 1775







Network Working Group                                         D. Crocker
Request for Comments: 1775                        Brandenburg Consulting
Category: Informational                                     March 1995


                        To Be "On" the Internet

 Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

 Abstract

   The Internet permits different levels of access for consumers and
   providers of service.  The nature of those differences is quite
   important in the capabilities They afford.  Hence, it is appropriate
   to provide terminology that distinguishes among the range, so that
   the Internet community can gain some clarity when distinguishing
   whether a user (or an organization) is "on" the Internet.  This
   document suggests four terms, for distinguishing the major classes of
   access.

1.   INTRODUCTION

   The Internet is many things to many people.  It began as a technology
   and has grown into a global service.  With the growth has come
   increased complexity in details of the technology and service,
   resulting in confusion when trying to determine whether a given user
   is "on" the Internet.  Who is on the Internet?  What capabilities do
   they have?  This note is an attempt to aid Internet consumers and
   providers in determining the basic types of end-user access that
   distinguish critical differences in Internet attachment.

   The list was developed primarily for the perspective of users, rather
   than for the technical community. The definitions in this list take
   the perspective that users are primarily interested in application
   services.   A curious implication is that some of the definitions do
   not rely on the direct use of the underlying Internet connectivity
   protocols, TCP/IP.  For many technical discussions, therefore, these
   terms will not be appropriate.









Crocker                                                      PAGE 1 top


RFC 1775 To Be "On" the Internet March 1995 2. LABELS FOR INTERNET ACCESS The following definitions move from "most" to "least" Internet access, from the perspective of the user (consumer). The first term is primarily applicable to Internet service providers. The remaining terms are primarily applicable to consumers of Internet service. FULL ACCESS This is a permanent (full-time) Internet attachment running TCP/IP, primarily appropriate for allowing the Internet community to access application servers, operated by Internet service providers. Machines with Full access are directly visible to others attached to the Internet, such as through the Internet Protocol's ICMP Echo (ping) facility. The core of the Internet comprises those machines with Full access. CLIENT ACCESS The user runs applications that employ Internet application protocols directly on their own computer platform, but might not be running underlying Internet protocols (TCP/IP), might not have full-time access, such as through dial-up, or might have constrained access, such as through a firewall. When active, Client users might be visible to the general Internet, but such visibility cannot be predicted. For example, this means that most Client access users will not be detected during an empirical probing of systems "on" the Internet at any given moment, such as through the ICMP Echo facility. MEDIATED ACCESS The user runs no Internet applications on their own platform. An Internet service provider runs applications that use Internet protocols on the provider's platform, for the user. User has simplified access to the provider, such as dial-up terminal connectivity. For Mediated access, the user is on the Internet, but their computer platform is not. Instead, it is the computer of the mediating service (provider) which is on the Internet. MESSAGING ACCESS The user has no Internet access, except through electronic mail and through netnews, such as Usenet or a bulletin board service. Since messaging services can be used as a high-latency -- i.e., slow -- transport service, the use of this level of access for mail-enabled services can be quite powerful, though not interactive. Crocker PAGE 2 top

RFC 1775 To Be "On" the Internet March 1995 3. SAMPLE USAGE The test of a nomenclature is, of course, its application to real- life situations. Two simple cases involve home users. If a user accesses the Internet by running a terminal program on their PC and then dials up a public service which provides the Internet applications, then that user has Mediated Internet access. The public service has Client or Full access, but the user does not. On the other hand, users who access via SLIP or PPP are running Internet applications on their own PCs and they have Client Internet access. Many corporations now have a full-time link to the Internet. The link is based on TCP/IP and usually has a number of Internet servers running, for email exchange and for making public corporate data available to the rest of the world, such as through the World Wide Web and Gopher. Clearly, the corporation is "on" the Internet, with Full Internet access. What about a user in that corporation? Many corporations today separate their internal internet from the public Internet via a firewall. If a user from the internal internet has a desktop computer and reaches out to the Internet, through the firewall, by running any Internet applications, such as a Web browser, then that user has Client Internet access. Some corporations will not allow this, instead requiring all software which touches the public Internet to be run on specially-administered machines which are part of the corporation's firewall suite of services. Hence, users must make a terminal connection to the special machines, from there running the Internet applications. Such users have Mediated Internet access, the same as home users who dial up a public service. 4. SECURITY CONSIDERATIONS This specification does NOT, itself, provide or define any security- related mechanisms. However it does describe scenarios with different security implications for users and providers. Readers of this discussion are cautioned to consider those implications when choosing a service. 5. ACKNOWLEDGMENTS Development of these definitions was spurred by many public and private discussions in which confusion over Internet access reigned. Convergence on an initial set of three terms was the result of discussion on the Big-Internet mailing list, particularly from comments made by Alan Barret, Howard Berkowitz, Noel Chiappa, Steve Crocker PAGE 3 top

RFC 1775 To Be "On" the Internet March 1995 Goldstein, Iain Hanson, Gary Malkin, Bob McKisson, Tim O'Reilly, Dave Piscitello and Bill Simpson. Eventually, the need for a fourth category became evident and was discussed further with the participants on the list. This does not mean that any of them necessarily endorses the terms and definitions provided, merely that their notes assisted my thinking on the topic. After the initial round of public discussion, Smoot Carl-Mitchell and John Quarterman of Texas Internet Consulting developed terminology for similar categories and served to prompt modification of this set, described, here, to distinguish between provider and consumer forms of access and emphasize the role of Full access in defining the Internet core. 6. Security Considerations Security issues are not discussed in this memo. 7. Author's Address David H. Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA Phone: +1 408 246 8253 Fax: +1 408 249 6205 EMail: dcrocker@mordor.stanford.edu Crocker PAGE 4 top

To Be 'On' the Internet RFC TOTAL SIZE: 8455 bytes PUBLICATION DATE: Monday, March 20th, 1995 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 1775: The IETF Trust, Monday, March 20th, 1995
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement