RFC 901

Official ARPA-Internet protocols

📅 published June 1984, from ietf

Official ARPA-Internet Protocols 💖

Title block, bestie: This is RFC 901 🎀, called Official ARPA-Internet Protocols. It was written by J. Reynolds and J. Postel of ISI, and it's dated June 1984. It's from the Network Working Group, and it obsoletes RFCs 880 and 840 🍓. It's an official status report, so it's the list of which protocols count as official. Basically the Internet's official protocol cheat sheet 📋✨

Status of this Memo ✨

Okay so this memo is an official status report on the protocols used in the ARPA-Internet community. It's the official word on what's what 💅

Introduction 🦋

So this RFC tells you which documents specify the official protocols used in the Internet. Annotations call out any revisions or changes that are planned 📝

Ngl, the official protocols are mostly the ones in the "Internet Protocol Transition Workbook" (IPTW) dated March 1982 📚. There are a few protocols in use that aren't in the IPTW, which is giving "not on the list but still vibing" energy 🙈. A few IPTW protocols have been revised too. The big one is mail: the mail protocols got their own volume called "Internet Mail Protocols," dated November 1982 💌. Telnet and the most useful option protocols came out from the NIC in a booklet called "Internet Telnet Protocol and Options" (ITP), dated June 1983 🖥️. Some protocols haven't been revised in years, and those live in the old "ARPANET Protocol Handbook" (APH), dated January 1978 🕰️. There's also a volume of protocol info called the "Internet Protocol Implementers Guide" (IPIG), dated August 1982 🧚

This document is organized like a sketchy outline 🗂️ (iykyk). The entries are protocols, like the Transmission Control Protocol. Each entry has notes on:

  • status
  • specification
  • comments
  • other references
  • dependencies
  • contact

Here's the breakdown:

  • Status is one of: required, recommended, elective, or experimental.
  • Specification names the protocol-defining documents.
  • Comments describe any differences from the specification or problems with the protocol.
  • Other references point to documents that comment on or expand on the protocol.
  • Dependencies show what other protocols this one calls on.
  • Contact is a person who can answer questions about the protocol.

And the status values, bestie, are a whole vibe 🌈:

  • required: all hosts must implement the required protocol 🔒
  • recommended: all hosts are encouraged to implement the recommended protocol 🌟
  • elective: hosts may implement or not implement the elective protocol 🤷‍♀️
  • experimental: hosts should not implement the experimental protocol unless they're participating in the experiment and have coordinated their use of this protocol with the contact person 🧪. This one is serious, so don't skip the coordinating part, okay?
  • none: this is not a protocol 🙅‍♀️
For more info about protocols in general, reach out to the contact below. She's the queen of this 👑
Joyce Reynolds
USC - Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California  90292-6695

Phone: (213) 822-1511

ARPA mail: JKREYNOLDS@USC-ISIF.ARPA

Overview 🌸

Catenet Model ✨

STATUS: None 🙅‍♀️

SPECIFICATION: IEN 48 (in IPTW) 📜

COMMENTS:

Gives an overview of the organization and principles of the Internet. It's giving "big picture" 🖼️

It could be revised and expanded, so this one's still a work in progress 🛠️

OTHER REFERENCES:

  • RFC 871 - A Perspective on the ARPANET Reference Model 🔍

DEPENDENCIES: none listed 🫶

CONTACT: Postel@USC-ISIF.ARPA 💌

Host Level 🖥️✨

Okay bestie, welcome to the host crew 💅 These are the protocols that actually live on the computers at each end of a connection. Each one gets a status, a spec, some comments, and a contact, so let's go 🦋

