| |
| RFC 3 | Documentation conventions |
| |
| Authors: | S.D. Crocker. |
| Date: | April 1969 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0010 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 10 | Documentation conventions |
| |
|
| |
| RFC 11 | Implementation of the Host - Host Software Procedures in GORDO |
| |
| Authors: | G. Deloche. |
| Date: | August 1969 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0033 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 16 | M.I.T |
| |
|
| |
| RFC 61 | Note on Interprocess Communication in a Resource Sharing Computer Network |
| |
| Authors: | D.C. Walden. |
| Date: | July 1970 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0062 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 66 | NIC - third level ideas and other noise |
| |
|
| |
| RFC 80 | Protocols and Data Formats |
| |
|
| |
| RFC 88 | NETRJS: A third level protocol for Remote Job Entry |
| |
| Authors: | R.T. Braden, S.M. Wolfe. |
| Date: | January 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0189 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 95 | Distribution of NWG/RFC's through the NIC |
| |
| Authors: | S.D. Crocker. |
| Date: | February 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0155 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 123 | Proffered Official ICP |
| |
|
| |
| RFC 127 | Comments on RFC 123 |
| |
|
| |
| RFC 132 | Typographical Error in RFC 107 |
| |
|
| |
| RFC 143 | Regarding proffered official ICP |
| |
|
| |
| RFC 145 | Initial Connection Protocol Control Commands |
| |
|
| |
| RFC 155 | ARPA Network mailing lists |
| |
|
| |
| RFC 158 | Telnet Protocol: A Proposed Document |
| |
|
| |
| RFC 160 | RFC brief list |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | May 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0200, RFC 0999 |
| Updates: | NIC 6716 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 168 | ARPA Network mailing lists |
| |
|
| |
| RFC 170 | RFC List by Number |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | June 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0200 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 171 | The Data Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | June 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0264 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 172 | The File Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | June 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0265 |
| Updates: | RFC 0114 |
| Updated by: | RFC 0238 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 189 | Interim NETRJS specifications |
| |
|
| |
| RFC 193 | NETWORK CHECKOUT |
| |
| Authors: | E. Harslem, J.F. Heafner. |
| Date: | July 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0198 |
| Updated by: | RFC 0198 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 196 | Mail Box Protocol |
| |
| Authors: | R.W. Watson. |
| Date: | July 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0221 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 198 | Site Certification - Lincoln Labs 360/67 |
| |
|
| |
| RFC 200 | RFC list by number |
| |
| Authors: | J.B. North. |
| Date: | August 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0170, RFC 0160 |
| Obsoleted by: | NIC 7724 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 207 | September Network Working Group meeting |
| |
| Authors: | A. Vezza. |
| Date: | August 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0212 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 211 | ARPA Network Mailing Lists |
| |
|
| |
| RFC 221 | Mail Box Protocol: Version 2 |
| |
|
| |
| RFC 226 | Standardization of host mnemonics |
| |
| Authors: | P.M. Karp. |
| Date: | September 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0247 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 229 | Standard host names |
| |
| Authors: | J. Postel. |
| Date: | September 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0236 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 235 | Site status |
| |
| Authors: | E. Westheimer. |
| Date: | September 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0240 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 237 | NIC view of standard host names |
| |
| Authors: | R.W. Watson. |
| Date: | October 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0273 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 240 | Site Status |
| |
| Authors: | A.M. McKenzie. |
| Date: | September 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0235 |
| Obsoleted by: | RFC 0252 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 243 | Network and data sharing bibliography |
| |
| Authors: | A.P. Mullery. |
| Date: | October 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0290 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 252 | Network host status |
| |
| Authors: | E. Westheimer. |
| Date: | October 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0240 |
| Obsoleted by: | RFC 0255 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 255 | Status of network hosts |
| |
| Authors: | E. Westheimer. |
| Date: | October 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0252 |
| Obsoleted by: | RFC 0266 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 264 | The Data Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White. |
| Date: | January 1972 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0171 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0310 |
| Also: | RFC 0265 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 265 | The File Transfer Protocol |
| |
| Authors: | A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. |
| Date: | November 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0172 |
| Obsoleted by: | RFC 0354 |
| Updated by: | RFC 0281, RFC 0294, RFC 0310 |
| Also: | RFC 0264 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 266 | Network host status |
| |
| Authors: | E. Westheimer. |
| Date: | November 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0255 |
| Obsoleted by: | RFC 0267 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 267 | Network Host Status |
| |
| Authors: | E. Westheimer. |
| Date: | November 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0266 |
| Obsoleted by: | RFC 0287 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 287 | Status of Network Hosts |
| |
| Authors: | E. Westheimer. |
| Date: | December 1971 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0267 |
| Obsoleted by: | RFC 0288 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 288 | Network host status |
| |
|
| |
| RFC 289 | What we hope is an official list of host names |
| |
| Authors: | R.W. Watson. |
| Date: | December 1971 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0384 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 292 | Graphics Protocol: Level 0 only |
| |
| Authors: | J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. |
| Date: | January 1972 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0493 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 293 | Network Host Status |
| |
|
| |
| RFC 298 | Network host status |
| |
| Authors: | E. Westheimer. |
| Date: | February 1972 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0293 |
| Obsoleted by: | RFC 0306 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 300 | ARPA Network mailing lists |
| |
|
| |
| RFC 303 | ARPA Network mailing lists |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | March 1972 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0300 |
| Obsoleted by: | RFC 0329 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 306 | Network host status |
| |
| Authors: | E. Westheimer. |
| Date: | February 1972 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0298 |
| Obsoleted by: | RFC 0315 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 315 | Network Host Status |
| |
| Authors: | E. Westheimer. |
| Date: | March 1972 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0306 |
| Obsoleted by: | RFC 0319 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 317 | Official Host-Host Protocol Modification: Assigned Link Numbers |
| |
| Authors: | J. Postel. |
| Date: | March 1972 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0604 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 326 | Network Host Status |
| |
|
| |
| RFC 329 | ARPA Network Mailing Lists |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | May 1972 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0303 |
| Obsoleted by: | RFC 0363 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 331 | IMP System Change Notification |
| |
| Authors: | J.M. McQuillan. |
| Date: | April 1972 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0343 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 332 | Network Host Status |
| |
|
| |
| RFC 342 | Network Host Status |
| |
|
| |
| RFC 343 | IMP System change notification |
| |
|
| |
| RFC 344 | Network Host Status |
| |
|
| |
| RFC 349 | Proposed Standard Socket Numbers |
| |
|
| |
| RFC 353 | Network host status |
| |
|
| |
| RFC 354 | File Transfer Protocol |
| |
|
| |
| RFC 360 | Proposed Remote Job Entry Protocol |
| |
| Authors: | C. Holland. |
| Date: | June 1972 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0407 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 362 | Network Host Status |
| |
|
| |
| RFC 363 | ARPA Network mailing lists |
| |
| Authors: | Network Information Center. Stanford Research Institute. |
| Date: | August 1972 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0329 |
| Obsoleted by: | RFC 0402 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 366 | Network Host Status |
| |
|
| |
| RFC 367 | Network host status |
| |
|
| |
| RFC 378 | Traffic statistics (July 1972) |
| |
| Authors: | A.M. McKenzie. |
| Date: | August 1972 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0391 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 389 | UCLA Campus Computing Network Liaison Staff for ARPA Network |
| |
| Authors: | B. Noble. |
| Date: | August 1972 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0423 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 399 | SMFS Login and Logout |
| |
| Authors: | M. Krilanovich. |
| Date: | September 1972 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0431 |
| Updates: | RFC 0122 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 433 | Socket number list |
| |
|
| |
| RFC 434 | IMP/TIP memory retrofit schedule |
| |
| Authors: | A.M. McKenzie. |
| Date: | January 1973 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0447 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 447 | IMP/TIP memory retrofit schedule |
| |
| Authors: | A.M. McKenzie. |
| Date: | January 1973 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0434 |
| Obsoleted by: | RFC 0476 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 503 | Socket number list |
| |
| Authors: | N. Neigus, J. Postel. |
| Date: | April 1973 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0433 |
| Obsoleted by: | RFC 0739 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 542 | File Transfer Protocol |
| |
|
| |
| RFC 599 | Update on NETRJS |
| |
| Authors: | R.T. Braden. |
| Date: | December 1973 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0189 |
| Obsoleted by: | RFC 0740 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 604 | Assigned link numbers |
| |
|
|
Modifies official host-host protocol. Replaces RFC 377. |
|
| |
| RFC 607 | Comments on the File Transfer Protocol |
| |
| Authors: | M. Krilanovich, G. Gregg. |
| Date: | January 1974 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0624 |
| Updated by: | RFC 0614 |
| Status: | UNKNOWN |
|
An old version; see RFC 624; see also RFCs 614, 542 and 640. |
|
| |
| RFC 608 | Host names on-line |
| |
| Authors: | M.D. Kudlick. |
| Date: | January 1974 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0810 |
| Status: | UNKNOWN |
|
Response to RFC 606; see also RFCs 627, 625 and 623. |
|
| |
| RFC 615 | Proposed Network Standard Data Pathname syntax |
| |
| Authors: | D. Crocker. |
| Date: | March 1974 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0645 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 633 | IMP/TIP preventive maintenance schedule |
| |
| Authors: | A.M. McKenzie. |
| Date: | March 1974 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0638 |
| Status: | UNKNOWN |
|
An old version; see RFC 638. |
|
| |
| RFC 651 | Revised Telnet status option |
| |
| Authors: | D. Crocker. |
| Date: | October 1974 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0859 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 687 | IMP/Host and Host/IMP Protocol changes |
| |
|
|
Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692. |
|
| |
| RFC 698 | Telnet extended ASCII option |
| |
| Authors: | T. Mock. |
| Date: | July 1975 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5198 |
| Status: | PROPOSED STANDARD |
|
Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs. |
|
| |
| RFC 724 | Proposed official standard for the format of ARPA Network messages |
| |
| Authors: | D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. |
| Date: | May 1977 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0733 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 729 | Telnet byte macro option |
| |
| Authors: | D. Crocker. |
| Date: | May 1977 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0735 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 731 | Telnet Data Entry Terminal option |
| |
| Authors: | J.D. Day. |
| Date: | June 1977 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0732 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 733 | Standard for the format of ARPA network text messages |
| |
| Authors: | D. Crocker, J. Vittal, K.T. Pogran, D.A. Henderson. |
| Date: | November 1977 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0724 |
| Obsoleted by: | RFC 0822 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 739 | Assigned numbers |
| |
|
| |
| RFC 742 | NAME/FINGER Protocol |
| |
|
| |
| RFC 750 | Assigned numbers |
| |
| Authors: | J. Postel. |
| Date: | September 1978 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0739 |
| Obsoleted by: | RFC 0755 |
| Status: | HISTORIC |
|
|
|
| |
| RFC 755 | Assigned numbers |
| |
|
| |
| RFC 758 | Assigned numbers |
| |
|
| |
| RFC 760 | DoD standard Internet Protocol |
| |
| Authors: | J. Postel. |
| Date: | January 1980 |
| Formats: | txt pdf |
| Obsoletes: | IEN 123 |
| Obsoleted by: | RFC 0791 |
| Updated by: | RFC 0777 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 761 | DoD standard Transmission Control Protocol |
| |
| Authors: | J. Postel. |
| Date: | January 1980 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0793 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 762 | Assigned numbers |
| |
|
| |
| RFC 764 | Telnet Protocol specification |
| |
| Authors: | J. Postel. |
| Date: | June 1980 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0854 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 765 | File Transfer Protocol specification |
| |
|
| |
| RFC 766 | Internet Protocol Handbook: Table of contents |
| |
| Authors: | J. Postel. |
| Date: | July 1980 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0774 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 770 | Assigned numbers |
| |
| Authors: | J. Postel. |
| Date: | September 1980 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0762 |
| Obsoleted by: | RFC 0776 |
| Status: | HISTORIC |
|
|
|
| |
| RFC 772 | Mail Transfer Protocol |
| |
| Authors: | S. Sluizer, J. Postel. |
| Date: | September 1980 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0780, STD 0010 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 776 | Assigned numbers |
| |
|
| |
| RFC 777 | Internet Control Message Protocol |
| |
|
| |
| RFC 780 | Mail Transfer Protocol |
| |
|
| |
| RFC 783 | TFTP Protocol (revision 2) |
| |
| Authors: | K.R. Sollins. |
| Date: | June 1981 |
| Formats: | txt pdf |
| Obsoletes: | IEN 133 |
| Obsoleted by: | RFC 1350 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 788 | Simple Mail Transfer Protocol |
| |
|
| |
| RFC 790 | Assigned numbers |
| |
| Authors: | J. Postel. |
| Date: | September 1981 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0776 |
| Obsoleted by: | RFC 0820 |
| Status: | HISTORIC |
|
|
|
| |
| RFC 802 | ARPANET 1822L Host Access Protocol |
| |
| Authors: | A.G. Malis. |
| Date: | November 1981 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0851 |
| Status: | UNKNOWN |
|
This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851. |
|
| |
| RFC 806 | Proposed Federal Information Processing Standard: Specification for message format for computer based message systems |
| |
| Authors: | National Bureau of Standards. |
| Date: | September 1981 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0841 |
| Status: | UNKNOWN |
|
This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841. |
|
| |
| RFC 810 | DoD Internet host table specification |
| |
| Authors: | E.J. Feinler, K. Harrenstien, Z. Su, V. White. |
| Date: | March 1982 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0608 |
| Obsoleted by: | RFC 0952 |
| Status: | UNKNOWN |
|
This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608. |
|
| |
| RFC 811 | Hostnames Server |
| |
| Authors: | K. Harrenstien, V. White, E.J. Feinler. |
| Date: | March 1982 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0953 |
| Status: | UNKNOWN |
|
This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment. |
|
| |
| RFC 812 | NICNAME/WHOIS |
| |
| Authors: | K. Harrenstien, V. White. |
| Date: | March 1982 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0954, RFC 3912 |
| Status: | UNKNOWN |
|
This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory. |
|
| |
| RFC 820 | Assigned numbers |
| |
|
|
This RFC is an old version, see RFC 870. |
|
| |
| RFC 821 | Simple Mail Transfer Protocol |
| |
|
|
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772. |
|
| |
| RFC 822 | STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES |
| |
|
|
This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952. |
|
| |
| RFC 825 | Request for comments on Requests For Comments |
| |
|
|
This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs. |
|
| |
| RFC 832 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | December 1982 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0833 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82. |
|
| |
| RFC 833 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | December 1982 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0832 |
| Obsoleted by: | RFC 0834 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82. |
|
| |
| RFC 834 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | December 1982 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0833 |
| Obsoleted by: | RFC 0835 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82. |
|
| |
| RFC 835 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | December 1982 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0834 |
| Obsoleted by: | RFC 0836 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83. |
|
| |
| RFC 836 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | January 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0835 |
| Obsoleted by: | RFC 0837 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83. |
|
| |
| RFC 837 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | January 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0836 |
| Obsoleted by: | RFC 0838 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83. |
|
| |
| RFC 838 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | January 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0837 |
| Obsoleted by: | RFC 0839 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83. |
|
| |
| RFC 839 | Who talks TCP? |
| |
| Authors: | D. Smallberg. |
| Date: | January 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0838 |
| Obsoleted by: | RFC 0842 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83. |
|
| |
| RFC 840 | Official protocols |
| |
| Authors: | J. Postel. |
| Date: | April 1983 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0880 |
| Status: | HISTORIC |
|
This RFC has been revised, see RFC 880. |
|
| |
| RFC 842 | Who talks TCP? - survey of 1 February 83 |
| |
| Authors: | D. Smallberg. |
| Date: | February 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0839 |
| Obsoleted by: | RFC 0843 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA. |
|
| |
| RFC 843 | Who talks TCP? - survey of 8 February 83 |
| |
|
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA. |
|
| |
| RFC 845 | Who talks TCP? - survey of 15 February 1983 |
| |
| Authors: | D. Smallberg. |
| Date: | February 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0843 |
| Obsoleted by: | RFC 0846 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA. |
|
| |
| RFC 846 | Who talks TCP? - survey of 22 February 1983 |
| |
| Authors: | D. Smallberg. |
| Date: | February 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0845 |
| Obsoleted by: | RFC 0847 |
| Status: | UNKNOWN |
|
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA. |
|
| |
| RFC 850 | Standard for interchange of USENET messages |
| |
| Authors: | M.R. Horton. |
| Date: | June 1983 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1036 |
| Status: | UNKNOWN |
|
This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on. |
|
| |
| RFC 851 | ARPANET 1822L Host Access Protocol |
| |
|
|
This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802. |
|
| |
| RFC 870 | Assigned numbers |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | October 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0820 |
| Obsoleted by: | RFC 0900 |
| Status: | HISTORIC |
|
This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604. |
|
| |
| RFC 877 | Standard for the transmission of IP datagrams over public data networks |
| |
| Authors: | J.T. Korb. |
| Date: | September 1983 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1356 |
| Status: | UNKNOWN |
|
This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks. |
|
| |
| RFC 880 | Official protocols |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | October 1983 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0840 |
| Obsoleted by: | RFC 0901 |
| Status: | HISTORIC |
|
This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840. |
|
| |
| RFC 882 | Domain names: Concepts and facilities |
| |
|
|
This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities. |
|
| |
| RFC 883 | Domain names: Implementation specification |
| |
|
|
This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software. |
|
| |
| RFC 884 | Telnet terminal type option |
| |
| Authors: | M. Solomon, E. Wimmers. |
| Date: | December 1983 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0930 |
| Status: | UNKNOWN |
|
This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol. |
|
| |
| RFC 892 | ISO Transport Protocol specification |
| |
| Authors: | International Organization for Standardization. |
| Date: | December 1983 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0905 |
| Status: | UNKNOWN |
|
This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date. |
|
| |
| RFC 900 | Assigned Numbers |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | June 1984 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0870 |
| Obsoleted by: | RFC 0923 |
| Status: | HISTORIC |
|
This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997. |
|
| |
| RFC 901 | Official ARPA-Internet protocols |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | June 1984 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0880 |
| Obsoleted by: | RFC 0924 |
| Status: | UNKNOWN |
|
This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991. |
|
| |
| RFC 912 | Authentication service |
| |
| Authors: | M. St. Johns. |
| Date: | September 1984 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0931 |
| Status: | UNKNOWN |
|
This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server. |
|
| |
| RFC 918 | Post Office Protocol |
| |
| Authors: | J.K. Reynolds. |
| Date: | October 1984 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0937 |
| Status: | UNKNOWN |
|
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP. |
|
| |
| RFC 923 | Assigned numbers |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | October 1984 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0900 |
| Obsoleted by: | RFC 0943 |
| Status: | HISTORIC |
|
This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997. |
|
| |
| RFC 924 | Official ARPA-Internet protocols for connecting personal computers to the Internet |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | October 1984 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0901 |
| Obsoleted by: | RFC 0944 |
| Status: | UNKNOWN |
|
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 926 | Protocol for providing the connectionless mode network services |
| |
| Authors: | International Organization for Standardization. |
| Date: | December 1984 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0994 |
| Status: | UNKNOWN |
|
This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet. |
|
| |
| RFC 930 | Telnet terminal type option |
| |
| Authors: | M. Solomon, E. Wimmers. |
| Date: | January 1985 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0884 |
| Obsoleted by: | RFC 1091 |
| Status: | UNKNOWN |
|
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation. |
|
| |
| RFC 931 | Authentication server |
| |
| Authors: | M. St. Johns. |
| Date: | January 1985 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0912 |
| Obsoleted by: | RFC 1413 |
| Status: | UNKNOWN |
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned. |
|
| |
| RFC 943 | Assigned numbers |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | April 1985 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0923 |
| Obsoleted by: | RFC 0960 |
| Status: | HISTORIC |
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 944 | Official ARPA-Internet protocols |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | April 1985 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0924 |
| Obsoleted by: | RFC 0961 |
| Status: | UNKNOWN |
|
This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 945 | DoD statement on the NRC report |
| |
| Authors: | J. Postel. |
| Date: | May 1985 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1039 |
| Status: | UNKNOWN |
|
In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only. |
|
| |
| RFC 948 | Two methods for the transmission of IP datagrams over IEEE 802.3 networks |
| |
| Authors: | I. Winston. |
| Date: | June 1985 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1042 |
| Status: | UNKNOWN |
|
This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 954 | NICNAME/WHOIS |
| |
| Authors: | K. Harrenstien, M.K. Stahl, E.J. Feinler. |
| Date: | October 1985 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0812 |
| Obsoleted by: | RFC 3912 |
| Status: | DRAFT STANDARD |
|
This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812. |
|
| |
| RFC 958 | Network Time Protocol (NTP) |
| |
|
|
This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 960 | Assigned numbers |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | December 1985 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0943 |
| Obsoleted by: | RFC 0990 |
| Status: | HISTORIC |
|
This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997. |
|
| |
| RFC 961 | Official ARPA-Internet protocols |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | December 1985 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0944 |
| Obsoleted by: | RFC 0991 |
| Status: | UNKNOWN |
|
This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991. |
|
| |
| RFC 966 | Host groups: A multicast extension to the Internet Protocol |
| |
| Authors: | S.E. Deering, D.R. Cheriton. |
| Date: | December 1985 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0988 |
| Status: | UNKNOWN |
|
This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988. |
|
| |
| RFC 969 | NETBLT: A bulk data transfer protocol |
| |
| Authors: | D.D. Clark, M.L. Lambert, L. Zhang. |
| Date: | December 1985 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0998 |
| Status: | UNKNOWN |
|
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998. |
|
| |
| RFC 973 | Domain system changes and observations |
| |
|
|
This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system. |
|
| |
| RFC 974 | Mail routing and the domain system |
| |
|
|
This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing. |
|
| |
| RFC 977 | Network News Transfer Protocol |
| |
| Authors: | B. Kantor, P. Lapsley. |
| Date: | February 1986 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3977 |
| Status: | PROPOSED STANDARD |
|
NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 983 | ISO transport arrives on top of the TCP |
| |
| Authors: | D.E. Cass, M.T. Rose. |
| Date: | April 1986 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1006 |
| Status: | UNKNOWN |
|
This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged. |
|
| |
| RFC 984 | PCMAIL: A distributed mail system for personal computers |
| |
| Authors: | D.D. Clark, M.L. Lambert. |
| Date: | May 1986 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 0993 |
| Status: | UNKNOWN |
|
This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993. |
|
| |
| RFC 985 | Requirements for Internet gateways - draft |
| |
| Authors: | National Science Foundation, Network Technical Advisory Group. |
| Date: | May 1986 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1009 |
| Status: | UNKNOWN |
|
This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification. |
|
| |
| RFC 986 | Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol |
| |
| Authors: | R.W. Callon, H.W. Braun. |
| Date: | June 1986 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1069 |
| Status: | UNKNOWN |
|
This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 987 | Mapping between X.400 and RFC 822 |
| |
|
|
The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 988 | Host extensions for IP multicasting |
| |
|
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here. |
|
| |
| RFC 989 | Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures |
| |
|
|
This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated. |
|
| |
| RFC 990 | Assigned numbers |
| |
|
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900. |
|
| |
| RFC 991 | Official ARPA-Internet protocols |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | November 1986 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0961 |
| Obsoleted by: | RFC 1011 |
| Status: | UNKNOWN |
|
This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924. |
|
| |
| RFC 993 | PCMAIL: A distributed mail system for personal computers |
| |
| Authors: | D.D. Clark, M.L. Lambert. |
| Date: | December 1986 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0984 |
| Obsoleted by: | RFC 1056 |
| Status: | UNKNOWN |
|
This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984. |
|
| |
| RFC 997 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900. |
|
| |
| RFC 999 | Requests For Comments summary notes: 900-999 |
| |
| Authors: | A. Westine, J. Postel. |
| Date: | April 1987 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0160 |
| Obsoleted by: | RFC 1000 |
| Status: | UNKNOWN |
|
|
|
| |
| RFC 1009 | Requirements for Internet gateways |
| |
| Authors: | R.T. Braden, J. Postel. |
| Date: | June 1987 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0985 |
| Obsoleted by: | RFC 1812 |
| Status: | HISTORIC |
|
This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community. |
|
| |
| RFC 1010 | Assigned numbers |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | May 1987 |
| Formats: | txt pdf |
| Obsoletes: | RFC 0990 |
| Obsoleted by: | RFC 1060 |
| Status: | HISTORIC |
|
This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations. |
|
| |
| RFC 1020 | Internet numbers |
| |
|
|
This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997. |
|
| |
| RFC 1023 | HEMS monitoring and control language |
| |
| Authors: | G. Trewitt, C. Partridge. |
| Date: | October 1987 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1076 |
| Status: | UNKNOWN |
|
This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1. |
|
| |
| RFC 1026 | Addendum to RFC 987: (Mapping between X.400 and RFC-822) |
| |
|
|
This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements. |
|
| |
| RFC 1036 | Standard for interchange of USENET messages |
| |
|
|
This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1038 | Draft revised IP security option |
| |
| Authors: | M. St. Johns. |
| Date: | January 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1108 |
| Status: | UNKNOWN |
|
This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol". |
|
| |
| RFC 1040 | Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures |
| |
|
|
This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated. |
|
| |
| RFC 1048 | BOOTP vendor information extensions |
| |
|
|
This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought. |
|
| |
| RFC 1050 | RPC: Remote Procedure Call Protocol specification |
| |
| Authors: | Sun Microsystems. |
| Date: | April 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1057 |
| Status: | HISTORIC |
|
This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time. |
|
| |
| RFC 1051 | Standard for the transmission of IP datagrams and ARP packets over ARCNET networks |
| |
| Authors: | P.A. Prindeville. |
| Date: | March 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1201 |
| Status: | HISTORIC |
|
This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community. |
|
| |
| RFC 1054 | Host extensions for IP multicasting |
| |
|
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988. |
|
| |
| RFC 1059 | Network Time Protocol (version 1) specification and implementation |
| |
|
|
This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol. |
|
| |
| RFC 1060 | Assigned numbers |
| |
|
|
This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited. |
|
| |
| RFC 1062 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community. |
|
| |
| RFC 1063 | IP MTU discovery options |
| |
| Authors: | J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie. |
| Date: | July 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1191 |
| Status: | UNKNOWN |
|
A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol. |
|
| |
| RFC 1064 | Interactive Mail Access Protocol: Version 2 |
| |
|
|
This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 1065 | Structure and identification of management information for TCP/IP-based internets |
| |
| Authors: | K. McCloghrie, M.T. Rose. |
| Date: | August 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1155 |
| Status: | STANDARD |
|
This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification. |
|
| |
| RFC 1066 | Management Information Base for network management of TCP/IP-based internets |
| |
| Authors: | K. McCloghrie, M.T. Rose. |
| Date: | August 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1156 |
| Status: | UNKNOWN |
|
This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. |
|
| |
| RFC 1067 | Simple Network Management Protocol |
| |
| Authors: | J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. |
| Date: | August 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1098 |
| Status: | UNKNOWN |
|
This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification. |
|
| |
| RFC 1072 | TCP extensions for long-delay paths |
| |
|
|
This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance. |
|
| |
| RFC 1080 | Telnet remote flow control option |
| |
| Authors: | C.L. Hedrick. |
| Date: | November 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1372 |
| Status: | UNKNOWN |
|
This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard. |
|
| |
| RFC 1081 | Post Office Protocol: Version 3 |
| |
| Authors: | M.T. Rose. |
| Date: | November 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1225 |
| Status: | UNKNOWN |
|
This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1083 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | December 1988 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1100 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. |
|
| |
| RFC 1084 | BOOTP vendor information extensions |
| |
|
|
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought. |
|
| |
| RFC 1089 | SNMP over Ethernet |
| |
| Authors: | M. Schoffstall, C. Davin, M. Fedor, J. Case. |
| Date: | February 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4789 |
| Status: | UNKNOWN |
|
This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer. |
|
| |
| RFC 1095 | Common Management Information Services and Protocol over TCP/IP (CMOT) |
| |
| Authors: | U.S. Warrier, L. Besaw. |
| Date: | April 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1189 |
| Status: | UNKNOWN |
|
This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet. |
|
| |
| RFC 1098 | Simple Network Management Protocol (SNMP) |
| |
| Authors: | J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. |
| Date: | April 1989 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1067 |
| Obsoleted by: | RFC 1157 |
| Status: | UNKNOWN |
|
This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet. |
|
| |
| RFC 1100 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | April 1989 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1083 |
| Obsoleted by: | RFC 1130 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89. |
|
| |
| RFC 1103 | Proposed standard for the transmission of IP datagrams over FDDI Networks |
| |
| Authors: | D. Katz. |
| Date: | June 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1188 |
| Status: | UNKNOWN |
|
This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK] |
|
| |
| RFC 1105 | Border Gateway Protocol (BGP) |
| |
| Authors: | K. Lougheed, Y. Rekhter. |
| Date: | June 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1163 |
| Status: | EXPERIMENTAL |
|
This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK] |
|
| |
| RFC 1106 | TCP big window and NAK options |
| |
| Authors: | R. Fox. |
| Date: | June 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6247 |
| Status: | HISTORIC |
|
Two extensions to the TCP protocol are described in this RFC in order to provide a more efficient operation over a network with a high bandwidth*delay product. The main issue that still needs to be solved is congestion versus noise. This issue is touched on in this memo, but further research is still needed on the applicability of the extensions in the Internet as a whole infrastructure and not just high bandwidth*delay product networks. Even with this outstanding issue, this document does describe the use of these options in the isolated satellite network environment to help facilitate more efficient use of this special medium to help off load bulk data transfers from links needed for interactive use. |
|
| |
| RFC 1110 | Problem with the TCP big window option |
| |
| Authors: | A.M. McKenzie. |
| Date: | August 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6247 |
| Status: | HISTORIC |
|
The TCP Big Window option discussed in RFC 1106 will not work properly in an Internet environment which has both a high bandwidth * delay product and the possibility of disordering and duplicating packets. In such networks, the window size must not be increased without a similar increase in the sequence number space. Therefore, a different approach to big windows should be taken in the Internet. |
|
| |
| RFC 1111 | Request for comments on Request for Comments: Instructions to RFC authors |
| |
|
|
This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard. |
|
| |
| RFC 1113 | Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures |
| |
|
|
This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK] |
|
| |
| RFC 1114 | Privacy enhancement for Internet electronic mail: Part II - certificate-based key management |
| |
| Authors: | S.T. Kent, J. Linn. |
| Date: | August 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1422 |
| Status: | HISTORIC |
|
This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK] |
|
| |
| RFC 1115 | Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers |
| |
| Authors: | J. Linn. |
| Date: | August 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1423 |
| Status: | HISTORIC |
|
This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK] |
|
| |
| RFC 1116 | Telnet Linemode option |
| |
| Authors: | D.A. Borman. |
| Date: | August 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1184 |
| Status: | PROPOSED STANDARD |
|
Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK] |
|
| |
| RFC 1117 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community. |
|
| |
| RFC 1119 | Network Time Protocol (version 2) specification and implementation |
| |
|
|
This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK] |
|
| |
| RFC 1120 | Internet Activities Board |
| |
| Authors: | V. Cerf. |
| Date: | September 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1160 |
| Status: | INFORMATIONAL |
|
This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. |
|
| |
| RFC 1130 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | October 1989 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1100 |
| Obsoleted by: | RFC 1140 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). |
|
| |
| RFC 1131 | OSPF specification |
| |
| Authors: | J. Moy. |
| Date: | October 1989 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 1247 |
| Status: | PROPOSED STANDARD |
|
This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK] |
|
| |
| RFC 1134 | Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links |
| |
| Authors: | D. Perkins. |
| Date: | November 1989 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1171 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:
1. A method for encapsulating datagrams over serial links.
2. An extensible Link Control Protocol (LCP).
3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP).
The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed. |
|
| |
| RFC 1138 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026. |
|
| |
| RFC 1139 | Echo function for ISO 8473 |
| |
| Authors: | R.A. Hagens. |
| Date: | January 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1574, RFC 1575 |
| Status: | PROPOSED STANDARD |
|
This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item.
When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard. |
|
| |
| RFC 1140 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | May 1990 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1130 |
| Obsoleted by: | RFC 1200 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90. |
|
| |
| RFC 1145 | TCP alternate checksum options |
| |
| Authors: | J. Zweig, C. Partridge. |
| Date: | February 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1146, RFC 6247 |
| Status: | HISTORIC |
|
This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. |
|
| |
| RFC 1146 | TCP alternate checksum options |
| |
| Authors: | J. Zweig, C. Partridge. |
| Date: | March 1990 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1145 |
| Obsoleted by: | RFC 6247 |
| Status: | HISTORIC |
|
This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145. |
|
| |
| RFC 1147 | FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices |
| |
| Authors: | R.H. Stine. |
| Date: | April 1990 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 1470 |
| Status: | INFORMATIONAL |
|
The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained. |
|
| |
| RFC 1148 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing. |
|
| |
| RFC 1150 | FYI on FYI: Introduction to the FYI Notes |
| |
| Authors: | G.S. Malkin, J.K. Reynolds. |
| Date: | March 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6360 |
| Status: | HISTORIC |
|
This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.] |
|
| |
| RFC 1154 | Encoding header field for internet messages |
| |
| Authors: | D. Robinson, R. Ullmann. |
| Date: | April 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1505 |
| Status: | EXPERIMENTAL |
|
This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement). |
|
| |
| RFC 1158 | Management Information Base for network management of TCP/IP-based internets: MIB-II |
| |
| Authors: | M.T. Rose. |
| Date: | May 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1213 |
| Status: | PROPOSED STANDARD |
|
This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK] |
|
| |
| RFC 1159 | Message Send Protocol |
| |
| Authors: | R. Nelson. |
| Date: | June 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1312 |
| Status: | EXPERIMENTAL |
|
This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol. |
|
| |
| RFC 1161 | SNMP over OSI |
| |
| Authors: | M.T. Rose. |
| Date: | June 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1418 |
| Status: | EXPERIMENTAL |
|
This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community, |
|
| |
| RFC 1162 | Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base |
| |
| Authors: | G. Satz. |
| Date: | June 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1238 |
| Status: | EXPERIMENTAL |
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community. |
|
| |
| RFC 1163 | Border Gateway Protocol (BGP) |
| |
| Authors: | K. Lougheed, Y. Rekhter. |
| Date: | June 1990 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1105 |
| Obsoleted by: | RFC 1267 |
| Status: | HISTORIC |
|
This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1164 | Application of the Border Gateway Protocol in the Internet |
| |
| Authors: | J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. |
| Date: | June 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1268 |
| Status: | HISTORIC |
|
This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1171 | Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links |
| |
| Authors: | D. Perkins. |
| Date: | July 1990 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1134 |
| Obsoleted by: | RFC 1331 |
| Status: | DRAFT STANDARD |
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts:
1. A method for encapsulating datagrams over serial links.
2. An extensible Link Control Protocol (LCP).
3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP).
The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed. |
|
| |
| RFC 1172 | Point-to-Point Protocol (PPP) initial configuration options |
| |
| Authors: | D. Perkins, R. Hobby. |
| Date: | July 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1331, RFC 1332 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of
1) a method for encapsulating datagrams over serial links,2) an extensible Link Control Protocol (LCP), and3) a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.
The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called theIP Control Protocol, IPCP) are defined in The Point-to-Point Protocol(PPP) [1].
This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme. |
|
| |
| RFC 1177 | FYI on Questions and Answers: Answers to commonly asked "new internet user" questions |
| |
| Authors: | G.S. Malkin, A.N. Marine, J.K. Reynolds. |
| Date: | August 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1206 |
| Status: | INFORMATIONAL |
|
This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.] |
|
| |
| RFC 1185 | TCP Extension for High-Speed Paths |
| |
| Authors: | V. Jacobson, R.T. Braden, L. Zhang. |
| Date: | October 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1323 |
| Status: | EXPERIMENTAL |
|
This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1186 | MD4 Message Digest Algorithm |
| |
| Authors: | R.L. Rivest. |
| Date: | October 1990 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1320 |
| Status: | INFORMATIONAL |
|
This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard. |
|
| |
| RFC 1190 | Experimental Internet Stream Protocol: Version 2 (ST-II) |
| |
| Authors: | C. Topolcic. |
| Date: | October 1990 |
| Formats: | txt pdf |
| Obsoletes: | IEN 119 |
| Obsoleted by: | RFC 1819 |
| Status: | EXPERIMENTAL |
|
This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1194 | Finger User Information Protocol |
| |
|
|
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. |
|
| |
| RFC 1196 | Finger User Information Protocol |
| |
|
|
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. |
|
| |
| RFC 1200 | IAB official protocol standards |
| |
| Authors: | Defense Advanced Research Projects Agency, Internet Activities Board. |
| Date: | April 1991 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1140 |
| Obsoleted by: | RFC 1250 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. |
|
| |
| RFC 1206 | FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions |
| |
| Authors: | G.S. Malkin, A.N. Marine. |
| Date: | February 1991 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1177 |
| Obsoleted by: | RFC 1325 |
| Status: | INFORMATIONAL |
|
This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4] |
|
| |
| RFC 1218 | Naming scheme for c=US |
| |
| Authors: | North American Directory Forum. |
| Date: | April 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1255, RFC 1417 |
| Status: | INFORMATIONAL |
|
This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1220 | Point-to-Point Protocol extensions for bridging |
| |
| Authors: | F. Baker. |
| Date: | April 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1638 |
| Status: | PROPOSED STANDARD |
|
This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK] |
|
| |
| RFC 1225 | Post Office Protocol: Version 3 |
| |
| Authors: | M.T. Rose. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1081 |
| Obsoleted by: | RFC 1460 |
| Status: | DRAFT STANDARD |
|
This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK] |
|
| |
| RFC 1228 | SNMP-DPI: Simple Network Management Protocol Distributed Program Interface |
| |
| Authors: | G. Carpenter, B. Wijnen. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1592 |
| Status: | EXPERIMENTAL |
|
This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1229 | Extensions to the generic-interface MIB |
| |
| Authors: | K. McCloghrie. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1573 |
| Updated by: | RFC 1239 |
| Status: | PROPOSED STANDARD |
|
This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS- TRACK] |
|
| |
| RFC 1231 | IEEE 802.5 Token Ring MIB |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] |
|
| |
| RFC 1232 | Definitions of managed objects for the DS1 Interface type |
| |
| Authors: | F. Baker, C.P. Kolb. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1406 |
| Updated by: | RFC 1239 |
| Status: | PROPOSED STANDARD |
|
|
|
| |
| RFC 1233 | Definitions of managed objects for the DS3 Interface type |
| |
| Authors: | T.A. Cox, K. Tesink. |
| Date: | May 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1407 |
| Updated by: | RFC 1239 |
| Status: | PROPOSED STANDARD |
|
This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1237 | Guidelines for OSI NSAP Allocation in the Internet |
| |
| Authors: | R. Colella, E. Gardner, R. Callon. |
| Date: | July 1991 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 1629 |
| Status: | PROPOSED STANDARD |
|
This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK] |
|
| |
| RFC 1243 | AppleTalk Management Information Base |
| |
| Authors: | S. Waldbusser. |
| Date: | July 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1742 |
| Status: | PROPOSED STANDARD |
|
This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1244 | Site Security Handbook |
| |
| Authors: | J.P. Holbrook, J.K. Reynolds. |
| Date: | July 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2196 |
| Status: | INFORMATIONAL |
|
This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8] |
|
| |
| RFC 1247 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1248 | OSPF Version 2 Management Information Base |
| |
| Authors: | F. Baker, R. Coltun. |
| Date: | July 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1252 |
| Updated by: | RFC 1349 |
| Status: | PROPOSED STANDARD |
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK] |
|
| |
| RFC 1250 | IAB Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1251 | Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members |
| |
| Authors: | G. Malkin. |
| Date: | August 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1336 |
| Status: | INFORMATIONAL |
|
This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9] |
|
| |
| RFC 1252 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK] |
|
| |
| RFC 1253 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK] |
|
| |
| RFC 1255 | A Naming Scheme for c=US |
| |
| Authors: | The North American Directory Forum. |
| Date: | September 1991 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1218 |
| Obsoleted by: | RFC 1417 |
| Status: | INFORMATIONAL |
|
This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1258 | BSD Rlogin |
| |
| Authors: | B. Kantor. |
| Date: | September 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1282 |
| Status: | INFORMATIONAL |
|
The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1264 | Internet Engineering Task Force Internet Routing Protocol Standardization Criteria |
| |
| Authors: | R.M. Hinden. |
| Date: | October 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4794 |
| Status: | HISTORIC |
|
This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard. |
|
| |
| RFC 1268 | Application of the Border Gateway Protocol in the Internet |
| |
| Authors: | Y. Rekhter, P. Gross. |
| Date: | October 1991 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1164 |
| Obsoleted by: | RFC 1655 |
| Status: | HISTORIC |
|
This document, together with its companion document, "A BorderGateway Protocol (BGP-3)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol (BGP-3)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (iwg@rice.edu). |
|
| |
| RFC 1269 | Definitions of Managed Objects for the Border Gateway Protocol: Version 3 |
| |
| Authors: | S. Willis, J.W. Burruss. |
| Date: | October 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4273 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1271 | Remote Network Monitoring Management Information Base |
| |
| Authors: | S. Waldbusser. |
| Date: | November 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1757 |
| Updated by: | RFC 1513 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK] |
|
| |
| RFC 1274 | The COSINE and Internet X.500 Schema |
| |
| Authors: | P. Barker, S. Kille. |
| Date: | November 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4524 |
| Status: | PROPOSED STANDARD |
|
This document suggests an X.500 Directory Schema, or NamingArchitecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema.
This document also proposes a mechanism for allowing the schema to evolve in line with emerging requirements. Proformas to support this process are included.
Corrections and additions to the schema should be sent to na- update@cs.ucl.ac.uk list, as described within. |
|
| |
| RFC 1280 | IAB Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1283 | SNMP over OSI |
| |
| Authors: | M. Rose. |
| Date: | December 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1418 |
| Status: | EXPERIMENTAL |
|
This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard. |
|
| |
| RFC 1284 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
| Authors: | J. Cook, Ed.. |
| Date: | December 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1398 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1286 | Definitions of Managed Objects for Bridges |
| |
| Authors: | E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. |
| Date: | December 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1493, RFC 1525 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK] |
|
| |
| RFC 1289 | DECnet Phase IV MIB Extensions |
| |
| Authors: | J. Saperia. |
| Date: | December 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1559 |
| Status: | PROPOSED STANDARD |
|
This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. When used in conjunction with the structure of management information (RFC 1155), the management information base for network management of TCP/IP-based internets(RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of combinedTCP/IP and DECnet Phase IV based internets. This document was produced by the DECnet Phase IV MIB working group of the InternetEngineering Task Force (IETF). |
|
| |
| RFC 1290 | There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places |
| |
| Authors: | J. Martin. |
| Date: | December 1991 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1402 |
| Status: | INFORMATIONAL |
|
This document was presented at the 1991 ACM SIGUCCS User ServicesConference. It appears here in its updated form.
There is a wealth of information on the network. In fact, so much information, that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users.
The ultimate goal is to make the route to these sources of information invisible to the user. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we can all be richer. |
|
| |
| RFC 1292 | A Catalog of Available X.500 Implementations |
| |
| Authors: | R. Lang, R. Wright. |
| Date: | January 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1632 |
| Status: | INFORMATIONAL |
|
The goal of this document is to provide information regarding the availability and capability of implementations of X.500. Comments and critiques of this document, and new or updated descriptions ofX.500 implementations are welcome. Send them to the DirectoryInformation Services Infrastructure (DISI) Working Group(disi@merit.edu) or to the editors. |
|
| |
| RFC 1293 | Inverse Address Resolution Protocol |
| |
| Authors: | T. Bradley, C. Brown. |
| Date: | January 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2390 |
| Status: | PROPOSED STANDARD |
|
This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK] |
|
| |
| RFC 1294 | Multiprotocol Interconnect over Frame Relay |
| |
| Authors: | T. Bradley, C. Brown, A. Malis. |
| Date: | January 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1490, RFC 2427 |
| Status: | PROPOSED STANDARD |
|
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK] |
|
| |
| RFC 1295 | User Bill of Rights for entries and listings in the Public Directory |
| |
| Authors: | The North American Directory Forum. |
| Date: | January 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1417 |
| Status: | INFORMATIONAL |
|
This RFC is a near-verbatim copy of a document, known as NADF-265, which has been produced by the North American Directory Forum (NADF).
User Bill of Rights for entries and listings in the Public Directory
The mission of the North American Directory Forum is to provide interconnected electronic directories which empower users with unprecedented access to public information. To address significant security and privacy issues, the North American Directory Forum introduces the following "User Bill of Rights" for entries in thePublic Directory. As a user, you have:
I. The right not to be listed.
II. The right to have you or your agent informed when your entry is created.
III. The right to examine your entry.
IV. The right to correct inaccurate information in your entry.
V. The right to remove specific information from your entry.
VI. The right to be assured that your listing in thePublic Directory will comply with US or Canadian law regulating privacy or access information.
VII. The right to expect timely fulfillment of these rights. |
|
| |
| RFC 1298 | SNMP over IPX |
| |
| Authors: | R. Wormley, S. Bostock. |
| Date: | February 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1420 |
| Status: | INFORMATIONAL |
|
This memo defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. |
|
| |
| RFC 1304 | Definitions of Managed Objects for the SIP Interface Type |
| |
| Authors: | T. Cox, K. Tesink, Eds.. |
| Date: | February 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1694 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing SIP (SMDS InterfaceProtocol) objects. |
|
| |
| RFC 1305 | Network Time Protocol (Version 3) Specification, Implementation and Analysis |
| |
|
|
This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK] |
|
| |
| RFC 1310 | The Internet Standards Process |
| |
| Authors: | L. Chapin. |
| Date: | March 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1602 |
| Status: | INFORMATIONAL |
|
This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK] |
|
| |
| RFC 1315 | Management Information Base for Frame Relay DTEs |
| |
| Authors: | C. Brown, F. Baker, C. Carvalho. |
| Date: | April 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2115 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Frame Relay. |
|
| |
| RFC 1316 | Definitions of Managed Objects for Character Stream Devices |
| |
| Authors: | B. Stewart. |
| Date: | April 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1658 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK] |
|
| |
| RFC 1317 | Definitions of Managed Objects for RS-232-like Hardware Devices |
| |
| Authors: | B. Stewart. |
| Date: | April 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1659 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK] |
|
| |
| RFC 1318 | Definitions of Managed Objects for Parallel-printer-like Hardware Devices |
| |
| Authors: | B. Stewart. |
| Date: | April 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1660 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK] |
|
| |
| RFC 1319 | The MD2 Message-Digest Algorithm |
| |
| Authors: | B. Kaliski. |
| Date: | April 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6149 |
| Status: | HISTORIC |
|
This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1320 | The MD4 Message-Digest Algorithm |
| |
|
|
This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1325 | FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions |
| |
| Authors: | G. Malkin, A. Marine. |
| Date: | May 1992 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1206 |
| Obsoleted by: | RFC 1594 |
| Status: | INFORMATIONAL |
|
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. |
|
| |
| RFC 1327 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 1988)Recommendations on Message Handling Systems / ISO IEC 10021 MessageOriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], and systems using the RFC 822 mail protocol [Crocker82a] or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings.The mappings should not require any changes to end systems. This document is a revision based on RFCs 987, 1026, 1138, and 1148[Kille86a,Kille87a] which it obsoletes.
This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on theDARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. |
|
| |
| RFC 1331 | The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links |
| |
|
|
The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating datagrams over serial links.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP encapsulation scheme, together with thePPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions.
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1333 | PPP Link Quality Monitoring |
| |
| Authors: | W. Simpson. |
| Date: | May 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1989 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link.
This document defines a protocol for generating Link-Quality-Reports.
This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1334 | PPP Authentication Protocols |
| |
| Authors: | B. Lloyd, W. Simpson. |
| Date: | October 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1994 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines two protocols for Authentication: the PasswordAuthentication Protocol and the Challenge-Handshake AuthenticationProtocol. This memo is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1338 | Supernetting: an Address Assignment and Aggregation Strategy |
| |
| Authors: | V. Fuller, T. Li, J. Yu, K. Varadhan. |
| Date: | June 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1519 |
| Status: | INFORMATIONAL |
|
This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. |
|
| |
| RFC 1340 | Assigned Numbers |
| |
| Authors: | J. Reynolds, J. Postel. |
| Date: | July 1992 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1060 |
| Obsoleted by: | RFC 1700 |
| Status: | HISTORIC |
|
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. |
|
| |
| RFC 1341 | MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies |
| |
| Authors: | N. Borenstein, N. Freed. |
| Date: | June 1992 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 1521 |
| Status: | PROPOSED STANDARD |
|
This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK] |
|
| |
| RFC 1342 | Representation of Non-ASCII Text in Internet Message Headers |
| |
| Authors: | K. Moore. |
| Date: | June 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1522 |
| Status: | PROPOSED STANDARD |
|
This memo describes an extension to the message format defined in [1](known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC822 message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1341. |
|
| |
| RFC 1348 | DNS NSAP RRs |
| |
|
|
This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1349 | Type of Service in the Internet Protocol Suite |
| |
|
|
This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK] |
|
| |
| RFC 1354 | IP Forwarding Table MIB |
| |
| Authors: | F. Baker. |
| Date: | July 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2096 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing routes in the IPInternet.
It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be deprecated and replaced with this table. This adds the ability to set or display multi-path routes, and varying routes by network management policy. |
|
| |
| RFC 1357 | A Format for E-mailing Bibliographic Records |
| |
| Authors: | D. Cohen. |
| Date: | July 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1807 |
| Status: | INFORMATIONAL |
|
This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). |
|
| |
| RFC 1358 | Charter of the Internet Architecture Board (IAB) |
| |
| Authors: | L. Chapin. |
| Date: | August 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1601 |
| Status: | INFORMATIONAL |
|
The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1360 | IAB Official Protocol Standards |
| |
| Authors: | J. Postel. |
| Date: | September 1992 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1280 |
| Obsoleted by: | RFC 1410 |
| Status: | HISTORIC |
|
|
|
| |
| RFC 1361 | Simple Network Time Protocol (SNTP) |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless RPC mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum does not obsolete or update any RFC. A working knowledge of RFC-1305 is not required for an implementation of SNTP. |
|
| |
| RFC 1362 | Novell IPX over Various WAN Media (IPXWAN) |
| |
| Authors: | M. Allen. |
| Date: | September 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1634 |
| Status: | INFORMATIONAL |
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. |
|
| |
| RFC 1364 | BGP OSPF Interaction |
| |
|
|
This memo defines the various criteria to be used when designingAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP. |
|
| |
| RFC 1366 | Guidelines for Management of IP Address Space |
| |
| Authors: | E. Gerich. |
| Date: | October 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1466 |
| Status: | INFORMATIONAL |
|
This document has been reviewed by the Federal Engineering Task Force(FEPG) on behalf of the Federal Networking Council (FNC), the co- chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. |
|
| |
| RFC 1367 | Schedule for IP Address Space Management Guidelines |
| |
| Authors: | C. Topolcic. |
| Date: | October 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1467 |
| Status: | INFORMATIONAL |
|
This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1368 | Definition of Managed Objects for IEEE 802.3 Repeater Devices |
| |
| Authors: | D. McMaster, K. McCloghrie. |
| Date: | October 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1516 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs." |
|
| |
| RFC 1374 | IP and ARP on HIPPI |
| |
| Authors: | J. Renwick, A. Nicholson. |
| Date: | October 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2834 |
| Status: | PROPOSED STANDARD |
|
The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP onHIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. |
|
| |
| RFC 1376 | The PPP DECnet Phase IV Control Protocol (DNCP) |
| |
| Authors: | S. Senum. |
| Date: | November 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1762 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuringDigital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). |
|
| |
| RFC 1379 | Extending TCP for Transactions -- Concepts |
| |
| Authors: | R. Braden. |
| Date: | November 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6247 |
| Updated by: | RFC 1644 |
| Status: | HISTORIC |
|
This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231. |
|
| |
| RFC 1384 | Naming Guidelines for Directory Pilots |
| |
| Authors: | P. Barker, S.E. Hardcastle-Kille. |
| Date: | January 1993 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 1617, RTR_0011 |
| Status: | INFORMATIONAL |
|
Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines.Alignment to these guidelines is recommended for directory pilots. |
|
| |
| RFC 1386 | The US Domain |
| |
| Authors: | A. Cooper, J. Postel. |
| Date: | December 1992 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1480 |
| Status: | INFORMATIONAL |
|
This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1387 | RIP Version 2 Protocol Analysis |
| |
| Authors: | G. Malkin. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1721 |
| Status: | INFORMATIONAL |
|
As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. |
|
| |
| RFC 1388 | RIP Version 2 Carrying Additional Information |
| |
| Authors: | G. Malkin. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1723 |
| Updates: | RFC 1058 |
| Status: | PROPOSED STANDARD |
|
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP packets and to add a measure of security.A companion document will define the SNMP MIB objects for RIP-2 [2]. |
|
| |
| RFC 1389 | RIP Version 2 MIB Extensions |
| |
| Authors: | G. Malkin, F. Baker. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1724 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing RIP Version 2. |
|
| |
| RFC 1391 | The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force |
| |
| Authors: | G. Malkin. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1539 |
| Status: | INFORMATIONAL |
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1392 | Internet Users' Glossary |
| |
| Authors: | G. Malkin, T. LaQuey Parker. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1983 |
| Status: | INFORMATIONAL |
|
There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them. |
|
| |
| RFC 1395 | BOOTP Vendor Information Extensions |
| |
|
|
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP). |
|
| |
| RFC 1398 | Definitions of Managed Objects for the Ethernet-Like Interface Types |
| |
| Authors: | F. Kastenholz. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1284 |
| Obsoleted by: | RFC 1623 |
| Status: | DRAFT STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing ethernet-like objects. |
|
| |
| RFC 1404 | A Model for Common Operational Statistics |
| |
| Authors: | B. Stockman. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1857 |
| Status: | INFORMATIONAL |
|
This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. |
|
| |
| RFC 1405 | Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) |
| |
| Authors: | C. Allocchio. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2162 |
| Status: | EXPERIMENTAL |
|
This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 )Recommendations on Message Handling Systems, and systems running theMail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme.
The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC 1327 and its eventual future updates.
This is a combined effort of COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working Group. |
|
| |
| RFC 1406 | Definitions of Managed Objects for the DS1 and E1 Interface Types |
| |
| Authors: | F. Baker, J. Watt, Eds.. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1232 |
| Obsoleted by: | RFC 2495 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links.
This document entirely replaces RFC 1232, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1232 should not be implemented. |
|
| |
| RFC 1407 | Definitions of Managed Objects for the DS3/E3 Interface Type |
| |
| Authors: | T. Cox, K. Tesink. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1233 |
| Obsoleted by: | RFC 2496 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3Interfaces. This document is a companion document with Definitions of Managed Objects for the DS1 Interface Type.
This document entirely replaces RFC 1233, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1233 should not be implemented. |
|
| |
| RFC 1409 | Telnet Authentication Option |
| |
| Authors: | D. Borman, Ed.. |
| Date: | January 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1416 |
| Status: | EXPERIMENTAL |
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1410 | IAB Official Protocol Standards |
| |
| Authors: | J. Postel, Ed.. |
| Date: | March 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1360 |
| Obsoleted by: | RFC 1500 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). |
|
| |
| RFC 1416 | Telnet Authentication Option |
| |
| Authors: | D. Borman, Ed.. |
| Date: | February 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1409 |
| Obsoleted by: | RFC 2941 |
| Status: | EXPERIMENTAL |
|
This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1417 | NADF Standing Documents: A Brief Overview |
| |
|
|
The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1425 | SMTP Service Extensions |
| |
| Authors: | J. Klensin, WG Chair, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1651 |
| Status: | PROPOSED STANDARD |
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1426 | SMTP Service Extension for 8bit-MIMEtransport |
| |
| Authors: | J. Klensin, WG Chair, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1652 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex |
|
| |
| RFC 1427 | SMTP Service Extension for Message Size Declaration |
| |
| Authors: | J. Klensin, WG Chair, N. Freed, Ed., K. Moore. |
| Date: | February 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1653 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK] |
|
| |
| RFC 1434 | Data Link Switching: Switch-to-Switch Protocol |
| |
| Authors: | R. Dixon, D. Kushi. |
| Date: | March 1993 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 1795 |
| Status: | INFORMATIONAL |
|
This RFC describes IBM's support of Data Link Switching over TCP/IP.The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.
Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: dlsw@ralvma.vnet.ibm.com. |
|
| |
| RFC 1442 | Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1902 |
| Status: | PROPOSED STANDARD |
|
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK] |
|
| |
| RFC 1443 | Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1903 |
| Status: | PROPOSED STANDARD |
|
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] |
|
| |
| RFC 1444 | Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1904 |
| Status: | PROPOSED STANDARD |
|
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] |
|
| |
| RFC 1448 | Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1905 |
| Status: | PROPOSED STANDARD |
|
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK] |
|
| |
| RFC 1449 | Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1906 |
| Status: | PROPOSED STANDARD |
|
It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK] |
|
| |
| RFC 1450 | Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1907 |
| Status: | PROPOSED STANDARD |
|
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] |
|
| |
| RFC 1452 | Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1908 |
| Status: | PROPOSED STANDARD |
|
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK] |
|
| |
| RFC 1455 | Physical Link Security Type of Service |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | May 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2474 |
| Status: | EXPERIMENTAL |
|
This RFC documents an experimental protocol providing a Type ofService (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type ofService in the Internet Protocol Suite. The new TOS requests the network to provide what protection it can against surreptitious observation by outside agents of traffic so labeled. The purpose is protection against traffic analysis and as an additional possible level of data confidentiality. This TOS is consistent with all other defined types of service for IP version 4 in that it is based on link level characteristics and will not provide any particular guaranteed level of service. |
|
| |
| RFC 1460 | Post Office Protocol - Version 3 |
| |
| Authors: | M. Rose. |
| Date: | June 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1225 |
| Obsoleted by: | RFC 1725 |
| Status: | DRAFT STANDARD |
|
This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS- TRACK] |
|
| |
| RFC 1466 | Guidelines for Management of IP Address Space |
| |
| Authors: | E. Gerich. |
| Date: | May 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1366 |
| Obsoleted by: | RFC 2050 |
| Status: | INFORMATIONAL |
|
This document has been reviewed by the Federal Engineering PlanningGroup (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. |
|
| |
| RFC 1483 | Multiprotocol Encapsulation over ATM Adaptation Layer 5 |
| |
| Authors: | Juha Heinanen. |
| Date: | July 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2684 |
| Status: | PROPOSED STANDARD |
|
This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit. |
|
| |
| RFC 1484 | Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)) |
| |
|
|
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability
This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [HK93], and it is intended that these specifications are compatible. Please send comments to the author or to the discussion group: <osi-ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1485 | A String Representation of Distinguished Names (OSI-DS 23 (v5)) |
| |
|
|
The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. Please send comments to the author or to the discussion group <osi-ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1486 | An Experiment in Remote Printing |
| |
| Authors: | M. Rose, C. Malamud. |
| Date: | July 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1528, RFC 1529 |
| Status: | EXPERIMENTAL |
|
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1487 | X.500 Lightweight Directory Access Protocol |
| |
| Authors: | W. Yeong, T. Howes, S. Kille. |
| Date: | July 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1777, RFC 3494 |
| Status: | HISTORIC |
|
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of theDirectory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the Directory, and is intended to be a complement to the DAP itself.
Key aspects of LDAP are:
- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.
- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).
- A lightweight BER encoding is used to encode all protocol elements. |
|
| |
| RFC 1488 | The X.500 String Representation of Standard Attribute Syntaxes |
| |
| Authors: | T. Howes, S. Kille, W. Yeong, C. Robbins. |
| Date: | July 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1778 |
| Status: | PROPOSED STANDARD |
|
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. |
|
| |
| RFC 1490 | Multiprotocol Interconnect over Frame Relay |
| |
| Authors: | T. Bradley, C. Brown, A. Malis. |
| Date: | July 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1294 |
| Obsoleted by: | RFC 2427 |
| Status: | DRAFT STANDARD |
|
This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU.
Systems with the ability to transfer both the encapsulation method described in this document, and others must have a priori knowledge of which virtual circuits will carry which encapsulation method and this encapsulation must only be used over virtual circuits that have been explicitly configured for its use. |
|
| |
| RFC 1493 | Definitions of Managed Objects for Bridges |
| |
| Authors: | E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. |
| Date: | July 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1286 |
| Obsoleted by: | RFC 4188 |
| Status: | DRAFT STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging.Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. |
|
| |
| RFC 1495 | Mapping between X.400 and RFC-822 Message Bodies |
| |
| Authors: | H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson. |
| Date: | August 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2156 |
| Updates: | RFC 1327 |
| Status: | PROPOSED STANDARD |
|
Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK] |
|
| |
| RFC 1497 | BOOTP Vendor Information Extensions |
| |
|
|
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP). |
|
| |
| RFC 1500 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1508 | Generic Security Service Application Program Interface |
| |
| Authors: | J. Linn. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2078 |
| Status: | PROPOSED STANDARD |
|
This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms |
|
| |
| RFC 1509 | Generic Security Service API : C-bindings |
| |
| Authors: | J. Wray. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2744 |
| Status: | PROPOSED STANDARD |
|
This document specifies C language bindings for the Generic SecurityService Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents.
The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. |
|
| |
| RFC 1510 | The Kerberos Network Authentication Service (V5) |
| |
| Authors: | J. Kohl, C. Neuman. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4120 |
| Status: | PROPOSED STANDARD |
|
This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT'sProject Athena, and at other Internet sites. |
|
| |
| RFC 1514 | Host Resources MIB |
| |
| Authors: | P. Grillo, S. Waldbusser. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2790 |
| Status: | PROPOSED STANDARD |
|
This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. |
|
| |
| RFC 1515 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
| Authors: | D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3Medium Attachment Units (MAUs). |
|
| |
| RFC 1516 | Definitions of Managed Objects for IEEE 802.3 Repeater Devices |
| |
| Authors: | D. McMaster, K. McCloghrie. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1368 |
| Obsoleted by: | RFC 2108 |
| Status: | DRAFT STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs." |
|
| |
| RFC 1519 | Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy |
| |
| Authors: | V. Fuller, T. Li, J. Yu, K. Varadhan. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1338 |
| Obsoleted by: | RFC 4632 |
| Status: | PROPOSED STANDARD |
|
This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. |
|
| |
| RFC 1521 | MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies |
| |
|
|
STD 11, RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC822.
In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi- font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents.
This document does NOT extend Internet mail header fields to permit anything other than US-ASCII text data. Such extensions are the subject of a companion document [RFC-1522].
This document is a revision of RFC 1341. Significant differences from RFC 1341 are summarized in Appendix H. |
|
| |
| RFC 1522 | MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text |
| |
|
|
This memo describes an extension to the message format defined in RFC1521 [1], to allow the representation of character sets other thanASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521. |
|
| |
| RFC 1523 | The text/enriched MIME Content-type |
| |
| Authors: | N. Borenstein. |
| Date: | September 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1563, RFC 1896 |
| Status: | INFORMATIONAL |
|
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. |
|
| |
| RFC 1531 | Dynamic Host Configuration Protocol |
| |
| Authors: | R. Droms. |
| Date: | October 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1541 |
| Status: | PROPOSED STANDARD |
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. |
|
| |
| RFC 1532 | Clarifications and Extensions for the Bootstrap Protocol |
| |
| Authors: | W. Wimer. |
| Date: | October 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1542 |
| Updates: | RFC 0951 |
| Status: | PROPOSED STANDARD |
|
Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas.
In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these. |
|
| |
| RFC 1533 | DHCP Options and BOOTP Vendor Extensions |
| |
|
|
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the "options" field of the DHCP message. The data items themselves are also called"options."
This document specifies the current set of DHCP options. This document will be periodically updated as new options are defined.Each superseding document will include the entire current list of valid options.
All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions. |
|
| |
| RFC 1537 | Common DNS Data File Configuration Errors |
| |
| Authors: | P. Beertema. |
| Date: | October 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1912 |
| Status: | INFORMATIONAL |
|
This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. |
|
| |
| RFC 1539 | The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force |
| |
| Authors: | G. Malkin. |
| Date: | October 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1391 |
| Obsoleted by: | RFC 1718 |
| Status: | INFORMATIONAL |
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1540 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1541 | Dynamic Host Configuration Protocol |
| |
| Authors: | R. Droms. |
| Date: | October 1993 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1531 |
| Obsoleted by: | RFC 2131 |
| Status: | PROPOSED STANDARD |
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Due to some errors introduced into RFC1531 in the editorial process, this memo is reissued as RFC 1541. |
|
| |
| RFC 1543 | Instructions to RFC Authors |
| |
|
|
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1544 | The Content-MD5 Header Field |
| |
| Authors: | M. Rose. |
| Date: | November 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1864 |
| Status: | PROPOSED STANDARD |
|
This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. |
|
| |
| RFC 1545 | FTP Operation Over Big Address Records (FOOBAR) |
| |
| Authors: | D. Piscitello. |
| Date: | November 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1639 |
| Status: | EXPERIMENTAL |
|
This paper describes a convention for specifying longer addresses in the PORT command. |
|
| |
| RFC 1548 | The Point-to-Point Protocol (PPP) |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1549 | PPP in HDLC Framing |
| |
| Authors: | W. Simpson, Ed.. |
| Date: | December 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1662 |
| Status: | DRAFT STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC for framing PPP encapsulated packets. This document is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1551 | Novell IPX Over Various WAN Media (IPXWAN) |
| |
| Authors: | M. Allen. |
| Date: | December 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1634 |
| Status: | INFORMATIONAL |
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and adds capability forUnnumbered RIP links, On-demand statically routed links and client to router connectivity. |
|
| |
| RFC 1558 | A String Representation of LDAP Search Filters |
| |
| Authors: | T. Howes. |
| Date: | December 1993 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1960 |
| Status: | INFORMATIONAL |
|
The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. |
|
| |
| RFC 1563 | The text/enriched MIME Content-type |
| |
| Authors: | N. Borenstein. |
| Date: | January 1994 |
| Formats: | txt pdf ps |
| Obsoletes: | RFC 1523 |
| Obsoleted by: | RFC 1896 |
| Status: | INFORMATIONAL |
|
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. |
|
| |
| RFC 1565 | Network Services Monitoring MIB |
| |
| Authors: | S. Kille, N. Freed. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2248 |
| Status: | PROPOSED STANDARD |
|
This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK] |
|
| |
| RFC 1566 | Mail Monitoring MIB |
| |
| Authors: | S. Kille, N. Freed. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2249, RFC 2789 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK] |
|
| |
| RFC 1567 | X.500 Directory Monitoring MIB |
| |
| Authors: | G. Mansfield, S. Kille. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2605 |
| Status: | PROPOSED STANDARD |
|
This document defines a portion of the Management Information Base(MIB). It defines the MIB for monitoring Directory System Agents(DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. |
|
| |
| RFC 1568 | Simple Network Paging Protocol - Version 1(b) |
| |
| Authors: | A. Gwinn. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1645 |
| Status: | INFORMATIONAL |
|
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months in one nationwide paging firm. One other paging firm is in the process of adopting it.
Earlier versions of this specification were reviewed by IESG members and the IETF's "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETFWork", below. |
|
| |
| RFC 1569 | Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures |
| |
| Authors: | M. Rose. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1703 |
| Status: | INFORMATIONAL |
|
This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1573 | Evolution of the Interfaces Group of MIB-II |
| |
| Authors: | K. McCloghrie, F. Kastenholz. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1229 |
| Obsoleted by: | RFC 2233 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK] |
|
| |
| RFC 1577 | Classical IP and ARP over ATM |
| |
| Authors: | M. Laubach. |
| Date: | January 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2225 |
| Status: | PROPOSED STANDARD |
|
This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connectingIP end-stations ("members") and routers operating in the "classical"LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper.
This memo introduces general ATM technology and nomenclature.Readers are encouraged to review the ATM Forum and ITU-TS (formerlyCCITT) references for more detailed information about ATM implementation agreements and standards. |
|
| |
| RFC 1578 | FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions |
| |
| Authors: | J. Sellers. |
| Date: | February 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1941 |
| Status: | INFORMATIONAL |
|
The goal of this FYI RFC, produced by the Internet School Networking(ISN) group in the User Services Area of the Internet EngineeringTask Force (IETF), is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. It is directed at educators, school media specialists, and school administrators who are recently connected to the Internet, who are accessing the Internet via dial-up or another means which is not a direct connection, or who are considering an Internet connection as a resource for their schools. |
|
| |
| RFC 1583 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. Separate routes can be calculated for each IP Type of Service. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in AppendixE. The differences consist of bug fixes and clarifications, and are backward-compatible in nature. Implementations of RFC 1247 and of this memo will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 1587 | The OSPF NSSA Option |
| |
| Authors: | R. Coltun, V. Fuller. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3101 |
| Status: | PROPOSED STANDARD |
|
This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK] |
|
| |
| RFC 1590 | Media Type Registration Procedure |
| |
|
|
Several protocols allow the use of data representing different"media" such as text, images, audio, and video, and within such media different encoding styles, such as (in video) jpeg, gif, ief, and tiff. The Multimedia Internet Message Extensions (MIME) protocol [1] defined several initial types of multimedia data objects, and a procedure for registering additional types with the Internet AssignedNumbers Authority (IANA). Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content- type/subtypes). It also generalizes the scope of use of these MediaTypes to make it appropriate to use the same registrations and specifications with other applications. |
|
| |
| RFC 1594 | FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions |
| |
| Authors: | A. Marine, J. Reynolds, G. Malkin. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1325 |
| Obsoleted by: | RFC 2664 |
| Status: | INFORMATIONAL |
|
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. |
|
| |
| RFC 1595 | Definitions of Managed Objects for the SONET/SDH Interface Type |
| |
| Authors: | T. Brown, K. Tesink. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2558 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407[13].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. |
|
| |
| RFC 1596 | Definitions of Managed Objects for Frame Relay Service |
| |
| Authors: | T. Brown, Ed.. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1604 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service. |
|
| |
| RFC 1597 | Address Allocation for Private Internets |
| |
| Authors: | Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
|
This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1600 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1601 | Charter of the Internet Architecture Board (IAB) |
| |
| Authors: | C. Huitema. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1358 |
| Obsoleted by: | RFC 2850 |
| Status: | INFORMATIONAL |
|
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. |
|
| |
| RFC 1602 | The Internet Standards Process -- Revision 2 |
| |
| Authors: | Internet Architecture Board, Internet Engineering Steering Group. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1310 |
| Obsoleted by: | RFC 2026 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
|
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.
This revision (revision 2) includes the following major changes:
(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.
(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).
(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.
(d) An appeals procedure is added (Section 3.6).
(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.
(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C. |
|
| |
| RFC 1603 | IETF Working Group Guidelines and Procedures |
| |
| Authors: | E. Huizer, D. Crocker. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2418 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined. |
|
| |
| RFC 1604 | Definitions of Managed Objects for Frame Relay Service |
| |
| Authors: | T. Brown, Ed.. |
| Date: | March 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1596 |
| Obsoleted by: | RFC 2954 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service. |
|
| |
| RFC 1610 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1619 | PPP over SONET/SDH |
| |
| Authors: | W. Simpson. |
| Date: | May 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2615 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Heirarchy (SDH) circuits.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. |
|
| |
| RFC 1623 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1626 | Default IP MTU for use over ATM AAL5 |
| |
| Authors: | R. Atkinson. |
| Date: | May 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2225 |
| Status: | PROPOSED STANDARD |
|
There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK] |
|
| |
| RFC 1627 | Network 10 Considered Harmful (Some Practices Shouldn't be Codified) |
| |
| Authors: | E. Lear, E. Fair, D. Crocker, T. Kessler. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
|
This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1631 | The IP Network Address Translator (NAT) |
| |
| Authors: | K. Egevang, P. Francis. |
| Date: | May 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3022 |
| Status: | INFORMATIONAL |
|
The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.
It is possible that CIDR will not be adequate to maintain the IPInternet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complementsCIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons. |
|
| |
| RFC 1632 | A Revised Catalog of Available X.500 Implementations |
| |
| Authors: | A. Getchell, S. Sataluri, Eds.. |
| Date: | May 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1292 |
| Obsoleted by: | RFC 2116 |
| Status: | INFORMATIONAL |
|
This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor inRFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions.
This document contains detailed description of twenty six (26) X.500 implementations - DSAs, DUAs, and DUA interfaces. |
|
| |
| RFC 1637 | DNS NSAP Resource Records |
| |
| Authors: | B. Manning, R. Colella. |
| Date: | June 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1348 |
| Obsoleted by: | RFC 1706 |
| Status: | EXPERIMENTAL |
|
The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain NameSystem (DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format. This document supercedes RFC 1348.
NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation. |
|
| |
| RFC 1638 | PPP Bridging Control Protocol (BCP) |
| |
| Authors: | F. Baker, R. Bowen. |
| Date: | June 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1220 |
| Obsoleted by: | RFC 2878 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. |
|
| |
| RFC 1642 | UTF-7 - A Mail-Safe Transformation Format of Unicode |
| |
| Authors: | D. Goldsmith, M. Davis. |
| Date: | July 1994 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 2152 |
| Status: | EXPERIMENTAL |
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of RFC 1521, RFC 1522, and the document "Using Unicode with MIME". |
|
| |
| RFC 1643 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
| Authors: | F. Kastenholz. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1623 |
| Obsoleted by: | RFC 3638 |
| Status: | HISTORIC |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1644 | T/TCP -- TCP Extensions for Transactions Functional Specification |
| |
|
|
This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This backwards-compatible extension could fill the gap between the current connection-oriented TCP and the datagram-based UDP.
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231. |
|
| |
| RFC 1645 | Simple Network Paging Protocol - Version 2 |
| |
| Authors: | A. Gwinn. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1568 |
| Obsoleted by: | RFC 1861 |
| Status: | INFORMATIONAL |
|
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging. In addition, email filters and SNPP client software for Unix and Windows are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below. |
|
| |
| RFC 1647 | TN3270 Enhancements |
| |
| Authors: | B. Kelly. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2355 |
| Status: | PROPOSED STANDARD |
|
This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new TelnetOption and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1]. |
|
| |
| RFC 1650 | Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 |
| |
| Authors: | F. Kastenholz. |
| Date: | August 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2358 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1651 | SMTP Service Extensions |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1425 |
| Obsoleted by: | RFC 1869 |
| Status: | DRAFT STANDARD |
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1652 | SMTP Service Extension for 8bit-MIMEtransport |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1426 |
| Obsoleted by: | RFC 6152 |
| Status: | DRAFT STANDARD |
|
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. |
|
| |
| RFC 1653 | SMTP Service Extension for Message Size Declaration |
| |
| Authors: | J. Klensin, N. Freed, K. Moore. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1427 |
| Obsoleted by: | RFC 1870 |
| Status: | DRAFT STANDARD |
|
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. |
|
| |
| RFC 1654 | A Border Gateway Protocol 4 (BGP-4) |
| |
| Authors: | Y. Rekhter, T. Li, Eds.. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1771 |
| Status: | PROPOSED STANDARD |
|
This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1655 | Application of the Border Gateway Protocol in the Internet |
| |
| Authors: | Y. Rekhter, P. Gross, Eds.. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1268 |
| Obsoleted by: | RFC 1772 |
| Status: | PROPOSED STANDARD |
|
This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net). |
|
| |
| RFC 1656 | BGP-4 Protocol Document Roadmap and Implementation Experience |
| |
| Authors: | P. Traina. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1773 |
| Status: | INFORMATIONAL |
|
Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1657 | Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 |
| |
| Authors: | S. Willis, J. Burruss, J. Chu, Ed.. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4273 |
| Status: | DRAFT STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK] |
|
| |
| RFC 1664 | Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables |
| |
| Authors: | C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. |
| Date: | August 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2163 |
| Status: | EXPERIMENTAL |
|
This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail andMessaging working group (WG-MSG). |
|
| |
| RFC 1665 | Definitions of Managed Objects for SNA NAUs using SMIv2 |
| |
| Authors: | Z. Kielczewski, D. Kostick, K. Shih, Eds.. |
| Date: | July 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1666 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK] |
|
| |
| RFC 1693 | An Extension to TCP : Partial Order Service |
| |
| Authors: | T. Connolly, P. Amer, P. Conrad. |
| Date: | November 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6247 |
| Status: | HISTORIC |
|
This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. Distribution of this memo is unlimited. |
|
| |
| RFC 1695 | Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 |
| |
| Authors: | M. Ahmed, K. Tesink, Eds.. |
| Date: | August 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2515 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK] |
|
| |
| RFC 1700 | Assigned Numbers |
| |
| Authors: | J. Reynolds, J. Postel. |
| Date: | October 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1340 |
| Obsoleted by: | RFC 3232 |
| Status: | HISTORIC |
|
This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. |
|
| |
| RFC 1714 | Referral Whois Protocol (RWhois) |
| |
| Authors: | S. Williamson, M. Kosters. |
| Date: | November 1994 |
| Formats: | txt pdf ps |
| Obsoleted by: | RFC 2167 |
| Status: | INFORMATIONAL |
|
This memo describes version 1.0 of the client/server interaction ofRWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information. |
|
| |
| RFC 1716 | Towards Requirements for IP Routers |
| |
| Authors: | P. Almquist, F. Kastenholz. |
| Date: | November 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1812 |
| Status: | INFORMATIONAL |
|
The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1717 | The PPP Multilink Protocol (MP) |
| |
| Authors: | K. Sklower, B. Lloyd, G. McGregor, D. Carr. |
| Date: | November 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1990 |
| Status: | PROPOSED STANDARD |
|
This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols. |
|
| |
| RFC 1718 | The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force |
| |
| Authors: | IETF Secretariat, G. Malkin. |
| Date: | November 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1539 |
| Obsoleted by: | RFC 3160 |
| Status: | INFORMATIONAL |
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) plenary meetings has grown phenomenally. Approximately one third of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought provoking e-mail messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1720 | Internet Official Protocol Standards |
| |
| Authors: | J. Postel. |
| Date: | November 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1610 |
| Obsoleted by: | RFC 1780 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1723 | RIP Version 2 - Carrying Additional Information |
| |
|
|
This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1,2], to expand the amount of useful information carried in RIP messages and to add a measure of security.This memo obsoletes RFC 1388, which specifies an update to the"Routing Information Protocol" STD 34, RFC 1058.
The RIP-2 protocol analysis is documented in RFC 1721 [4].
The RIP-2 applicability statement is document in RFC 1722 [5].
The RIP-2 MIB description is defined in RFC 1724 [3]. This memo obsoletes RFC 1389. |
|
| |
| RFC 1725 | Post Office Protocol - Version 3 |
| |
| Authors: | J. Myers, M. Rose. |
| Date: | November 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1460 |
| Obsoleted by: | RFC 1939 |
| Status: | STANDARD |
|
This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK] |
|
| |
| RFC 1730 | Internet Message Access Protocol - Version 4 |
| |
| Authors: | M. Crispin. |
| Date: | December 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2060, RFC 2061 |
| Status: | PROPOSED STANDARD |
|
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server.IMAP4 permits manipulation of remote message folders, called"mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers.These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous).
IMAP4 supports a single server. A mechanism for supporting multipleIMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.Compatibility issues are discussed in [IMAP-COMPAT]. |
|
| |
| RFC 1734 | POP3 AUTHentication command |
| |
| Authors: | J. Myers. |
| Date: | December 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5034 |
| Status: | PROPOSED STANDARD |
|
This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK] |
|
| |
| RFC 1738 | Uniform Resource Locators (URL) |
| |
|
|
This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. |
|
| |
| RFC 1739 | A Primer On Internet and TCP/IP Tools |
| |
| Authors: | G. Kessler, S. Shepard. |
| Date: | December 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2151 |
| Status: | INFORMATIONAL |
|
This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1743 | IEEE 802.5 MIB using SMIv2 |
| |
| Authors: | K. McCloghrie, E. Decker. |
| Date: | December 1994 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1231 |
| Obsoleted by: | RFC 1748 |
| Status: | DRAFT STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK] |
|
| |
| RFC 1750 | Randomness Recommendations for Security |
| |
| Authors: | D. Eastlake 3rd, S. Crocker, J. Schiller. |
| Date: | December 1994 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4086 |
| Status: | INFORMATIONAL |
|
Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available. And it gives examples of how large such quantities need to be for some particular applications. |
|
| |
| RFC 1757 | Remote Network Monitoring Management Information Base |
| |
| Authors: | S. Waldbusser. |
| Date: | February 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1271 |
| Obsoleted by: | RFC 2819 |
| Status: | DRAFT STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices. |
|
| |
| RFC 1759 | Printer MIB |
| |
| Authors: | R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3805 |
| Status: | PROPOSED STANDARD |
|
A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK] |
|
| |
| RFC 1766 | Tags for the Identification of Languages |
| |
| Authors: | H. Alvestrand. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3066, RFC 3282 |
| Status: | PROPOSED STANDARD |
|
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object.
It also defines a Content-language: header, for use in the case where one desires to indicate the language of something that has RFC-822- like headers, like MIME body parts or Web documents, and a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header. |
|
| |
| RFC 1769 | Simple Network Time Protocol (SNTP) |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It can operate in both unicast modes (point to point) and broadcast modes (point to multipoint). It can also operate in IP multicast mode where this service is available. SNTP involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum obsoletes RFC-1361 of the same title. Its purpose is to explain the protocol model for operation in broadcast mode, to provide additional clarification in some places and to correct a few typographical errors. A working knowledge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP.Distribution of this memorandum is unlimited. |
|
| |
| RFC 1771 | A Border Gateway Protocol 4 (BGP-4) |
| |
| Authors: | Y. Rekhter, T. Li. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1654 |
| Obsoleted by: | RFC 4271 |
| Status: | DRAFT STANDARD |
|
This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet. |
|
| |
| RFC 1777 | Lightweight Directory Access Protocol |
| |
| Authors: | W. Yeong, T. Howes, S. Kille. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1487 |
| Obsoleted by: | RFC 3494 |
| Status: | HISTORIC |
|
The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500Directory, and is intended to be a complement to the DAP itself.
Key aspects of LDAP are:
- Protocol elements are carried directly over TCP or other transport, bypassing much of the session/presentation overhead.
- Many protocol data elements are encoding as ordinary strings (e.g.,Distinguished Names).
- A lightweight BER encoding is used to encode all protocol elements. |
|
| |
| RFC 1778 | The String Representation of Standard Attribute Syntaxes |
| |
| Authors: | T. Howes, S. Kille, W. Yeong, C. Robbins. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1488 |
| Obsoleted by: | RFC 3494 |
| Updated by: | RFC 2559 |
| Status: | HISTORIC |
|
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. |
|
| |
| RFC 1779 | A String Representation of Distinguished Names |
| |
|
|
The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1.When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name.This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. |
|
| |
| RFC 1780 | Internet Official Protocol Standards |
| |
| Authors: | J. Postel, Ed.. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1720 |
| Obsoleted by: | RFC 1800 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1781 | Using the OSI Directory to Achieve User Friendly Naming |
| |
|
|
The OSI Directory has user friendly naming as a goal. A simple minded usage of the directory does not achieve this. Two aspects not achieved are: o A user oriented notation o Guessability
This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them.This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in [5], and it is intended that these specifications are compatible. |
|
| |
| RFC 1782 | TFTP Option Extension |
| |
| Authors: | G. Malkin, A. Harkin. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2347 |
| Updates: | RFC 1350 |
| Status: | PROPOSED STANDARD |
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. |
|
| |
| RFC 1783 | TFTP Blocksize Option |
| |
| Authors: | G. Malkin, A. Harkin. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2348 |
| Updates: | RFC 1350 |
| Status: | PROPOSED STANDARD |
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-byte blocksize is not the most efficient for use on a LAN whose MTU may 1500 bytes or greater.
This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2]. |
|
| |
| RFC 1784 | TFTP Timeout Interval and Transfer Size Options |
| |
| Authors: | G. Malkin, A. Harkin. |
| Date: | March 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2349 |
| Updates: | RFC 1350 |
| Status: | PROPOSED STANDARD |
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.
This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2].
This document assumes that the reader is familiar with the terminology and notation of both [1] and [2]. |
|
| |
| RFC 1798 | Connection-less Lightweight X.500 Directory Access Protocol |
| |
| Authors: | A. Young. |
| Date: | June 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3352 |
| Status: | HISTORIC |
|
The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK] |
|
| |
| RFC 1800 | Internet Official Protocol Standards |
| |
| Authors: | J. Postel, Ed.. |
| Date: | July 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1780 |
| Obsoleted by: | RFC 1880 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1806 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header |
| |
| Authors: | R. Troost, S. Dorner. |
| Date: | June 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2183 |
| Status: | EXPERIMENTAL |
|
This memo provides a mechanism whereby messages conforming to the[RFC 1521] ("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for any [RFC 1521] entity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such, the reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The information presented herein supplements but does not replace that found in those documents. |
|
| |
| RFC 1808 | Relative Uniform Resource Locators |
| |
|
|
A Uniform Resource Locator (URL) is a compact representation of the location and access method for a resource available via the Internet.When embedded within a base document, a URL in its absolute form may contain a great deal of information which is already known from the context of that base document's retrieval, including the scheme, network location, and parts of the url-path. In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative UniformResource Locators. |
|
| |
| RFC 1811 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | June 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1816 |
| Status: | INFORMATIONAL |
|
This document describes the registration policies for the top-level domain ".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1816 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1811 |
| Obsoleted by: | RFC 2146 |
| Status: | INFORMATIONAL |
|
This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for.GOV can be fit. This policy is exactly comparable to that for the top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1820 | Multimedia E-mail (MIME) User Agent Checklist |
| |
| Authors: | E. Huizer. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1844 |
| Status: | INFORMATIONAL |
|
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. |
|
| |
| RFC 1825 | Security Architecture for the Internet Protocol |
| |
| Authors: | R. Atkinson. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2401 |
| Status: | PROPOSED STANDARD |
|
This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS- TRACK] |
|
| |
| RFC 1826 | IP Authentication Header |
| |
| Authors: | R. Atkinson. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2402 |
| Status: | PROPOSED STANDARD |
|
This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK] |
|
| |
| RFC 1827 | IP Encapsulating Security Payload (ESP) |
| |
| Authors: | R. Atkinson. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2406 |
| Status: | PROPOSED STANDARD |
|
This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK] |
|
| |
| RFC 1830 | SMTP Service Extensions for Transmission of Large and Binary MIME Messages |
| |
| Authors: | G. Vaudreuil. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3030 |
| Status: | EXPERIMENTAL |
|
This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1831 | RPC: Remote Procedure Call Protocol Specification Version 2 |
| |
| Authors: | R. Srinivasan. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5531 |
| Status: | PROPOSED STANDARD |
|
This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] |
|
| |
| RFC 1832 | XDR: External Data Representation Standard |
| |
| Authors: | R. Srinivasan. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4506 |
| Status: | DRAFT STANDARD |
|
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK] |
|
| |
| RFC 1836 | Representing the O/R Address hierarchy in the X.500 Directory Information Tree |
| |
| Authors: | S. Kille. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2294 |
| Status: | EXPERIMENTAL |
|
This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including: |
|
| |
| RFC 1837 | Representing Tables and Subtrees in the X.500 Directory |
| |
| Authors: | S. Kille. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2293 |
| Status: | EXPERIMENTAL |
|
This document defines techniques for representing two types of information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might be done in a table lookup.
2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability. |
|
| |
| RFC 1838 | Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses |
| |
| Authors: | S. Kille. |
| Date: | August 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2164 |
| Status: | EXPERIMENTAL |
|
This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. |
|
| |
| RFC 1849 | "Son of 1036": News Article Format and Transmission |
| |
|
|
By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adoptedProposed Standards for Netnews.
It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. |
|
| |
| RFC 1850 | OSPF Version 2 Management Information Base |
| |
| Authors: | F. Baker, R. Coltun. |
| Date: | November 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1253 |
| Obsoleted by: | RFC 4750 |
| Status: | DRAFT STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Open Shortest PathFirst Routing Protocol. |
|
| |
| RFC 1852 | IP Authentication using Keyed SHA |
| |
| Authors: | P. Metzger, W. Simpson. |
| Date: | September 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2841 |
| Status: | EXPERIMENTAL |
|
This document describes the use of keyed SHA with the IPAuthentication Header. |
|
| |
| RFC 1854 | SMTP Service Extension for Command Pipelining |
| |
| Authors: | N. Freed. |
| Date: | October 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2197 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. |
|
| |
| RFC 1860 | Variable Length Subnet Table For IPv4 |
| |
| Authors: | T. Pummill, B. Manning. |
| Date: | October 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 1878 |
| Status: | INFORMATIONAL |
|
This document itemizes the potential values for IPv4 subnets.Additional information is provided for Hex and Decmial values, classfull equivalents, and number of addresses available within the indicated block. We appreciate inputs from Bruce Pinsky (cisco) andDaniel Karrenberg (RIPE). |
|
| |
| RFC 1863 | A BGP/IDRP Route Server alternative to a full mesh routing |
| |
| Authors: | D. Haskin. |
| Date: | October 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4223 |
| Status: | HISTORIC |
|
This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.
The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud). |
|
| |
| RFC 1866 | Hypertext Markup Language - 2.0 |
| |
| Authors: | T. Berners-Lee, D. Connolly. |
| Date: | November 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
|
The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.
HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text andOffice Systems; Standard Generalized Markup Language (SGML).
The "text/html" Internet Media Type (RFC 1590) and MIME Content Type(RFC 1521) is defined by this specification. |
|
| |
| RFC 1867 | Form-based File Upload in HTML |
| |
| Authors: | E. Nebel, L. Masinter. |
| Date: | November 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
|
Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1869 | SMTP Service Extensions |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. |
| Date: | November 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1651 |
| Obsoleted by: | RFC 2821 |
| Also: | STD 0010 |
| Status: | STANDARD |
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1871 | Addendum to RFC 1602 -- Variance Procedure |
| |
|
|
This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This is a modification to the procedures of RFC 1602 and 1603. |
|
| |
| RFC 1872 | The MIME Multipart/Related Content-type |
| |
| Authors: | E. Levinson. |
| Date: | December 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2112 |
| Status: | EXPERIMENTAL |
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 1880 | Internet Official Protocol Standards |
| |
| Authors: | J. Postel, Ed.. |
| Date: | November 1995 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1800 |
| Obsoleted by: | RFC 1920 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1883 | Internet Protocol, Version 6 (IPv6) Specification |
| |
| Authors: | S. Deering, R. Hinden. |
| Date: | December 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2460 |
| Status: | PROPOSED STANDARD |
|
This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. |
|
| |
| RFC 1884 | IP Version 6 Addressing Architecture |
| |
| Authors: | R. Hinden, Ed., S. Deering, Ed.. |
| Date: | December 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2373 |
| Status: | HISTORIC |
|
This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 nodes required addresses. |
|
| |
| RFC 1885 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) |
| |
| Authors: | A. Conta, S. Deering. |
| Date: | December 1995 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2463 |
| Status: | PROPOSED STANDARD |
|
This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document. |
|
| |
| RFC 1886 | DNS Extensions to support IP version 6 |
| |
|
|
This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. |
|
| |
| RFC 1888 | OSI NSAPs and IPv6 |
| |
| Authors: | J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. |
| Date: | August 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4048 |
| Updated by: | RFC 4548 |
| Status: | HISTORIC |
|
This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required. |
|
| |
| RFC 1889 | RTP: A Transport Protocol for Real-Time Applications |
| |
| Authors: | Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3550 |
| Status: | PROPOSED STANDARD |
|
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. |
|
| |
| RFC 1890 | RTP Profile for Audio and Video Conferences with Minimal Control |
| |
| Authors: | Audio-Video Transport Working Group, H. Schulzrinne. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3551 |
| Status: | PROPOSED STANDARD |
|
This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. |
|
| |
| RFC 1891 | SMTP Service Extension for Delivery Status Notifications |
| |
| Authors: | K. Moore. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3461 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK] |
|
| |
| RFC 1892 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| |
| Authors: | G. Vaudreuil. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3462 |
| Status: | PROPOSED STANDARD |
|
The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK] |
|
| |
| RFC 1893 | Enhanced Mail System Status Codes |
| |
| Authors: | G. Vaudreuil. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3463 |
| Status: | PROPOSED STANDARD |
|
There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK] |
|
| |
| RFC 1894 | An Extensible Message Format for Delivery Status Notifications |
| |
| Authors: | K. Moore, G. Vaudreuil. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3464 |
| Updated by: | RFC 2852 |
| Status: | PROPOSED STANDARD |
|
This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used inInternet electronic mail.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail.
Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address<notifications@cs.utk.edu&rt;. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu&rt;.Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability.
NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text(phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change. |
|
| |
| RFC 1897 | IPv6 Testing Address Allocation |
| |
| Authors: | R. Hinden, J. Postel. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2471 |
| Status: | EXPERIMENTAL |
|
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community. |
|
| |
| RFC 1902 | Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1442 |
| Obsoleted by: | RFC 2578 |
| Status: | DRAFT STANDARD |
|
It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK] |
|
| |
| RFC 1903 | Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1443 |
| Obsoleted by: | RFC 2579 |
| Status: | DRAFT STANDARD |
|
It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK] |
|
| |
| RFC 1904 | Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1444 |
| Obsoleted by: | RFC 2580 |
| Status: | DRAFT STANDARD |
|
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK] |
|
| |
| RFC 1905 | Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1448 |
| Obsoleted by: | RFC 3416 |
| Status: | DRAFT STANDARD |
|
It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK] |
|
| |
| RFC 1906 | Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1449 |
| Obsoleted by: | RFC 3417 |
| Status: | DRAFT STANDARD |
|
It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK] |
|
| |
| RFC 1907 | Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1450 |
| Obsoleted by: | RFC 3418 |
| Status: | DRAFT STANDARD |
|
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] |
|
| |
| RFC 1908 | Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | January 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1452 |
| Obsoleted by: | RFC 2576 |
| Status: | DRAFT STANDARD |
|
The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1>. [STANDARDS-TRACK] |
|
| |
| RFC 1911 | Voice Profile for Internet Mail |
| |
|
|
The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1920 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1933 | Transition Mechanisms for IPv6 Hosts and Routers |
| |
| Authors: | R. Gilligan, E. Nordmark. |
| Date: | April 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2893 |
| Status: | PROPOSED STANDARD |
|
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. |
|
| |
| RFC 1938 | A One-Time Password System |
| |
| Authors: | N. Haller, C. Metz. |
| Date: | May 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2289 |
| Status: | PROPOSED STANDARD |
|
This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK] |
|
| |
| RFC 1942 | HTML Tables |
| |
| Authors: | D. Raggett. |
| Date: | May 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
|
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to support a wide variety of tables. The model is designed to work well with associated style sheets, but does not require them. It also supports rendering to braille, or speech, and exchange of tabular data with databases and spreadsheets. The HTML table model embodies certain aspects of the CALS table model, e.g. the ability to group table rows into thead, tbody and tfoot sections, plus the ability to specify cell alignment compactly for sets of cells according to the context. |
|
| |
| RFC 1944 | Benchmarking Methodology for Network Interconnect Devices |
| |
| Authors: | S. Bradner, J. McQuaid. |
| Date: | May 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2544 |
| Status: | INFORMATIONAL |
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. |
|
| |
| RFC 1948 | Defending Against Sequence Number Attacks |
| |
| Authors: | S. Bellovin. |
| Date: | May 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6528 |
| Status: | INFORMATIONAL |
|
IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. |
|
| |
| RFC 1959 | An LDAP URL Format |
| |
| Authors: | T. Howes, M. Smith. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2255 |
| Status: | PROPOSED STANDARD |
|
This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1960 | A String Representation of LDAP Search Filters |
| |
| Authors: | T. Howes. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1558 |
| Obsoleted by: | RFC 2254 |
| Status: | PROPOSED STANDARD |
|
The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] |
|
| |
| RFC 1965 | Autonomous System Confederations for BGP |
| |
| Authors: | P. Traina. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3065 |
| Status: | EXPERIMENTAL |
|
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.
The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
The extension this document describes is widely deployed in theInternet today. |
|
| |
| RFC 1966 | BGP Route Reflection An alternative to full mesh IBGP |
| |
| Authors: | T. Bates, R. Chandra. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4456 |
| Updated by: | RFC 2796 |
| Status: | EXPERIMENTAL |
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP. |
|
| |
| RFC 1969 | The PPP DES Encryption Protocol (DESE) |
| |
| Authors: | K. Sklower, G. Meyer. |
| Date: | June 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2419 |
| Status: | INFORMATIONAL |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. |
|
| |
| RFC 1970 | Neighbor Discovery for IP Version 6 (IPv6) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson. |
| Date: | August 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2461 |
| Status: | PROPOSED STANDARD |
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 1971 | IPv6 Stateless Address Autoconfiguration |
| |
| Authors: | S. Thomson, T. Narten. |
| Date: | August 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2462 |
| Status: | PROPOSED STANDARD |
|
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. |
|
| |
| RFC 1972 | A Method for the Transmission of IPv6 Packets over Ethernet Networks |
| |
| Authors: | M. Crawford. |
| Date: | August 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2464 |
| Status: | PROPOSED STANDARD |
|
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK] |
|
| |
| RFC 1980 | A Proposed Extension to HTML : Client-Side Image Maps |
| |
| Authors: | J. Seidman. |
| Date: | August 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
|
The markup language known as "HTML/2.0" provides for image maps.Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified byUniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client-Side Image Maps," which resolves these limitations. |
|
| |
| RFC 1991 | PGP Message Exchange Formats |
| |
| Authors: | D. Atkins, W. Stallings, P. Zimmermann. |
| Date: | August 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4880 |
| Status: | INFORMATIONAL |
|
This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2000 | Internet Official Protocol Standards |
| |
| Authors: | J. Postel, Ed.. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1920 |
| Obsoleted by: | RFC 2200 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. |
|
| |
| RFC 2001 | TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms |
| |
| Authors: | W. Stevens. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2581 |
| Status: | PROPOSED STANDARD |
|
Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [2] and [3] provide some details on these algorithms, [4] provides examples of the algorithms in action, and [5] provides the source code for the 4.4BSD implementation. RFC 1122 requires that a TCP must implement slow start and congestion avoidance (Section 4.2.2.15 of [1]), citing [2] as the reference, but fast retransmit and fast recovery were implemented after RFC 1122. The purpose of this document is to document these four algorithms for the Internet. |
|
| |
| RFC 2002 | IP Mobility Support |
| |
| Authors: | C. Perkins, Ed.. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3220 |
| Updated by: | RFC 2290 |
| Status: | PROPOSED STANDARD |
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 2010 | Operational Criteria for Root Name Servers |
| |
| Authors: | B. Manning, P. Vixie. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2870 |
| Status: | INFORMATIONAL |
|
This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. |
|
| |
| RFC 2011 | SNMPv2 Management Information Base for the Internet Protocol using SMIv2 |
| |
| Authors: | K. McCloghrie, Ed.. |
| Date: | November 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4293 |
| Updates: | RFC 1213 |
| Status: | PROPOSED STANDARD |
|
This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK] |
|
| |
| RFC 2012 | SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 |
| |
| Authors: | K. McCloghrie, Ed.. |
| Date: | November 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4022 |
| Updates: | RFC 1213 |
| Status: | PROPOSED STANDARD |
|
This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK] |
|
| |
| RFC 2013 | SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 |
| |
| Authors: | K. McCloghrie, Ed.. |
| Date: | November 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4113 |
| Updates: | RFC 1213 |
| Status: | PROPOSED STANDARD |
|
This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK] |
|
| |
| RFC 2019 | Transmission of IPv6 Packets Over FDDI |
| |
| Authors: | M. Crawford. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2467 |
| Status: | PROPOSED STANDARD |
|
This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK] |
|
| |
| RFC 2021 | Remote Network Monitoring Management Information Base Version 2 using SMIv2 |
| |
| Authors: | S. Waldbusser. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4502 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices. |
|
| |
| RFC 2023 | IP Version 6 over PPP |
| |
| Authors: | D. Haskin, E. Allen. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2472 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. |
|
| |
| RFC 2027 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
| Authors: | J. Galvin. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2282 |
| Status: | INFORMATIONAL |
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self- consistent, organized compilation of the process as it is known today. |
|
| |
| RFC 2030 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
| Authors: | D. Mills. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1769 |
| Obsoleted by: | RFC 4330 |
| Status: | INFORMATIONAL |
|
This memorandum describes the Simple Network Time Protocol (SNTP)Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI[COL94] addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.
This memorandum obsoletes RFC-1769, which describes SNTP Version 3.Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 andOSI), which are also used for SNTP. A working knowledge of the NTPVersion 3 specification RFC-1305 is not required for an implementation of SNTP. |
|
| |
| RFC 2032 | RTP Payload Format for H.261 Video Streams |
| |
| Authors: | T. Turletti, C. Huitema. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4587 |
| Status: | PROPOSED STANDARD |
|
This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK] |
|
| |
| RFC 2035 | RTP Payload Format for JPEG-compressed Video |
| |
| Authors: | L. Berc, W. Fenner, R. Frederick, S. McCanne. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2435 |
| Status: | PROPOSED STANDARD |
|
This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame.
This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s). |
|
| |
| RFC 2037 | Entity MIB using SMIv2 |
| |
| Authors: | K. McCloghrie, A. Bierman. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2737 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK] |
|
| |
| RFC 2038 | RTP Payload Format for MPEG1/MPEG2 Video |
| |
| Authors: | D. Hoffman, G. Fernando, V. Goyal. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2250 |
| Status: | PROPOSED STANDARD |
|
This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. |
|
| |
| RFC 2044 | UTF-8, a transformation format of Unicode and ISO 10646 |
| |
| Authors: | F. Yergeau. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2279 |
| Status: | INFORMATIONAL |
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. 16-bit characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range: US-ASCII characters are encoded in one octet having the usual US-ASCII value, and any octet with such a value can only be an US-ASCII character.This provides compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. |
|
| |
| RFC 2048 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities:
(1) media types,
(2) external body access types,
(3) content-transfer-encodings.
Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document.
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. |
|
| |
| RFC 2052 | A DNS RR for specifying the location of services (DNS SRV) |
| |
| Authors: | A. Gulbrandsen, P. Vixie. |
| Date: | October 1996 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2782 |
| Status: | EXPERIMENTAL |
|
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). |
|
| |
| RFC 2058 | Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | C. Rigney, A. Rubens, W. Simpson, S. Willens. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2138 |
| Status: | PROPOSED STANDARD |
|
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server. |
|
| |
| RFC 2059 | RADIUS Accounting |
| |
| Authors: | C. Rigney. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2139 |
| Status: | INFORMATIONAL |
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2060 | Internet Message Access Protocol - Version 4rev1 |
| |
| Authors: | M. Crispin. |
| Date: | December 1996 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1730 |
| Obsoleted by: | RFC 3501 |
| Status: | PROPOSED STANDARD |
|
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution ofIMAP4rev1, some aspects in the earlier protocol have become obsolete.Obsolete commands, responses, and data formats which an IMAP4rev1 implementation may encounter when used with an earlier implementation are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest. |
|
| |
| RFC 2063 | Traffic Flow Measurement: Architecture |
| |
| Authors: | N. Brownlee, C. Mills, G. Ruth. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2722 |
| Status: | EXPERIMENTAL |
|
This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group. |
|
| |
| RFC 2064 | Traffic Flow Measurement: Meter MIB |
| |
| Authors: | N. Brownlee. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2720 |
| Status: | EXPERIMENTAL |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. |
|
| |
| RFC 2065 | Domain Name System Security Extensions |
| |
|
|
The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases.
The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
In addition, the security extensions provide for the optional authentication of DNS protocol transactions. |
|
| |
| RFC 2068 | Hypertext Transfer Protocol -- HTTP/1.1 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2616 |
| Status: | PROPOSED STANDARD |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods.A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1". |
|
| |
| RFC 2069 | An Extension to HTTP : Digest Access Authentication |
| |
| Authors: | J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2617 |
| Status: | PROPOSED STANDARD |
|
The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". Like Basic,Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. |
|
| |
| RFC 2070 | Internationalization of the Hypertext Markup Language |
| |
| Authors: | F. Yergeau, G. Nicol, G. Adams, M. Duerst. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
|
The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.
This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world. |
|
| |
| RFC 2073 | An IPv6 Provider-Based Unicast Address Format |
| |
| Authors: | Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2374 |
| Status: | PROPOSED STANDARD |
|
This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2074 | Remote Network Monitoring MIB Protocol Identifiers |
| |
| Authors: | A. Bierman, R. Iddon. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2895 |
| Status: | PROPOSED STANDARD |
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK] |
|
| |
| RFC 2078 | Generic Security Service Application Program Interface, Version 2 |
| |
| Authors: | J. Linn. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1508 |
| Obsoleted by: | RFC 2743 |
| Status: | PROPOSED STANDARD |
|
The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
This memo revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. |
|
| |
| RFC 2082 | RIP-2 MD5 Authentication |
| |
| Authors: | F. Baker, R. Atkinson. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4822 |
| Status: | PROPOSED STANDARD |
|
Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK] |
|
| |
| RFC 2086 | IMAP4 ACL extension |
| |
| Authors: | J. Myers. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4314 |
| Status: | PROPOSED STANDARD |
|
The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 2089 | V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent |
| |
| Authors: | B. Wijnen, D. Levi. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2576 |
| Status: | INFORMATIONAL |
|
The goal of this memo is to document a common way of mapping anSNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). |
|
| |
| RFC 2095 | IMAP/POP AUTHorize Extension for Simple Challenge/Response |
| |
| Authors: | J. Klensin, R. Catoe, P. Krumviede. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2195 |
| Status: | PROPOSED STANDARD |
|
While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734. |
|
| |
| RFC 2096 | IP Forwarding Table MIB |
| |
| Authors: | F. Baker. |
| Date: | January 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1354 |
| Obsoleted by: | RFC 4292 |
| Status: | PROPOSED STANDARD |
|
This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK] |
|
| |
| RFC 2106 | Data Link Switching Remote Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2114 |
| Status: | INFORMATIONAL |
|
This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com. |
|
| |
| RFC 2109 | HTTP State Management Mechanism |
| |
| Authors: | D. Kristol, L. Montulli. |
| Date: | February 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2965 |
| Status: | HISTORIC |
|
This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK] |
|
| |
| RFC 2110 | MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) |
| |
| Authors: | J. Palme, A. Hopmann. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2557 |
| Status: | PROPOSED STANDARD |
|
Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate usingHTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base". |
|
| |
| RFC 2111 | Content-ID and Message-ID Uniform Resource Locators |
| |
| Authors: | E. Levinson. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2392 |
| Status: | PROPOSED STANDARD |
|
The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. |
|
| |
| RFC 2112 | The MIME Multipart/Related Content-type |
| |
| Authors: | E. Levinson. |
| Date: | March 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1872 |
| Obsoleted by: | RFC 2387 |
| Status: | PROPOSED STANDARD |
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 2117 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2362 |
| Status: | EXPERIMENTAL |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2133 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, W. Stevens. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2553 |
| Status: | INFORMATIONAL |
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [5]. |
|
| |
| RFC 2137 | Secure Domain Name System Dynamic Update |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3007 |
| Updates: | RFC 1035 |
| Status: | PROPOSED STANDARD |
|
Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services[RFC2065]. DNS Dynamic Update operations have also been defined[RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. |
|
| |
| RFC 2138 | Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | C. Rigney, A. Rubens, W. Simpson, S. Willens. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2058 |
| Obsoleted by: | RFC 2865 |
| Status: | PROPOSED STANDARD |
|
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server. |
|
| |
| RFC 2139 | RADIUS Accounting |
| |
| Authors: | C. Rigney. |
| Date: | April 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2059 |
| Obsoleted by: | RFC 2866 |
| Status: | INFORMATIONAL |
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2147 | TCP and UDP over IPv6 Jumbograms |
| |
| Authors: | D. Borman. |
| Date: | May 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2675 |
| Status: | PROPOSED STANDARD |
|
IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK] |
|
| |
| RFC 2155 | Definitions of Managed Objects for APPN using SMIv2 |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | June 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2455 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK] |
|
| |
| RFC 2168 | Resolution of Uniform Resource Identifiers using the Domain Name System |
| |
|
|
The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2178 | OSPF Version 2 |
| |
|
|
This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree.
OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated.
The differences between this memo and RFC 1583 are explained inAppendix G. All differences are backward-compatible in nature.Implementations of this memo and of RFC 1583 will interoperate.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 2184 | MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations |
| |
|
|
This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK] |
|
| |
| RFC 2192 | IMAP URL Scheme |
| |
| Authors: | C. Newman. |
| Date: | September 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5092 |
| Status: | PROPOSED STANDARD |
|
IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores.This document defines a URL scheme for referencing objects on anIMAP server. |
|
| |
| RFC 2197 | SMTP Service Extension for Command Pipelining |
| |
| Authors: | N. Freed. |
| Date: | September 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1854 |
| Obsoleted by: | RFC 2920 |
| Status: | DRAFT STANDARD |
|
This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK] |
|
| |
| RFC 2200 | Internet Official Protocol Standards |
| |
|
|
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK] |
|
| |
| RFC 2204 | ODETTE File Transfer Protocol |
| |
| Authors: | D. Nash. |
| Date: | September 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5024 |
| Status: | INFORMATIONAL |
|
This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners.
The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community. |
|
| |
| RFC 2222 | Simple Authentication and Security Layer (SASL) |
| |
|
|
This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK] |
|
| |
| RFC 2233 | The Interfaces Group MIB using SMIv2 |
| |
| Authors: | K. McCloghrie, F. Kastenholz. |
| Date: | November 1997 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1573 |
| Obsoleted by: | RFC 2863 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK] |
|
| |
| RFC 2234 | Augmented BNF for Syntax Specifications: ABNF |
| |
| Authors: | D. Crocker, Ed., P. Overell. |
| Date: | November 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4234 |
| Status: | PROPOSED STANDARD |
|
In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK] |
|
| |
| RFC 2236 | Internet Group Management Protocol, Version 2 |
| |
| Authors: | W. Fenner. |
| Date: | November 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3376 |
| Updates: | RFC 1112 |
| Status: | PROPOSED STANDARD |
|
This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112.
IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.
This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s). |
|
| |
| RFC 2239 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 |
| |
| Authors: | K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | November 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2668 |
| Status: | PROPOSED STANDARD |
|
This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing 10 and 100 Mb/secondMedium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30,"10 & 100 Mb/s Management," October 26, 1995. |
|
| |
| RFC 2240 | A Legal Basis for Domain Name Allocation |
| |
| Authors: | O. Vaughan. |
| Date: | November 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2352 |
| Status: | INFORMATIONAL |
|
The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2245 | Anonymous SASL Mechanism |
| |
| Authors: | C. Newman. |
| Date: | November 1997 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4505 |
| Status: | PROPOSED STANDARD |
|
It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using "anonymous" as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. |
|
| |
| RFC 2246 | The TLS Protocol Version 1.0 |
| |
|
|
This document specifies Version 1.0 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
|
| |
| RFC 2248 | Network Services Monitoring MIB |
| |
| Authors: | N. Freed, S. Kille. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1565 |
| Obsoleted by: | RFC 2788 |
| Status: | PROPOSED STANDARD |
|
This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK] |
|
| |
| RFC 2249 | Mail Monitoring MIB |
| |
| Authors: | N. Freed, S. Kille. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1566 |
| Obsoleted by: | RFC 2789 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS- TRACK] |
|
| |
| RFC 2251 | Lightweight Directory Access Protocol (v3) |
| |
|
|
The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK] |
|
| |
| RFC 2252 | Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions |
| |
|
|
This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 2253 | Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names |
| |
|
|
The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight DirectoryAccess Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. |
|
| |
| RFC 2254 | The String Representation of LDAP Search Filters |
| |
|
|
This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] |
|
| |
| RFC 2255 | The LDAP URL Format |
| |
|
|
This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK] |
|
| |
| RFC 2256 | A Summary of the X.500(96) User Schema for use with LDAPv3 |
| |
|
|
This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS- TRACK] |
|
| |
| RFC 2257 | Agent Extensibility (AgentX) Protocol Version 1 |
| |
| Authors: | M. Daniele, B. Wijnen, D. Francisco. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2741 |
| Status: | PROPOSED STANDARD |
|
This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK] |
|
| |
| RFC 2261 | An Architecture for Describing SNMP Management Frameworks |
| |
| Authors: | D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2271 |
| Status: | PROPOSED STANDARD |
|
This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
|
| |
| RFC 2262 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2272 |
| Status: | PROPOSED STANDARD |
|
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
|
| |
| RFC 2263 | SNMPv3 Applications |
| |
| Authors: | D. Levi, P. Meyer, B. Stewart. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2273 |
| Status: | PROPOSED STANDARD |
|
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
|
| |
| RFC 2264 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
| Authors: | U. Blumenthal, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2274 |
| Status: | PROPOSED STANDARD |
|
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
|
| |
| RFC 2265 | View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | B. Wijnen, R. Presuhn, K. McCloghrie. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2275 |
| Status: | PROPOSED STANDARD |
|
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
|
| |
| RFC 2267 | Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing |
| |
| Authors: | P. Ferguson, D. Senie. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2827 |
| Status: | INFORMATIONAL |
|
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. |
|
| |
| RFC 2271 | An Architecture for Describing SNMP Management Frameworks |
| |
| Authors: | D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2261 |
| Obsoleted by: | RFC 2571 |
| Status: | PROPOSED STANDARD |
|
This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
|
| |
| RFC 2272 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2262 |
| Obsoleted by: | RFC 2572 |
| Status: | PROPOSED STANDARD |
|
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
|
| |
| RFC 2273 | SNMPv3 Applications |
| |
| Authors: | D. Levi, P. Meyer, B. Stewart. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2263 |
| Obsoleted by: | RFC 2573 |
| Status: | PROPOSED STANDARD |
|
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
|
| |
| RFC 2274 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
| Authors: | U. Blumenthal, B. Wijnen. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2264 |
| Obsoleted by: | RFC 2574 |
| Status: | PROPOSED STANDARD |
|
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
|
| |
| RFC 2275 | View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | B. Wijnen, R. Presuhn, K. McCloghrie. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2265 |
| Obsoleted by: | RFC 2575 |
| Status: | PROPOSED STANDARD |
|
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
|
| |
| RFC 2278 | IANA Charset Registration Procedures |
| |
| Authors: | N. Freed, J. Postel. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2978 |
| Status: | INFORMATIONAL |
|
MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2279 | UTF-8, a transformation format of ISO 10646 |
| |
| Authors: | F. Yergeau. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2044 |
| Obsoleted by: | RFC 3629 |
| Status: | DRAFT STANDARD |
|
ISO/IEC 10646-1 defines a multi-octet character set called theUniversal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. |
|
| |
| RFC 2280 | Routing Policy Specification Language (RPSL) |
| |
| Authors: | C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar. |
| Date: | January 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2622 |
| Status: | PROPOSED STANDARD |
|
This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] |
|
| |
| RFC 2282 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
| Authors: | J. Galvin. |
| Date: | February 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2027 |
| Obsoleted by: | RFC 2727 |
| Status: | INFORMATIONAL |
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. |
|
| |
| RFC 2283 | Multiprotocol Extensions for BGP-4 |
| |
| Authors: | T. Bates, R. Chandra, D. Katz, Y. Rekhter. |
| Date: | February 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2858 |
| Status: | PROPOSED STANDARD |
|
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] |
|
| |
| RFC 2284 | PPP Extensible Authentication Protocol (EAP) |
| |
| Authors: | L. Blunk, J. Vollbrecht. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3748 |
| Updated by: | RFC 2484 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link.
This document defines the PPP Extensible Authentication Protocol. |
|
| |
| RFC 2292 | Advanced Sockets API for IPv6 |
| |
| Authors: | W. Stevens, M. Thomas. |
| Date: | February 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3542 |
| Status: | INFORMATIONAL |
|
Specifications are in progress for changes to the sockets API to support IP version 6 [RFC-2133]. These changes are for TCP and UDP- based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like.
But another class of applications exists that will also be run underIPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features.
There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too. |
|
| |
| RFC 2298 | An Extensible Message Format for Message Disposition Notifications |
| |
| Authors: | R. Fajman. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3798 |
| Status: | PROPOSED STANDARD |
|
This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. |
|
| |
| RFC 2300 | Internet Official Protocol Standards |
| |
|
|
A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK] |
|
| |
| RFC 2301 | File Format for Internet Fax |
| |
| Authors: | L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3949 |
| Status: | PROPOSED STANDARD |
|
This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed RasterContent modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-TRecommendations. Files formatted according to this specification use the image/tiff MIME Content Type. |
|
| |
| RFC 2302 | Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration |
| |
| Authors: | G. Parsons, J. Rafferty, S. Zilles. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3302 |
| Status: | PROPOSED STANDARD |
|
This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK] |
|
| |
| RFC 2303 | Minimal PSTN address format in Internet Mail |
| |
| Authors: | C. Allocchio. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3191 |
| Status: | PROPOSED STANDARD |
|
This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK] |
|
| |
| RFC 2304 | Minimal FAX address format in Internet Mail |
| |
| Authors: | C. Allocchio. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3192 |
| Status: | PROPOSED STANDARD |
|
This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS- TRACK] |
|
| |
| RFC 2305 | A Simple Mode of Facsimile Using Internet Mail |
| |
| Authors: | K. Toyoda, H. Ohno, J. Murai, D. Wing. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3965 |
| Status: | PROPOSED STANDARD |
|
This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2313 | PKCS #1: RSA Encryption Version 1.5 |
| |
| Authors: | B. Kaliski. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2437 |
| Status: | INFORMATIONAL |
|
This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2314 | PKCS #10: Certification Request Syntax Version 1.5 |
| |
| Authors: | B. Kaliski. |
| Date: | March 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2986 |
| Status: | INFORMATIONAL |
|
This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2327 | SDP: Session Description Protocol |
| |
| Authors: | M. Handley, V. Jacobson. |
| Date: | April 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4566 |
| Updated by: | RFC 3266 |
| Status: | PROPOSED STANDARD |
|
This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. |
|
| |
| RFC 2338 | Virtual Router Redundancy Protocol |
| |
| Authors: | S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. |
| Date: | April 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3768 |
| Status: | PROPOSED STANDARD |
|
This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. |
|
| |
| RFC 2344 | Reverse Tunneling for Mobile IP |
| |
| Authors: | G. Montenegro, Ed.. |
| Date: | May 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3024 |
| Status: | PROPOSED STANDARD |
|
Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address.When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent.
This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. |
|
| |
| RFC 2358 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
| Authors: | J. Flick, J. Johnson. |
| Date: | June 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1650 |
| Obsoleted by: | RFC 2665 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1650 "Definitions of Managed Objects for theEthernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2359 | IMAP4 UIDPLUS extension |
| |
| Authors: | J. Myers. |
| Date: | June 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4315 |
| Status: | PROPOSED STANDARD |
|
The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK] |
|
| |
| RFC 2362 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2117 |
| Obsoleted by: | RFC 4601, RFC 5059 |
| Status: | EXPERIMENTAL |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2366 | Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks |
| |
| Authors: | C. Chung, M. Greene. |
| Date: | July 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2417 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community. |
|
| |
| RFC 2368 | The mailto URL scheme |
| |
| Authors: | P. Hoffman, L. Masinter, J. Zawinski. |
| Date: | July 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6068 |
| Updates: | RFC 1738, RFC 1808 |
| Status: | PROPOSED STANDARD |
|
This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', andRFC 1808, 'Relative Uniform Resource Locators'. The syntax of'mailto' URLs from RFC 1738 is extended to allow creation of more RFC822 messages by allowing the URL to express additional header and body fields. |
|
| |
| RFC 2370 | The OSPF Opaque LSA Option |
| |
|
|
This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK] |
|
| |
| RFC 2373 | IP Version 6 Addressing Architecture |
| |
| Authors: | R. Hinden, S. Deering. |
| Date: | July 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1884 |
| Obsoleted by: | RFC 3513 |
| Status: | PROPOSED STANDARD |
|
This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses. |
|
| |
| RFC 2374 | An IPv6 Aggregatable Global Unicast Address Format |
| |
| Authors: | R. Hinden, M. O'Dell, S. Deering. |
| Date: | July 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2073 |
| Obsoleted by: | RFC 3587 |
| Status: | HISTORIC |
|
This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2376 | XML Media Types |
| |
| Authors: | E. Whitehead, M. Murata. |
| Date: | July 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3023 |
| Status: | INFORMATIONAL |
|
This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the WorldWide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. |
|
| |
| RFC 2385 | Protection of BGP Sessions via the TCP MD5 Signature Option |
| |
| Authors: | A. Heffernan. |
| Date: | August 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5925 |
| Status: | PROPOSED STANDARD |
|
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points.Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. |
|
| |
| RFC 2393 | IP Payload Compression Protocol (IPComp) |
| |
| Authors: | A. Shacham, R. Monsour, R. Pereira, M. Thomas. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3173 |
| Status: | PROPOSED STANDARD |
|
This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. |
|
| |
| RFC 2396 | Uniform Resource Identifiers (URI): Generic Syntax |
| |
|
|
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource. This document defines the generic syntax of URI, including both absolute and relative forms, and guidelines for their use; it revises and replaces the generic definitions in RFC 1738 and RFC 1808.
This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. This document does not define a generative grammar for URI; that task will be performed by the individual specifications of each URI scheme. |
|
| |
| RFC 2400 | Internet Official Protocol Standards |
| |
| Authors: | J. Postel, J. Reynolds. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2300 |
| Obsoleted by: | RFC 2500 |
| Status: | HISTORIC |
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK] |
|
| |
| RFC 2401 | Security Architecture for the Internet Protocol |
| |
| Authors: | S. Kent, R. Atkinson. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1825 |
| Obsoleted by: | RFC 4301 |
| Updated by: | RFC 3168 |
| Status: | PROPOSED STANDARD |
|
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK] |
|
| |
| RFC 2402 | IP Authentication Header |
| |
|
|
The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK] |
|
| |
| RFC 2406 | IP Encapsulating Security Payload (ESP) |
| |
|
|
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK] |
|
| |
| RFC 2407 | The Internet IP Security Domain of Interpretation for ISAKMP |
| |
| Authors: | D. Piper. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4306 |
| Status: | PROPOSED STANDARD |
|
This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK] |
|
| |
| RFC 2408 | Internet Security Association and Key Management Protocol (ISAKMP) |
| |
| Authors: | D. Maughan, M. Schertler, M. Schneider, J. Turner. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4306 |
| Status: | PROPOSED STANDARD |
|
This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and KeyManagement Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management ofSecurity Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications(via IP Security Service or any other security protocol) in anInternet environment. |
|
| |
| RFC 2409 | The Internet Key Exchange (IKE) |
| |
| Authors: | D. Harkins, D. Carrel. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4306 |
| Updated by: | RFC 4109 |
| Status: | PROPOSED STANDARD |
|
This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] |
|
| |
| RFC 2411 | IP Security Document Roadmap |
| |
| Authors: | R. Thayer, N. Doraswamy, R. Glenn. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6071 |
| Status: | INFORMATIONAL |
|
The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and AuthenticationAlgorithm documents are described. |
|
| |
| RFC 2413 | Dublin Core Metadata for Resource Discovery |
| |
| Authors: | S. Weibel, J. Kunze, C. Lagoze, M. Wolf. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5013 |
| Status: | INFORMATIONAL |
|
This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community. |
|
| |
| RFC 2414 | Increasing TCP's Initial Window |
| |
| Authors: | M. Allman, S. Floyd, C. Partridge. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3390 |
| Status: | EXPERIMENTAL |
|
This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP. |
|
| |
| RFC 2421 | Voice Profile for Internet Mail - version 2 |
| |
| Authors: | G. Vaudreuil, G. Parsons. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1911 |
| Obsoleted by: | RFC 3801 |
| Status: | PROPOSED STANDARD |
|
This document profiles Internet mail for voice messaging. [STANDARDS- TRACK] |
|
| |
| RFC 2422 | Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration |
| |
| Authors: | G. Vaudreuil, G. Parsons. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1911 |
| Obsoleted by: | RFC 3802 |
| Status: | PROPOSED STANDARD |
|
This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK] |
|
| |
| RFC 2423 | VPIM Voice Message MIME Sub-type Registration |
| |
| Authors: | G. Vaudreuil, G. Parsons. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1911 |
| Obsoleted by: | RFC 3801 |
| Status: | PROPOSED STANDARD |
|
This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK] |
|
| |
| RFC 2424 | Content Duration MIME Header Definition |
| |
| Authors: | G. Vaudreuil, G. Parsons. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3803 |
| Status: | PROPOSED STANDARD |
|
This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK] |
|
| |
| RFC 2425 | A MIME Content-Type for Directory Information |
| |
| Authors: | T. Howes, M. Smith, F. Dawson. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
|
This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK] |
|
| |
| RFC 2426 | vCard MIME Directory Profile |
| |
| Authors: | F. Dawson, T. Howes. |
| Date: | September 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
|
This memo defines the profile of the MIME Content-Type [MIME-DIR] for directory information for a white-pages person object, based on a vCard electronic business card. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The directory information used by this profile is based on the attributes for the person object defined in the X.520 and X.521 directory services recommendations. The profile also provides the method for including a [VCARD] representation of a white-pages directory entry within the MIME Content-Type defined by the [MIME-DIR] document. |
|
| |
| RFC 2429 | RTP Payload Format for the 1998 Version of ITU-T Rec |
| |
| Authors: | H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. |
| Date: | October 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4629 |
| Status: | PROPOSED STANDARD |
|
This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK] |
|
| |
| RFC 2434 | Guidelines for Writing an IANA Considerations Section in RFCs |
| |
| Authors: | T. Narten, H. Alvestrand. |
| Date: | October 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5226 |
| Updated by: | RFC 3692 |
| Status: | BEST CURRENT PRACTICE |
|
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned NumbersAuthority (IANA).
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. |
|
| |
| RFC 2436 | Collaboration between ISOC/IETF and ITU-T |
| |
| Authors: | R. Brett, S. Bradner, G. Parsons. |
| Date: | October 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3356 |
| Status: | INFORMATIONAL |
|
This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community. |
|
| |
| RFC 2437 | PKCS #1: RSA Cryptography Specifications Version 2.0 |
| |
| Authors: | B. Kaliski, J. Staddon. |
| Date: | October 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2313 |
| Obsoleted by: | RFC 3447 |
| Status: | INFORMATIONAL |
|
This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community. |
|
| |
| RFC 2440 | OpenPGP Message Format |
| |
| Authors: | J. Callas, L. Donnerhacke, H. Finney, R. Thayer. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4880 |
| Status: | PROPOSED STANDARD |
|
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network.It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.
Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP. |
|
| |
| RFC 2445 | Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| |
| Authors: | F. Dawson, D. Stenerson. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5545 |
| Status: | PROPOSED STANDARD |
|
There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across theInternet.
This memo is formatted as a registration for a MIME media type per[RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type.
The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below.
This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities.
This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information.In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification.
This memo defines the format for specifying iCalendar object methods.An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendentInteroperability Protocol (iTIP) defined in [ITIP] is one such scheduling protocol. |
|
| |
| RFC 2446 | iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries |
| |
| Authors: | S. Silverberg, S. Mansour, F. Dawson, R. Hopson. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5546 |
| Status: | PROPOSED STANDARD |
|
This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems.Subsequent documents specify interoperable methods of communications between systems that use this protocol.
The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects.Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects.
This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol(iTIP)". iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols. |
|
| |
| RFC 2447 | iCalendar Message-Based Interoperability Protocol (iMIP) |
| |
| Authors: | F. Dawson, S. Mansour, S. Silverberg. |
| Date: | November 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6047 |
| Status: | PROPOSED STANDARD |
|
This document, [iMIP], specifies a binding from the iCalendarTransport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendarObject Model [iCAL] are composed using constructs from [RFC-822],[RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
This document is based on discussions within the Internet EngineeringTask Force (IETF) Calendaring and Scheduling (CALSCH) working group.More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. |
|
| |
| RFC 2452 | IP Version 6 Management Information Base for the Transmission Control Protocol |
| |
| Authors: | M. Daniele. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4022 |
| Status: | PROPOSED STANDARD |
|
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the TransmissionControl Protocol (TCP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of whichIP versions underlie TCP, and only the TCP connection information isIP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets. |
|
| |
| RFC 2454 | IP Version 6 Management Information Base for the User Datagram Protocol |
| |
| Authors: | M. Daniele. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4113 |
| Status: | HISTORIC |
|
This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the UserDatagram Protocol (UDP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of whichIP versions underlie UDP, and only the UDP listener information is IP version-specific.
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets. |
|
| |
| RFC 2459 | Internet X.509 Public Key Infrastructure Certificate and CRL Profile |
| |
| Authors: | R. Housley, W. Ford, W. Polk, D. Solo. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3280 |
| Status: | PROPOSED STANDARD |
|
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices. |
|
| |
| RFC 2461 | Neighbor Discovery for IP Version 6 (IPv6) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1970 |
| Obsoleted by: | RFC 4861 |
| Updated by: | RFC 4311 |
| Status: | DRAFT STANDARD |
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 2462 | IPv6 Stateless Address Autoconfiguration |
| |
| Authors: | S. Thomson, T. Narten. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1971 |
| Obsoleted by: | RFC 4862 |
| Status: | DRAFT STANDARD |
|
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. |
|
| |
| RFC 2463 | Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification |
| |
| Authors: | A. Conta, S. Deering. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1885 |
| Obsoleted by: | RFC 4443 |
| Status: | DRAFT STANDARD |
|
This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). |
|
| |
| RFC 2465 | Management Information Base for IP Version 6: Textual Conventions and General Group |
| |
| Authors: | D. Haskin, S. Onishi. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4293 |
| Status: | PROPOSED STANDARD |
|
This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.
This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions. |
|
| |
| RFC 2466 | Management Information Base for IP Version 6: ICMPv6 Group |
| |
| Authors: | D. Haskin, S. Onishi. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4293 |
| Status: | PROPOSED STANDARD |
|
This document is one in the series of documents that define variousMIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets.
This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions. |
|
| |
| RFC 2471 | IPv6 Testing Address Allocation |
| |
| Authors: | R. Hinden, R. Fink, J. Postel. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1897 |
| Obsoleted by: | RFC 3701 |
| Status: | HISTORIC |
|
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2472 | IP Version 6 over PPP |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. |
|
| |
| RFC 2476 | Message Submission |
| |
| Authors: | R. Gellens, J. Klensin. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4409 |
| Status: | PROPOSED STANDARD |
|
This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK] |
|
| |
| RFC 2478 | The Simple and Protected GSS-API Negotiation Mechanism |
| |
| Authors: | E. Baize, D. Pinkas. |
| Date: | December 1998 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4178 |
| Status: | PROPOSED STANDARD |
|
This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS- TRACK] |
|
| |
| RFC 2481 | A Proposal to add Explicit Congestion Notification (ECN) to IP |
| |
| Authors: | K. Ramakrishnan, S. Floyd. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3168 |
| Status: | EXPERIMENTAL |
|
This note describes a proposed addition of ECN (Explicit CongestionNotification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a CongestionExperienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols(e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. |
|
| |
| RFC 2482 | Language Tagging in Unicode Plain Text |
| |
| Authors: | K. Whistler, G. Adams. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6082 |
| Status: | HISTORIC |
|
This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community. |
|
| |
| RFC 2486 | The Network Access Identifier |
| |
| Authors: | B. Aboba, M. Beadles. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4282 |
| Status: | PROPOSED STANDARD |
|
This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK] |
|
| |
| RFC 2487 | SMTP Service Extension for Secure SMTP over TLS |
| |
| Authors: | P. Hoffman. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3207 |
| Status: | PROPOSED STANDARD |
|
This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK] |
|
| |
| RFC 2489 | Procedure for Defining New DHCP Options |
| |
| Authors: | R. Droms. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2939 |
| Also: | BCP 0029 |
| Status: | BEST CURRENT PRACTICE |
|
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called "options."
New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options. |
|
| |
| RFC 2493 | Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals |
| |
| Authors: | K. Tesink, Ed.. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3593 |
| Status: | PROPOSED STANDARD |
|
This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. |
|
| |
| RFC 2495 | Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types |
| |
| Authors: | D. Fowler, Ed.. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1406 |
| Obsoleted by: | RFC 3895 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document withDefinitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3(RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types.
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. |
|
| |
| RFC 2496 | Definitions of Managed Object for the DS3/E3 Interface Type |
| |
| Authors: | D. Fowler, Ed.. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1407 |
| Obsoleted by: | RFC 3896 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494 [25]), DS1/E1/DS2/E2 (RFC2495 [17]), and the work in progress SONET/SDH Interface Types.
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. |
|
| |
| RFC 2498 | IPPM Metrics for Measuring Connectivity |
| |
| Authors: | J. Mahdavi, V. Paxson. |
| Date: | January 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2678 |
| Status: | EXPERIMENTAL |
|
This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2500 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2400 |
| Obsoleted by: | RFC 2600 |
| Status: | HISTORIC |
|
This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK] |
|
| |
| RFC 2509 | IP Header Compression over PPP |
| |
| Authors: | M. Engan, S. Casner, C. Bormann. |
| Date: | February 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3544 |
| Status: | PROPOSED STANDARD |
|
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol [RFC1661]. It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. |
|
| |
| RFC 2510 | Internet X.509 Public Key Infrastructure Certificate Management Protocols |
| |
| Authors: | C. Adams, S. Farrell. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4210 |
| Status: | PROPOSED STANDARD |
|
This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management.Note that "certificate" in this document refers to an X.509v3Certificate as defined in [COR95, X509-AM]. |
|
| |
| RFC 2511 | Internet X.509 Certificate Request Message Format |
| |
| Authors: | M. Myers, C. Adams, D. Solo, D. Kemp. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4211 |
| Status: | PROPOSED STANDARD |
|
This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK] |
|
| |
| RFC 2518 | HTTP Extensions for Distributed Authoring -- WEBDAV |
| |
| Authors: | Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. |
| Date: | February 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4918 |
| Status: | PROPOSED STANDARD |
|
This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). |
|
| |
| RFC 2527 | Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
| |
| Authors: | S. Chokhani, W. Ford. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3647 |
| Status: | INFORMATIONAL |
|
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. |
|
| |
| RFC 2531 | Content Feature Schema for Internet Fax |
| |
| Authors: | G. Klyne, L. McIntyre. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2879 |
| Status: | PROPOSED STANDARD |
|
This document defines a content feature schema that is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5].
This document does not describe any specific mechanisms for communicating capability information, but does presume that any such mechanisms will transfer textual values. It specifies a textual format to be used for describing Internet fax capability information. |
|
| |
| RFC 2535 | Domain Name System Security Extensions |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2065 |
| Obsoleted by: | RFC 4033, RFC 4034, RFC 4035 |
| Updates: | RFC 2181, RFC 1035, RFC 1034 |
| Updated by: | RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Status: | PROPOSED STANDARD |
|
Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.These digital signatures are included in secured zones as resource records. Security can also be provided through non-security awareDNS servers in some cases.
The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured.Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests.
This document incorporates feedback on RFC 2065 from early implementers and potential users. |
|
| |
| RFC 2537 | RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3110 |
| Status: | PROPOSED STANDARD |
|
A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNSKEY and SIG resource records. |
|
| |
| RFC 2538 | Storing Certificates in the Domain Name System (DNS) |
| |
| Authors: | D. Eastlake 3rd, O. Gudmundsson. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4398 |
| Status: | PROPOSED STANDARD |
|
Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). |
|
| |
| RFC 2541 | DNS Security Operational Considerations |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4641 |
| Status: | INFORMATIONAL |
|
Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. |
|
| |
| RFC 2543 | SIP: Session Initiation Protocol |
| |
|
|
The Session Initiation Protocol (SIP) is an application-layer control(signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types.SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. |
|
| |
| RFC 2546 | 6Bone Routing Practice |
| |
| Authors: | A. Durand, B. Buclin. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2772 |
| Status: | INFORMATIONAL |
|
This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community. |
|
| |
| RFC 2547 | BGP/MPLS VPNs |
| |
| Authors: | E. Rosen, Y. Rekhter. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4364 |
| Status: | INFORMATIONAL |
|
This document describes a method by which a Service Provider with anIP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border GatewayProtocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers. |
|
| |
| RFC 2553 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, W. Stevens. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2133 |
| Obsoleted by: | RFC 3493 |
| Updated by: | RFC 3152 |
| Status: | INFORMATIONAL |
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. |
|
| |
| RFC 2554 | SMTP Service Extension for Authentication |
| |
| Authors: | J. Myers. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4954 |
| Status: | PROPOSED STANDARD |
|
This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK] |
|
| |
| RFC 2558 | Definitions of Managed Objects for the SONET/SDH Interface Type |
| |
| Authors: | K. Tesink. |
| Date: | March 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1595 |
| Obsoleted by: | RFC 3592 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK] |
|
| |
| RFC 2559 | Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 |
| |
| Authors: | S. Boeyen, T. Howes, P. Richard. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3494 |
| Updates: | RFC 1778 |
| Status: | HISTORIC |
|
Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK] |
|
| |
| RFC 2565 | Internet Printing Protocol/1.0: Encoding and Transport |
| |
| Authors: | R. Herriot, Ed., S. Butler, P. Moore, R. Turner. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2910 |
| Status: | EXPERIMENTAL |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp".
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport (this document)Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2566 | Internet Printing Protocol/1.0: Model and Semantics |
| |
| Authors: | R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2911 |
| Status: | EXPERIMENTAL |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs.This document also addresses security, internationalization, and directory issues.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics (this document)Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2570 | Introduction to Version 3 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, R. Mundy, D. Partain, B. Stewart. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3410 |
| Status: | INFORMATIONAL |
|
The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard ManagementFramework (SNMPv1) and the second Internet-standard ManagementFramework (SNMPv2).
The architecture is designed to be modular to allow the evolution of the Framework over time. |
|
| |
| RFC 2571 | An Architecture for Describing SNMP Management Frameworks |
| |
| Authors: | B. Wijnen, D. Harrington, R. Presuhn. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2271 |
| Obsoleted by: | RFC 3411 |
| Status: | DRAFT STANDARD |
|
This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
|
| |
| RFC 2572 | Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | J. Case, D. Harrington, R. Presuhn, B. Wijnen. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2272 |
| Obsoleted by: | RFC 3412 |
| Status: | DRAFT STANDARD |
|
This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2571]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
|
| |
| RFC 2573 | SNMP Applications |
| |
| Authors: | D. Levi, P. Meyer, B. Stewart. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2273 |
| Obsoleted by: | RFC 3413 |
| Status: | DRAFT STANDARD |
|
This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2571]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
|
| |
| RFC 2574 | User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) |
| |
| Authors: | U. Blumenthal, B. Wijnen. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2274 |
| Obsoleted by: | RFC 3414 |
| Status: | DRAFT STANDARD |
|
This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2571]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
|
| |
| RFC 2575 | View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | B. Wijnen, R. Presuhn, K. McCloghrie. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2275 |
| Obsoleted by: | RFC 3415 |
| Status: | DRAFT STANDARD |
|
This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2571]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
|
| |
| RFC 2576 | Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework |
| |
| Authors: | R. Frye, D. Levi, S. Routhier, B. Wijnen. |
| Date: | March 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1908, RFC 2089 |
| Obsoleted by: | RFC 3584 |
| Status: | PROPOSED STANDARD |
|
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework,(SNMPv3), version 2 of the Internet-standard Network ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14]. |
|
| |
| RFC 2581 | TCP Congestion Control |
| |
| Authors: | M. Allman, V. Paxson, W. Stevens. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2001 |
| Obsoleted by: | RFC 5681 |
| Updated by: | RFC 3390 |
| Status: | PROPOSED STANDARD |
|
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. |
|
| |
| RFC 2582 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
| Authors: | S. Floyd, T. Henderson. |
| Date: | April 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3782 |
| Status: | EXPERIMENTAL |
|
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to asNewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. |
|
| |
| RFC 2587 | Internet X.509 Public Key Infrastructure LDAPv2 Schema |
| |
| Authors: | S. Boeyen, T. Howes, P. Richard. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4523 |
| Status: | PROPOSED STANDARD |
|
The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK] |
|
| |
| RFC 2591 | Definitions of Managed Objects for Scheduling Management Operations |
| |
| Authors: | D. Levi, J. Schoenwaelder. |
| Date: | May 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3231 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. |
|
| |
| RFC 2592 | Definitions of Managed Objects for the Delegation of Management Script |
| |
| Authors: | D. Levi, J. Schoenwaelder. |
| Date: | May 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3165 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. |
|
| |
| RFC 2593 | Script MIB Extensibility Protocol Version 1.0 |
| |
| Authors: | J. Schoenwaelder, J. Quittek. |
| Date: | May 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3179 |
| Status: | EXPERIMENTAL |
|
The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. |
|
| |
| RFC 2596 | Use of Language Codes in LDAP |
| |
| Authors: | M. Wahl, T. Howes. |
| Date: | May 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3866 |
| Status: | PROPOSED STANDARD |
|
This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK] |
|
| |
| RFC 2598 | An Expedited Forwarding PHB |
| |
| Authors: | V. Jacobson, K. Nichols, K. Poduri. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3246 |
| Status: | PROPOSED STANDARD |
|
The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given.
A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf |
|
| |
| RFC 2600 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden. |
| Date: | March 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2500 |
| Obsoleted by: | RFC 2700 |
| Status: | HISTORIC |
|
This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK] |
|
| |
| RFC 2604 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
| Authors: | R. Gellens. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2636 |
| Status: | INFORMATIONAL |
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2611 | URN Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3406 |
| Also: | BCP 0033 |
| Status: | BEST CURRENT PRACTICE |
|
The URN WG has defined a syntax for Uniform Resource Names (URNs)[RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces". |
|
| |
| RFC 2618 | RADIUS Authentication Client MIB |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4668 |
| Status: | PROPOSED STANDARD |
|
This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. |
|
| |
| RFC 2619 | RADIUS Authentication Server MIB |
| |
| Authors: | G. Zorn, B. Aboba. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4669 |
| Status: | PROPOSED STANDARD |
|
This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. |
|
| |
| RFC 2620 | RADIUS Accounting Client MIB |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4670 |
| Status: | INFORMATIONAL |
|
This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. |
|
| |
| RFC 2621 | RADIUS Accounting Server MIB |
| |
| Authors: | G. Zorn, B. Aboba. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4671 |
| Status: | INFORMATIONAL |
|
This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. |
|
| |
| RFC 2625 | IP and ARP over Fibre Channel |
| |
| Authors: | M. Rajagopal, R. Bhagwat, W. Rickard. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4338 |
| Status: | PROPOSED STANDARD |
|
Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small ComputerSystem Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards[3] do not adequately specify how IP packets may be transported overFC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and AddressResolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. |
|
| |
| RFC 2630 | Cryptographic Message Syntax |
| |
|
|
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management. |
|
| |
| RFC 2632 | S/MIME Version 3 Certificate Handling |
| |
| Authors: | B. Ramsdell, Ed.. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3850 |
| Status: | PROPOSED STANDARD |
|
S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK] |
|
| |
| RFC 2633 | S/MIME Version 3 Message Specification |
| |
| Authors: | B. Ramsdell, Ed.. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3851 |
| Status: | PROPOSED STANDARD |
|
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK] |
|
| |
| RFC 2639 | Internet Printing Protocol/1.0: Implementer's Guide |
| |
| Authors: | T. Hastings, C. Manros. |
| Date: | July 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3196 |
| Status: | INFORMATIONAL |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. TheJob supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2646 | The Text/Plain Format Parameter |
| |
| Authors: | R. Gellens, Ed.. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3676 |
| Updates: | RFC 2046 |
| Status: | PROPOSED STANDARD |
|
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK] |
|
| |
| RFC 2665 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
| Authors: | J. Flick, J. Johnson. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2358 |
| Obsoleted by: | RFC 3635 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2358, "Definitions of Managed Objects for theEthernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000Mb/s and full-duplex Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2667 | IP Tunnel MIB |
| |
| Authors: | D. Thaler. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4087 |
| Status: | PROPOSED STANDARD |
|
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK] |
|
| |
| RFC 2668 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
| Authors: | A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2239 |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2239, "Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2669 | DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems |
| |
| Authors: | M. St. Johns, Ed.. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4639 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable ModemTermination Systems.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2670 | Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces |
| |
| Authors: | M. St. Johns, Ed.. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4546 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2674 | Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions |
| |
| Authors: | E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4363 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.
Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes severalMIB modules in a manner that is compliant to the SMIv2 [V2SMI].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB]. |
|
| |
| RFC 2700 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden. |
| Date: | August 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2600 |
| Obsoleted by: | RFC 2800 |
| Status: | HISTORIC |
|
This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering TaskForce (IETF). Sections 3.1 - 3.6 contain the lists of protocols in each stage of standardization - Standard, Draft Standard, ProposedStandard, Experimental and Historic. Protocols that are new to this document or have been moved from one protocol level to another, or differ from the previous edition of this document are marked.Informational Request for Comments (RFCs) are not included. This memo lists the current protocols; it is not a complete index to RFCs. |
|
| |
| RFC 2705 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
| Authors: | M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. |
| Date: | October 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3435 |
| Updated by: | RFC 3660 |
| Status: | INFORMATIONAL |
|
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
The document is structured in 6 main sections:
* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.
* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress.
* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.
* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).
* The event packages section provides an initial definition of packages and event names.
* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0. |
|
| |
| RFC 2706 | ECML v1: Field Names for E-Commerce |
| |
| Authors: | D. Eastlake 3rd, T. Goldstein. |
| Date: | October 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3106 |
| Status: | INFORMATIONAL |
|
Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. |
|
| |
| RFC 2716 | PPP EAP TLS Authentication Protocol |
| |
| Authors: | B. Aboba, D. Simon. |
| Date: | October 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5216 |
| Status: | EXPERIMENTAL |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2717 | Registration Procedures for URL Scheme Names |
| |
| Authors: | R. Petke, I. King. |
| Date: | November 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4395 |
| Status: | BEST CURRENT PRACTICE |
|
This document defines the process by which new URL scheme names are registered. |
|
| |
| RFC 2718 | Guidelines for new URL Schemes |
| |
| Authors: | L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. |
| Date: | November 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4395 |
| Status: | INFORMATIONAL |
|
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet.This document provides guidelines for the definition of new URL schemes. |
|
| |
| RFC 2727 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
| Authors: | J. Galvin. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2282 |
| Obsoleted by: | RFC 3777 |
| Status: | BEST CURRENT PRACTICE |
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 2731 | Encoding Dublin Core Metadata in HTML |
| |
| Authors: | J. Kunze. |
| Date: | December 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5791 |
| Status: | INFORMATIONAL |
|
The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community. |
|
| |
| RFC 2732 | Format for Literal IPv6 Addresses in URL's |
| |
| Authors: | R. Hinden, B. Carpenter, L. Masinter. |
| Date: | December 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3986 |
| Updates: | RFC 2396 |
| Status: | PROPOSED STANDARD |
|
This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol.
This document incudes an update to the generic syntax for UniformResource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose. |
|
| |
| RFC 2733 | An RTP Payload Format for Generic Forward Error Correction |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | December 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
|
This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. |
|
| |
| RFC 2737 | Entity MIB (Version 2) |
| |
| Authors: | K. McCloghrie, A. Bierman. |
| Date: | December 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2037 |
| Obsoleted by: | RFC 4133 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. |
|
| |
| RFC 2740 | OSPF for IPv6 |
| |
| Authors: | R. Coltun, D. Ferguson, J. Moy. |
| Date: | December 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5340 |
| Status: | PROPOSED STANDARD |
|
This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header andEncapsulating Security Payload.
Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed.In addition, option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF(MOSPF) are also supported in OSPF for IPv6. |
|
| |
| RFC 2751 | Signaled Preemption Priority Policy Element |
| |
| Authors: | S. Herzog. |
| Date: | January 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3181 |
| Status: | PROPOSED STANDARD |
|
This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and[COPS]).
Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. |
|
| |
| RFC 2752 | Identity Representation for RSVP |
| |
| Authors: | S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog. |
| Date: | January 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3182 |
| Status: | PROPOSED STANDARD |
|
This document describes the representation of identity information inPOLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner.We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting. |
|
| |
| RFC 2754 | RPS IANA Issues |
| |
| Authors: | C. Alaettinoglu, C. Villamizar, R. Govindan. |
| Date: | January 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6254 |
| Status: | HISTORIC |
|
RPS Security [2] requires certain RPSL [1] objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required fromIANA. |
|
| |
| RFC 2763 | Dynamic Hostname Exchange Mechanism for IS-IS |
| |
| Authors: | N. Shen, H. Smit. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5301 |
| Status: | INFORMATIONAL |
|
Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. |
|
| |
| RFC 2765 | Stateless IP/ICMP Translation Algorithm (SIIT) |
| |
| Authors: | E. Nordmark. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6145 |
| Status: | PROPOSED STANDARD |
|
This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. |
|
| |
| RFC 2766 | Network Address Translation - Protocol Translation (NAT-PT) |
| |
| Authors: | G. Tsirtsis, P. Srisuresh. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4966 |
| Updated by: | RFC 3152 |
| Status: | HISTORIC |
|
This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified in [TRANS]. This solution attempts to provide transparent routing, as defined in [NAT-TERM], to end-nodes in V6 realm trying to communicate with end-nodes in V4 realm and vice versa. This is achieved using a combination of NetworkAddress Translation and Protocol Translation. The scheme described does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol support) or special purpose routing requirements (such as requiring tunneling support) on end nodes. This scheme is based on a combination of address translation theme as described in [NAT-TERM] and V6/V4 protocol translation theme as described in [SIIT]. |
|
| |
| RFC 2767 | Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) |
| |
| Authors: | K. Tsuchiya, H. Higuchi, Y. Atarashi. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6535 |
| Status: | INFORMATIONAL |
|
In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called"Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications. |
|
| |
| RFC 2770 | GLOP Addressing in 233/8 |
| |
| Authors: | D. Meyer, P. Lothberg. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3180 |
| Status: | EXPERIMENTAL |
|
This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]).
This memo is a product of the Multicast Deployment Working Group(MBONED) in the Operations and Management Area of the InternetEngineering Task Force. Submit comments to <mboned@ns.uoregon.edu&rt; or the authors. |
|
| |
| RFC 2777 | Publicly Verifiable Nomcom Random Selection |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | February 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3797 |
| Status: | INFORMATIONAL |
|
This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee from the pool of eligible volunteers is used.Similar techniques would be applicable to other cases. |
|
| |
| RFC 2787 | Definitions of Managed Objects for the Virtual Router Redundancy Protocol |
| |
| Authors: | B. Jewell, D. Chuang. |
| Date: | March 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6527 |
| Status: | PROPOSED STANDARD |
|
This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router RedundancyProtocol (VRRP) [17].
This memo specifies a MIB module in a manner that is compliant withSMIv2 [5], and semantically identical to the SMIv1 definitions [2]. |
|
| |
| RFC 2793 | RTP Payload for Text Conversation |
| |
| Authors: | G. Hellstrom. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4103 |
| Status: | PROPOSED STANDARD |
|
This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified inITU-T Recommendation T.140 [1].
Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services.
This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198. |
|
| |
| RFC 2796 | BGP Route Reflection - An Alternative to Full Mesh IBGP |
| |
| Authors: | T. Bates, R. Chandra, E. Chen. |
| Date: | April 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4456 |
| Updates: | RFC 1966 |
| Status: | PROPOSED STANDARD |
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within thatAS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP. |
|
| |
| RFC 2797 | Certificate Management Messages over CMS |
| |
| Authors: | M. Myers, X. Liu, J. Schaad, J. Weinstein. |
| Date: | April 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5272 |
| Status: | PROPOSED STANDARD |
|
This document defines a Certificate Management protocol using CMS(CMC). This protocol addresses two immediate needs within theInternet PKI community:
1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and2. The need in [SMIMEV3] for a certificate enrollment protocol forDSA-signed certificates with Diffie-Hellman public keys.
A small number of additional services are defined to supplement the core certificate request service.
Throughout this specification the term CMS is used to refer to both[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification. |
|
| |
| RFC 2800 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden, S. Ginoza. |
| Date: | May 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2700 |
| Obsoleted by: | RFC 2900 |
| Status: | HISTORIC |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to theRFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 2806 | URLs for Telephone Calls |
| |
| Authors: | A. Vaha-Sipila. |
| Date: | April 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3966 |
| Status: | PROPOSED STANDARD |
|
This document specifies URL (Uniform Resource Locator) schemes "tel","fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers. |
|
| |
| RFC 2821 | Simple Mail Transfer Protocol |
| |
|
|
This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following:
- the original SMTP (Simple Mail Transfer Protocol) specification ofRFC 821 [30],
- domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],
- the clarifications and applicability statements in RFC 1123 [2], and
- material drawn from the SMTP Extension mechanisms [19].
It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models.Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476[15].
Section 2.3 provides definitions of terms specific to this document.Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.
A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship. |
|
| |
| RFC 2822 | Internet Message Format |
| |
|
|
This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request ForComments (RFC) 822, "Standard for the Format of ARPA Internet TextMessages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
|
| |
| RFC 2828 | Internet Security Glossary |
| |
| Authors: | R. Shirey. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4949 |
| Status: | INFORMATIONAL |
|
This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion,ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future. |
|
| |
| RFC 2829 | Authentication Methods for LDAP |
| |
| Authors: | M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4513, RFC 4510 |
| Updated by: | RFC 3377 |
| Status: | PROPOSED STANDARD |
|
This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations. |
|
| |
| RFC 2830 | Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security |
| |
|
|
This document defines the "Start Transport Layer Security (TLS)Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of anLDAP extended request. |
|
| |
| RFC 2831 | Using Digest Authentication as a SASL Mechanism |
| |
| Authors: | P. Leach, C. Newman. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6331 |
| Status: | HISTORIC |
|
This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5[RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. |
|
| |
| RFC 2833 | RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals |
| |
| Authors: | H. Schulzrinne, S. Petrack. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4733, RFC 4734 |
| Status: | PROPOSED STANDARD |
|
This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. |
|
| |
| RFC 2836 | Per Hop Behavior Identification Codes |
| |
| Authors: | S. Brim, B. Carpenter, F. Le Faucheur. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3140 |
| Status: | PROPOSED STANDARD |
|
This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS TRACK] |
|
| |
| RFC 2837 | Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard |
| |
| Authors: | K. Teow. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4044 |
| Status: | PROPOSED STANDARD |
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre ChannelStandards. |
|
| |
| RFC 2842 | Capabilities Advertisement with BGP-4 |
| |
| Authors: | R. Chandra, J. Scudder. |
| Date: | May 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3392 |
| Status: | PROPOSED STANDARD |
|
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives anOPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities inBGP by providing graceful capability advertisement without requiring that BGP peering be terminated. |
|
| |
| RFC 2851 | Textual Conventions for Internet Network Addresses |
| |
| Authors: | M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. |
| Date: | June 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3291 |
| Status: | PROPOSED STANDARD |
|
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations.
This work is output from the Operations and Management Area "IPv6MIB" design team. |
|
| |
| RFC 2853 | Generic Security Service API Version 2 : Java Bindings |
| |
| Authors: | J. Kabat, M. Upadhyay. |
| Date: | June 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5653 |
| Status: | PROPOSED STANDARD |
|
The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE].
The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are TheSimple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5GSS-API Mechanism [KERBV5]. |
|
| |
| RFC 2858 | Multiprotocol Extensions for BGP-4 |
| |
| Authors: | T. Bates, Y. Rekhter, R. Chandra, D. Katz. |
| Date: | June 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2283 |
| Obsoleted by: | RFC 4760 |
| Status: | PROPOSED STANDARD |
|
Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions.
This document obsoletes RFC 2283. |
|
| |
| RFC 2877 | 5250 Telnet Enhancements |
| |
| Authors: | T. Murphy Jr., P. Rieth, J. Stevens. |
| Date: | July 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4777 |
| Updates: | RFC 1205 |
| Status: | INFORMATIONAL |
|
This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described.
By allowing a Telnet client to select the device name, the 5250Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing,2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange.
Applications may need to use system API's on the AS/400 in order to extract Telnet session settings from the device name description.Refer to the Retrieve Device Description (QDCRDEVD) API described in the AS/400 System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates.
This memo describes how the IBM 5250 Telnet server supports WorkStation Function (WSF) printers using 5250 Display Station Pass-Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session. |
|
| |
| RFC 2878 | PPP Bridging Control Protocol (BCP) |
| |
| Authors: | M. Higashiyama, F. Baker. |
| Date: | July 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1638 |
| Obsoleted by: | RFC 3518 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
This document obsoletes RFC 1638, which was based on the IEEE802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1QVirtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs. |
|
| |
| RFC 2885 | Megaco Protocol version 0.8 |
| |
| Authors: | F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers. |
| Date: | August 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3015 |
| Status: | HISTORIC |
|
This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. A merged document presenting the Megaco protocol with the Errata incorporated will be available shortly.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. |
|
| |
| RFC 2886 | Megaco Errata |
| |
| Authors: | T. Taylor. |
| Date: | August 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3015 |
| Status: | HISTORIC |
|
This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS TRACK] |
|
| |
| RFC 2893 | Transition Mechanisms for IPv6 Hosts and Routers |
| |
| Authors: | R. Gilligan, E. Nordmark. |
| Date: | August 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1933 |
| Obsoleted by: | RFC 4213 |
| Status: | PROPOSED STANDARD |
|
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933. |
|
| |
| RFC 2900 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden, S. Ginoza. |
| Date: | August 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2800 |
| Obsoleted by: | RFC 3000 |
| Status: | HISTORIC |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 2908 | The Internet Multicast Address Allocation Architecture |
| |
| Authors: | D. Thaler, M. Handley, D. Estrin. |
| Date: | September 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6308 |
| Status: | HISTORIC |
|
This document proposes a multicast address allocation architecture(MALLOC) for the Internet. The architecture is modular with three layers, comprising a host-server mechanism, an intra-domain server- server coordination mechanism, and an inter-domain mechanism. |
|
| |
| RFC 2915 | The Naming Authority Pointer (NAPTR) DNS Resource Record |
| |
|
|
This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label orUniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer(NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc).
This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource DiscoverySystems to moving out-of-date services to new domains.
This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR. |
|
| |
| RFC 2916 | E.164 number and DNS |
| |
| Authors: | P. Faltstrom. |
| Date: | September 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3761 |
| Status: | PROPOSED STANDARD |
|
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number.Routing of the actual connection using the service selected using these methods is not discussed. |
|
| |
| RFC 2925 | Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations |
| |
| Authors: | K. White. |
| Date: | September 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4560 |
| Status: | PROPOSED STANDARD |
|
This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to anIP address at a remote host.
Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. |
|
| |
| RFC 2929 | Domain Name System (DNS) IANA Considerations |
| |
| Authors: | D. Eastlake 3rd, E. Brunner-Williams, B. Manning. |
| Date: | September 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5395 |
| Status: | BEST CURRENT PRACTICE |
|
Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System(DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. |
|
| |
| RFC 2932 | IPv4 Multicast Routing MIB |
| |
| Authors: | K. McCloghrie, D. Farinacci, D. Thaler. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5132 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing IPMulticast Routing for IPv4, independent of the specific multicast routing protocol in use. |
|
| |
| RFC 2933 | Internet Group Management Protocol MIB |
| |
| Authors: | K. McCloghrie, D. Farinacci, D. Thaler. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5519 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing the InternetGroup Management Protocol (IGMP). |
|
| |
| RFC 2960 | Stream Control Transmission Protocol |
| |
| Authors: | R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4960 |
| Updated by: | RFC 3309 |
| Status: | PROPOSED STANDARD |
|
This document describes the Stream Control Transmission Protocol(SCTP). SCTP is designed to transport PSTN signaling messages overIP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:
-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi- homing at either or both ends of an association.
The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. |
|
| |
| RFC 2965 | HTTP State Management Mechanism |
| |
| Authors: | D. Kristol, L. Montulli. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2109 |
| Obsoleted by: | RFC 6265 |
| Status: | HISTORIC |
|
This document specifies a way to create a stateful session withHypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109 and obsoletes it. |
|
| |
| RFC 2966 | Domain-wide Prefix Distribution with Two-Level IS-IS |
| |
| Authors: | T. Li, T. Przygienda, H. Smit. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5302 |
| Status: | INFORMATIONAL |
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [2].
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. |
|
| |
| RFC 2976 | The SIP INFO Method |
| |
| Authors: | S. Donovan. |
| Date: | October 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6086 |
| Status: | PROPOSED STANDARD |
|
This document proposes an extension to the Session InitiationProtocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP andISDN signaling messages used to control telephony call services.
This and other example uses of the INFO method may be standardized in the future. |
|
| |
| RFC 2988 | Computing TCP's Retransmission Timer |
| |
| Authors: | V. Paxson, M. Allman. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6298 |
| Status: | PROPOSED STANDARD |
|
This document defines the standard algorithm that TransmissionControl Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. |
|
| |
| RFC 3000 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden, S. Ginoza, L. Shiota. |
| Date: | November 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2900 |
| Obsoleted by: | RFC 3300 |
| Status: | HISTORIC |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3001 | A URN Namespace of Object Identifiers |
| |
| Authors: | M. Mealling. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3061 |
| Status: | INFORMATIONAL |
|
This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). |
|
| |
| RFC 3008 | Domain Name System Security (DNSSEC) Signing Authority |
| |
|
|
This document proposes a revised model of Domain Name System Security(DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. |
|
| |
| RFC 3009 | Registration of parityfec MIME types |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
|
The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes.This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. |
|
| |
| RFC 3010 | NFS version 4 Protocol |
| |
| Authors: | S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. |
| Date: | December 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3530 |
| Status: | PROPOSED STANDARD |
|
NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. |
|
| |
| RFC 3012 | Mobile IPv4 Challenge/Response Extensions |
| |
| Authors: | C. Perkins, P. Calhoun. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4721 |
| Status: | PROPOSED STANDARD |
|
Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. |
|
| |
| RFC 3015 | Megaco Protocol Version 1.0 |
| |
| Authors: | F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2885, RFC 2886 |
| Obsoleted by: | RFC 3525 |
| Status: | PROPOSED STANDARD |
|
This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and aMedia Gateway Controller. The document is common text with ITU-TRecommendation H.248 and is a result of applying the changes in RFC2886 to the text of RFC 2885.
The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. |
|
| |
| RFC 3016 | RTP Payload Format for MPEG-4 Audio/Visual Streams |
| |
| Authors: | Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. |
| Date: | November 2000 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6416 |
| Status: | PROPOSED STANDARD |
|
This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications forMultipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP). |
|
| |
| RFC 3019 | IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol |
| |
| Authors: | B. Haberman, R. Worzella. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5519 |
| Status: | PROPOSED STANDARD |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in Internet ProtocolVersion 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the MulticastListener Discovery Protocol [RFC2710]. |
|
| |
| RFC 3025 | Mobile IP Vendor/Organization-Specific Extensions |
| |
| Authors: | G. Dommety, K. Leung. |
| Date: | February 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3115 |
| Status: | PROPOSED STANDARD |
|
This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. |
|
| |
| RFC 3028 | Sieve: A Mail Filtering Language |
| |
| Authors: | T. Showalter. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5228, RFC 5429 |
| Status: | PROPOSED STANDARD |
|
This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs. |
|
| |
| RFC 3036 | LDP Specification |
| |
| Authors: | L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5036 |
| Status: | PROPOSED STANDARD |
|
The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. |
|
| |
| RFC 3039 | Internet X.509 Public Key Infrastructure Qualified Certificates Profile |
| |
| Authors: | S. Santesson, W. Polk, P. Barzin, M. Nystrom. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3739 |
| Status: | PROPOSED STANDARD |
|
This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term QualifiedCertificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, QualifiedCertificates are issued exclusively to physical persons.
The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs.
It is important to note that the profile does not define any legal requirements for Qualified Certificates. |
|
| |
| RFC 3041 | Privacy Extensions for Stateless Address Autoconfiguration in IPv6 |
| |
| Authors: | T. Narten, R. Draves. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4941 |
| Status: | PROPOSED STANDARD |
|
Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host ConfigurationProtocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. |
|
| |
| RFC 3047 | RTP Payload Format for ITU-T Recommendation G.722.1 |
| |
| Authors: | P. Luthi. |
| Date: | January 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5577 |
| Status: | PROPOSED STANDARD |
|
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use ofG.722.1 with MIME and SDP. |
|
| |
| RFC 3057 | ISDN Q.921-User Adaptation Layer |
| |
| Authors: | K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. |
| Date: | February 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4233 |
| Updated by: | RFC 3807 |
| Status: | PROPOSED STANDARD |
|
This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. |
|
| |
| RFC 3065 | Autonomous System Confederations for BGP |
| |
| Authors: | P. Traina, D. McPherson, J. Scudder. |
| Date: | February 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1965 |
| Obsoleted by: | RFC 5065 |
| Status: | PROPOSED STANDARD |
|
The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. |
|
| |
| RFC 3066 | Tags for the Identification of Languages |
| |
|
|
This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. |
|
| |
| RFC 3075 | XML-Signature Syntax and Processing |
| |
| Authors: | D. Eastlake 3rd, J. Reagle, D. Solo. |
| Date: | March 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3275 |
| Status: | PROPOSED STANDARD |
|
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. |
|
| |
| RFC 3090 | DNS Security Extension Clarification on Zone Status |
| |
|
|
The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. |
|
| |
| RFC 3119 | A More Loss-Tolerant RTP Payload Format for MP3 Audio |
| |
| Authors: | R. Finlayson. |
| Date: | June 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5219 |
| Status: | PROPOSED STANDARD |
|
This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. |
|
| |
| RFC 3126 | Electronic Signature Formats for long term electronic signatures |
| |
| Authors: | D. Pinkas, J. Ross, N. Pope. |
| Date: | September 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5126 |
| Status: | INFORMATIONAL |
|
This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates the validity of the signature).
The format can be considered as an extension to RFC 2630 and RFC2634, where, when appropriate additional signed and unsigned attributes have been defined.
The contents of this Informational RFC is technically equivalent toETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org |
|
| |
| RFC 3138 | Extended Assignments in 233/8 |
| |
| Authors: | D. Meyer. |
| Date: | June 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5771 |
| Status: | INFORMATIONAL |
|
This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. |
|
| |
| RFC 3152 | Delegation of IP6.ARPA |
| |
|
|
This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. |
|
| |
| RFC 3160 | The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force |
| |
| Authors: | S. Harris. |
| Date: | August 2001 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1718 |
| Obsoleted by: | RFC 4677 |
| Status: | INFORMATIONAL |
|
This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process. |
|
| |
| RFC 3164 | The BSD Syslog Protocol |
| |
| Authors: | C. Lonvick. |
| Date: | August 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5424 |
| Status: | INFORMATIONAL |
|
This document describes the observed behavior of the syslog protocol.This protocol has been used for the transmission of event notification messages across networks for many years. While this protocol was originally developed on the University of CaliforniaBerkeley Software Distribution (BSD) TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices. |
|
| |
| RFC 3171 | IANA Guidelines for IPv4 Multicast Address Assignments |
| |
| Authors: | Z. Albanna, K. Almeroth, D. Meyer, M. Schipper. |
| Date: | August 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5771 |
| Status: | BEST CURRENT PRACTICE |
|
This memo provides guidance for the Internet Assigned NumbersAuthority (IANA) in assigning IPv4 multicast addresses. |
|
| |
| RFC 3177 | IAB/IESG Recommendations on IPv6 Address Allocations to Sites |
| |
| Authors: | IAB, IESG. |
| Date: | September 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6177 |
| Status: | INFORMATIONAL |
|
This document provides recommendations to the addressing registries(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of/48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record. |
|
| |
| RFC 3189 | RTP Payload Format for DV (IEC 61834) Video |
| |
| Authors: | K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. |
| Date: | January 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6469 |
| Status: | PROPOSED STANDARD |
|
This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). |
|
| |
| RFC 3211 | Password-based Encryption for CMS |
| |
| Authors: | P. Gutmann. |
| Date: | December 2001 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3369, RFC 3370 |
| Status: | PROPOSED STANDARD |
|
This document provides a method of encrypting data using user- supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. |
|
| |
| RFC 3220 | IP Mobility Support for IPv4 |
| |
| Authors: | C. Perkins, Ed.. |
| Date: | January 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2002 |
| Obsoleted by: | RFC 3344 |
| Status: | PROPOSED STANDARD |
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 3242 | RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP |
| |
| Authors: | L-E. Jonsson, G. Pelletier. |
| Date: | April 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4362 |
| Status: | PROPOSED STANDARD |
|
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. |
|
| |
| RFC 3250 | Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration |
| |
| Authors: | L. McIntyre, G. Parsons, J. Rafferty. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3950 |
| Status: | PROPOSED STANDARD |
|
This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax and its extensions. |
|
| |
| RFC 3266 | Support for IPv6 in Session Description Protocol (SDP) |
| |
| Authors: | S. Olson, G. Camarillo, A. B. Roach. |
| Date: | June 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4566 |
| Updates: | RFC 2327 |
| Status: | PROPOSED STANDARD |
|
This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP).Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. |
|
| |
| RFC 3267 | Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs |
| |
| Authors: | J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. |
| Date: | June 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4867 |
| Status: | PROPOSED STANDARD |
|
This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both theRTP payload format and the storage format. |
|
| |
| RFC 3268 | Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) |
| |
| Authors: | P. Chown. |
| Date: | June 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5246 |
| Status: | PROPOSED STANDARD |
|
This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) areRC2, RC4, International Data Encryption Algorithm (IDEA), DataEncryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. |
|
| |
| RFC 3276 | Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing |
| |
| Authors: | B. Ray, R. Abbi. |
| Date: | May 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4319 |
| Status: | PROPOSED STANDARD |
|
This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-PairHigh-Speed Digital Subscriber Line (SHDSL) interfaces. |
|
| |
| RFC 3278 | Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Blake-Wilson, D. Brown, P. Lambert. |
| Date: | April 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5753 |
| Status: | INFORMATIONAL |
|
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.
The readers attention is called to the Intellectual Property Rights section at the end of this document. |
|
| |
| RFC 3280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This memo profiles the X.509 v3 certificate and X.509 v2 CertificateRevocation List (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. AnASN.1 module and examples are provided in the appendices. |
|
| |
| RFC 3281 | An Internet Attribute Certificate Profile for Authorization |
| |
| Authors: | S. Farrell, R. Housley. |
| Date: | April 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5755 |
| Status: | PROPOSED STANDARD |
|
This specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. |
|
| |
| RFC 3285 | Using Microsoft Word to create Internet Drafts and RFCs |
| |
| Authors: | M. Gahrns, T. Hain. |
| Date: | May 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5385 |
| Status: | INFORMATIONAL |
|
This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. |
|
| |
| RFC 3288 | Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) |
| |
| Authors: | E. O'Tuathail, M. Rose. |
| Date: | June 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4227 |
| Status: | PROPOSED STANDARD |
|
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network.
The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. |
|
| |
| RFC 3291 | Textual Conventions for Internet Network Addresses |
| |
| Authors: | M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. |
| Date: | May 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2851 |
| Obsoleted by: | RFC 4001 |
| Status: | PROPOSED STANDARD |
|
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations.
This document obsoletes RFC 2851. |
|
| |
| RFC 3300 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. |
| Date: | November 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3000 |
| Obsoleted by: | RFC 3600 |
| Status: | HISTORIC |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 24, 2002. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3309 | Stream Control Transmission Protocol (SCTP) Checksum Change |
| |
| Authors: | J. Stone, R. Stewart, D. Otis. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4960 |
| Updates: | RFC 2960 |
| Status: | PROPOSED STANDARD |
|
Stream Control Transmission Protocol (SCTP) currently uses an Adler-32 checksum. For small packets Adler-32 provides weak detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum. |
|
| |
| RFC 3330 | Special-Use IPv4 Addresses |
| |
| Authors: | IANA. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5735 |
| Status: | INFORMATIONAL |
|
This document describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned NumbersAuthority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. |
|
| |
| RFC 3332 | Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) |
| |
| Authors: | G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed.. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4666 |
| Status: | PROPOSED STANDARD |
|
This memo defines a protocol for supporting the transport of any SS7MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a MediaGateway Controller (MGC) or IP-resident Database, or between twoIP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. |
|
| |
| RFC 3338 | Dual Stack Hosts Using "Bump-in-the-API" (BIA) |
| |
| Authors: | S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. |
| Date: | October 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6535 |
| Status: | EXPERIMENTAL |
|
This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications.The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation. |
|
| |
| RFC 3344 | IP Mobility Support for IPv4 |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 3369 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 3373 | Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies |
| |
| Authors: | D. Katz, R. Saluja. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5303 |
| Status: | INFORMATIONAL |
|
The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.
This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. |
|
| |
| RFC 3377 | Lightweight Directory Access Protocol (v3): Technical Specification |
| |
|
|
This document specifies the set of RFCs comprising the LightweightDirectory Access Protocol Version 3 (LDAPv3), and addresses the "IESGNote" attached to RFCs 2251 through 2256. |
|
| |
| RFC 3383 | Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | K. Zeilenga. |
| Date: | September 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4520 |
| Status: | BEST CURRENT PRACTICE |
|
This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). This document also provides guidelines to the Internet Assigned Numbers Authority(IANA) describing conditions under which new values can be assigned. |
|
| |
| RFC 3388 | Grouping of Media Lines in the Session Description Protocol (SDP) |
| |
| Authors: | G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5888 |
| Status: | PROPOSED STANDARD |
|
This document defines two Session Description Protocol (SDP) attributes: "group" and "mid". They allow to group together several"m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams) that are encoded in different formats during a particular session, on different ports and host interfaces. |
|
| |
| RFC 3392 | Capabilities Advertisement with BGP-4 |
| |
| Authors: | R. Chandra, J. Scudder. |
| Date: | November 2002 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2842 |
| Obsoleted by: | RFC 5492 |
| Status: | DRAFT STANDARD |
|
This document defines a new Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.
This document obsoletes RFC 2842. |
|
| |
| RFC 3427 | Change Process for the Session Initiation Protocol (SIP) |
| |
| Authors: | A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, B. Rosen. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5727 |
| Updated by: | RFC 3968, RFC 3969 |
| Status: | BEST CURRENT PRACTICE |
|
This memo documents a process intended to apply architectural discipline to the future development of the Session InitiationProtocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. |
|
| |
| RFC 3431 | Sieve Extension: Relational Tests |
| |
| Authors: | W. Segmuller. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5231 |
| Status: | PROPOSED STANDARD |
|
This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators.In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. |
|
| |
| RFC 3445 | Limiting the Scope of the KEY Resource Record (RR) |
| |
|
|
This document limits the Domain Name System (DNS) KEY Resource Record(RR) to only keys used by the Domain Name System Security Extensions(DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub- types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. |
|
| |
| RFC 3448 | TCP Friendly Rate Control (TFRC): Protocol Specification |
| |
| Authors: | M. Handley, S. Floyd, J. Padhye, J. Widmer. |
| Date: | January 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5348 |
| Status: | PROPOSED STANDARD |
|
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. |
|
| |
| RFC 3450 | Asynchronous Layered Coding (ALC) Protocol Instantiation |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5775 |
| Status: | EXPERIMENTAL |
|
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. |
|
| |
| RFC 3451 | Layered Coding Transport (LCT) Building Block |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5651 |
| Status: | EXPERIMENTAL |
|
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. |
|
| |
| RFC 3452 | Forward Error Correction (FEC) Building Block |
| |
| Authors: | M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5052, RFC 5445 |
| Status: | EXPERIMENTAL |
|
This document generally describes how to use Forward Error Correction(FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport usingIP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry.The procedures for specifying FEC codes and registering them with theInternet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward ErrorCorrection (FEC) in Reliable Multicast". |
|
| |
| RFC 3462 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| |
|
|
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports.
This document is part of a four document set describing the delivery status report service. This collection includes the Simple MailTransfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. |
|
| |
| RFC 3489 | STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) |
| |
| Authors: | J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. |
| Date: | March 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5389 |
| Status: | PROPOSED STANDARD |
|
Simple Traversal of User Datagram Protocol (UDP) Through NetworkAddress Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol(IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them.As a result, it allows a wide variety of applications to work through existing NAT infrastructure. |
|
| |
| RFC 3490 | Internationalizing Domain Names in Applications (IDNA) |
| |
| Authors: | P. Faltstrom, P. Hoffman, A. Costello. |
| Date: | March 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5890, RFC 5891 |
| Status: | PROPOSED STANDARD |
|
Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism calledInternationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so- called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. |
|
| |
| RFC 3491 | Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) |
| |
| Authors: | P. Hoffman, M. Blanchet. |
| Date: | March 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5891 |
| Status: | PROPOSED STANDARD |
|
This document describes how to prepare internationalized domain name(IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). |
|
| |
| RFC 3513 | Internet Protocol Version 6 (IPv6) Addressing Architecture |
| |
| Authors: | R. Hinden, S. Deering. |
| Date: | April 2003 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2373 |
| Obsoleted by: | RFC 4291 |
| Status: | PROPOSED STANDARD |
|
This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses. |
|
| |
| RFC 3525 | Gateway Control Protocol Version 1 |
| |
| Authors: | C. Groves, M. Pantaleo, T. Anderson, T. Taylor, Eds.. |
| Date: | June 2003 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3015 |
| Obsoleted by: | RFC 5125 |
| Status: | HISTORIC |
|
This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and aMedia Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.
This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T StudyGroup 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the MegacoE-mail list and incorporated into the Study Group 16 Implementor'sGuide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1.Because of ITU-T renumbering, it was published by the ITU-T asRecommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.
Users of this specification are advised to consult the H.248 Sub- series Implementors' Guide at http://www.itu.int/itudoc/itu- t/com16/implgd for additional corrections and clarifications. |
|
| |
| RFC 3534 | The application/ogg Media Type |
| |
| Authors: | L. Walleij. |
| Date: | May 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5334 |
| Status: | PROPOSED STANDARD |
|
The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the OggBitstream Format developers that it be usable without intellectual property concerns. |
|
| |
| RFC 3536 | Terminology Used in Internationalization in the IETF |
| |
| Authors: | P. Hoffman. |
| Date: | May 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6365 |
| Status: | INFORMATIONAL |
|
This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. |
|
| |
| RFC 3546 | Transport Layer Security (TLS) Extensions |
| |
| Authors: | S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. |
| Date: | June 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4366 |
| Updates: | RFC 2246 |
| Status: | PROPOSED STANDARD |
|
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. |
|
| |
| RFC 3547 | The Group Domain of Interpretation |
| |
| Authors: | M. Baugher, B. Weis, T. Hardjono, H. Harney. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6407 |
| Status: | PROPOSED STANDARD |
|
This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. TheGDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. |
|
| |
| RFC 3548 | The Base16, Base32, and Base64 Data Encodings |
| |
| Authors: | S. Josefsson, Ed.. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4648 |
| Status: | INFORMATIONAL |
|
This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. |
|
| |
| RFC 3555 | MIME Type Registration of RTP Payload Formats |
| |
|
|
This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences asMIME subtypes. Some of these may also be used for transfer modes other than RTP. |
|
| |
| RFC 3567 | Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication |
| |
| Authors: | T. Li, R. Atkinson. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5304 |
| Status: | INFORMATIONAL |
|
This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords.
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. |
|
| |
| RFC 3576 | Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. |
| Date: | July 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5176 |
| Status: | INFORMATIONAL |
|
This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. |
|
| |
| RFC 3598 | Sieve Email Filtering -- Subaddress Extension |
| |
| Authors: | K. Murchison. |
| Date: | September 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5233 |
| Status: | PROPOSED STANDARD |
|
On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses.This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. |
|
| |
| RFC 3600 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, Ed., S. Ginoza, Ed.. |
| Date: | November 2003 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3300 |
| Obsoleted by: | RFC 3700 |
| Status: | HISTORIC |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3603 | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
| Authors: | W. Marshall, Ed., F. Andreasen, Ed.. |
| Date: | October 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5503 |
| Status: | INFORMATIONAL |
|
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
|
| |
| RFC 3627 | Use of /127 Prefix Length Between Routers Considered Harmful |
| |
| Authors: | P. Savola. |
| Date: | September 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6547 |
| Status: | HISTORIC |
|
In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers.Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers. |
|
| |
| RFC 3636 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 MediumAttachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515. |
|
| |
| RFC 3655 | Redefinition of DNS Authenticated Data (AD) bit |
| |
|
|
This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy. |
|
| |
| RFC 3658 | Delegation Signer (DS) Resource Record (RR) |
| |
|
|
The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.
This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035,RFC 2535, RFC 3008 and RFC 3090. |
|
| |
| RFC 3664 | The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) |
| |
| Authors: | P. Hoffman. |
| Date: | January 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4434 |
| Status: | PROPOSED STANDARD |
|
Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, called AES-XCBC-PRF-128. |
|
| |
| RFC 3667 | IETF Rights in Contributions |
| |
| Authors: | S. Bradner. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3978 |
| Updates: | RFC 2026 |
| Status: | BEST CURRENT PRACTICE |
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC2026. |
|
| |
| RFC 3668 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418. |
|
| |
| RFC 3674 | Feature Discovery in Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | K. Zeilenga. |
| Date: | December 2003 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4512 |
| Status: | PROPOSED STANDARD |
|
The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms. |
|
| |
| RFC 3682 | The Generalized TTL Security Mechanism (GTSM) |
| |
| Authors: | V. Gill, J. Heasley, D. Meyer. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5082 |
| Status: | EXPERIMENTAL |
|
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),Bidirectional Forwarding Detection, and Label Distribution Protocol(LDP) (RFC 3036). While the Generalized TTL Security Mechanism(GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. |
|
| |
| RFC 3685 | SIEVE Email Filtering: Spamtest and VirusTest Extensions |
| |
| Authors: | C. Daboo. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5235 |
| Status: | PROPOSED STANDARD |
|
The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. |
|
| |
| RFC 3695 | Compact Forward Error Correction (FEC) Schemes |
| |
| Authors: | M. Luby, L. Vicisano. |
| Date: | February 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5445 |
| Status: | EXPERIMENTAL |
|
This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FECPayload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.
This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. |
|
| |
| RFC 3697 | IPv6 Flow Label Specification |
| |
| Authors: | J. Rajahalme, A. Conta, B. Carpenter, S. Deering. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6437 |
| Status: | PROPOSED STANDARD |
|
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. |
|
| |
| RFC 3700 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, Ed., S. Ginoza, Ed.. |
| Date: | July 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3600 |
| Obsoleted by: | RFC 5000 |
| Status: | HISTORIC |
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3730 | Extensible Provisioning Protocol (EPP) |
| |
| Authors: | S. Hollenbeck. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4930 |
| Status: | PROPOSED STANDARD |
|
This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. |
|
| |
| RFC 3731 | Extensible Provisioning Protocol (EPP) Domain Name Mapping |
| |
| Authors: | S. Hollenbeck. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4931 |
| Status: | PROPOSED STANDARD |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. |
|
| |
| RFC 3732 | Extensible Provisioning Protocol (EPP) Host Mapping |
| |
| Authors: | S. Hollenbeck. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4932 |
| Status: | PROPOSED STANDARD |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. |
|
| |
| RFC 3733 | Extensible Provisioning Protocol (EPP) Contact Mapping |
| |
| Authors: | S. Hollenbeck. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4933 |
| Status: | PROPOSED STANDARD |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. |
|
| |
| RFC 3734 | Extensible Provisioning Protocol (EPP) Transport Over TCP |
| |
| Authors: | S. Hollenbeck. |
| Date: | March 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4934 |
| Status: | PROPOSED STANDARD |
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. |
|
| |
| RFC 3755 | Legacy Resolver Compatibility for Delegation Signer (DS) |
| |
|
|
As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed.Many deployed nameservers understand variants of these semantics.Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. |
|
| |
| RFC 3757 | Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag |
| |
|
|
With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the DomainName System KEY (DNSKEY) resource record set. A flag bit in theDNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC2535 and RFC 3755. |
|
| |
| RFC 3761 | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) |
| |
|
|
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the DynamicDelegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. |
|
| |
| RFC 3768 | Virtual Router Redundancy Protocol (VRRP) |
| |
| Authors: | R. Hinden, Ed.. |
| Date: | April 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2338 |
| Obsoleted by: | RFC 5798 |
| Status: | DRAFT STANDARD |
|
This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. |
|
| |
| RFC 3770 | Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) |
| |
| Authors: | R. Housley, T. Moore. |
| Date: | May 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4334 |
| Status: | PROPOSED STANDARD |
|
This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). |
|
| |
| RFC 3771 | The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message |
| |
|
|
This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). TheIntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAPExtendedRequest and ExtendedResponse to define new single- request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. |
|
| |
| RFC 3775 | Mobility Support in IPv6 |
| |
| Authors: | D. Johnson, C. Perkins, J. Arkko. |
| Date: | June 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6275 |
| Status: | PROPOSED STANDARD |
|
This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation,Mobile IPv6 defines a new IPv6 protocol and a new destination option.All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. |
|
| |
| RFC 3782 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
| Authors: | S. Floyd, T. Henderson, A. Gurtov. |
| Date: | April 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2582 |
| Obsoleted by: | RFC 6582 |
| Status: | PROPOSED STANDARD |
|
The purpose of this document is to advance NewReno TCP's FastRetransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewRenoTCP. |
|
| |
| RFC 3784 | Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) |
| |
| Authors: | H. Smit, T. Li. |
| Date: | June 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5305 |
| Updated by: | RFC 4205 |
| Status: | INFORMATIONAL |
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. |
|
| |
| RFC 3786 | Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit |
| |
| Authors: | A. Hermelin, S. Previdi, M. Shand. |
| Date: | May 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5311 |
| Status: | INFORMATIONAL |
|
This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. |
|
| |
| RFC 3825 | Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information |
| |
| Authors: | J. Polk, J. Schnizlein, M. Linsner. |
| Date: | July 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6225 |
| Status: | PROPOSED STANDARD |
|
This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. TheLocation Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. |
|
| |
| RFC 3831 | Transmission of IPv6 Packets over Fibre Channel |
| |
| Authors: | C. DeSanti. |
| Date: | July 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4338 |
| Status: | PROPOSED STANDARD |
|
This document specifies the way of encapsulating IPv6 packets overFibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. |
|
| |
| RFC 3845 | DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format |
| |
|
|
This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. |
|
| |
| RFC 3847 | Restart Signaling for Intermediate System to Intermediate System (IS-IS) |
| |
| Authors: | M. Shand, L. Ginsberg. |
| Date: | July 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5306 |
| Status: | INFORMATIONAL |
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. |
|
| |
| RFC 3850 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling |
| |
| Authors: | B. Ramsdell, Ed.. |
| Date: | July 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2632 |
| Obsoleted by: | RFC 5750 |
| Status: | PROPOSED STANDARD |
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the InternetX.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. |
|
| |
| RFC 3851 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification |
| |
| Authors: | B. Ramsdell, Ed.. |
| Date: | July 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2633 |
| Obsoleted by: | RFC 5751 |
| Status: | PROPOSED STANDARD |
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. |
|
| |
| RFC 3852 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 3895 | Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types |
| |
| Authors: | O. Nicklass, Ed.. |
| Date: | September 2004 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2495 |
| Obsoleted by: | RFC 4805 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2495. |
|
| |
| RFC 3920 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
| Authors: | P. Saint-Andre, Ed.. |
| Date: | October 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6120 |
| Updated by: | RFC 6122 |
| Status: | PROPOSED STANDARD |
|
This memo defines the core features of the Extensible Messaging andPresence Protocol (XMPP), a protocol for streaming Extensible MarkupLanguage (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. |
|
| |
| RFC 3921 | Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence |
| |
| Authors: | P. Saint-Andre, Ed.. |
| Date: | October 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6121 |
| Status: | PROPOSED STANDARD |
|
This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. |
|
| |
| RFC 3932 | The IESG and RFC Editor Documents: Procedures |
| |
|
|
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
This document updates procedures described in RFC 2026 and RFC 3710. |
|
| |
| RFC 3940 | Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5740 |
| Status: | EXPERIMENTAL |
|
This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such asTransmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. |
|
| |
| RFC 3941 | Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5401 |
| Status: | EXPERIMENTAL |
|
This document discusses the creation of negative-acknowledgment(NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. |
|
| |
| RFC 3946 | Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control |
| |
| Authors: | E. Mannie, D. Papadimitriou. |
| Date: | October 2004 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4606 |
| Status: | PROPOSED STANDARD |
|
This document is a companion to the Generalized Multi-Protocol LabelSwitching (GMPLS) signaling. It defines the Synchronous OpticalNetwork (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. |
|
| |
| RFC 3978 | IETF Rights in Contributions |
| |
|
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC2026. |
|
| |
| RFC 3984 | RTP Payload Format for H.264 Video |
| |
| Authors: | S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer. |
| Date: | February 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6184 |
| Status: | PROPOSED STANDARD |
|
This memo describes an RTP Payload format for the ITU-TRecommendation H.264 video codec and the technically identicalISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network AbstractionLayer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, toInternet video streaming with interleaved transmission, to high bit- rate video-on-demand. |
|
| |
| RFC 3989 | Middlebox Communications (MIDCOM) Protocol Semantics |
| |
| Authors: | M. Stiemerling, J. Quittek, T. Taylor. |
| Date: | February 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5189 |
| Status: | INFORMATIONAL |
|
This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from theMIDCOM requirements, from the MIDCOM framework, and from working group decisions. |
|
| |
| RFC 4009 | The SEED Encryption Algorithm |
| |
| Authors: | J. Park, S. Lee, J. Kim, J. Lee. |
| Date: | February 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4269 |
| Status: | INFORMATIONAL |
|
This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). |
|
| |
| RFC 4049 | BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 |
| |
| Authors: | R. Housley. |
| Date: | April 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6019 |
| Status: | EXPERIMENTAL |
|
This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. |
|
| |
| RFC 4068 | Fast Handovers for Mobile IPv6 |
| |
| Authors: | R. Koodli, Ed.. |
| Date: | July 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5268 |
| Status: | EXPERIMENTAL |
|
Mobile IPv6 enables a Mobile Node to maintain its connectivity to theInternet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and BindingUpdate, is often unacceptable to real-time traffic such as Voice overIP. Reducing the handover latency could be beneficial to non-real- time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 4091 | The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework |
| |
| Authors: | G. Camarillo, J. Rosenberg. |
| Date: | June 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
|
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. |
|
| |
| RFC 4092 | Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, J. Rosenberg. |
| Date: | June 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
|
This document describes how to use the Alternative Network AddressTypes (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. |
|
| |
| RFC 4132 | Addition of Camellia Cipher Suites to Transport Layer Security (TLS) |
| |
| Authors: | S. Moriai, A. Kato, M. Kanda. |
| Date: | July 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5932 |
| Status: | PROPOSED STANDARD |
|
This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. |
|
| |
| RFC 4140 | Hierarchical Mobile IPv6 Mobility Management (HMIPv6) |
| |
| Authors: | H. Soliman, C. Castelluccia, K. El Malki, L. Bellier. |
| Date: | August 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5380 |
| Status: | EXPERIMENTAL |
|
This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. |
|
| |
| RFC 4148 | IP Performance Metrics (IPPM) Metrics Registry |
| |
| Authors: | E. Stephan. |
| Date: | August 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6248 |
| Also: | BCP 0108 |
| Status: | BEST CURRENT PRACTICE |
|
This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.
This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.
IANA has been assigned to administer this new registry. |
|
| |
| RFC 4205 | Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) |
| |
| Authors: | K. Kompella, Ed., Y. Rekhter, Ed.. |
| Date: | October 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5307 |
| Updates: | RFC 3784 |
| Status: | INFORMATIONAL |
|
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS). |
|
| |
| RFC 4214 | Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin, T. Gleeson, M. Talwar, D. Thaler. |
| Date: | October 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5214 |
| Status: | EXPERIMENTAL |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connectsIPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. |
|
| |
| RFC 4234 | Augmented BNF for Syntax Specifications: ABNF |
| |
| Authors: | D. Crocker, Ed., P. Overell. |
| Date: | October 2005 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2234 |
| Obsoleted by: | RFC 5234 |
| Status: | DRAFT STANDARD |
|
Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form(BNF), called Augmented BNF (ABNF), has been popular among manyInternet specifications. The current specification documents ABNF.It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF andABNF involve naming rules, repetition, alternatives, order- independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. |
|
| |
| RFC 4281 | The Codecs Parameter for "Bucket" Media Types |
| |
| Authors: | R. Gellens, D. Singer, P. Frojdh. |
| Date: | November 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
|
Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from theContent-Type alone if the content can be rendered.
This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.
By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action(such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) |
|
| |
| RFC 4294 | IPv6 Node Requirements |
| |
| Authors: | J. Loughney, Ed.. |
| Date: | April 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6434 |
| Updated by: | RFC 5095 |
| Status: | INFORMATIONAL |
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. |
|
| |
| RFC 4305 | Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. |
|
| |
| RFC 4306 | Internet Key Exchange (IKEv2) Protocol |
| |
|
|
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations(SAs).
This version of the IKE specification combines the contents of what were previously separate documents, including Internet SecurityAssociation and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC2409), the Internet Domain of Interpretation (DOI, RFC 2407), NetworkAddress Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.
Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. |
|
| |
| RFC 4310 | Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | S. Hollenbeck. |
| Date: | December 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5910 |
| Status: | PROPOSED STANDARD |
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. |
|
| |
| RFC 4325 | Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension |
| |
| Authors: | S. Santesson, R. Housley. |
| Date: | December 2005 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5280 |
| Updates: | RFC 3280 |
| Status: | PROPOSED STANDARD |
|
This document updates RFC 3280 by defining the Authority InformationAccess Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. |
|
| |
| RFC 4327 | Link Management Protocol (LMP) Management Information Base (MIB) |
| |
| Authors: | M. Dubuc, T. Nadeau, J. Lang, E. McGinnis. |
| Date: | January 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4631 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling the LinkManagement Protocol (LMP). |
|
| |
| RFC 4330 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
|
|
This memorandum describes the Simple Network Time Protocol Version 4(SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based onRFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.
This memorandum obsoletes RFC 1769, which describes SNTP Version 3(SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) andSNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation ofSNTP. |
|
| |
| RFC 4346 | The Transport Layer Security (TLS) Protocol Version 1.1 |
| |
|
|
This document specifies Version 1.1 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
|
| |
| RFC 4347 | Datagram Transport Layer Security |
| |
| Authors: | E. Rescorla, N. Modadugu. |
| Date: | April 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6347 |
| Updated by: | RFC 5746 |
| Status: | PROPOSED STANDARD |
|
This document specifies Version 1.0 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. |
|
| |
| RFC 4366 | Transport Layer Security (TLS) Extensions |
| |
|
|
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. |
|
| |
| RFC 4369 | Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) |
| |
| Authors: | K. Gibbons, C. Monia, J. Tseng, F. Travostino. |
| Date: | January 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6173 |
| Status: | PROPOSED STANDARD |
|
The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. |
|
| |
| RFC 4409 | Message Submission for Mail |
| |
| Authors: | R. Gellens, J. Klensin. |
| Date: | April 2006 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2476 |
| Obsoleted by: | RFC 6409 |
| Status: | DRAFT STANDARD |
|
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
Message relay and final delivery are unaffected, and continue to useSMTP over port 25.
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. |
|
| |
| RFC 4420 | Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
| |
| Authors: | A. Farrel, Ed., D. Papadimitriou, J.-P. Vasseur, A. Ayyangar. |
| Date: | February 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5420 |
| Updates: | RFC 3209, RFC 3473 |
| Status: | PROPOSED STANDARD |
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs. |
|
| |
| RFC 4507 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
| Authors: | J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. |
| Date: | May 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5077 |
| Status: | PROPOSED STANDARD |
|
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. |
|
| |
| RFC 4550 | Internet Email to Support Diverse Service Environments (Lemonade) Profile |
| |
| Authors: | S. Maes, A. Melnikov. |
| Date: | June 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5550 |
| Status: | PROPOSED STANDARD |
|
This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail.This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). |
|
| |
| RFC 4590 | RADIUS Extension for Digest Authentication |
| |
| Authors: | B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. |
| Date: | July 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5090 |
| Status: | PROPOSED STANDARD |
|
This document defines an extension to the Remote AuthenticationDial-In User Service (RADIUS) protocol to enable support of DigestAuthentication, for use with HTTP-style protocols like the SessionInitiation Protocol (SIP) and HTTP. |
|
| |
| RFC 4622 | Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre. |
| Date: | July 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5122 |
| Status: | PROPOSED STANDARD |
|
This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP). |
|
| |
| RFC 4630 | Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
| Authors: | R. Housley, S. Santesson. |
| Date: | August 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5280 |
| Updates: | RFC 3280 |
| Status: | PROPOSED STANDARD |
|
This document updates the handling of DirectoryString in the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding.The requirement for exclusive use of UTF8String after December 31,2003 is removed. |
|
| |
| RFC 4634 | US Secure Hash Algorithms (SHA and HMAC-SHA) |
| |
| Authors: | D. Eastlake 3rd, T. Hansen. |
| Date: | July 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6234 |
| Updates: | RFC 3174 |
| Status: | INFORMATIONAL |
|
The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), specifically SHA-224 (RFC3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS180-2.
Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. |
|
| |
| RFC 4646 | Tags for Identifying Languages |
| |
| Authors: | A. Phillips, M. Davis. |
| Date: | September 2006 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3066 |
| Obsoleted by: | RFC 5646 |
| Status: | BEST CURRENT PRACTICE |
|
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. |
|
| |
| RFC 4676 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information |
| |
| Authors: | H. Schulzrinne. |
| Date: | October 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4776 |
| Status: | PROPOSED STANDARD |
|
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. |
|
| |
| RFC 4693 | IETF Operational Notes |
| |
| Authors: | H. Alvestrand. |
| Date: | October 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6393 |
| Status: | HISTORIC |
|
This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.
It proposes to establish this series as an RFC 3933 process experiment. |
|
| |
| RFC 4695 | RTP Payload Format for MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | November 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6295 |
| Status: | PROPOSED STANDARD |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio. |
|
| |
| RFC 4718 | IKEv2 Clarifications and Implementation Guidelines |
| |
| Authors: | P. Eronen, P. Hoffman. |
| Date: | October 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5996 |
| Status: | INFORMATIONAL |
|
This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. |
|
| |
| RFC 4722 | Media Server Control Markup Language (MSCML) and Protocol |
| |
| Authors: | J. Van Dyke, E. Burger, Ed., A. Spitzer. |
| Date: | November 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5022 |
| Status: | INFORMATIONAL |
|
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. |
|
| |
| RFC 4741 | NETCONF Configuration Protocol |
| |
| Authors: | R. Enns, Ed.. |
| Date: | December 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6241 |
| Status: | PROPOSED STANDARD |
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. |
|
| |
| RFC 4742 | Using the NETCONF Configuration Protocol over Secure SHell (SSH) |
| |
| Authors: | M. Wasserman, T. Goddard. |
| Date: | December 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6242 |
| Status: | PROPOSED STANDARD |
|
This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. |
|
| |
| RFC 4748 | RFC 3978 Update to Recognize the IETF Trust |
| |
| Authors: | S. Bradner, Ed.. |
| Date: | October 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5378 |
| Updates: | RFC 3978 |
| Status: | BEST CURRENT PRACTICE |
|
This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of allIETF-related intellectual property rights.
This document does not constrain how the IETF Trust exercises those rights. |
|
| |
| RFC 4753 | ECP Groups For IKE and IKEv2 |
| |
| Authors: | D. Fu, J. Solinas. |
| Date: | January 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5903 |
| Status: | INFORMATIONAL |
|
This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to alignIKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. |
|
| |
| RFC 4756 | Forward Error Correction Grouping Semantics in Session Description Protocol |
| |
| Authors: | A. Li. |
| Date: | November 2006 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5956 |
| Status: | PROPOSED STANDARD |
|
This document defines the semantics that allow for grouping ofForward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in theSession Description Protocol" (RFC 3388) to group together "m" lines in the same session. |
|
| |
| RFC 4770 | vCard Extensions for Instant Messaging (IM) |
| |
| Authors: | C. Jennings, J. Reschke, Ed.. |
| Date: | January 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
|
This document describes an extension to vCard to support InstantMessaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. |
|
| |
| RFC 4813 | OSPF Link-Local Signaling |
| |
| Authors: | B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5613 |
| Status: | EXPERIMENTAL |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. |
|
| |
| RFC 4869 | Suite B Cryptographic Suites for IPsec |
| |
| Authors: | L. Law, J. Solinas. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6379 |
| Status: | INFORMATIONAL |
|
This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with theUnited States National Security Agency's Suite B specifications. |
|
| |
| RFC 4870 | Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) |
| |
| Authors: | M. Delany. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4871 |
| Status: | HISTORIC |
|
"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.
This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.
Proof and protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4871 | DomainKeys Identified Mail (DKIM) Signatures |
| |
| Authors: | E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 4870 |
| Obsoleted by: | RFC 6376 |
| Updated by: | RFC 5672 |
| Status: | PROPOSED STANDARD |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or MailUser Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4909 | Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport |
| |
| Authors: | L. Dondeti, Ed., D. Castleford, F. Hartung. |
| Date: | June 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5410, RFC 6309 |
| Status: | INFORMATIONAL |
|
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast(BCAST) group's Service and Content protection specification. |
|
| |
| RFC 4930 | Extensible Provisioning Protocol (EPP) |
| |
| Authors: | S. Hollenbeck. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3730 |
| Obsoleted by: | RFC 5730 |
| Status: | DRAFT STANDARD |
|
This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730. |
|
| |
| RFC 4931 | Extensible Provisioning Protocol (EPP) Domain Name Mapping |
| |
| Authors: | S. Hollenbeck. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3731 |
| Obsoleted by: | RFC 5731 |
| Status: | DRAFT STANDARD |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.This document obsoletes RFC 3731. |
|
| |
| RFC 4932 | Extensible Provisioning Protocol (EPP) Host Mapping |
| |
| Authors: | S. Hollenbeck. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3732 |
| Obsoleted by: | RFC 5732 |
| Status: | DRAFT STANDARD |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.This document obsoletes RFC 3732. |
|
| |
| RFC 4933 | Extensible Provisioning Protocol (EPP) Contact Mapping |
| |
| Authors: | S. Hollenbeck. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3733 |
| Obsoleted by: | RFC 5733 |
| Status: | DRAFT STANDARD |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733. |
|
| |
| RFC 4934 | Extensible Provisioning Protocol (EPP) Transport Over TCP |
| |
| Authors: | S. Hollenbeck. |
| Date: | May 2007 |
| Formats: | txt pdf |
| Obsoletes: | RFC 3734 |
| Obsoleted by: | RFC 5734 |
| Status: | DRAFT STANDARD |
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. This document obsoletes RFC 3734. |
|
| |
| RFC 4938 | PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics |
| |
| Authors: | B. Berry, H. Holgate. |
| Date: | June 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5578 |
| Status: | INFORMATIONAL |
|
This document extends the Point-to-Point over Ethernet (PPPoE)Protocol with a credit-based flow control mechanism and Link QualityMetric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. |
|
| |
| RFC 4952 | Overview and Framework for Internationalized Email |
| |
| Authors: | J. Klensin, Y. Ko. |
| Date: | July 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6530 |
| Updated by: | RFC 5336 |
| Status: | INFORMATIONAL |
|
Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. |
|
| |
| RFC 4995 | The RObust Header Compression (ROHC) Framework |
| |
| Authors: | L-E. Jonsson, G. Pelletier, K. Sandlund. |
| Date: | July 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5795 |
| Status: | PROPOSED STANDARD |
|
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. |
|
| |
| RFC 5006 | IPv6 Router Advertisement Option for DNS Configuration |
| |
| Authors: | J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. |
| Date: | September 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6106 |
| Status: | EXPERIMENTAL |
|
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses toIPv6 hosts. |
|
| |
| RFC 5008 | Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) |
| |
| Authors: | R. Housley, J. Solinas. |
| Date: | September 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6318 |
| Status: | INFORMATIONAL |
|
This document specifies the conventions for using the United StatesNational Security Agency's Suite B algorithms in Secure/MultipurposeInternet Mail Extensions (S/MIME) as specified in RFC 3851. |
|
| |
| RFC 5075 | IPv6 Router Advertisement Flags Option |
| |
| Authors: | B. Haberman, Ed., R. Hinden. |
| Date: | November 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5175 |
| Status: | PROPOSED STANDARD |
|
The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. |
|
| |
| RFC 5081 | Using OpenPGP Keys for Transport Layer Security (TLS) Authentication |
| |
| Authors: | N. Mavrogiannopoulos. |
| Date: | November 2007 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6091 |
| Status: | EXPERIMENTAL |
|
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. |
|
| |
| RFC 5143 | Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation |
| |
| Authors: | A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang. |
| Date: | February 2008 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4842 |
| Status: | HISTORIC |
|
This document describes a historical method for encapsulatingSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Path signals for transport across packet-switched networks (PSNs).The PSNs explicitly supported by this document include MPLS and IP.Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. |
|
| |
| RFC 5208 | Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 |
| |
| Authors: | B. Kaliski. |
| Date: | May 2008 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5958 |
| Status: | INFORMATIONAL |
|
This document represents a republication of PKCS #8 v1.2 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.
This document describes a syntax for private-key information. |
|
| |
| RFC 5268 | Mobile IPv6 Fast Handovers |
| |
| Authors: | R. Koodli, Ed.. |
| Date: | June 2008 |
| Formats: | txt pdf |
| Obsoletes: | RFC 4068 |
| Obsoleted by: | RFC 5568 |
| Status: | PROPOSED STANDARD |
|
Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, andBinding Update, is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 5335 | Internationalized Email Headers |
| |
|
|
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant ofInternet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. |
|
| |
| RFC 5336 | SMTP Extension for Internationalized Email Addresses |
| |
|
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952. |
|
| |
| RFC 5337 | Internationalized Delivery Status and Disposition Notifications |
| |
|
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document experimentally extends RFC 3461, RFC 3464, and RFC3798. |
|
| |
| RFC 5395 | Domain Name System (DNS) IANA Considerations |
| |
|
|
Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System(DNS) resource record types, CLASSes, operation codes, error codes,DNS protocol message header bits, and AFSDB resource record subtypes. |
|
| |
| RFC 5414 | Wireless LAN Control Protocol (WiCoP) |
| |
| Authors: | S. Iino, S. Govindan, M. Sugiura, H. Cheng. |
| Date: | February 2010 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 5415 |
| Status: | HISTORIC |
|
The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points(WTPs) and covering substantial areas are increasingly common.
The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of WirelessAccess Points (CAPWAP). |
|
| |
| RFC 5430 | Suite B Profile for Transport Layer Security (TLS) |
| |
| Authors: | M. Salter, E. Rescorla, R. Housley. |
| Date: | March 2009 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6460 |
| Status: | INFORMATIONAL |
|
The United States government has published guidelines for "NSA SuiteB Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile ofTransport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible. |
|
| |
| RFC 5467 | GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric. |
| Date: | March 2009 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6387 |
| Status: | EXPERIMENTAL |
|
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. |
|
| |
| RFC 5504 | Downgrading Mechanism for Email Address Internationalization |
| |
| Authors: | K. Fujiwara, Ed., Y. Yoneya, Ed.. |
| Date: | March 2009 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6530 |
| Status: | EXPERIMENTAL |
|
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email AddressInternationalization (UTF8SMTP) extension allows UTF-8 characters inSMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. |
|
| |
| RFC 5672 | RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update |
| |
| Authors: | D. Crocker, Ed.. |
| Date: | August 2009 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6376 |
| Updates: | RFC 4871 |
| Status: | PROPOSED STANDARD |
|
This document updates RFC 4871, "DomainKeys Identified Mail (DKIM)Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.The Update is in the style of an Errata entry, albeit a rather long one. |
|
| |
| RFC 5825 | Displaying Downgraded Messages for Email Address Internationalization |
| |
| Authors: | K. Fujiwara, B. Leiba. |
| Date: | April 2010 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6530 |
| Status: | EXPERIMENTAL |
|
This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. |
|
| |
| RFC 5953 | Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | W. Hardaker. |
| Date: | August 2010 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6353 |
| Status: | PROPOSED STANDARD |
|
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of aSNMP Transport Subsystem to make this protection possible in an interoperable way.
This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.
This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. |
|
| |
| RFC 6045 | Real-time Inter-network Defense (RID) |
| |
| Authors: | K. Moriarty. |
| Date: | November 2010 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6545 |
| Status: | INFORMATIONAL |
|
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system.Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter- network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. |
|
| |
| RFC 6046 | Transport of Real-time Inter-network Defense (RID) Messages |
| |
| Authors: | K. Moriarty, B. Trammell. |
| Date: | November 2010 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6546 |
| Status: | INFORMATIONAL |
|
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). |
|
| |
| RFC 6312 | Mobile Networks Considerations for IPv6 Deployment |
| |
| Authors: | R. Koodli. |
| Date: | July 2011 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 6342 |
| Status: | INFORMATIONAL |
|
Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. |
|
