| |
| RFC 1400 | Transition and Modernization of the Internet Registration Service |
| |
| Authors: | S. Williamson. |
| Date: | March 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1400 |
|
As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1401 | Correspondence between the IAB and DISA on the use of DNS |
| |
| Authors: | Internet Architecture Board. |
| Date: | January 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1401 |
|
This memo reproduces three letters exchanged between the InternetActivities Board (IAB) and the Defense Information Systems Agency(DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt". |
|
| |
| RFC 1402 | There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places |
| |
|
|
A wealth of information exists on the network. In fact, there is 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 useful.
The ultimate goal is to make the route to these sources of information invisible to you. 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 all can be richer. |
|
| |
| RFC 1403 | BGP OSPF Interaction |
| |
|
|
This memo defines the various criteria to be used when designing anAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP. This is a republication of RFC 1364 to correct some editorial problems. |
|
| |
| RFC 1404 | A Model for Common Operational Statistics |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 1408 | Telnet Environment Option |
| |
|
|
This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. |
|
| |
| RFC 1409 | Telnet Authentication Option |
| |
|
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1410 | IAB Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). |
|
| |
| RFC 1411 | Telnet Authentication: Kerberos Version 4 |
| |
| Authors: | D. Borman, Ed.. |
| Date: | January 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1411 |
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1412 | Telnet Authentication: SPX |
| |
| Authors: | K. Alagappan. |
| Date: | January 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1412 |
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1413 | Identification Protocol |
| |
|
|
The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK] |
|
| |
| RFC 1414 | Identification MIB |
| |
| Authors: | M. St. Johns, M. Rose. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1414 |
|
This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1].This document is a product of the TCP Client Identity ProtocolWorking Group of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 1415 | FTP-FTAM Gateway Specification |
| |
| Authors: | J. Mindel, R. Slaski. |
| Date: | January 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1415 |
|
This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols.
Two key assumptions are made: 1) POSIX file naming conventions and hierarchical organization, rather than proprietary conventions are in use; and 2) X.500 Directory Services are available. |
|
| |
| RFC 1416 | Telnet Authentication Option |
| |
|
|
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 1418 | SNMP over OSI |
| |
|
|
This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK] |
|
| |
| RFC 1419 | SNMP over AppleTalk |
| |
| Authors: | G. Minshall, M. Ritter. |
| Date: | March 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1419 |
|
This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK] |
|
| |
| RFC 1420 | SNMP over IPX |
| |
|
|
This document 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 1421 | Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures |
| |
|
|
This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1422 | Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management |
| |
|
|
This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK] |
|
| |
| RFC 1423 | Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers |
| |
|
|
This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail(PEM) in the Internet community. It is intended to become one member of the set of related PEM RFCs. This document is organized into four primary sections, dealing with message encryption algorithms, message integrity check algorithms, symmetric key management algorithms, and asymmetric key management algorithms (including both asymmetric encryption and asymmetric signature algorithms).
Some parts of this material are cited by other documents and it is anticipated that some of the material herein may be changed, added, or replaced without affecting the citing documents. Therefore, algorithm-specific material has been placed into this separate document.
Use of other algorithms and/or modes will require case-by-case study to determine applicability and constraints. The use of additional algorithms may be documented first in Prototype or Experimental RFCs.As experience is gained, these protocols may be considered for incorporation into the standard. Additional algorithms and modes approved for use in PEM in this context will be specified in successors to this document. |
|
| |
| RFC 1424 | Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services |
| |
| Authors: | B. Kaliski. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1424 |
|
This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK] |
|
| |
| RFC 1425 | SMTP Service Extensions |
| |
| Authors: | J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1651 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1425 |
|
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, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1652 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1426 |
|
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, N. Freed, Ed., K. Moore. |
| Date: | February 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1427 |
|
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 1428 | Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME |
| |
| Authors: | G. Vaudreuil. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1428 |
|
Protocols for extending SMTP to pass 8bit characters have been defined [3] [4]. These protocols require that messages transported by the extended SMTP are to be encoded in MIME [1] [2]. Before work began on these protocols, several SMTP implementations adopted ad-hoc mechanisms for sending 8bit data. It is desirable for the extendedSMTP environment and these ad hoc mechanisms interoperate. This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. |
|
| |
| RFC 1429 | Listserv Distribute Protocol |
| |
| Authors: | E. Thomas. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1429 |
|
This memo specifies a subset of the distribution protocol used by theBITNET LISTSERV to deliver mail messages to large amounts of recipients. This protocol, known as DISTRIBUTE, optimizes the distribution by sending a single copy of the message over heavily loaded links, insofar as topological information is available to guide such decisions, and reduces the average turnaround time for large mailing lists to 5-15 minutes on the average. This memo describes a simple interface allowing non-BITNET mailing list exploders (or other bulk-delivery scripts) to take advantage of this service by letting the BITNET distribution network take care of the delivery. |
|
| |
| RFC 1430 | A Strategic Plan for Deploying an Internet X.500 Directory Service |
| |
| Authors: | S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1430 |
|
There are a number of reasons why a new Internet Directory Service is required. This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 DirectoryService. It then describes in more detail the initial steps which need to be taken in order to achieve these goals, and how work already undertaken by Internet Engineering Task Force Working Groups(IETF WGs) is working towards these goals. |
|
| |
| RFC 1431 | DUA Metrics (OSI-DS 33 (v2)) |
| |
| Authors: | P. Barker. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1431 |
|
This 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 implementers.
This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. Particular issues covered include terminal requirements; style of interface; target user; default object classes and attribute types; use of DAP; error handling. The focus of the note is on"white pages" DUAs: this is a reflection of the current information base. Nevertheless much of the document will be applicable to DUAs developed for other types of Directory usage.
Please send comments to the author or to the discussion group <osi- ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1432 | Recent Internet Books |
| |
| Authors: | J. Quarterman. |
| Date: | March 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1432 |
|
This article originally appeared in Volume 2 Number 12, (December1992) of Matrix News, the monthly newsletter of Matrix Information and Directory Services, Inc. (MIDS). |
|
| |
| RFC 1433 | Directed ARP |
| |
| Authors: | J. Garrett, J. Hagan, J. Wong. |
| Date: | March 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1433 |
|
A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (viaICMP Redirects) and routers (via dynamic routing protocols).However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the"foreign" IP network to their corresponding link level addresses.Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. |
|
| |
| RFC 1434 | Data Link Switching: Switch-to-Switch Protocol |
| |
|
|
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 1435 | IESG Advice from Experience with Path MTU Discovery |
| |
| Authors: | S. Knowles. |
| Date: | March 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1435 |
|
In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTUDiscovery. |
|
| |
| RFC 1436 | The Internet Gopher Protocol (a distributed document search and retrieval protocol) |
| |
| Authors: | F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. Alberti. |
| Date: | March 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1436 |
|
The Internet Gopher protocol is designed for distributed document search and retrieval. This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This document is adapted from the basic Internet Gopher protocol document first issued by the Microcomputer Center at the University ofMinnesota in 1991. |
|
| |
| RFC 1437 | The Extension of MIME Content-Types to a New Medium |
| |
| Authors: | N. Borenstein, M. Linimon. |
| Date: | 1 April 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1437 |
|
A previous document, RFC 1341, 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 matter-transport/sentient-life-form type. The matter- transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings.
Other informally proposed subtypes, such as "non-sentient-life-form","non-sentient-non-life-form", and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form", are not described in this memo. |
|
| |
| RFC 1438 | Internet Engineering Task Force Statements Of Boredom (SOBs) |
| |
| Authors: | A. Lyman Chapin, C. Huitema. |
| Date: | 1 April 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1438 |
|
This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1439 | The Uniqueness of Unique Identifiers |
| |
| Authors: | C. Finseth. |
| Date: | March 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1439 |
|
This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. |
|
| |
| RFC 1440 | SIFT/UFT: Sender-Initiated/Unsolicited File Transfer |
| |
| Authors: | R. Troth. |
| Date: | July 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1440 |
|
This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1441 | Introduction to version 2 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1441 |
|
The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK] |
|
| |
| 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 html json |
| Obsoleted by: | RFC 1902 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1442 |
|
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 html json |
| Obsoleted by: | RFC 1903 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1443 |
|
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 json html |
| Obsoleted by: | RFC 1904 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1444 |
|
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 1445 | Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Galvin, K. McCloghrie. |
| Date: | April 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1445 |
|
It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK] |
|
| |
| RFC 1446 | Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | J. Galvin, K. McCloghrie. |
| Date: | April 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1446 |
|
It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1447 | Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) |
| |
| Authors: | K. McCloghrie, J. Galvin. |
| Date: | April 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1447 |
|
The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [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 json html |
| Obsoleted by: | RFC 1905 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1448 |
|
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 json html |
| Obsoleted by: | RFC 1906 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1449 |
|
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 json html |
| Obsoleted by: | RFC 1907 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1450 |
|
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK] |
|
| |
| RFC 1451 | Manager-to-Manager Management Information Base |
| |
| Authors: | J. Case, K. McCloghrie, M. Rose, S. Waldbusser. |
| Date: | April 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1451 |
|
It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [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 html json |
| Obsoleted by: | RFC 1908 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1452 |
|
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 1453 | A Comment on Packet Video Remote Conferencing and the Transport/Network Layers |
| |
| Authors: | W. Chimiak. |
| Date: | April 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1453 |
|
The new generation of multimedia applications demands new features and new mechanisms for proper performance. ATM technology has moved from concept to reality, delivering very high bandwidths and new capabilities to the data link layer user. In an effort to anticipate the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT[RFC 988], and VMTP [RFC 1045] were developed. The excellent insights and mechanisms pioneered by the creators of these experimental Internet protocols were used in the design of XpressTransfer Protocol (XTP) [XTP92] with the goal of eventually delivering ATM bandwidths to a user process. This RFC is a vehicle to inform the Internet community about XTP as it benefits from pastInternet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. |
|
| |
| RFC 1454 | Comparison of Proposals for Next Version of IP |
| |
| Authors: | T. Dixon. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1454 |
|
This is a slightly edited reprint of RARE Technical Report(RTC(93)004).
The following is a brief summary of the characteristics of the three main proposals for replacing the current Internet Protocol. It is not intended to be exhaustive or definitive (a brief bibliography at the end points to sources of more information), but to serve as input to the European discussions on these proposals, to be co-ordinated byRARE and RIPE. It should be recognised that the proposals are themselves "moving targets", and in so far as this paper is accurate at all, it reflects the position at the 25th IETF meeting inWashington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated. Note that for a time the term"IPv7" was use to mean the eventual next version of IP, but that the same term was closely associated with a particilar proposal, so the term "IPng" is now used to identify the eventual next generation ofIP.
The paper begins with a "generic" discussion of the mechanisms for solving problems and achieving particular goals, before discussing the proposals invidually. |
|
| |
| RFC 1455 | Physical Link Security Type of Service |
| |
|
|
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 1456 | Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification |
| |
| Authors: | Vietnamese Standardization Working Group. |
| Date: | May 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1456 |
|
This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into7-bit US ASCII and in an 8-bit form. These conventions are widely used by the overseas Vietnamese who are on the Internet and are active in USENET. This document only provides information and specifies no level of standard. |
|
| |
| RFC 1457 | Security Label Framework for the Internet |
| |
| Authors: | R. Housley. |
| Date: | May 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1457 |
|
This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1458 | Requirements for Multicast Protocols |
| |
| Authors: | R. Braudes, S. Zabele. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1458 |
|
This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1459 | Internet Relay Chat Protocol |
| |
|
|
The IRC protocol was developed over the last 4 years since it was first implemented as a means for users on a BBS to chat amongst themselves. Now it supports a world-wide network of servers and clients, and is stringing to cope with growth. Over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10.
The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. |
|
| |
| RFC 1460 | Post Office Protocol - Version 3 |
| |
|
|
This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS- TRACK] |
|
| |
| RFC 1461 | SNMP MIB extension for Multiprotocol Interconnect over X.25 |
| |
|
|
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 MultiprotocolInterconnect (including IP) traffic carried over X.25. The objects defined here, along with the objects in the "SNMP MIB extension for the Packet Layer of X.25"[8], "SNMP MIB extension for LAPB"[7], and the "Definitions of Managed Objects for RS-232-like Hardware Devices"[6], combine to allow management of the traffic over an X.25 protocol stack. |
|
| |
| RFC 1462 | FYI on "What is the Internet?" |
| |
|
|
This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the InternetEngineering Task Force (IETF). Containing a modified chapter from EdKrol's 1992 book, "The Whole Internet User's Guide and Catalog," the paper covers the Internet's definition, history, administration, protocols, financing, and current issues such as growth, commercialization, and privatization. |
|
| |
| RFC 1463 | FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings |
| |
|
|
This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history.This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel. |
|
| |
| RFC 1464 | Using the Domain Name System To Store Arbitrary String Attributes |
| |
| Authors: | R. Rosenbaum. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1464 |
|
While the Domain Name System (DNS) [2,3] is generally used to store predefined types of information (e.g., addresses of hosts), it is possible to use it to store information that has not been previously classified.
This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. It uses DNS TXT resource records to store the information. It requires no change to current DNS implementations. |
|
| |
| RFC 1465 | Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing |
| |
| Authors: | D. Eppenberger. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1465 |
|
This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1466 | Guidelines for Management of IP Address Space |
| |
|
|
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 1467 | Status of CIDR Deployment in the Internet |
| |
|
|
This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation.Since all the milestones proposed in RFC 1367 except for the delivery and installation of CIDR software were met, it does not seem appropriate to issue an updated schedule. Rather, this document is intended to provide information about how this effort is proceeding, which may be of interest to the community. |
|
| |
| RFC 1468 | Japanese Character Encoding for Internet Messages |
| |
| Authors: | J. Murai, M. Crispin, E. van der Poel. |
| Date: | June 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1468 |
|
This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1469 | IP Multicast over Token-Ring Local Area Networks |
| |
| Authors: | T. Pusateri. |
| Date: | June 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1469 |
|
This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. Although an interim solution has emerged and is currently being used, it is the intention of this document to specify a more efficient means of transmission using an assigned Token-Ring functional address. |
|
| |
| RFC 1470 | FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices |
| |
|
|
The goal of this FYI memo is to provide an update to FYI 2, RFC 1147[1], which provided practical information to site administrators and network managers. New and/or updated tools are listed in this RFC.Additonal descriptions are welcome, and should be sent to: noctools- entries@merit.edu. |
|
| |
| RFC 1471 | The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol |
| |
| Authors: | F. Kastenholz. |
| Date: | June 1993 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1471 |
|
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 managed objects used for managing theLink Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10,11, & 12]. |
|
| |
| RFC 1472 | The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol |
| |
| Authors: | F. Kastenholz. |
| Date: | June 1993 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1472 |
|
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 managed objects used for managing theSecurity Protocols on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12]. |
|
| |
| RFC 1473 | The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol |
| |
| Authors: | F. Kastenholz. |
| Date: | June 1993 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1473 |
|
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 managed objects used for managing the IPNetwork Control Protocol on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12]. |
|
| |
| RFC 1474 | The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol |
| |
| Authors: | F. Kastenholz. |
| Date: | June 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1474 |
|
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 managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. |
|
| |
| RFC 1475 | TP/IX: The Next Internet |
| |
|
|
The first version of this memo, describing a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989, and circulated informally, including to theIESG, in December 1989. A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list during March of 1992. |
|
| |
| RFC 1476 | RAP: Internet Route Access Protocol |
| |
| Authors: | R. Ullmann. |
| Date: | June 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1476 |
|
This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. |
|
| |
| RFC 1477 | IDPR as a Proposed Standard |
| |
| Authors: | M. Steenstrup. |
| Date: | July 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1477 |
|
This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1478 | An Architecture for Inter-Domain Policy Routing |
| |
| Authors: | M. Steenstrup. |
| Date: | June 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1478 |
|
We present an architecture for inter-domain policy routing (IDPR).The objective of IDPR is to construct and maintain routes, between source and destination administrative domains, that provide user traffic with the requested services within the constraints stipulated for the domains transited. The IDPR architecture is designed to accommodate an internetwork containing tens of thousands of administrative domains with heterogeneous service requirements and restrictions. |
|
| |
| RFC 1479 | Inter-Domain Policy Routing Protocol Specification: Version 1 |
| |
| Authors: | M. Steenstrup. |
| Date: | July 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1479 |
|
We present the set of protocols and procedures that constituteInter-Domain Policy Routing (IDPR). IDPR includes the virtual gateway protocol, the flooding protocol, the route server query protocol, the route generation procedure, the path control protocol, and the data message forwarding procedure. |
|
| |
| RFC 1480 | The US Domain |
| |
|
|
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 1481 | IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling |
| |
|
|
CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1482 | Aggregation Support in the NSFNET Policy-Based Routing Database |
| |
| Authors: | M. Knopper, S. Richardson. |
| Date: | June 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1482 |
|
This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing(CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone NetworkService. Mechanisms for exchange of route aggregates between the backbone service and regional/midlevel networks are specified.Additionally, the memo proposes the implementation of an AggregateRegistry which can be used by network service providers to share information about the use of aggregation. Finally, the operational impact of incorporating CIDR and aggregation is considered, including an analysis of how routing table size will be affected. This impact analysis will be used to modify the deployment plan, if necessary, to maximize operational stability. |
|
| |
| RFC 1483 | Multiprotocol Encapsulation over ATM Adaptation Layer 5 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 1778 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1488 |
|
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 1489 | Registration of a Cyrillic Character Set |
| |
| Authors: | A. Chernov. |
| Date: | July 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1489 |
|
Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1490 | Multiprotocol Interconnect over Frame Relay |
| |
|
|
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 1491 | A Survey of Advanced Usages of X.500 |
| |
|
|
This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the IntegratedDirectory Services Working Group of the Application and User ServicesAreas of the IETF. |
|
| |
| RFC 1492 | An Access Control Protocol, Sometimes Called TACACS |
| |
| Authors: | C. Finseth. |
| Date: | July 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1492 |
|
This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1493 | Definitions of Managed Objects for Bridges |
| |
| Authors: | E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. |
| Date: | July 1993 |
| Formats: | txt html json |
| Obsoletes: | RFC 1286 |
| Obsoleted by: | RFC 4188 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1493 |
|
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 1494 | Equivalences between 1988 X.400 and RFC-822 Message Bodies |
| |
| Authors: | H. Alvestrand, S. Thompson. |
| Date: | August 1993 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1494 |
|
This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK] |
|
| |
| 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 json html |
| Obsoleted by: | RFC 2156 |
| Updates: | RFC 1327 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1495 |
|
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 1496 | Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages |
| |
| Authors: | H. Alvestrand, J. Romaguera, K. Jordan. |
| Date: | August 1993 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1496 |
|
This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [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 1498 | On the Naming and Binding of Network Destinations |
| |
| Authors: | J. Saltzer. |
| Date: | August 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1498 |
|
This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas:First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. To illustrate the usefulness of this approach, the paper interprets some more subtle and confusing properties of two real-world network systems for naming destinations. |
|
| |
| RFC 1499 | Summary of 1400-1499 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1499 |
|
|
|