User Datagram Protocol (UDP) 🦋

  • STATUS: Recommended
  • SPECIFICATION: RFC 768 (in IPTW)
  • COMMENTS:
    • UDP gives applications a datagram service, and it adds port addressing on top of the IP services. Iconic. 🎀
    • The only change noted for the UDP spec is a minor clarification: if a padding octet is used when computing the checksum, it is not transmitted or counted in the length. Tiny detail, big vibes 🙈
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Transmission Control Protocol (TCP) 🌊

  • STATUS: Recommended
  • SPECIFICATION: RFC 793 (in IPTW)
  • COMMENTS:
    • TCP provides a reliable end-to-end data stream service. The main character of the transport layer, no cap 👑
    • Lots of comments and corrections have come in for the TCP spec. Mostly these are document bugs, not protocol bugs, so the protocol itself is fine 💖
    • Event Processing Section: There are many minor corrections and clarifications needed in this section. Bestie, it's a lot 😭
    • Push: A few phrases in the document give the push a "record mark" flavor, and that needs clarifying. The push is not a record mark. Say it with me 🫶
    • Listening Servers: Several comments came in about trouble contacting listening servers. There should be some discussion of implementation issues for servers, plus some notes on alternative models of system and process organization for servers. Lowkey a whole vibe 🌈
    • Maximum Segment Size: The maximum segment size option should be generalized and clarified. It can be used to either increase or decrease the maximum segment size from the default. The TCP Maximum Segment Size is the IP Maximum Datagram Size minus forty. The default IP Maximum Datagram Size is 576. The default TCP Maximum Segment Size is 536. For further discussion, see RFC 879. ✨
    • Idle Connections: People have asked about automatically closing idle connections. Idle connections are ok, and they should not be closed. Several cases produce idle connections, for example in Telnet, when a user is thinking for a long time after a message from the server computer before their next input. There is no TCP "probe" mechanism, and none is needed. Patience is a virtue, babe 🧚
    • Queued Receive Data on Closing: There are several points where the description isn't clear about what to do with data that TCP has received but not yet passed to the user, especially when the connection is closing. In general, the data is to be kept so it can be given to the user if they make a RECV call. Don't lose the tea 🍓
    • Out of Order Segments: The description says that segments arriving out of order, meaning they are not exactly the next segment to be processed, may be kept on hand. It should also point out that there is a very large performance penalty for not doing so. Big "why would you not" energy 💀
    • User Time Out: This is the timeout started on an open or send call. If this user timeout occurs, the user should be notified, but the connection should not be closed or the TCB deleted. The user should explicitly ABORT the connection if they want to give up. Not me deciding to quit by accident 🙅‍♀️
  • OTHER REFERENCES:
    • RFC 813 (in IPIG) - Window and Acknowledgement Strategy in TCP
    • RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes
    • RFC 816 (in IPIG) - Fault Isolation and Recovery
    • RFC 817 (in IPIG) - Modularity and Efficiency in Protocol Implementation
    • RFC 879 - TCP Maximum Segment Size
    • RFC 889 - Internet Delay Experiments
    • RFC 896 - TCP/IP Congestion Control
    • MIL-STD-1778 - Military Standard Transmission Control Protocol
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Host Monitoring Protocol (HMP) 🔍

  • STATUS: Elective
  • SPECIFICATION: RFC 869
  • COMMENTS:
    • This is a good tool for debugging protocol implementations on remotely located computers. Girl, debugging from afar? Iconic 🫶
    • This protocol is used to monitor Internet gateways and the TACs. 🛰️
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Hinden@BBN-UNIX.ARPA

Cross Net Debugger (XNET) 🐞

  • STATUS: Elective
  • SPECIFICATION: IEN 158
  • COMMENTS:
    • A debugging protocol that allows debugger-like access to remote systems. Main character debugging energy 💜
    • This specification should be updated and reissued as an RFC. Someone please give this one a glow-up ✨
  • OTHER REFERENCES: RFC 643
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

"Stub" Exterior Gateway Protocol 🚪

  • STATUS: Recommended for Gateways
  • SPECIFICATION: RFC 888
  • COMMENTS:
    • This is the gateway protocol that's still under development. Stay tuned, bestie 👀
    • Please discuss any plans for implementation or use of this protocol with the contact. Ask before you build, periodt 💅
  • OTHER REFERENCES: RFC 827, RFC 890
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Mills@USC-ISID.ARPA

