Internet Documents

RFCs 1300 - 1399s

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

PROPOSEDDRAFTSTANDARDEXPMTLBCPINFOHISTORICUPDATEDOBSOLETEDUNKNOWN

 
RFC 1300 Remembrances of Things Past
 
Authors:S. Greenfield.
Date:February 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1300
Poem. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1301 Multicast Transport Protocol
 
Authors:S. Armstrong, A. Freier, K. Marzullo.
Date:February 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1301
This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1302 Building a Network Information Services Infrastructure
 
Authors:D. Sitzler, P. Smith, A. Marine.
Date:February 1992
Formats:txt html json
Also:FYI 0012
Status:INFORMATIONAL
DOI:10.17487/RFC 1302
This FYI RFC document is intended for existing Internet NetworkInformation Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. The document strives to:

- Define a basic set of essential services that NetworkInformation Centers (NICs) will provide to Internet users, including new mechanisms that will facilitate the timely dissemination of information to the Internet community and encourage cooperation among NICs.

- Describe existing NIC services as an aid to Internet users and as a model for organizations establishing new NICs.

 
RFC 1303 A Convention for Describing SNMP-based Agents
 
Authors:K. McCloghrie, M. Rose.
Date:February 1992
Formats:txt html json
Also:RFC 1155, RFC 1157, RFC 1212, RFC 1213
Status:INFORMATIONAL
DOI:10.17487/RFC 1303
This memo suggests a straight-forward approach towards describingSNMP-based agents.
 
RFC 1304 Definitions of Managed Objects for the SIP Interface Type
 
Authors:T. Cox, Ed., K. Tesink, Ed..
Date:February 1992
Formats:txt json html
Obsoleted by:RFC 1694
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1304
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
 
Authors:D. Mills.
Date:March 1992
Formats:txt json tar html pdf
Obsoletes:RFC 0958, RFC 1059, RFC 1119
Obsoleted by:RFC 5905
Status:DRAFT STANDARD
DOI:10.17487/RFC 1305
This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]
 
RFC 1306 Experiences Supporting By-Request Circuit-Switched T3 Networks
 
Authors:A. Nicholson, J. Young.
Date:March 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1306
This memo describes the experiences of a project team at CrayResearch, Inc., in implementing support for circuit-switched T3 services. 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 implementers.

Developers at Cray Research, Inc. were presented with an opportunity to use a circuit-switched T3 network for wide area networking. They devised an architectural model for using this new resource. This involves activating the circuit-switched connection when an application program engages in a bulk data transfer, and releasing the connection when the transfer is complete.

Three software implementations for this feature have been tested, and the results documented here. A variety of issues are involved, and further research is necessary. Network users are beginning to recognize the value of this service, and are planning to make use of by-request circuit-switched networks. A standard method of access will be needed to ensure interoperability among vendors of circuit- switched network support products.

 
RFC 1307 Dynamically Switched Link Control Protocol
 
Authors:J. Young, A. Nicholson.
Date:March 1992
Formats:txt html json
Status:EXPERIMENTAL
DOI:10.17487/RFC 1307
This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit- switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. It is documented here for the benefit of others who may wish to perform further research.

While working with circuit-switched T3 networks, developers at CrayResearch, Inc., defined a model wherein a host would generate control messages for a network switch. This work is described in RFC 1306,"Experiences Supporting By-Request Circuit-Switched T3 Networks". In order to simplify the model it was decided that the inconsistencies of switch control should be hidden from the host generating the control messages. To that end, a protocol was defined and implemented. This RFC documents the Dynamically Switched LinkControl Protocol (DSLCP), which is used for creation and control of downstream network links by a host.

 
RFC 1308 Executive Introduction to Directory Services Using the X.500 Protocol
 
Authors:C. Weider, J. Reynolds.
Date:March 1992
Formats:txt json html
Also:FYI 0013
Status:INFORMATIONAL
DOI:10.17487/RFC 1308
This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500.

This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF).

 
RFC 1309 Technical Overview of Directory Services Using the X.500 Protocol
 
