| |
| RFC 1600 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1601 | Charter of the Internet Architecture Board (IAB) |
| |
|
|
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. |
|
| |
| RFC 1602 | The Internet Standards Process -- Revision 2 |
| |
| Authors: | Internet Architecture Board, Internet Engineering Steering Group. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1310 |
| Obsoleted by: | RFC 2026 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1602 |
|
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.
This revision (revision 2) includes the following major changes:
(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.
(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).
(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.
(d) An appeals procedure is added (Section 3.6).
(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.
(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C. |
|
| |
| RFC 1603 | IETF Working Group Guidelines and Procedures |
| |
|
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined. |
|
| |
| RFC 1604 | Definitions of Managed Objects for Frame Relay Service |
| |
|
|
This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service. |
|
| |
| RFC 1605 | SONET to Sonnet Translation |
| |
| Authors: | W. Shakespeare. |
| Date: | 1 April 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1605 |
|
Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation(SONNET). |
|
| |
| RFC 1606 | A Historical Perspective On The Usage Of IP Version 9 |
| |
| Authors: | J. Onions. |
| Date: | 1 April 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1606 |
|
This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. |
|
| |
| RFC 1607 | A VIEW FROM THE 21ST CENTURY |
| |
| Authors: | V. Cerf. |
| Date: | 1 April 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1607 |
|
This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1608 | Representing IP Information in the X.500 Directory |
| |
| Authors: | T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1608 |
|
This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in theDirectory by applying it to IP networks. This application of theDirectory is intended to support the work of IP network assigning authorities, NICs, as well as other applications looking for a mapping of IP numbers to data of related networks. Furthermore,Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks and organizations. |
|
| |
| RFC 1609 | Charting Networks in the X.500 Directory |
| |
| Authors: | G. Mansfield, T. Johannsen, M. Knopper. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1609 |
|
There is a need for a framework wherein the infrastructural and service related information about communication networks can be made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy. This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. Schemas of objects and their attributes which may be used for this purpose are presented. The model envisages physical objects and several logical abstractions of the physical objects. |
|
| |
| RFC 1610 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK] |
|
| |
| RFC 1611 | DNS Server MIB Extensions |
| |
| Authors: | R. Austein, J. Saperia. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1611 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK] |
|
| |
| RFC 1612 | DNS Resolver MIB Extensions |
| |
| Authors: | R. Austein, J. Saperia. |
| Date: | May 1994 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1612 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK] |
|
| |
| RFC 1613 | cisco Systems X.25 over TCP (XOT) |
| |
| Authors: | J. Forster, G. Satz, G. Glick, R. Day. |
| Date: | May 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1613 |
|
This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1614 | Network Access to Multimedia Information |
| |
| Authors: | C. Adie. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1614 |
|
This report summarises the requirements of research and academic network users for network access to multimedia information. It does this by investigating some of the projects planned or currently underway in the community. Existing information systems such asGopher, WAIS and World-Wide Web are examined from the point of view of multimedia support, and some interesting hypermedia systems emerging from the research community are also studied. Relevant existing and developing standards in this area are discussed. The report identifies the gaps between the capabilities of currentlydeployed systems and the user requirements, and proposes further work centred on the World-Wide Web system to rectify this.
The report is in some places very detailed, so it is preceded by an extended summary, which outlines the findings of the report. |
|
| |
| RFC 1615 | Migrating from X.400(84) to X.400(88) |
| |
| Authors: | J. Houttuin, J. Craigie. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1615 |
|
This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. It not only describes the technical complications, but also the effect the transition will have on the end users, especially concerning interworking between end users of the 84 and the 88 services. |
|
| |
| RFC 1616 | X.400(1988) for the Academic and Research Community in Europe |
| |
| Authors: | RARE WG-MSG Task Force 88, E. Huizer, Ed., J. Romaguera, Ed.. |
| Date: | May 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1616 |
|
The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1617 | Naming and Structuring Guidelines for X.500 Directory Pilots |
| |
| Authors: | P. Barker, S. Kille, T. Lenggenhager. |
| Date: | May 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1384 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1617 |
|
Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. The final version of this document will replace RFC 1384. |
|
| |
| RFC 1618 | PPP over ISDN |
| |
| Authors: | W. Simpson. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1618 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Integrated ServicesDigital Network (ISDN) switched circuits.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. |
|
| |
| RFC 1619 | PPP over SONET/SDH |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Heirarchy (SDH) circuits.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. |
|
| |
| RFC 1620 | Internet Architecture Extensions for Shared Media |
| |
| Authors: | B. Braden, J. Postel, Y. Rekhter. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1620 |
|
The original Internet architecture assumed that each network is labeled with a single IP network number. This assumption may be violated for shared media, including "large public data networks"(LPDNs). The architecture still works if this assumption is violated, but it does not have a means to prevent multiple host- router and router-router hops through the shared medium. This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. |
|
| |
| RFC 1621 | Pip Near-term Architecture |
| |
|
|
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to evolve to all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures. |
|
| |
| RFC 1622 | Pip Header Processing |
| |
|
|
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification defines the Pip header processing for Routers andHosts. |
|
| |
| RFC 1623 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1624 | Computation of the Internet Checksum via Incremental Update |
| |
|
|
This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. |
|
| |
| RFC 1625 | WAIS over Z39.50-1988 |
| |
| Authors: | M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte. |
| Date: | June 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1625 |
|
The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1626 | Default IP MTU for use over ATM AAL5 |
| |
|
|
There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK] |
|
| |
| RFC 1627 | Network 10 Considered Harmful (Some Practices Shouldn't be Codified) |
| |
| Authors: | E. Lear, E. Fair, D. Crocker, T. Kessler. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1627 |
|
This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1628 | UPS Management Information Base |
| |
| Authors: | J. Case, Ed.. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1628 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK] |
|
| |
| RFC 1629 | Guidelines for OSI NSAP Allocation in the Internet |
| |
| Authors: | R. Colella, R. Callon, E. Gardner, Y. Rekhter. |
| Date: | May 1994 |
| Formats: | txt html json |
| Obsoletes: | RFC 1237 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1629 |
|
CLNP is currently being deployed in the Internet. This is useful to support OSI and DECnet(tm) traffic. In addition, CLNP has been proposed as a possible IPng candidate, to provide a long-term solution to IP address exhaustion. Required as part of the CLNP infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocatingNSAP addresses in the Internet.
The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. |
|
| |
| RFC 1630 | Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web |
| |
| Authors: | T. Berners-Lee. |
| Date: | June 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1630 |
|
This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1631 | The IP Network Address Translator (NAT) |
| |
|
|
The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.
It is possible that CIDR will not be adequate to maintain the IPInternet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complementsCIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons. |
|
| |
| RFC 1632 | A Revised Catalog of Available X.500 Implementations |
| |
|
|
This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor inRFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions.
This document contains detailed description of twenty six (26) X.500 implementations - DSAs, DUAs, and DUA interfaces. |
|
| |
| RFC 1633 | Integrated Services in the Internet Architecture: an Overview |
| |
| Authors: | R. Braden, D. Clark, S. Shenker. |
| Date: | June 1994 |
| Formats: | txt json ps html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1633 |
|
This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation.
This memo represents the direct product of recent work by Dave Clark,Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, JohnWroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon the work of many others. |
|
| |
| RFC 1634 | Novell IPX Over Various WAN Media (IPXWAN) |
| |
|
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and RFC 1551. The changes from RFC 1551 are to correct a problem in the wording when anRFC 1362 router talks to an RFC 1551 router and to allow numbers to be specified in a Router Name. |
|
| |
| RFC 1635 | How to Use Anonymous FTP |
| |
|
|
This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. It shows a sample anonymous FTP session. It also discusses common ways files are packaged for efficient storage and transmission. |
|
| |
| RFC 1636 | Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994 |
| |
| Authors: | R. Braden, D. Clark, S. Crocker, C. Huitema. |
| Date: | June 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1636 |
|
This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture.
This document should be regarded as a set of working notes containing ideas about security that were developed by Internet experts in a broad spectrum of areas, including routing, mobility, realtime service, and provider requirements, as well as security. It contains some significant diversity of opinions on some important issues.This memo is offered as one input in the process of developing viable security mechanisms and procedures for the Internet. |
|
| |
| RFC 1637 | DNS NSAP Resource Records |
| |
|
|
The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain NameSystem (DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format. This document supercedes RFC 1348.
NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation. |
|
| |
| RFC 1638 | PPP Bridging Control Protocol (BCP) |
| |
|
|
The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. |
|
| |
| RFC 1639 | FTP Operation Over Big Address Records (FOOBAR) |
| |
|
|
This paper describes a convention for specifying address families other than the default Internet address family in FTP commands and replies. |
|
| |
| RFC 1640 | The Process for Organization of Internet Standards Working Group (POISED) |
| |
| Authors: | S. Crocker. |
| Date: | June 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1640 |
|
This report, originally prepared in January 1993 provides a summary of the POISED 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 1641 | Using Unicode with MIME |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document specifies the usage of Unicode within MIME. |
|
| |
| RFC 1642 | UTF-7 - A Mail-Safe Transformation Format of Unicode |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of RFC 1521, RFC 1522, and the document "Using Unicode with MIME". |
|
| |
| RFC 1643 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1644 | T/TCP -- TCP Extensions for Transactions Functional Specification |
| |
|
|
This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This backwards-compatible extension could fill the gap between the current connection-oriented TCP and the datagram-based UDP.
This work was supported in part by the National Science Foundation under Grant Number NCR-8922231. |
|
| |
| RFC 1645 | Simple Network Paging Protocol - Version 2 |
| |
|
|
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging. In addition, email filters and SNPP client software for Unix and Windows are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below. |
|
| |
| RFC 1646 | TN3270 Extensions for LUname and Printer Selection |
| |
| Authors: | C. Graves, T. Butts, M. Angel. |
| Date: | July 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1646 |
|
This document describes protocol extensions to TN3270. There are two extensions outlined in this document. The first defines a way by which a TN3270 client can request a specific device (LUname) from aTN3270 server. The second extension specifies how a TN3270 printer device can be requested by a TN3270 client and the manner in which the 3270 printer status information can be sent to the TN3270 server.Discussions and suggestions for improvements to these enhancements should be sent to the TN3270E Working Group mailing listTN3270E@list.nih.gov . These extensions will be called TN3287 in this document. This information is being provided to members of theInternet community that want to support the 3287 data stream within the TELNET protocol. |
|
| |
| RFC 1647 | TN3270 Enhancements |
| |
|
|
This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new TelnetOption and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1]. |
|
| |
| RFC 1648 | Postmaster Convention for X.400 Operations |
| |
| Authors: | A. Cargille. |
| Date: | July 1994 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1648 |
|
Both STD 11, RFC 822 [1] and STD 3, RFC 1123 [2] (Host Requirements) require that the email address "postmaster" be supported at all hosts. This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. |
|
| |
| RFC 1649 | Operational Requirements for X.400 Management Domains in the GO-MHS Community |
| |
| Authors: | R. Hagens, A. Hansen. |
| Date: | July 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1649 |
|
The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1650 | Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK] |
|
| |
| RFC 1651 | SMTP Service Extensions |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1425 |
| Obsoleted by: | RFC 1869 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1651 |
|
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK] |
|
| |
| RFC 1652 | SMTP Service Extension for 8bit-MIMEtransport |
| |
| Authors: | J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. |
| Date: | July 1994 |
| Formats: | txt html json |
| Obsoletes: | RFC 1426 |
| Obsoleted by: | RFC 6152 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1652 |
|
This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. |
|
| |
| RFC 1653 | SMTP Service Extension for Message Size Declaration |
| |
|
|
This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. |
|
| |
| RFC 1654 | A Border Gateway Protocol 4 (BGP-4) |
| |
| Authors: | Y. Rekhter, Ed., T. Li, Ed.. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1771 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1654 |
|
This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 1655 | Application of the Border Gateway Protocol in the Internet |
| |
|
|
This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet.
Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net). |
|
| |
| RFC 1656 | BGP-4 Protocol Document Roadmap and Implementation Experience |
| |
|
|
Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1657 | Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 |
| |
| Authors: | S. Willis, J. Burruss, J. Chu, Ed.. |
| Date: | July 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4273 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1657 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK] |
|
| |
| RFC 1658 | Definitions of Managed Objects for Character Stream Devices using SMIv2 |
| |
|
|
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK] |
|
| |
| RFC 1659 | Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2 |
| |
|
|
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK] |
|
| |
| RFC 1660 | Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2 |
| |
|
|
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK] |
|
| |
| RFC 1661 | The Point-to-Point Protocol (PPP) |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the PPP organization and methodology, and thePPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism. |
|
| |
| RFC 1662 | PPP in HDLC-like Framing |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC-like framing for PPP encapsulated packets. |
|
| |
| RFC 1663 | PPP Reliable Transmission |
| |
| Authors: | D. Rand. |
| Date: | July 1994 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1663 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link.
This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. |
|
| |
| RFC 1664 | Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables |
| |
| Authors: | C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. |
| Date: | August 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2163 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1664 |
|
This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail andMessaging working group (WG-MSG). |
|
| |
| RFC 1665 | Definitions of Managed Objects for SNA NAUs using SMIv2 |
| |
| Authors: | Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1666 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1665 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK] |
|
| |
| RFC 1666 | Definitions of Managed Objects for SNA NAUs using SMIv2 |
| |
| Authors: | Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. |
| Date: | August 1994 |
| Formats: | txt html json |
| Obsoletes: | RFC 1665 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1666 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK] |
|
| |
| RFC 1667 | Modeling and Simulation Requirements for IPng |
| |
| Authors: | S. Symington, D. Wood, M. Pullen. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1667 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1668 | Unified Routing Requirements for IPng |
| |
| Authors: | D. Estrin, T. Li, Y. Rekhter. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1668 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1669 | Market Viability as a IPng Criteria |
| |
| Authors: | J. Curran. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1669 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1670 | Input to IPng Engineering Considerations |
| |
| Authors: | D. Heagerty. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1670 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1671 | IPng White Paper on Transition and Other Considerations |
| |
| Authors: | B. Carpenter. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1671 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1672 | Accounting Requirements for IPng |
| |
| Authors: | N. Brownlee. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1672 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1673 | Electric Power Research Institute Comments on IPng |
| |
| Authors: | R. Skelton. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1673 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1674 | A Cellular Industry View of IPng |
| |
| Authors: | M. Taylor. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1674 |
|
This memo is a response to RFC 1550, "IP: Next Generation (IPng)White Paper Solicitation". The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers or any of its constituent companies. |
|
| |
| RFC 1675 | Security Concerns for IPng |
| |
| Authors: | S. Bellovin. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1675 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1676 | INFN Requirements for an IPng |
| |
| Authors: | A. Ghiselli, D. Salomoni, C. Vistoli. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1676 |
|
This white paper is sent by INFN network team, the Italian NationalInstitute for nuclear physics, whose network, named INFNet, is a nationwide network founded to provide the access to existing national and international HEP laboratory and to facilitate communications between the researchers. With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan.We do not really expect to add original items to the selection, but we think that it could be useful to submit the opinions and ideas that come from our network experience. |
|
| |
| RFC 1677 | Tactical Radio Frequency Communication Requirements for IPng |
| |
| Authors: | B. Adamson. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1677 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1678 | IPng Requirements of Large Corporate Networks |
| |
| Authors: | E. Britton, J. Tavs. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1678 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. |
|
| |
| RFC 1679 | HPN Working Group Input to the IPng Requirements Solicitation |
| |
| Authors: | D. Green, P. Irey, D. Marlow, K. O'Donoghue. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1679 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1680 | IPng Support for ATM Services |
| |
| Authors: | C. Brazdziunas. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1680 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1681 | On Many Addresses per Host |
| |
| Authors: | S. Bellovin. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1681 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1682 | IPng BSD Host Implementation Analysis |
| |
| Authors: | J. Bound. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1682 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1683 | Multiprotocol Interoperability In IPng |
| |
| Authors: | R. Clark, M. Ammar, K. Calvert. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1683 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1684 | Introduction to White Pages Services based on X.500 |
| |
| Authors: | P. Jurg. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1684 |
|
This document aims at organisations who are using local and global electronic communication on a day to day basis and for whom using an electronic White Pages Service is therefore indispensable.
The document provides an introduction to the international ITU-T(formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic WhitePages Service.
In addition a short overview of the experience gained from theParadise X.500 pilot is given. References to more detailed information are included.
The document should be useful for managers of the above mentioned organisations who need to get the necessary executive commitment for making the address information of their organisation available by means of X.500. |
|
| |
| RFC 1685 | Writing X.400 O/R Names |
| |
| Authors: | H. Alvestrand. |
| Date: | August 1994 |
| Formats: | txt json html |
| Also: | RTR_0012 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1685 |
|
There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind. |
|
| |
| RFC 1686 | IPng Requirements: A Cable Television Industry Viewpoint |
| |
| Authors: | M. Vecchi. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1686 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cable television industry or any of its companies. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1687 | A Large Corporate User's View of IPng |
| |
| Authors: | E. Fleischman. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1687 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1688 | IPng Mobility Considerations |
| |
| Authors: | W. Simpson. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1688 |
|
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. |
|
| |
| RFC 1689 | A Status Report on Networked Information Retrieval: Tools and Groups |
| |
|
|
The purpose of this report is to increase the awareness of NetworkedInformation Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools.NIR Tools covered include Archie, WAIS, gopher and World Wide Web. |
|
| |
| RFC 1690 | Introducing the Internet Engineering and Planning Group (IEPG) |
| |
| Authors: | G. Huston. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1690 |
|
This memo introduces the IEPG to the Internet Community. The IEPG is an Internet Service Operators' forum, intended to assist ServiceOperators to coordinate in operational aspects of managing Internet services. |
|
| |
| RFC 1691 | The Document Architecture for the Cornell Digital Library |
| |
| Authors: | W. Turner. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1691 |
|
This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library.
Two unique features of this architecture are the ability to generate reference documents and the ability to create multiple views of a document. |
|
| |
| RFC 1692 | Transport Multiplexing Protocol (TMux) |
| |
| Authors: | P. Cameron, D. Crocker, D. Cohen, J. Postel. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1692 |
|
One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair. |
|
| |
| RFC 1693 | An Extension to TCP : Partial Order Service |
| |
| Authors: | T. Connolly, P. Amer, P. Conrad. |
| Date: | November 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6247 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1693 |
|
This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. Distribution of this memo is unlimited. |
|
| |
| RFC 1694 | Definitions of Managed Objects for SMDS Interfaces using SMIv2 |
| |
| Authors: | T. Brown, Ed., K. Tesink, Ed.. |
| Date: | August 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1304 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 1694 |
|
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 objects for SMDS access interfaces. This includes the following access protocols:
SIP [13]SIP/DXI [18] and [20]SIP/FR [19]SIP/ATM [24]
This memo replaces RFC 1304 [12], and defines a MIB module which is both compliant to the SNMPv2 SMI and semantically-identical to the existing RFC 1304-based definitions.
This memo also assumes application of the MIB II Interfaces group as defined in [9]. |
|
| |
| RFC 1695 | Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 |
| |
| Authors: | M. Ahmed, Ed., K. Tesink, Ed.. |
| Date: | August 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2515 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1695 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK] |
|
| |
| RFC 1696 | Modem Management Information Base (MIB) using SMIv2 |
| |
| Authors: | J. Barnes, L. Brown, R. Royston, S. Waldbusser. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 1696 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK] |
|
| |
| RFC 1697 | Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 |
| |
| Authors: | D. Brower, Ed., B. Purvy, A. Daniel, M. Sinykin, J. Smith. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1697 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK] |
|
| |
| RFC 1698 | Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications |
| |
| Authors: | P. Furniss. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1698 |
|
This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and DirectoryAccess Protocol, and "migrant" protocols, originally defined for use over other transports.
As well as the octet sequences which are the supporting layer headers(and trailers) around the application data, this document includes some tutorial material on the OSI upper layers.
An implementation that sends the octet sequences given here, and interprets the equivalent protocol received, will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol. |
|
| |
| RFC 1699 | Summary of 1600-1699 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1699 |
|
|
|