Gateway Gateway Protocol (GGP) 🌉

  • STATUS: Experimental
  • SPECIFICATION: RFC 823
  • COMMENTS:
    • This is the gateway protocol now used in the core gateways. The OG crew 👑
    • Please discuss any plans for implementation or use of this protocol with the contact. 💌
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Brescia@BBN-UNIX.ARPA

Multiplexing Protocol (MUX) 🧩

  • STATUS: Experimental
  • SPECIFICATION: IEN 90
  • COMMENTS:
    • It defines a way to combine several segments from different higher-level protocols into one IP datagram. Packing a whole lunchbox into one bag 🍱
    • There is no current experiment in progress. There's some question about how much of the sharing this protocol envisions can actually happen. There are also some issues with the information captured in the multiplexing header: it might be (a) insufficient, or (b) over-specific. Honestly, a little messy 🙃
    • Please discuss any plans for implementation or use of this protocol with the contact. 💬
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Stream Protocol (ST) 🌊

  • STATUS: Experimental
  • SPECIFICATION: IEN 119
  • COMMENTS:
    • A gateway resource allocation protocol designed for use in multihost real-time applications. Real-time and resource-savvy, I'm obsessed 🤩
    • The implementation of this protocol has evolved and may no longer be consistent with this specification. The document should be updated and issued as an RFC. Time for a little spring cleaning 🧹
    • Please discuss any plans for implementation or use of this protocol with the contact. 💌
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Protocol
  • CONTACT: jwf@LL-EN.ARPA

Network Voice Protocol (NVP-II) 🎙️

  • STATUS: Experimental
  • SPECIFICATION: RFC xxx
  • COMMENTS:
    • It defines the procedures for real-time voice conferencing. Group call, but make it protocol 📞
    • The specification is an ISI Internal Memo, which should be updated and issued as an RFC. Let's get this one out in public 🌸
    • Please discuss any plans for implementation or use of this protocol with the contact. 💬
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Internet Protocol, Stream Protocol
  • CONTACT: Casner@USC-ISIB.ARPA

Application Level 📱

Telnet Protocol (TELNET) ⌨️

  • STATUS: Recommended
  • SPECIFICATION: RFC 854 (in "Internet Telnet Protocol and Options")
  • COMMENTS:
    • This is the protocol for remote terminal access. Typing from across the world, bestie 🌍
    • It has been revised since the IPTW. RFC 764 in IPTW is now obsolete, so don't go back to it 🙅‍♀️
  • OTHER REFERENCES:
    • MIL-STD-1782 - Telnet Protocol and Options (TELNET)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Telnet Options (TELNET-OPTIONS) 🎛️

  • STATUS: Elective
  • SPECIFICATION: General description of options: RFC 855 (in "Internet Telnet Protocol and Options")

Here's the full options table, and yes, it's giving spreadsheet energy 🍓

Number   Name                                RFC  NIC  ITP APH USE
------   ---------------------------------   --- ----- --- --- ---
   0     Binary Transmission                 856 ----- yes obs yes
   1     Echo                                857 ----- yes obs yes
   2     Reconnection                        ... 15391  no yes  no
   3     Suppress Go Ahead                   858 ----- yes obs yes
   4     Approx Message Size Negotiation     ... 15393  no yes  no
   5     Status                              859 ----- yes obs yes
   6     Timing Mark                         860 ----- yes obs yes
   7     Remote Controlled Trans and Echo    726 39237  no yes  no
   8     Output Line Width                   ... 20196  no yes  no
   9     Output Page Size                    ... 20197  no yes  no
  10     Output Carriage-Return Disposition  652 31155  no yes  no
  11     Output Horizontal Tabstops          653 31156  no yes  no
  12     Output Horizontal Tab Disposition   654 31157  no yes  no
  13     Output Formfeed Disposition         655 31158  no yes  no
  14     Output Vertical Tabstops            656 31159  no yes  no
  15     Output Vertical Tab Disposition     657 31160  no yes  no
  16     Output Linefeed Disposition         658 31161  no yes  no
  17     Extended ASCII                      698 32964  no yes  no
  18     Logout                              727 40025  no yes  no
  19     Byte Macro                          735 42083  no yes  no
  20     Data Entry Terminal                 732 41762  no yes  no
  21     SUPDUP                          734 736 42213  no yes  no
  22     SUPDUP Output                       749 45449  no  no  no
  23     Send Location                       779 -----  no  no  no
  24     Terminal Type                       884 -----  no  no yes
  25     End of Record                       885 -----  no  no yes
 255     Extended-Options-List               861 ----- yes obs yes

                                                  (obs = obsolete)