Authors:C. Weider, J. Reynolds, S. Heker.
Date:March 1992
Formats:txt json html
Also:FYI 0014
Status:INFORMATIONAL
DOI:10.17487/RFC 1309
This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts DirectoryServices based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information.

A primary purpose of this paper is to illustrate the vast functionality of the X.500 protocol and to show how it can be used to provide a global directory for human use, and can support other applications which would benefit from directory services, such as main programs.

This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF).

 
RFC 1310 The Internet Standards Process
 
Authors:L. Chapin.
Date:March 1992
Formats:txt json html
Obsoleted by:RFC 1602
Status:INFORMATIONAL
DOI:10.17487/RFC 1310
This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]
 
RFC 1311 Introduction to the STD Notes
 
Authors:J. Postel.
Date:March 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1311
The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS- TRACK]
 
RFC 1312 Message Send Protocol 2
 
Authors:R. Nelson, G. Arnold.
Date:April 1992
Formats:txt html json
Obsoletes:RFC 1159
Status:EXPERIMENTAL
DOI:10.17487/RFC 1312
The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1313 Today's Programming for KRFC AM 1313 Internet Talk Radio
 
Authors:C. Partridge.
Date:1 April 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1313
Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1314 A File Format for the Exchange of Images in the Internet
 
Authors:A. Katz, D. Cohen.
Date:April 1992
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 1314
This document defines a standard file format for the exchange of fax-like black and white images within the Internet. It is a product of the Network Fax Working Group of the Internet Engineering TaskForce (IETF).

The standard is:

** The file format should be TIFF-B with multi-page files supported. Images should be encoded as one TIFF strip per page.

** Images should be compressed using MMR when possible. Images may also be MH or MR compressed or uncompressed. If MH or MR compression is used, scan lines should be "byte-aligned".

** For maximum interoperability, image resolutions should either be 600, 400, or 300 dpi; or else be one of the standard Group 3 fax resolutions (98 or 196 dpi vertically and 204 dpi horizontally).

Note that this specification is self contained and an implementation should be possible without recourse to the TIFF references, and that only the specific TIFF documents cited are relevant to this specification. Updates to the TIFF documents do not change this specification.

Experimentation with this file format specified here is encouraged.

 
RFC 1315 Management Information Base for Frame Relay DTEs
 
Authors:C. Brown, F. Baker, C. Carvalho.
Date:April 1992
Formats:txt json html
Obsoleted by:RFC 2115
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1315
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 html json
Obsoleted by:RFC 1658
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1316
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 html json
Obsoleted by:RFC 1659
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1317
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 json html
Obsoleted by:RFC 1660
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1318
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 json html
Obsoleted by:RFC 6149
Status:HISTORIC
DOI:10.17487/RFC 1319
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
 
Authors:R. Rivest.
Date:April 1992
Formats:txt json html
Obsoletes:RFC 1186
Obsoleted by:RFC 6150
Status:HISTORIC
DOI:10.17487/RFC 1320
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 1321 The MD5 Message-Digest Algorithm
 
Authors:R. Rivest.
Date:April 1992
Formats:txt json html
Updated by:RFC 6151
Status:INFORMATIONAL
DOI:10.17487/RFC 1321
This document describes the MD5 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 1322 A Unified Approach to Inter-Domain Routing
 
Authors:D. Estrin, Y. Rekhter, S. Hotz.
Date:May 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1322
This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. The focus is on scalability to very large networks and functionality, as well as scalability, to support routing in an environment of heterogeneous services, requirements, and route selection criteria.

Note: The work of D. Estrin and S. Hotz was supported by the NationalScience Foundation under contract number NCR-9011279, with matching funds from GTE Laboratories. The work of Y. Rekhter was supported by the Defense Advanced Research Projects Agency, under contractDABT63-91-C-0019. Views and conclusions expressed in this paper are not necessarily those of the Defense Advanced Research ProjectsAgency and National Science Foundation.

 
RFC 1323 TCP Extensions for High Performance
 