The ITP column tells you if the specification is included in the Internet Telnet Protocol and Options. The APH column tells you if the specification is included in the ARPANET Protocol Handbook. The USE column shows which options are in general use. 📚

  • COMMENTS:
    • Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark, and Extended Options List were recently updated and reissued. These are the most frequently implemented options. The popular girls 💖
    • The remaining options should be reviewed. The useful ones should be revised and reissued, and the others should be eliminated. Spring cleaning round two 🧼
    • The following are recommended: Binary Transmission, Echo, Suppress Go Ahead, Status, Timing Mark, and Extended Options List. ⭐
  • OTHER REFERENCES: None listed.
  • DEPENDENCIES: Telnet
  • CONTACT: Postel@USC-ISIF.ARPA

File Transfer Protocol (FTP) 📁

  • STATUS: Recommended
  • SPECIFICATION: RFC 765 (in IPTW)
  • COMMENTS:

The FTP entry is where the mail stuff gets cut, and honestly it's the most dramatic glow-up in the whole list 💅✨ Here's what's still going on:

Okay so FTP is the protocol for moving files between Internet hosts 📁, and it handles access control AND lets you negotiate file parameters 🔐. There are a bunch of minor corrections still to be made 🙈. The big one is that the mail commands are getting deleted 💀, and the data connection management part needs a major clarification. There was also a suggestion to add some directory manipulation commands, see RFC 775 🗂️.

Even though the MAIL features are still defined in this document, they are not to be used 🚫. SMTP is the one for all mail service on the Internet 📬🫶

Data Connection Management:

  • Default Data Connection Ports: All FTP implementations must support use of the default data connection ports, and only the User-PI may initiate the use of non-default ports. 🔒
  • Negotiating Non-Default Data Ports: The User-PI may specify a non-default user side data port with the PORT command. The User-PI may request the server side to identify a non-default server side data port with the PASV command. Since a connection is defined by the pair of addresses, doing either one is enough to get a different data connection, though it is still permitted to do both commands to use new ports on both ends of the data connection. 🦋
  • Reuse of the Data Connection: When using the stream mode of data transfer, the end of the file must be indicated by closing the connection. This causes a problem if multiple files are to be transferred in the session, because TCP needs to hold the connection record for a time out period to guarantee reliable communication. So the connection can not be reopened right away. 😭
    • There are two solutions to this problem. The first is to negotiate a non-default port (as in (b) above). The second is to use another transfer mode. ✨
    • A comment on transfer modes: the stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not. The other transfer modes (Block, Compressed) do not close the connection to indicate the end of file. They have enough FTP encoding that the data connection can be parsed to determine the end of the file. So with these modes, one can leave the data connection open for multiple file transfers. Lowkey the best option 🌿
    • Why this was not a problem with the old NCP FTP:
      • The NCP was designed with only the ARPANET in mind. The ARPANET provides very reliable service, and the NCP counted on it. If any packet of data from an NCP connection were lost or damaged by the network, the NCP could not recover. It is a tribute to the ARPANET designers that the NCP FTP worked so well. 👑
      • The TCP is designed to provide reliable connections over many different types of networks and interconnections of networks. TCP must cope with a set of networks that can not promise to work as well as the ARPANET. TCP must make its own provisions for end-to-end recovery from lost or damaged packets. This leads to the need for the connection phase-down time-out. The NCP never had to deal with acknowledgements or retransmissions or many other things the TCP must do to make the connection reliable in a more complex world. 🧚

LIST and NLST:

There is some confusion about the LIST and NLST commands, and about what is appropriate to return. Some clarification and motivation for these commands should be added to the specification. 🤔

OTHER REFERENCES:

  • RFC 678 - Document File Format Standards
  • MIL-STD-1780 - File Transfer Protocol (FTP)

DEPENDENCIES: Transmission Control Protocol

CONTACT: Postel@USC-ISIF.ARPA

Trivial File Transfer Protocol (TFTP)

  • STATUS: Elective
  • SPECIFICATION: RFC 783 (in IPTW)
  • COMMENTS: A very simple file moving protocol. No access control is provided. No known problems with this specification, and it's in use in several local networks. 🌸
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Simple Mail Transfer Protocol (SMTP)

  • STATUS: Recommended
  • SPECIFICATION: RFC 821 (in "Internet Mail Protocols")
  • COMMENTS: The procedure for transmitting computer mail between hosts. This has been revised since the IPTW, and it's in the "Internet Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is obsolete. 📨 There were many misunderstandings and errors in the early implementations, and some documentation of these problems can be found in the file [ISIF]<SMTP>MAIL.ERRORS. Some minor differences between RFC 821 and RFC 822 should be resolved.
  • OTHER REFERENCES:
    • RFC 822 - Mail Header Format Standards
      • This has been revised since the IPTW, and it's in the "Internet Mail Protocols" volume of November 1982. RFC 733 (in IPTW) is obsolete. Further revision of RFC 822 is needed to correct some minor errors in the details of the specification. 🧐
    • MIL-STD-1781 - Simple Mail Transfer Protocol (SMTP)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Resource Location Protocol (RLP)

  • STATUS: Elective
  • SPECIFICATION: RFC 887
  • COMMENTS: A resource location protocol for use in the ARPA-Internet. This protocol utilizes the User Datagram Protocol (UDP), which in turn calls on the Internet Protocol to deliver its datagrams. 🛰️
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Accetta@CMU-CS-A.ARPA

Remote Job Entry (RJE)

  • STATUS: Elective
  • SPECIFICATION: RFC 407 (in APH)
  • COMMENTS: The general protocol for submitting batch jobs and retrieving the results. Some changes are needed for use with TCP. No known active implementations. 🥀
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: File Transfer Protocol, Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Remote Job Service (NETRJS)

  • STATUS: Elective
  • SPECIFICATION: RFC 740 (in APH)
  • COMMENTS: A special protocol for submitting batch jobs and retrieving the results, used with the UCLA IBM OS system. Please discuss any plans for implementation or use of this protocol with the contact. Revision in progress. 🛠️
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Braden@USC-ISIA.ARPA

Remote Telnet Service (RTELNET)

  • STATUS: Elective
  • SPECIFICATION: RFC 818
  • COMMENTS: Provides special access to user Telnet on a remote system. 💻
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Telnet, Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Graphics Protocol (GRAPHICS)

  • STATUS: Elective
  • SPECIFICATION: NIC 24308 (in APH)
  • COMMENTS: The protocol for vector graphics. Very minor changes are needed for use with TCP. No known active implementations. 🎨
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Telnet, Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Echo Protocol (ECHO)

  • STATUS: Recommended
  • SPECIFICATION: RFC 862
  • COMMENTS: A debugging protocol that sends back whatever you send it. 🪞
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Discard Protocol (DISCARD)

  • STATUS: Elective
  • SPECIFICATION: RFC 863
  • COMMENTS: A debugging protocol that throws away whatever you send it. 🗑️
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Character Generator Protocol (CHARGEN)

  • STATUS: Elective
  • SPECIFICATION: RFC 864
  • COMMENTS: A debugging protocol that sends you ASCII data. 🔤
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Quote of the Day Protocol (QUOTE)

  • STATUS: Elective
  • SPECIFICATION: RFC 865
  • COMMENTS: A debugging protocol that sends you a short ASCII message. 💬
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Active Users Protocol (USERS)

  • STATUS: Elective
  • SPECIFICATION: RFC 866
  • COMMENTS: Lists the currently active users. 👀
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Finger Protocol (FINGER)

  • STATUS: Elective
  • SPECIFICATION: RFC 742 (in APH)
  • COMMENTS: Provides information on the current or most recent activity of a user. Some extensions have been suggested, and some changes are needed for TCP. 🔍
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