Authors:V. Jacobson, R. Braden, D. Borman.
Date:May 1992
Formats:txt html json
Obsoletes:RFC 1072, RFC 1185
Obsoleted by:RFC 7323
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1323
This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms:RTTM (Round Trip Time Measurement) and PAWS (Protect Against WrappedSequences). Selective acknowledgments are not included in this memo.

This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification. Appendix C summarizes the changes from the earlier RFCs.

 
RFC 1324 A Discussion on Computer Network Conferencing
 
Authors:D. Reed.
Date:May 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1324
This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. It is also the intention of this memo to stimulate the computer community and generate some useful discussion about the merits of this field.
 
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 json html
Obsoletes:RFC 1206
Obsoleted by:RFC 1594
Status:INFORMATIONAL
DOI:10.17487/RFC 1325
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 1326 Mutual Encapsulation Considered Dangerous
 
Authors:P. Tsuchiya.
Date:May 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1326
This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A).
 
RFC 1327 Mapping between X.400(1988) / ISO 10021 and RFC 822
 
Authors:S. Hardcastle-Kille.
Date:May 1992
Formats:txt html json
Obsoletes:RFC 0987, RFC 1026, RFC 1138, RFC 1148
Obsoleted by:RFC 2156
Updates:RFC 0822
Updated by:RFC 1495
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1327
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 1328 X.400 1988 to 1984 downgrading
 
Authors:S. Hardcastle-Kille.
Date:May 1992
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 1328
This document considers issues of downgrading from X.400(1988) toX.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe.

This specification is not tutorial. COSINE Study 8.2 by J.A.I.Craigie gives a useful overview [Cra88].

 
RFC 1329 Thoughts on Address Resolution for Dual MAC FDDI Networks
 
Authors:P. Kuehn.
Date:May 1992
Formats:txt json html
Updated by:RFC 5494
Status:INFORMATIONAL
DOI:10.17487/RFC 1329
In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community
 
Authors:ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet).
Date:May 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1330
This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links
 
Authors:W. Simpson.
Date:May 1992
Formats:txt json html
Obsoletes:RFC 1171, RFC 1172
Obsoleted by:RFC 1548
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1331
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 1332 The PPP Internet Protocol Control Protocol (IPCP)
 
Authors:G. McGregor.
Date:May 1992
Formats:txt html json
Obsoletes:RFC 1172
Updated by:RFC 3241
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1332
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 configuring theInternet Protocol [2] over PPP, and a method to negotiate and use VanJacobson TCP/IP header compression [3] with PPP.

This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).

 
RFC 1333 PPP Link Quality Monitoring
 
Authors:W. Simpson.
Date:May 1992
Formats:txt html json
Obsoleted by:RFC 1989
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1333
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 json html
Obsoleted by:RFC 1994
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1334
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 1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion
 
Authors:Z. Wang, J. Crowcroft.
Date:May 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1335
This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for theInternet. This is an "idea" paper and discussion is strongly encouraged.
 
RFC 1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members
 