WhoIs Protocol (NICNAME)

  • STATUS: Elective
  • SPECIFICATION: RFC 812 (in IPTW)
  • COMMENTS: Accesses the ARPANET Directory database. It provides a way to find out about people, their addresses, phone numbers, organizations, and mailboxes. 📇
  • OTHER REFERENCES: none listed
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Feinler@SRI-NIC.ARPA

Domain Name Protocol (DOMAIN)

  • STATUS: Experimental
  • SPECIFICATION: RFC 881, 882, 883
  • COMMENTS:
  • OTHER REFERENCES:
    • RFC 897 - Domain Name Implementation Schedule
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Mockapetris@USC-ISIF.ARPA

HOSTNAME Protocol (HOSTNAME)

  • STATUS: Elective
  • SPECIFICATION: RFC 811 (in IPTW)
  • COMMENTS: Accesses the Registered Internet Hosts database (HOSTS.TXT). It provides a way to find out about a host in the Internet, its Internet Address, and the protocols it implements. 🖥️
  • OTHER REFERENCES:
    • RFC 810 - Host Table Specification
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Feinler@SRI-NIC.ARPA

Host Name Server Protocol (NAMESERVER)

  • STATUS: Experimental

Okay bestie, let's keep going 💅

Internet Protocol Listing (continued) 🌸

The first one up is the IEN 116 name protocol, and it's giving "old but important" 👑

  • STATUS: Elective... wait, no. Correction: the original lists this one as Elective? Let me check... it's actually listed under the header in the previous part, so here are its details:
  • SPECIFICATION: IEN 116 (in IPTW)
  • COMMENTS: It gives you a machine-oriented procedure for translating a host name into an Internet Address 🔥. Lowkey, it has three big problems 💀:
    1. The name syntax is out of date.
    2. The protocol details are ambiguous. In particular, the length octet either does or doesn't include itself and the op code 🙈.
    3. The extensions are not supported by any known implementation.

Work is in progress on a significant revision ✨, so further implementations of this protocol are not advised 🚫. If you're thinking about implementing or using it, please discuss your plans with the contact.

  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

CSNET Mailbox Name Server Protocol (CSNET-NS) 🎀

  • STATUS: Experimental
  • SPECIFICATION: CS-DN-2
  • COMMENTS: This one gives you access to the CSNET database of users, so you can look up user names, affiliations, and mailboxes 📬. Please discuss any plans for implementing or using it with the contact 🫶.
  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Solomon@UWISC.ARPA

Daytime Protocol (DAYTIME) 🌈

  • STATUS: Elective
  • SPECIFICATION: RFC 867
  • COMMENTS: It tells you the day and time as an ASCII character string ⏰.
  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Time Server Protocol (TIME) ⏳

  • STATUS: Recommended
  • SPECIFICATION: RFC 868
  • COMMENTS: Gives you the time as a count of seconds from a specified reference time 🧚.
  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: Transmission Control Protocol or User Datagram Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

DCNET Time Server Protocol (CLOCK) 🕰️

  • STATUS: Elective
  • SPECIFICATION: RFC 778
  • COMMENTS: A mechanism for keeping clocks synchronized, which is so important for a main character network ⭐.
  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: Internet Control Message Protocol
  • CONTACT: Mills@USC-ISID.ARPA

SUPDUP Protocol (SUPDUP) 🖥️

  • STATUS: Elective
  • SPECIFICATION: RFC 734 (in APH)
  • COMMENTS: A special, Telnet-like protocol for display terminals 💜.
  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Admin.MRC@SU-SCORE.ARPA