Authors:G. Malkin.
Date:May 1992
Formats:txt html json
Obsoletes:RFC 1251
Also:FYI 0009
Status:INFORMATIONAL
DOI:10.17487/RFC 1336
This FYI RFC contains biographical information about members of theInternet Activities Board (IAB), the Internet Engineering SteeringGroup (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet ResearchTask Force (IRTF).
 
RFC 1337 TIME-WAIT Assassination Hazards in TCP
 
Authors:R. Braden.
Date:May 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1337
This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified.
 
RFC 1338 Supernetting: an Address Assignment and Aggregation Strategy
 
Authors:V. Fuller, T. Li, J. Yu, K. Varadhan.
Date:June 1992
Formats:txt json html
Obsoleted by:RFC 1519
Status:INFORMATIONAL
DOI:10.17487/RFC 1338
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 1339 Remote Mail Checking Protocol
 
Authors:S. Dorner, P. Resnick.
Date:June 1992
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 1339
This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user.
 
RFC 1340 Assigned Numbers
 
Authors:J. Reynolds, J. Postel.
Date:July 1992
Formats:txt html json
Obsoletes:RFC 1060
Obsoleted by:RFC 1700
Status:HISTORIC
DOI:10.17487/RFC 1340
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 html pdf json ps
Obsoleted by:RFC 1521
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1341
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 json html
Obsoleted by:RFC 1522
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1342
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 1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information
 
Authors:N. Borenstein.
Date:June 1992
Formats:txt json pdf html ps
Status:INFORMATIONAL
DOI:10.17487/RFC 1343
This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1344 Implications of MIME for Internet Mail Gateways
 
Authors:N. Borenstein.
Date:June 1992
Formats:txt html pdf json ps
Status:INFORMATIONAL
DOI:10.17487/RFC 1344
While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1345 Character Mnemonics and Character Sets
 
Authors:K. Simonsen.
Date:June 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1345
This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1346 Resource Allocation, Control, and Accounting for the Use of Network Resources
 
Authors:P. Jones.
Date:June 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1346
The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing
 
Authors:R. Callon.
Date:June 1992
Formats:txt json pdf ps html
Status:HISTORIC
DOI:10.17487/RFC 1347
This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1348 DNS NSAP RRs
 
Authors:B. Manning.
Date:July 1992
Formats:txt html json
Obsoleted by:RFC 1637
Updates:RFC 1034, RFC 1035
Status:EXPERIMENTAL
DOI:10.17487/RFC 1348
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
 
Authors:P. Almquist.
Date:July 1992
Formats:txt html json
Obsoleted by:RFC 2474
Updates:RFC 1248, RFC 1247, RFC 1195, RFC 1123, RFC 1122, RFC 1060, RFC 0791
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1349
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 1350 The TFTP Protocol (Revision 2)
 
Authors:K. Sollins.
Date:July 1992
Formats:txt html json
Obsoletes:RFC 0783
Updated by:RFC 1782, RFC 1783, RFC 1784, RFC 1785, RFC 2347, RFC 2348, RFC 2349
Also:STD 0033
Status:INTERNET STANDARD
DOI:10.17487/RFC 1350
TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]
 
RFC 1351 SNMP Administrative Model
 
Authors:J. Davin, J. Galvin, K. McCloghrie.
Date:July 1992
Formats:txt html json
Status:HISTORIC
DOI:10.17487/RFC 1351
This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]
 
RFC 1352 SNMP Security Protocols
 
Authors:J. Galvin, K. McCloghrie, J. Davin.
Date:July 1992
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 1352
The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]
 
RFC 1353 Definitions of Managed Objects for Administration of SNMP Parties
 
Authors:K. McCloghrie, J. Davin, J. Galvin.
Date:July 1992
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 1353
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 describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet StandardSMI [1]. These definitions are consistent with the SNMP Security protocols set forth in [9].
 
RFC 1354 IP Forwarding Table MIB
 
Authors:F. Baker.
Date:July 1992
Formats:txt html json
Obsoleted by:RFC 2096
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1354
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 1355 Privacy and Accuracy Issues in Network Information Center Databases
 
Authors:J. Curran, A. Marine.
Date:August 1992
Formats:txt html json
Also:FYI 0015
Status:INFORMATIONAL
DOI:10.17487/RFC 1355
This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. The purpose is to formalize procedures for the responsible handling of the personal and organizational information maintained by NICs in publically accessible databases, and to improve the accuracy and accessibility of such data where appropriate.
 
RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode
 
Authors:A. Malis, D. Robinson, R. Ullmann.
Date:August 1992
Formats:txt json html
Obsoletes:RFC 0877
Status:DRAFT STANDARD
DOI:10.17487/RFC 1356
This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment withISO/IEC and CCITT standards. It is a replacement for RFC 877, "AStandard for the Transmission of IP Datagrams Over Public DataNetworks" [1].

It was written to correct several ambiguities in the InternetStandard for IP/X.25 (RFC 877), to align it with ISO/IEC standards that have been written following RFC 877, to allow interoperable multiprotocol operation between routers and bridges over X.25, and to add some additional remarks based upon practical experience with the specification over the 8 years since that RFC.

The substantive change to the IP encapsulation is an increase in the allowed IP datagram Maximum Transmission Unit from 576 to 1600, to reflect existing practice.

This document also specifies the Internet encapsulation for protocols, including IP, on the packet mode of the ISDN. It applies to the use of Internet protocols on the ISDN in the circuit mode only when the circuit is established as an end-to-end X.25 connection.

 
RFC 1357 A Format for E-mailing Bibliographic Records
 
Authors:D. Cohen.
Date:July 1992
Formats:txt json html
Obsoleted by:RFC 1807
Status:INFORMATIONAL
DOI:10.17487/RFC 1357
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 html json
Obsoleted by:RFC 1601
Status:INFORMATIONAL
DOI:10.17487/RFC 1358
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 1359 Connecting to the Internet - What Connecting Institutions Should Anticipate
 
Authors:ACM SIGUCCS.
Date:August 1992
Formats:txt html json
Also:FYI 0016
Status:INFORMATIONAL
DOI:10.17487/RFC 1359
This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to theInternet.

In order to provide clarity to the reader, some specific information has been detailed. In doing so, the document has been directed toward U.S. academic institutions that have not yet connected to theInternet.

However, the issues for which specific information has been provided can be generalized for any organization that wishes to participate in the world-wide Internet community. It will be necessary for those organizations to obtain the correct and detailed information from their local or national IP service providers. In addition, this document may be used as an evaluation checklist for organizations that are currently connected. Readers are expected to have general familiarity with networking concepts and terminology.

 
RFC 1360 IAB Official Protocol Standards
 
Authors:J. Postel.
Date:September 1992
Formats:txt html json
Obsoletes:RFC 1280
Obsoleted by:RFC 1410
Status:HISTORIC
DOI:10.17487/RFC 1360
 
 
RFC 1361 Simple Network Time Protocol (SNTP)
 
Authors:D. Mills.
Date:August 1992
Formats:txt html json
Obsoleted by:RFC 1769
Also:RFC 1305
Status:INFORMATIONAL
DOI:10.17487/RFC 1361
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 json html
Obsoleted by:RFC 1634
Status:INFORMATIONAL
DOI:10.17487/RFC 1362
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 1363 A Proposed Flow Specification
 
Authors:C. Partridge.
Date:September 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1363
A flow specification (or "flow spec") is a data structure used by internetwork hosts to request special services of the internetwork, often guarantees about how the internetwork will handle some of the hosts' traffic. In the future, hosts are expected to have to request such services on behalf of distributed applications such as multimedia conferencing.

The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF).

 
RFC 1364 BGP OSPF Interaction
 
Authors:K. Varadhan.
Date:September 1992
Formats:txt html json
Obsoleted by:RFC 1403
Also:RFC 1247, RFC 1267
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1364
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 1365 An IP Address Extension Proposal
 
Authors:K. Siyan.
Date:September 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1365
This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements.
 
RFC 1366 Guidelines for Management of IP Address Space
 
Authors:E. Gerich.
Date:October 1992
Formats:txt json html
Obsoleted by:RFC 1466
Status:INFORMATIONAL
DOI:10.17487/RFC 1366
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 json html
Obsoleted by:RFC 1467
Status:INFORMATIONAL
DOI:10.17487/RFC 1367
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 html json
Obsoleted by:RFC 1516
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1368
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 1369 Implementation Notes and Experience for the Internet Ethernet MIB
 
Authors:F. Kastenholz.
Date:October 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1369
This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1370 Applicability Statement for OSPF
 
Authors:Internet Architecture Board, L. Chapin.
Date:October 1992
Formats:txt html json
Status:HISTORIC
DOI:10.17487/RFC 1370
This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]
 
RFC 1371 Choosing a Common IGP for the IP Internet
 