Internet Message Protocol (MPM) 💌

  • STATUS: Experimental
  • SPECIFICATION: RFC 759
  • COMMENTS: This is an experimental multimedia mail transfer protocol, and the implementation is called a Message Processing Module, or MPM 🦋. Please discuss any plans for implementing or using it with the contact.
  • OTHER REFERENCES:
    • RFC 767 - Structured Document Formats
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Post Office Protocol (POP) 📮

  • STATUS: Experimental
  • SPECIFICATION: RFC xxx
  • COMMENTS: An experimental procedure for accessing mailbox services from personal workstations 💻. Please discuss any plans for implementing or using it with the contact.
  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: Transmission Control Protocol
  • CONTACT: Postel@USC-ISIF.ARPA

Network Standard Text Editor (NETED) ✏️

  • STATUS: Elective
  • SPECIFICATION: RFC 569
  • COMMENTS: Describes a simple line editor that could be provided by every Internet host 🍓.
  • OTHER REFERENCES: (none listed)
  • DEPENDENCIES: (none listed)
  • CONTACT: Postel@USC-ISIF.ARPA

Appendices 🎀

Assigned Numbers 🔢

  • STATUS: None
  • SPECIFICATION: RFC 900
  • COMMENTS: This describes the fields of various protocols that have specific values assigned for actual use, and it lists the currently assigned values 📋.

Issued June 1984, replaces RFC 870, RFC 790 in IPTW, and RFC 820 of January 1983.

  • OTHER REFERENCES: (none listed)
  • CONTACT: JKReynolds@USC-ISIF.ARPA

Pre-emption 🚨

  • STATUS: Elective
  • SPECIFICATION: RFC 794 (in IPTW)
  • COMMENTS: Describes how to do pre-emption of TCP connections 🫣.
  • OTHER REFERENCES: (none listed)
  • CONTACT: Postel@USC-ISIF.ARPA

Service Mappings 🗺️

  • STATUS: None
  • SPECIFICATION: RFC 795 (in IPTW)
  • COMMENTS: Describes the mapping of the IP type of service field onto the parameters of some specific networks. Out of date, needs revision 🥲.
  • OTHER REFERENCES: (none listed)
  • CONTACT: Postel@USC-ISIF.ARPA

Address Mappings 📍

  • STATUS: None
  • SPECIFICATION: RFC 796 (in IPTW)
  • COMMENTS: Describes the mapping between Internet Addresses and the addresses of some specific networks. Out of date, needs revision 🥲.
  • OTHER REFERENCES: (none listed)
  • CONTACT: Postel@USC-ISIF.ARPA

Internet Protocol on X.25 Networks 📡

  • STATUS: Recommended
  • SPECIFICATION: RFC 877
  • COMMENTS: A standard for transmitting IP Datagrams over Public Data Networks 🌐.
  • OTHER REFERENCES: (none listed)
  • CONTACT: jtk@PURDUE.ARPA

Internet Protocol on DC Networks 🧩

  • STATUS: Elective
  • SPECIFICATION: RFC 891
  • COMMENTS: (none)
  • OTHER REFERENCES:
    • RFC 778 - DCNET Internet Clock Service
  • CONTACT: Mills@USC-ISID.ARPA

Internet Protocol on Ethernet Networks 🔌

  • STATUS: Recommended
  • SPECIFICATION: RFC 894
  • COMMENTS: (none)
  • OTHER REFERENCES:
  • CONTACT: Postel@USC-ISIF.ARPA

Internet Protocol on Experimental Ethernet Networks 🧪

  • STATUS: Recommended
  • SPECIFICATION: RFC 895
  • COMMENTS: (none)
  • OTHER REFERENCES: (none listed)
  • CONTACT: Postel@USC-ISIF.ARPA

Address Resolution Protocol (ARP) 🔍

  • STATUS: Recommended
  • SPECIFICATION: RFC 826
  • COMMENTS: A procedure for finding the network hardware address that corresponds to an Internet Address. It's the ultimate "where are you?" move 🦋✨.
  • OTHER REFERENCES: (none listed)
  • CONTACT: Postel@USC-ISIF.ARPA
📦 where this page comes from