Authors:P. Gross.
Date:October 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1371
This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to theIAB for a single "common IGP" for the IP portions of the Internet.

In this memo, the term "common IGP" is defined, the need for a commonIGP is explained, the relation of this issue to other ongoingInternet Engineering Task Force (IETF) routing protocol development is provided, and the relation of this issue to the goal for multi- protocol integration in the Internet is explored.

Finally, a specific IGP is recommended as the "common IGP" for IP portions of the Internet -- the Open Shortest Path First (OSPF) routing protocol.

The goal of this recommendation is for all vendors of Internet IP routers to make OSPF available as one of the IGP's provided with their routers.

 
RFC 1372 Telnet Remote Flow Control Option
 
Authors:C. Hedrick, D. Borman.
Date:October 1992
Formats:txt json html
Obsoletes:RFC 1080
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1372
This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]
 
RFC 1373 Portable DUAs
 
Authors:T. Tignor.
Date:October 1992
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1373
This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1374 IP and ARP on HIPPI
 
Authors:J. Renwick, A. Nicholson.
Date:October 1992
Formats:txt html json
Obsoleted by:RFC 2834
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1374
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 1375 Suggestion for New Classes of IP Addresses
 
Authors:P. Robinson.
Date:October 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1375
This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address.
 
RFC 1376 The PPP DECnet Phase IV Control Protocol (DNCP)
 
Authors:S. Senum.
Date:November 1992
Formats:txt json html
Obsoleted by:RFC 1762
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1376
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 1377 The PPP OSI Network Layer Control Protocol (OSINLCP)
 
Authors:D. Katz.
Date:November 1992
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1377
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 configuring OSINetwork Layer Protocols.

This memo is the 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 1378 The PPP AppleTalk Control Protocol (ATCP)
 
Authors:B. Parker.
Date:November 1992
Formats:txt html json
Status:HISTORIC
DOI:10.17487/RFC 1378
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 configuring theAppleTalk Protocol [3] over PPP.

This memo is a joint effort of the AppleTalk-IP Working Group and thePoint-to-Point Protocol Working Group of the Internet EngineeringTask Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.

 
RFC 1379 Extending TCP for Transactions -- Concepts
 
Authors:R. Braden.
Date:November 1992
Formats:txt html json
Obsoleted by:RFC 6247
Updated by:RFC 1644
Status:HISTORIC
DOI:10.17487/RFC 1379
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 1380 IESG Deliberations on Routing and Addressing
 
Authors:P. Gross, P. Almquist.
Date:November 1992
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1380
This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the InternetEngineering Task Force (IETF).

It also provides a preliminary report of the Internet EngineeringSteering Group (IESG) deliberations on how these routing and addressing issues should be pursued in the Internet ArchitectureBoard (IAB)/IETF.

 
RFC 1381 SNMP MIB Extension for X.25 LAPB
 
Authors:D. Throop, F. Baker.
Date:November 1992
Formats:txt html json
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1381
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 Link Layer ofX.25, LAPB. The objects defined here, along with the objects in the"SNMP MIB Extension for the Packet Layer of X.25" [9] and the"Definitions of Managed Objects for RS-232-like Hardware Devices"[8], combine to allow management of an X.25 protocol stack.
 
RFC 1382 SNMP MIB Extension for the X.25 Packet Layer
 
Authors:D. Throop, Ed..
Date:November 1992
Formats:txt json html
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1382
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 Packet Layer ofX.25. The objects defined here, along with the objects in the "SNMPMIB Extension for LAPB" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8], combine to allow management of an X.25 protocol stack.
 
RFC 1383 An Experiment in DNS Based IP Routing
 
Authors:C. Huitema.
Date:December 1992
Formats:txt json html
Status:EXPERIMENTAL
DOI:10.17487/RFC 1383
Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1384 Naming Guidelines for Directory Pilots
 
Authors:P. Barker, S.E. Hardcastle-Kille.
Date:January 1993
Formats:txt ps html pdf json
Obsoleted by:RFC 1617, RTR_0011
Status:INFORMATIONAL
DOI:10.17487/RFC 1384
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 1385 EIP: The Extended Internet Protocol
 
Authors:Z. Wang.
Date:November 1992
Formats:txt html json
Obsoleted by:RFC 6814
Status:HISTORIC
DOI:10.17487/RFC 1385
EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.
 
RFC 1386 The US Domain
 
Authors:A. Cooper, J. Postel.
Date:December 1992
Formats:txt json html
Obsoleted by:RFC 1480
Status:INFORMATIONAL
DOI:10.17487/RFC 1386
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 json html
Obsoleted by:RFC 1721
Status:INFORMATIONAL
DOI:10.17487/RFC 1387
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 html json
Obsoleted by:RFC 1723
Updates:RFC 1058
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1388
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 html json
Obsoleted by:RFC 1724
Status:PROPOSED STANDARD
DOI:10.17487/RFC 1389
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 1390 Transmission of IP and ARP over FDDI Networks
 
Authors:D. Katz.
Date:January 1993
Formats:txt html json
Also:STD 0036
Status:INTERNET STANDARD
DOI:10.17487/RFC 1390
This memo defines a method of encapsulating the Internet Protocol(IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks.

This RFC is the product of the IP over FDDI Working Group of theInternet Engineering Task Force (IETF).

 
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 html json
Obsoleted by:RFC 1539
Status:INFORMATIONAL
DOI:10.17487/RFC 1391
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 json html
Obsoleted by:RFC 1983
Status:INFORMATIONAL
DOI:10.17487/RFC 1392
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 1393 Traceroute Using an IP Option
 
Authors:G. Malkin.
Date:January 1993
Formats:txt json html
Obsoleted by:RFC 6814
Status:HISTORIC
DOI:10.17487/RFC 1393
Traceroute serves as a valuable network debugging tool. The way in which it is currently implemented has the advantage of being automatically supported by all of the routers. It's two problems are the number of packets it generates and the amount of time it takes to run.

This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time.

 
RFC 1394 Relationship of Telex Answerback Codes to Internet Domains
 
Authors:P. Robinson.
Date:January 1993
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1394
This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available.It will also list major Internet "Public" E-Mail addresses.

This list is designed to show the corresponding codes for Fax and voice messages, telex country codes, telex answerbacks and Internet domains. It is an attempt to place all of the information into one list and all the connections for each country.

 
RFC 1395 BOOTP Vendor Information Extensions
 
Authors:J. Reynolds.
Date:January 1993
Formats:txt html json
Obsoletes:RFC 1084, RFC 1048
Obsoleted by:RFC 1497, RFC 1533
Updates:RFC 0951
Status:DRAFT STANDARD
DOI:10.17487/RFC 1395
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 1396 The Process for Organization of Internet Standards Working Group (POISED)
 
Authors:S. Crocker.
Date:January 1993
Formats:txt json html
Status:INFORMATIONAL
DOI:10.17487/RFC 1396
This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period. Quite a few people hold strong views about both the overall sequence and specific events. My intent here is to convey as neutral a point of view as possible.
 
RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol
 
Authors:D. Haskin.
Date:January 1993
Formats:txt json html
Status:HISTORIC
DOI:10.17487/RFC 1397
This document specifies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol.

This recommendation only applies to BGP2 and BGP3 versions of theBorder Gateway Protocol since starting with the BGP4 [3] version a default route advertisement capability is built in the protocol.

 
RFC 1398 Definitions of Managed Objects for the Ethernet-Like Interface Types
 
Authors:F. Kastenholz.
Date:January 1993
Formats:txt html json
Obsoletes:RFC 1284
Obsoleted by:RFC 1623
Status:DRAFT STANDARD
DOI:10.17487/RFC 1398
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 1399 Summary of 1300-1399
 
Authors:J. Elliott.
Date:January 1997
Formats:txt html json
Status:INFORMATIONAL
DOI:10.17487/RFC 1399