Current Internet Drafts This summary sheet provides a short synopsis of each Internet Draft available within the "Internet-Drafts" Directory at the NIC and NNSC. These drafts are listed alphabetically by Working Group acronym and initial post date. Internet Message Extensions --------------------------- "Japanese Character Encoding for Internet Messages", Jun Murai, Mark Crispin, Erik van der Poel,, 12/02/1992, This document describes the encoding used in the bodies of electronic mail and network news messages in several Japanese networks. It was first specified by and used in JUNET [JUNET]. The encoding is now also widely used in Japanese IP communities. This document provides a name for the encoding which is intended to be used in the "charset" parameter field of MIME [MIME] messages and RFC 1342 [RFC1342] headers. This document only describes the encoding of plain text. The encoding of other subtypes of text, such as rich text, is not discussed here. Internet Accounting ------------------- "Internet Accounting Meter Services MIB", C. Mills, C. Brooks, A. Owen,, 07/09/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining accounting information from network devices (meters). "INTERNET ACCOUNTING: USAGE REPORTING ARCHITECTURE", C. Mills, K. Laube, G. Ruth,, 07/09/1992, This draft describes an architecture for Internet usage reporting. The usage reporting architecture specifies common metrics for measuring usage in an Internet environment. By using the same metrics, usage data can be exchanged and compared across multiple platforms. IP over AppleTalk ----------------- "A Method for the Transmission of Internet Packets Over AppleTalk Networks [MacIP]", T. Evans, C. Ranch, 11/12/1992, This Internet Draft describes an existing protocol for transporting IP packets over AppleTalk networks. It is intended to specify, standardize, and enhance existing implementations. There is much confusion over what MacIP really is, as it has grown by many small increments designed and implemented by at least as many people. There has been no central or formal design document, so each of the protocol additions and their effects are not well understood. We hope to dissect the anatomy of the current state of the art, and recommend a functional subset of the protocol features and a new gateway architecture that will help provide services to multiple zones more reliably. The MacIP protocol is used to transport IP packets across AppleTalk networks. There are many existing host and gateway implementations of this protocol, and most of them have many slight differences. "AppleTalk Management Information Base II", S. Waldbusser, K. Frisa, 12/21/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. RFC1243 defines a set of MIB objects for managing the lower layers of the AppleTalk protocol stack, up to the Network layer. This memo defines additional objects that exist in the AppleTalk portion of the MIB. These objects provide for the management of the transport and session layers of the AppleTalk protocol stack, as well as extensions to the lower layers. This is achieved in an upwardly-compatable fashion. IP over Asynchronous Transfer Mode ---------------------------------- "Multiprotocol Interconnect over ATM Adaptation Layer 5", Juha Heinanen, 11/24/1992, 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. Audio/Video Transport --------------------- "Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications", H. Schulzrinne, 12/17/1992, This draft is a companion document to the RTP protocol draft draft-ietf-avt-rtp-00.{txt,ps}. It discusses aspects of sign transporting real-time services (such as voice or video) over the Internet. It compares and evaluates design alternatives for a real-time transport protocol, providing rationales for the design decisions made for RTP. Also covered are issues of port assignment and multicast address allocation. A comprehensive glossary of terms related to multimedia conferencing is provided. "Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control", H. Schulzrinne, 12/16/1992, This note describes a profile for the use of the real-time transport protocol (RTP) within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from content index to encodings. "Media Encodings", H. Schulzrinne, 12/16/1992, This document describes a possible structure of the media content for audio and video for Internet applications. The definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. "A Transport Protocol for Real-Time Applications", H. Schulzrinne, 12/17/1992, This draft describes a protocol (RTP) suitable for the transport of real-time data, such as audio, video or simulation data. The data transport is enhanced by a control protocol designed to provide minimal control and identification functionality. A reverse control protocol provides mechanisms for monitoring quality of service and other content-specific requests. This protocol is intended for experimental use. Border Gateway Protocol ----------------------- "Default Route Advertisement In The Border Gateway Protocol", Dimitry Haskin, 09/18/1992, This document specifies the recommendation of the BGP Working Group on default route advertisement support in BGP2 and BGP3 versions of the Border Gateway Protocol. This recommendation only applies to BGP2 and BGP3 versions of the Border Gateway Protocol since starting with the BGP4 version a default route advertisement capability is built in the protocol. "IP Multicast Communications Using BGP", Scott Brim, Yakov Rekhter, 10/23/1992, This document, a major revision of the previous version, reflects the current status of recommendations for supporting inter-domain multicast packet forwarding using BGP. Research is underway on other methods for inter-domain multicasting, but only what can be done today is considered here. "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, 12/02/1992, The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 and EGP usage in the NSFNET Backbone as described in RFC 1092 and RFC 1093. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. "Definitions of Managed Objects for the Border Gateway Protocol (Version 4)", S. Willis, J. Burruss, J. Chu,, 12/22/1992, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. "BGP4 OSPF Interaction", K. Varadhan, 09/15/1992, This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP4 with other ASBRs external to the AS and OSPF as its IGP. "Application of the Border Gateway Protocol in the Internet", Y. Rekhter, P. Gross, 10/01/1992, This document, together with its companion document, "A Border Gateway 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 (iwg@rice.edu). Bridge MIB ---------- "Definitions of Managed Objects for Bridges", E. Decker, P. Langille, A. Rijsinghani,, 10/27/1992, 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. Common Authentication Technology -------------------------------- "Generic Security Service Application Program Interface", John Linn, 12/01/1992, This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications. "The Kerberos Network Authentication Service (V5)", John Kohl, B. Clifford Neuman, 09/02/1992, This DRAFT document gives an overview and specification of the Version 5 protocol for the Kerberos network authentication system. Version 4 is presently in production use at MIT's Project Athena, and at other Internet sites. "Generic Security Service API : C-bindings", John Wray, 08/25/1992, This draft document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other drafts. The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative underlying cryptographic mechanisms. Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. "Distributed Authentication Security Service", Charles Kaufman, 12/11/1992, Abstract not provided. Commercial Internet Protocol Security Option -------------------------------------------- "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Trusted Sys Interop. Group (TSIG), 08/31/1992, This Internet Draft provides the high level specification for a Commercial IP Security Option (CIPSO). This draft reflects the version as approved by the CIPSO IETF Working Group. Dynamic Host Configuration -------------------------- "Clarifications and Extensions for the Bootstrap Protocol", Walt Wimer, 09/02/1992, Some aspects of the BOOTP protocol were rather loosely-defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these. "Dynamic Host Configuration Protocol", R. Droms, 11/10/1992, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. "Interoperation Between DHCP and BOOTP", R. Droms, 11/10/1992, The Dynamic Host Configuration Protocol (DHCP) provides a superset of the functions provided by the Bootstrap Protocol (BOOTP). This document describes the interactions between DHCP and BOOTP network participants. "DHCP Options and BOOTP Vendor Extensions", S. Alexander, R. Droms, 11/10/1992, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the "options" field of the DHCP message. The data items themselves are also called "options." This document specifies the current set of DHCP options. This document will be periodically updated as new options are defined. Each superseding document will include the entire current list of valid options. Directory Information Services Infrastructure --------------------------------------------- "A Survey of Advanced Usages of X.500", Chris Weider, Russ Wright, Elizabeth Feinler,, 10/07/1992, 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. Domain Name System ------------------ "DNS MIB Extensions", R. Austein, J. Saperia, 11/23/1992, This memo defines a set of DNS (Domain Name System) extensions that have been created for the Internet MIB. When used in conjunction with the Structure of Management Information (RFC 1155), the Management Information Base for Network Management of TCP/IP-based internets (RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of DNS resolver and server software in standard TCP/IP based environments. This document was produced by the DNS working group. "A Strategy for Encoding Hierarchical Addresses in Internet Name Services", G. Wollman, 12/17/1992, This document describes NAP-based addressing, a scheme for abstracting and encoding hierarchical addresses in a name service in such a way as to allow the entities responsible for various levels in an address to change their portions independently and scaleably. As a byproduct, it also defines a particular addressing scheme which the author believes to be appropriate for the existing model of Internet connectivity. Ethernet MIB ------------ "Definitions of Managed Objects for the Ethernet-like Interface Types", Frank Kastenholz, 08/13/1992, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. IP over FDDI ------------ "Transmission of IP and ARP over FDDI Networks", D. Katz, 09/14/1992, This document specifies a method for the use of IP and ARP on FDDI networks. The encapsulation method used is described, as well as various media-specific issues. Host Resources MIB ------------------ "Host Resources MIB", Pete Grillo, Steven Waldbusser, 10/07/1992, This memo defines a MIB for use with managing host systems. The term "host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. Internet Architecture Board --------------------------- "IP Version 7", Internet Architecture Board, 07/01/1992, Internet growth has created serious problems of address space consumption and routing information explosion. A solution to these problems requires a new version of the Internet Protocol, which we call IP version 7 ("IPv7"). This memo presents architectural guidelines that any IPv7 should meet. It then discusses how an IPv7 based upon the OSI CLNP protocol would meet these requirements, and presents the reasons for the IAB's preference for this solution. Finally, it makes a three-part recommendation: (1) proceed at full speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3) continue to pursue research in advanced routing and other future extensions of the Internet architecture. "Draft revision to RFC-1310 -- The Internet Standards Process", L. Chapin, 11/13/1992, This memo is a draft of the first update to RFC-1310, which documents the current standards procedures in the Internet community. This memo is being distributed for comment from the Internet community. Major changes in this update include the following: (a) Add Prototype Status (b) Rewrite the Intellectual Property Rights section, to incorporate legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. (c) Describe new procedures, e.g., the IESG "last call". (d) Incorporate many suggestions made by IETF members. Significant content changes from RFC-1310 are noted with change bars. In addition, there are many stylistic changes and some reorganization. TCP Client Identity Protocol ---------------------------- "Ident MIB", Michael St. Johns, Marshall Rose, 08/03/1992, 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 931. "Identification Server", Mike StJohns, 11/23/1992, The Identification Server Protocol (aka "ident", aka "the Ident Protocol", aka "the Identification Protocol") provides a means to determine the identity of a user of a particular TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. The Identification Server Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. Inter-Domain Policy Routing --------------------------- "An Architecture for Inter-Domain Policy Routing", Marianne Lepp, Martha Steenstrup, 06/24/1992, We present an architecture for inter-domain policy routing (IDPR). The objective of inter-domain policy routing is to construct routes between source and destination administrative domains, that provide user traffic with the requested service 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. "Inter-Domain Policy Routing Protocol Specification: Version 1", M. Steenstrup, 06/03/1992, We present the set of protocols and procedures that constitute inter-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. "IDPR as a Proposed Standard", M. Steenstrup, 04/28/1992, The objective of IDPR is to construct and maintain routes between source and destination administrative domains, that provide user traffic with theand destination administrative domains, that provide user traffic with the services requested within the constraints stipulated for the domains transited. IP Address Encapsulation ------------------------ "IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and the Simple Internet Protocol (SIP)", R. Hinden, S. Deering, D. Crocker,, 11/11/1992, This document describes how the IPv7 proposal called IP Address Encapsulation (IPAE) meets the evaluation criteria established by the Internet Engineering Steering Group and described in "RFC-1380 IESG Deliberations on Routing and Addressing". IPAE is currently developed to be a transition mechanism for a new IP protocol. This document focuses on the specific case of using IPAE to transition to the Simple IP Protocol (SIP). It addresses the criteria against both IPAE and SIP. This document also includes how IPAE meets the criteria described by Craig Partridge in a message titled "Criteria for selecting IPv7" sent to the Big-Internet mailing list on 22-October-1992. "IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP", D. Crocker, R. Hinden, 11/11/1992, The Internet seeks to increase the amount of IP address space that is available for hosts and to decrease the amount of table storage that is required by routers. Ultimately, the current IP (IP version 4) and any replacement are inherently incompatible and movement to the new version requires very substantial change to the IP installed base. This specification describes an approach which retains as much software, operations and training as possible, and minimizes overall operational disruption by allowing subsets of the Internet to carry the new-format Internet datagrams inside old-style IPv4 datagrams, using a technique called "IP Address Encapsulation" (IPAE). This permits incremental and asynchronous introduction and makes transition entirely optional for portions of the Internet infrastructure. It further permits early reduction to routing table size. IP over Large Public Data Networks ---------------------------------- "Shortcut Routing: Discovery and Routing over Large Public Data Networks", P. Tsuchiya, J. Lawrence, 06/29/1992, Various RFCs and Internet Drafts specify how to run IP or CLNP over various public data network services. These documents specify the encapsulation to be used, and sometimes specify protocol techniques to aid in discovery and routing functions. None of the specifications, however, solve the problem of discovery and routing in the full, especially with respect to scaling. This RFC extends these specifications by describing a general and scalable technique, called shortcut routing, for discovery and routing of any connection-less internet protocol over any switched data network (connectionless or connection-oriented). "Directed ARP", John Garrett, John Hagan, Jeff Wong,, 06/19/1992, 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 (via ICMP 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. ISIS for IP Internets --------------------- "Integrated IS-IS Management Information Base", Chris Gunner, 10/01/1992, This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the operation of the Integrated IS-IS routing protocol. MHS-DS ------ "Representing Tables and Subtrees in the Directory", S. Hardcastle-Kille, 11/09/1992, This document defines techniques for representing two types of information mapping in the OSI Directory. "Representing the O/R Address hierarchy in the Directory Information Tree", S. Hardcastle-Kille, 11/09/1992, This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. This is useful for a range of purposes, including Support for MHS Routing and Support for X.400/RFC 822 address mappings. "MHS use of the Directory to support distribution lists", S. Hardcastle-Kille, 11/10/1992, This document specifies a procedure for managing distribution lists using the directory. This is an extension of the mechanism defined in X.400. "Use of the Directory to support mapping between X.400 and RFC 822 Addresses", S. Hardcastle-Kille, 11/10/1992, This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327. "A simple profile for MHS use of Directory", S. Hardcastle-Kille, 11/10/1992, The document ``MHS Use of Directory to support MHS Routing'' describes a comprehensive approach to MHS use of directory to support routing. This document defines a strict subset of this document, which is intended to solve the most pressing problems. It also defines a practical first step for implementation, such that this subset can be deployed prior to fuller implementation. "Use of the Directory to support routing for RFC 822 and related protocols", S. Hardcastle-Kille, 11/10/1992, This document defines a mechanism to route RFC 822 using the OSI Directory. The basic mechanisms are being developed for routing X.400. These offer a number of benefits relative to the the current mechanisms available for RFC 822 routing. The prime goal of this specification is to provide integrated routing management for sites using both RFC 822 and X.400. "MHS use of Directory to support MHS Routing", Steve Hardcastle-Kille, 11/10/1992, This document specifies an approach for X.400 Message Handling Systems to perform application level routing using the OSI Directory. Use of the directory in this manner is fundamental to enabling large scale deployment of X.400. "MHS use of Directory to support MHS Content Conversion", S. Hardcastle-Kille, 11/10/1992, User Agents have various capabilities for support of multimedia messages. To facilitate interworking between UAs of differing capabilities, it is useful for the MTS to be able to perform content conversion. This document specifies an approach for X.400 Message Handling Systems to perform application level routing using the OSI Directory in order to support content conversion. This document assumes MHS use of directory to perfom routing accoreding to ``MHS use of Directory to support MHS Routing''. MIME-MHS Interworking --------------------- "Mapping between X.400 and RFC-822 Message Bodies", H. Alvestrand, S. Hardcastle-Kille, R. Miles, M. Rose, S. Thompson,, 09/01/1992, Abstract not provided. "Equivalences between 1988 X.400 and RFC-822 Message Bodies", H. Alvestrand, S. Thomspon, 11/11/1992, This document defines specific content-type conversions between MIME and X.400/88, using the architecture defined in the "mapping" document. "HARPOON: Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages", H. Alvestrand, J. Romaguera, K. Jordan,, 09/28/1992, The IETF MIME-MHS working group has defined how to gateway MIME messages between X.400(88) and MIME with minimal loss of functionality. This document describes how to translate that functionality into X.400(84) messages. Multicast Extensions to OSPF ---------------------------- "Multicast Extensions to OSPF", J. Moy, 10/21/1992, This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. In this proposal, an IP multicast packet is routed based both on the packet's source and its multicast destination (commonly referred to as source/destination routing). As it is routed, the multicast packet follows a shortest path to each multicast destination. During packet forwarding, any commonality of paths is exploited; when multiple hosts belong to a single multicast group, a multicast packet will be replicated only when the paths to the separate hosts diverge. OSPF, a link-state based routing protocol, provides a database describing the Autonomous System's topology. A new OSPF link state advertisement is added describing the location of multicast destinations. A multicast packet's path is then calculated by building a pruned shortest-path tree rooted at the packet's IP source. These trees are built on demand, and the results of the calculation are cached for use by subsequent packets. SNMP over a Multi-protocol Internet ----------------------------------- "SNMP over AppleTalk", G. Minshall, M. Ritter, 07/24/1992, This memo describes the method by which the Simple Network Management Protocol (SNMP) can be used over AppleTalk protocols instead of the Internet UDP/IP protocol stack. This specification is useful for network elements which have AppleTalk support but lack TCP/IP support. It should be noted that if a network element supports multiple protocol stacks, and UDP is available, it is the preferred network layer to use. "SNMP over OSI", Marshall Rose, 07/21/1992, The Simple Network Management Protocol (SNMP) as defined in is now used as an integral part of the network management framework for TCP/IP-based internets. Together with its companions standards, which define the Structure of Management Information (SMI), and the Management Information Base (MIB) , the SNMP has received widespread deployment in many operational networks running the Internet suite of protocols. "SNMP over IPX", Steve Bostock, 08/20/1992, This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet (IPX) protocol. Network Access Server Requirements ---------------------------------- "Network Access Server Proposed Requirements Document", J. Vollbrecht, A. Rubens, G. McGregor, L. Blunk, Richard Conto,, 10/01/1992, This document attempts to define a set of requirements for a class of devices referred to as Network Access Servers (NAS's). The term "Network Access Server" is used instead of the more conventional term "Terminal Server" as it more accurately describes the devices of interest. This is written as input to the NAS requirements working group of the IETF. Network Database ---------------- "Network Database Protocol", Daisy Shen, 06/24/1992, This memo defines a protocol for use with relational database systems in a TCP/IP based internet environment. This protocol is intended to make interoperability among different database systems possible. It is built on RPC (Remote Procedure Call) with a client/server type of relationship. This document also defines the concept of Unit of Work. The work of Network Database is involved with Data Conversion, Security, I/O Buffer Management, and Transaction Management. They will be described one by one in this document. "Network Database Implementation Information Internet Draft", Daisy Shen, 06/24/1992, This document provides the implementation information of Network Database Protocol. The protocol is defined in the document of Network Database Protocol for use with relational database systems in a TCP/IP based Internet environment. This document will show readers some data structures and examples, and provide as much details information as possible. This document will go over each component one by one. Network News Transport Protocol ------------------------------- "Network News Transfer Protocol Version 2: A Protocol for the Stream-Based Transmission of News", Eliot Lear, 12/10/1992, Abstract not provided. NOC-Tool Catalogue Revisions ---------------------------- "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", R. Enger, J. Reynolds, 11/11/1992, The goal of this FYI memo is to provide an update to FYI 2, RFC 1147, 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 Robert Enger, at enger@ans.com, or to the NOCTools2 Working Group, at: noctools@merit.edu. To subscribe: noctools-request@merit.edu. Independant Submissions to Internet Drafts ------------------------------------------ "A Method for the Transmission of IP Datagrams Over SNA Networks Using LU6.2 Conversations", H. Stevenson, S. Schwell, W. Siddall,, 05/29/1992, Proposes a method for the transmission of IP datagrams over SNA networks using Advanced Program to Program Communication (APPC) conversations, and requests discussion and suggestions for improvements. IP datagrams between two LU 6.2 nodes are transmitted as GDS records on a uni-directional conversation between a pair of sending and receiving transaction programs (TPs). "HYBRID NETBIOS END-NODES", F. Noon, 10/08/1992, STD-19/RFC-1001/RFC-1002 defines a "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport," or "NetBIOS-over-TCP" for short. STD-19 defines NetBIOS end-nodes as stations which "support NetBIOS service interfaces and contain applications." That standard describes three types of end-nodes: Broadcast nodes (B nodes), Point-to-point nodes (P nodes), and Mixed mode nodes (M nodes). This memo describes a fourth note type, an H node, which is basically a P node which can transmit UDP broadcasts when NetBIOS servers cannot be reached. "IDRP for IP", Susan Hares, 07/21/1992, IDRP is defined as the protocol for exchange of Inter-Domain routing information between routers to support forwarding of ISO 8473 PDUs (Connectionless Network Layer Protocol (CLNP)). This document contains the appropriate adaptation to the IDRP protocol definition that enables it to be used as protocol for exchange inter-autonomous system information among routers to support forwarding of IP packets across multiple autonomous systems. The adaptation is defined is such a way that a Dual IDRP will be able to fully interoperate with IDRP for IP. "Physical Link Security Type of Service", Donald Eastlake, III, 11/10/1992, This draft proposes a type of service (TOS) to request maximum physical link security. This would be an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This TOS would request 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 in that it is based on physical link characteristics and will not provide any particular guaranteed level of service. "A Revision to IP Address Classifications", F. Solensky, F. Kastenholz, 04/20/1992, This memo presents an extension to the method of classifying and assigning IP network numbers. It is intended to provide a work-around to the imminent exhaustion of assignable Class B network numbers (and, to a lesser extent, the recent growth of routes that need to be tracked in the NSFNet routing database) by defining the format of Class C-sharp (C#) IP addresses, consuming the upper half of the existing Class C numbering space. The manner in which these changes impact existing systems is also discussed. It is a product of a "birds-of-a-feather" (BoF) discussion held on July 31, 1991 at the twenty-first IETF conference in Atlanta, GA and subsequent discussions on the mailing list. It should be noted that this document does NOT solve the limitations inherent in the current routing architectures and technology that are discussed. These must wait until new architectures are developed. Specifically, the issue of scaling the size of future routing tables is only indirectly addressed. "UPS Management Information Base", M. Davison, R. Wasson, R. Draper, J. Case, 07/06/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing uninterruptable power supply (UPS) systems. "Pip: The `P' Internet Protocol", P. Tsuchiya, 05/20/1992, Pip is an IP protocol that scales, encodes policy, and is high speed. The purpose of this draft is to explain the basic concepts behind Pip so that people can start thinking about potential pitfalls. I am proposing Pip as an alternative to the two "medium term" proposals that emerged from the Road (Routing and Addressing) group to deal with the dual IP problems of scaling and address depletion. Because this proposal, which represents new ideas, is competing with old (and therefore well thought-out) ideas, I wish to circulate it (and get the process started) as quickly as possible, albeit in not as complete a form as I would like. I expect to have a complete proposal by the beginning of September. There will be a plenary presentation and a BOF covering this material at the Boston meeting of IETF. "Guidelines for IP Address Allocation", Y. Rekhter, T. Li, 10/23/1992, This paper provides guidelines and a plan for allocating IP addresses in the Internet. These guidelines and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. The IP address space is a scarce shared resource that must be managed for the good of the community. The managers of this resource are acting as its custodians. They have a responsibility to the community to manage it for the common good. "A Proposal for A Global Internet Addressing Scheme", Daniel Karrenberg, Bernhard Stockman, 05/28/1992, This is a proposal for a hierarchically based assignment of future IP addresses by distributed control of segments of the IP address space. "TN3287 Printer Specification", Cleve Graves, 06/05/1992, The purpose of the TN3287 protocol is to provide a general, bi-directional printer communications facility. It's primary goal is to allow a standard method of interfacing printer devices and printer-oriented processes to each other. This protocol will allow a TN3270 Client to process 3287 print data streams. This RFC supplements and extends the RFC 854, TELNET Protocol Specification. This RFC also presents an example of the correct implementation. "Pip Overview and Examples", Paul Tsuchiya, 06/28/1992, Pip is an internet protocol that scales efficiently encodes policy. It facilitates many advanced features, such as mobility and multiple defaults routing, and has a well-bounded routing table lookup, and is therefore fast. Pip is proposed as an alternative to the two "medium term" proposals that emerged from the Road (Routing and Addressing) group to deal with the dual IP problems of scaling and address depletion. "Son of IPSO A Generic IP Sensitivity Labeling Option", Michael C. St Johns, 06/17/1992, This document is a direct descendent of RFC1038 and RFC1108 and is a close cousin to the work done in the Commercial IP Security Option (CIPSO) Working Group of the Trusted Systems Interoperability Group. The original IP Security options defined by 1038 and 1108 were designed with one specific purpose in mind - to support the fielding of an IP packet encryption device called a BLACKER. Because of this, the definitions and assumptions in those documents were necessarily US Department of Defense and BLACKER centric. This document is meant to serve a larger community, while still meeting the needs of the 1038/1108 audience. "NET-UTF: International character set", R. L. Ullmann, 06/17/1992, The Internet is no longer a creature of the United States, much less of DARPA (the US Defence Advance Research Projects Agency). It is now an international network, and the ability to communicate in any of the world languages on an equal footing is an imperative. This draft attempts to track the development of ISO 10646, a moving target at this writing. The reference citation below is to the 2nd 10646 draft, for which balloting has just concluded. (June 1992). It is therefore expected that this memo will potentially change until the publication of IS 10646. Some of the following text refers to 10646 in the present tense, as if it is IS now; it should be understood in this context. "ISO Transport Protocol (ISO 8072 & ISO 8073) Management Information Base", Russell Blaesing, James Verploegh, 06/19/1992, This memo defines an experimental version of an ISO Transport Management Information Base for use with network management protocols. "IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP", R. Hinden, D. Crocker, 11/11/1992, The Internet seeks to increase the amount of IP address space that is available for hosts and to decrease the amount of table storage that is required by routers. Ultimately, the current IP (IP version 4) and any replacement are inherently incompatible and movement to the new version requires very substantial change to the IP installed base. This specification describes an approach which retains as much software, operations and training as possible, and minimizes overall operational disruption by allowing subsets of the Internet to carry the new-format Internet datagrams inside old-style IPv4 datagrams, using a technique called "IP Address Encapsulation" (IPAE). This permits incremental and asynchronous introduction and makes transition entirely optional for portions of the Internet infrastructure. It further permits early reduction to routing table size. "Definitions of Managed Objects for the SONET Interface Type", Tracy Cox, Kaj Tesink, 06/30/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SONET objects. This document is a companion document with Definitions of Managed Objects for the DS1 and DS3 Interface Types, RFC1232 and RFC1233. "EIP: The Extended Internet Protocol a long-term solution to Internet address exhaustion", Zheng Wang, 07/02/1992, In this paper, we present the Extended Internet Protocol (EIP) which provides a long-term solution to Internet address exhaustion. What we propose here is not a new addressing and routing scheme, but a framework in which any addressing and routing schemes can be accommodated. The goal of EIP is to provide maximum flexibility to accommodate any addressing and routing schemes yet to maintain maximum backward compatibility with current IP. It can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. "Transmitting IP Traffic over LocalTalk Networks", C. Ranch, 07/10/1992, This draft document specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across LocalTalk. It is intended to supplement existing technology for enabling Apple Macintoshes with built-in LocalTalk network media to communicate with other IP hosts in a TCP/IP internet. "Core Based Trees - Scalable Multicast Routing", J. Crowcroft, T. Ballardie, P. Tsuchiya,, 11/10/1992, Multicasting is a technique used which allows for group communication either locally or on a wide-area scale. Most local-area networks such as Ethernet and Token Ring provide a multicast service, which has since been exploited by many applications and distributed systems. More recently, multicast capability has been extended to the internetwork using a combination of a distance-vector routing algorithm, a host-to-router group-membership reporting protocol, and the computation of sender-based multicast trees. This, and other approaches to internetwork multicasting, are not scalable to large groups, especially so for large numbers of groups. This document provides a proposal for a new multicast routing algorithm which provides multicast capability in a datagram internetwork. It is scalable, low-cost and efficient - properties lacking in current internetwork multicast routing protocols. Distribution of this draft is unlimited. A mailing list is in place in idmr@cs.ucl.ac.uk (subscribe to idmr-request@cs.ucl.ac.uk) to discuss this and other inter-domain multicast routing issues. "TCP/IP: Internet Version 7", R. L. Ullmann, 12/03/1992, This memo describes a proposal for the next version of the Internet protocols. The protocol is described is for information only, this does not represent a protocol on the formal internet standards track at this writing. The first version of this memo, describing a possible Internet Version 7 protocol was written by the present author in the summer and fall of 1989, and circulated informally, including to the IESG, 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. "AUDIT INFORMATION TRANSFER PROTOCOL (AITP)", J. Dempsey, C. Feil, N. Lewis,, 08/13/1992, This document defines the Audit Information Transfer Protocol (AITP), a simple transaction protocol suitable for transferring audit information between systems. An initiator can use AITP to request audit data from, or set audit management parameters at, a responder. The responder handles the request and sets or returns the resulting data. Both the amount of time required to generate the response and the amount of audit data returned can be very large. These are the main reasons for a unique protocol to support this type of service. "Use of ISO CLNP in TUBA Environments", David Piscitello, 09/04/1992, This document describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. CLNP provides essentially the same datagram service as Internet Protocol, but offers a means of conveying bigger network addresses (with additional structure, to aid routing). While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments. This maximizes the use of already-deployed CLNP implementations. "Source Demand Routing Protocol Specification (Version 1).", Deborah Estrin, Tony Li, Yakov Rekhter,, 10/30/1992, The purpose of SDRP is to support source-initiated selection of inter-domain routes to complement the intermediate-node route selection provided by BGP ([1], [2], [3]) or IDRP ([4]). This document refers to such source-initiated routes as "SDRP routes". The protocol makes minimal assumptions about the distribution and acquisition of routing information needed to construct the SDRP routes. These minimal assumptions are believed to be sufficient for the existing Internet. Future versions of the protocol will extend capabilities in this area and others in a largely backward-compatible manner. This version of the protocol sends all packets with the complete SDRP route in the SDRP header. Future versions will address route setup and other enhancements and optimizations. "The Tao of IETF: A Guide for New Attendees of the Internet Engineering Task Force", Gary Malkin, 10/02/1992, Over the last two years, the attendance at Internet Engineering Task Force (IETF) Plenary meetings has grown phenomenally. Approximately 38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages. The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. "IP Version 7 Bibliography", B. Fink, 11/10/1992, This Internet Draft provides a bibliography of documents which address the routing and addressing scaling problems in the current IP architecture, and the design of the next generation of the IP protocol suite, commonly referred to as IPv7. This document is intended to simplify the process of locating all of the relevant documents pertaining to this area. These documents take various forms, including Request For Comments (RFCs), Internet Drafts (I-Ds), and other papers produced either by Working Groups of the IETF or individuals actively working in this area. It is suggested that Internet Drafts related to this topic reference this bibliography I-D, which will be updated on a regular basis as new documents are published or existing ones are modified or change status, e.g. from Internet Draft to RFC. "Traceroute", G. Malkin, 10/29/1992, Traceroute serves as a valuable network debugging tool. The way in which it is currently implemented has the advantage of being automatically supported by all of the routers. It's two problems are the number of packets it generates and the amount of time it takes to run. This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. "Requirements for mail based servers", J. Houttuin, A. Cargille, 10/15/1992, This document defines minimal requirements and recommendations that must be implemented in all mail based servers in the Internet e-mail community and all e-mail networks connected to it, such as the GO-MHS community. "Application Monitoring MIB", S. Hardcastle-Kille, T. Lenggenhager, D. Partain, W. Yeong,, 10/19/1992, This document defines a MIB for monitoring applications running on a system. It defines specific attributes for MTAs and DSAs, and this approach could be easily extended to other applications. This document is an agreed ISODE Consortium specification (IC 4 (Version 3.12)). "Mapping between X.400 and RFC 822 for a closed RFC 822 Community", S. Hardcastle-Kille, 10/19/1992, This document proposes a modification of the X.400/RFC 822 mapping described in RFC 1327, for a specific type of application. This document will be submitted to the IETF X.400 OPS WG for suggested progress as a standards track RFC. "SMTP Accumulated knowledge", J. Onions, 10/20/1992, This memo describes a number of folklore issues associated with the SMTP protocol and attempts to tie down some loose ends. This document is an extension to RFC-821 and its extensions, not a replacement. This document is for information and does not set any standard. It indicates what is correct, what is pragmatic, and what is religious. "IP and ARP on Fibre Channel (FC)", Y. Rekhter, 10/22/1992, This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on FC hardware and protocols. "Possible Changes in the Standards Development Process", S. Crocker, C. Malamud, 10/26/1992, This document is a response to the call for a working group to examine the Process for Organization of Internet Standards (POISED). The document contains one possible set of solutions to the issues examined by the POISED working group. It does not reflect a position of the working group and is not necessarily a consensus view. The document suggests the replacement of the current technology development bodies of the Internet (the IAB, IETF, IESG, and IRTF) with a new, streamlined structure. We refer to this community as the Technical Task Force of the Internet. The document also deals at length the with questions of accountability of boards to the general membership. The document recommends a set of procedures, such as open meetings, and discusses ways of handling the selection and approval process for personnel changes. The document considers many of these issues within the broader context of the Internet Society as well as the Technical Task Force. "Criteria for Choosing IP Version 7 (IPv7)", C. Partridge, F. Kastenholz, 12/14/1992, This note attempts to codify and organize the criteria to be used in evaluating the protocols being proposed for adoption as IP Version 7. "TCP & UDP with Network-independent Endpoints (TUNE)", J. Curran, 11/06/1992, This memo proposes a strategy for providing TCP and UDP services over _multiple_ network services in a manner compatible with existing TCP/IP applications. By introducing network-independent endpoint identifiers for transport entities, TUNE makes it possible to change network addresses (and potentially network protocols) without impact to the application layer. While this paper describes the use of Connection-Less Network Protocol [1] as a possible long-term network service for the Internet, the overall approach differs from the "TCP & UDP with Bigger Addresses" [2] initiative due to the addition of network-independent endpoint identifiers. TUNE also provides network layer programming interfaces which are unchanged from those of the current Internet Protocol (IP) suite and hence alleviate the need for application code changes during initial deployment. Comments should be sent to the author (jcurran@nic.near.net). "IP Multicast over Token-Ring Local Area Networks", T. Pusateri, 11/30/1992, 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. "Simple Internet Protocol (SIP) Specification", S. Deering, 11/11/1992, This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast. "ISO/CCITT and Internet Management Coexistence (IIMC): Translation of ISO/CCITT GDMO MIBs to Internet MIBs (IIMCOMIBTRANS)", O. Newnan, 11/23/1992, This memo is intended to facilitate the use of ISO/CCITT CMI for integrated management of networks via proxy management of TCP/IP networks that are managed using SNMP. This memo provides heuristic procedures that translate managed object specifications from ISO/CCITT Guidelines for Definition of Managed Object (GDMO) templates to Internet MIB macros. Currently, some market segments demand SNMP for customer network management while others require the ISO/CCITT Common Management Information Protocol (CMIP). This approach accommodates both, protecting investment already made in management information specifications and minimizing cost to implement a second protocol where the market requires. The translation is designed to: lose as little functionality as possible in translation; minimize need for human involvement to translate; minimize cost to implement dual protocol and proxy-based applications; and support generic network models that span many computer platforms and network elements. It has been contributed the network and systems management community to encourage standardization of such an approach and promote consistent usage of MIB definitions independent of protocol. "Routing over Demand Circuits on Wide Area Networks - RIP", G. M. Meyer, 11/23/1992, Running routing protocols on connection oriented Public Data Networks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection must to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data. Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide Area Network (WAN). This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above. The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links. "ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet Party MIB (RFC1353) to ISO/CCITT GDMO MIB (IIMCPARTY)", L. LaBarre, 11/23/1992, This memo is intended to facilitate the multi-protocol management coexistance and interworking for networks that are managed using the OSI Common Management Information Protocol (CMIP) and networks that are managed using the Simple Network Management Protocol (SNMP). This RFC contains the OSI definition and registration of the IIMC SNMP Parties MIB as derived from the Internet SNMP Parties MIB (RFC1353) according to the procedures defined in "Translation of Internet MIBs for CMIP/SNMP and SMP Proxy" [IIMCMIBTRANS]. "ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB (IIMCMIB-II)", L. LeBarre, 11/23/1992, This memo is intended to facilitate the multi-protocol management coexistance and interworking for networks that are managed using the OSI Common Management Information Protocol (CMIP) and networks that are managed using the Simple Network Management Protocol (SNMP). This RFC contains the OSI definition and registration of the OSI Proxy MIB-II as derived from the Internet MIB-II [RFC1213] according to the procedures defined in "Translation of Internet MIBs to OSI GDMO MIBs" [IIMCIMIBTRANS]. In addition, it includes the IP Forwarding Table defined in [RFC1354]. "ISO/CCITT and Internet Management Coexistence (IIMC): ISO/CCITT to Internet Management Proxy (IIMCPROXY)", A. Chang, 11/23/1992, This memo is intended to facilitate the use of the OSI Common Management Information Protocol (CMIP) for integrated management of networks via proxy management of TCP/IP networks that are managed using Simple Network Management Protocol (SNMP). This memo describes a ISO/Internet "proxy" which allows interworking between CMIP-based managers and SNMP-based agents. The proxy emulates CMIS service requests by mapping between corresponding ISO/CCITT GDMO and Internet MIB definitions, and generating SNMP message(s) needed to emulate the service. The proxy also emulates CMIS service responses and notifications by converting incoming SNMP response and trap message(s) in a similar fashion. Thus, the proxy appears as a CMIP-based agent to the manager, and as an SNMP-based manager to the agent. The proxy depends on the availability of corresponding MIB definitions translated as described in [OIMMIBTRANS]. "ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs (IIMCIMIBTRANS)", L. LeBarre, 11/23/1992, This memo is intended to facilitate the multi-protocol management coexistance and interworking for networks that are managed using the OSI Common Management Information Protocol (CMIP) and networks that are managed using the Simple Network Management Protocol (SNMP). This RFC contains translation and registration procedures that are applicable to translation of Internet MIBs defined according to the Internet Structure of Management Information (SMI) into ISO/CCITT SMI defined MIBs. It also defines management information and SNMP trap to ISO/CCITT event mappings required for ISO/CCITT-Internet proxy. "RFC 1327 tutorial", J. Houttuin, 11/24/1992, This tutorial was produced to help RFC 1327 novices, such as new gateway managers, to find their way into this complicated subject. End-users are encouraged to read the COSINE MHS pocket user guide [pug] instead. The COSINE MHS managers agreed that this tutorial is needed because it is often felt that the learning curve for this subject is frustratingly steep. The introduction is general enough to be read not only by gateway managers, but also by those who are new to e-mail in general. Parts of this introduction can be skipped as needed. To a certain extent, this document can also be used as a reference guide to X.400 <-> RFC 822 gatewaying. Wherever there is a lack of detail in the tutorial, it will at least refer to the corresponding chapters in other documents. As such, it shields the RFC 1327 novice from too much detail. "DNS NSAP RRs", B. Manning, R. Colella, 11/30/1992, 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 DNS for mapping between names and NSAP addresses. This document redefines the format of two new Resource Records for the Domain Name System, as defined in RFC 1348. This format may be used with any OSI NSAP address format. "Definitions of Managed Objects for the HIPPI Interface Type", J. Miller, 12/21/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing HIPPI objects. These objects are intended to be used in conjunction with the interface mib to fully monitor a HIPPI interface. "A RFC Subseries for IETF Statements Of Policy (SOPs)", T. Li, Y. Rekhter, 12/23/1992, The IETF currently has no other mechanism or means of publishing relevant technical information which it endorses. This document creates a new subseries of RFCs, entitled IETF Statements Of Policy (SOPs). The SOP process is similar to that of the normal standards track. The SOP is submitted to the IESG for review, and the existing review process for standards track documents applies. Network OSI Operations ---------------------- "Tools RFC", S. Hares, C. Wittbrodt, 11/10/1992, This draft specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): 1) ping or ISO Echo function 2) traceroute function which uses the ISO Echo function and 3) routing table dump function "An Echo Function for ISO 8473", R. Hagens, 11/10/1992, This memo defines an echo function for the connection-less network layer protocol. The mechanism that is recommended here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" This document is intended to mirror the ISO work and provide easy access to that information to the Internet community. OSI Integration Area -------------------- "FTP-FTAM Gateway Specification", J.L. Mindel, R.L. Slaski, 09/10/1992, 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. The proposed application layer gateway is based on a set of mappings between the FTP and FTAM protocols. The gateway is comprised of a dual set of mappings: FTP to FTAM, and FTAM to FTP. Since the protocols have quite different command structures, the mappings between them are not one-to-one. OSI Directory Services ---------------------- "Using the OSI Directory to Achieve User Friendly Naming", S. Kille, 10/06/1992, 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: 1) A user oriented notation and 2) Guessability. This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This then leads to a specification of a standard format for representing names, and to procedures to resolve them. This leads to a specification which allows directory names to be communicated between humans. The format in this specification is identical to that defined in the reference of "A String Representation of Distinguished Name", and it is intended that these specifications are compatible. "Naming Guidelines for Directory Pilots", P. Barker, S.E. Hardcastle-Kille, 04/14/1992, Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. "A String Representation of Distinguished Names", S. E. Hardcastle-Kille, 10/21/1992, 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. "Lightweight Directory Access Protocol", Wengyik Yeong, Tim Howes, Steve Hardcastle-Kille,, 12/22/1992, The tremendous interest in X.500 technology in the Internet has lead to efforts to reduce the high ``cost of entry'' associated with use of the technology, such as the Directory Assistance Service and DIXIE. While efforts such as these have met with success, they have been solutions based on particular implementations and as such have limited applicability. This document continues the efforts to define Directory protocol alternatives but departs from previous efforts in that it consciously avoids dependence on particular implementations. The protocol described in this document is the first of a series of protocols designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the Directory, and is intended to be a complement to the DAP itself. "The String Representation of Standard Attribute Syntaxes", T. Howes, S. Hardcastle-Kille, W. Yeong, C. Robbins, 08/18/1992, The lightweight directory protocols require 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 lightweight directory protocols, then goes on to define the encoding rules for the standard set of attribute syntaxes. "DSA Metrics", P. Barker, S. Hardcastle-Kille, 09/23/1992, No Abstract provided. "DUA Metrics", Paul Barker, 09/23/1992, No Abstract provided. "A strategic Plan for deploying an Internet Directory Service", S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent, J. Postel,, 10/14/1992, 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 Directory Service. 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 IETF WGs is working towards these goals. Open Shortest Path First IGP ---------------------------- "OSPF Version 2 Traps", Rob Coltun, 11/12/1992, OSPF is an event driven routing protocol, where an event can be a change in an OSPF interface's link-level status, the expiration of an OSPF timer or the reception of an OSPF protocol packet. Many of the actions that OSPF takes as a result of these events will result in a change of the routing topology. As routing topologies become large and complex it is often difficult to locate the source of a topology change or unpredicted routing path by polling a large number or routers. Another approach is to notify a network manager of potentially critical OSPF events with SNMP traps. This draft document defines a set of traps, objects and mechanisms to enhance the ability to manage IP internetworks which use OSPF as its IGP. It is meant as an extension to the OSPF MIB. "The OSPF NSSA Option", R. Coltun, V. Fuller, 10/13/1992, This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. "OSPF Version 2 Management Information Base", F. Baker, R. Coltun, 11/03/1992, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. "OSPF Version 2", J. Moy, 11/11/1992, This memo documents version 2 of the OSPF protocol. OSPF is a link-state based routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree. Privacy-Enhanced Electronic Mail -------------------------------- "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", John Linn, 07/24/1992, This Internet-Draft defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. It is intended to become one member of a related set of four RFCs. The procedures defined in the current document are intended to be compatible with a wide range of key management approaches, including both symmetric (secret-key) and asymmetric (public-key) approaches for encryption of data encrypting keys. Use of symmetric cryptography for message text encryption and/or integrity check computation is anticipated. Related Internet-Drafts specify supporting key management mechanisms based on the use of public-key certificates, algorithms, modes, and associated identifiers, and details of paper and electronic formats and procedures for the key management infrastructure being established in support of these services. "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", Steve Kent, 08/06/1992, This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. It defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients. "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", David Balenson, 11/24/1992, 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. Additional algorithms and modes approved for use in PEM in this context will be specified in successors to this document. "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", B. Kaliski, 09/01/1992, No Abstract Provided. "MIME-PEM Interaction", S. Crocker, N. Freed, M. Rose,, 11/23/1992, This memo defines a framework for interaction between MIME and PEM services. P. Internet Protocol -------------------- "Pip Header Processing", P. Tsuchiya, 10/30/1992, 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 and Hosts. "Pip Objects", P. Tsuchyia, 10/30/1992, Pip has a strong separation of packet syntax and semantics. Each Pip system determines its own syntax for the Handling Directive (HD) and Routing Context (RC) fields. While the syntax can be local, the semantics that the syntax represents must be globally unambiguous. This document 1) describes the syntax for globally unambiguous Pip HD and RC semantics, 2) a packet format for exchanging the mappings between semantics and HD and RC syntax, and 3) lists objects defined for Pip operation. "The EIPIP Protocol: a Pip engine with an EIP shell", Z. Wang, P. Tsuchiya, 11/03/1992, In this memo, we present an internet protocol called "EIPIP". EIPIP is basically a protocol with a Pip engine and an EIP shell; it has the full capacity of Pip and all the desirable properties of EIP. We discuss the modifications required to the current Internet systems, the support for old IP hosts, deployment plan and implementation experience. "Transition to the Future Internet Protocol a comparison of three transition schemes", Z. Wang, 11/03/1992, A number of schemes have been put forward to replace the current IP with a new internet protocol. In this memo, we examine the issues in the transition to a new internet protocol. Three schemes are compared in detail. "Pip Identifiers", P. Tsuchiya, 11/03/1992, Pip is an internet protocol intended as the replacement for IP version 4. The Pip header defines source and destination ID fields whose function it is to only identify the source and destination of a Pip packet--they have no routing significance. While Pip systems treat the IDs as flat for the purpose of identification, it is useful to have hierarchical structure in the ID for other purposes, such as for doing a reverse DNS lookup on the ID. This internet-draft defines the structure of Pip IDs. "IPv7 Criteria Analysis for EIPIP", P. Tsuchiya, Z. Wang, 11/13/1992, This document describes how the IPv7 proposal called EIPIP (Extended IP using PIP) meets the evaluation criteria established by the Internet Engineering Steering Group and described in "RFC-1380 IESG Deliberations on Routing and Addressing". EIPIP is currently developed to be both a transition mechanism for a new IP protocol (PIP), and the new IP protocol. This document also includes how EIPIP meets the criteria described by Partridge/Kastenholz in their Internet Draft "Criteria for Choosing IP Version 7 (IPv7)". Point-to-Point Protocol Extensions ---------------------------------- "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)", W. Simpson, 10/19/1992, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. The IPX protocol was originally used in Novell's NetWare products, and is now supported by numerous other vendors. This document defines the NCP for establishing and configuring the IPX protocol over PPP. "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", Frank Kastenholz, 07/27/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols. "The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol", Frank Kastenholz, 07/27/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols. "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", Frank Kastenholz, 07/27/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols. "The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol", Frank Kastenholz, 07/27/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols. "Compressing IPX Headers Over WAN Media (CIPX)", S. Mathur, M. Lewis, 12/08/1992, This document describes a method for compressing the headers of IPX datagrams (CIPX). With this method, is is possible to significantly improve performance over lower speed wide area network (WAN) media. For normal IPX packet traffic, CIPX will provide a compression ratio of approximately 2:1. This method can be used on various type of WAN media, including those supporting PPP, IPXWAN and X.25. RIP Version II -------------- "RIP Version 2 Carrying Additional Information", Gary Malkin, 10/06/1992, This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP packets and to add a measure of security. A companion document will define the SNMP MIB objects for RIP-2. "RIP Version 2 MIB Extension", Gary Malkin, Fred Baker, 08/05/1992, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects (in addition to those in the MIB-II RIP Group) for managing RIP Version 2. "RIP Version 2 Protocol Analysis", G. Malkin, 08/14/1992, As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to entering RIP-2 into the standards track. Internet Mail Extensions ------------------------ "SMTP Service Extensions", J. Klensin, N. Freed, E. Stefferud,, 11/25/1992, 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. Standard extensions to the SMTP service are registered with the IANA. "SMTP Service Extension for Message Size Declaration", K. Moore, N. Freed, J. Klensin,, 11/25/1992, 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. "SMTP Service Extension for 8bit-MIMEtransport", J. Klensin, N. Freed, M. Rose,, 11/25/1992, This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP. "Transition of Internet Mail from Just-Send-8 to 8Bit-SMTP/MIME", G. Vaudreuil, 12/16/1992, Protocols for extending SMTP to pass 8 bit characters have been defined. The messages transported by the extended SMTP are required to be encoded in MIME. Several SMTP implementations adopted an ad-hoc mechanism for sending 8 bit data prior to these standards and with which the extended SMTP mail system must interoperate. This document outlines the problems in this environment and an approach to minimizing the cost of transition. SNMP Security ------------- "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Galvin, K. McCloghrie, J. Davin,, 12/10/1992, Abstract not provided. "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Davin, J. Galvin, K. McCloghrie,, 12/10/1992, Abstract not provided. "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", K. McCloghrie, J. Davin, J. Galvin,, 12/10/1992, Abstract not provided. "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose,, 12/23/1992, Abstract not provided. "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Davin, J. Galvin, K. McCloghrie,, 12/23/1992, Abstract not provided. "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose,, 12/23/1992, Abstract not provided. "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", K. McCloghrie, J. Davin, J. Galvin,, 12/23/1992, Abstract not provided. "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Galvin, K. McCloghrie, J. Davin,, 12/23/1992, Abstract not provided. SNMP Version 2 -------------- "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose, S. Waldbusser, 12/22/1992, Abstract not provided. "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose, S. Waldbusser, 12/22/1992, Abstract not provided. "Introduction to version 2 of the Internet Network Management Framework", J. Case, K. McCloghrie, M. Rose, S. Waldbusser, 12/22/1992, Abstract not provided. "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose,, 12/22/1992, Abstract not provided. "Manager to Manager Management Information Base", J. Case, K. McCloghrie, M. Rose, S. Waldbusser, 12/22/1992, Abstract not provided. "Coexistence between version 1 and version 2 of the Internet Network Management Framework", J. Case, K. McCloghrie, M. Rose, S. Waldbusser, 12/22/1992, Abstract not provided. "Textual Conventions for for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose, S. Waldbusser, 12/22/1992, Abstract not provided. "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose, S. Waldbusser, 12/22/1992, Abstract not provided. "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", J. Case, K. McCloghrie, M. Rose,, 12/22/1992, Abstract not provided. TELNET ------ "Telnet Authentication Option", Dave Borman, 07/09/1992, No abstract provided. "Telnet Environment Option", D. Borman, 07/02/1992, 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. Distribution of this memo is unlimited. "Telnet Authentication: Kerberos Version 4", D. Borman, 07/09/1992, No abstract provided. "Telnet Authentication : SPX", Kannan Alagappan, 07/09/1992, No Abstract provided. Trusted Network File Systems ---------------------------- "A Specification of Trusted NFS (TNFS) Protocol Extensions", Fred Glover, 07/24/1992, Additional functionality has been developed for UNIXr systems to address the TCSEC requirements for trusted systems. New requirements are driving efforts to develop interoperable, networked solutions for trusted UNIX environments. A specific approach for addressing TCSEC MLS requirements is identified in the CMW requirements document. Developing support for network interoperability among MLS classified systems is a primary goal of the trusted UNIX community. DS1/DS3 MIB ----------- "Definitions of Managed Objects for the DS3/E3 Interface Type", T. Cox, K. Tesink, 11/30/1992, 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 E3 Interfaces. This document is a companion document with Definitions of Managed Objects for the DS1 Interface Type. This memo does not specify a standard for the Internet community. 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, the MIB documented in RFC 1233 should not be implemented. "Definitions of Managed Objects for the DS1 and E1 Interface Types", F. Baker, J. Watt, 11/24/1992, 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 memo does not, in its draft form, specify a standard for the Internet community. 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, the MIB documented in RFC 1232 should not be implemented. TCP/UDP over CLNP-addressed Networks ------------------------------------ "Addressing and End Point Identification, For Use with TUBA", R. Callon, 11/06/1992, Addressing is critically tied into routing and scaling in very large Internets. This draft paper discusses how NSAP addresses can be used to allow scaling in a huge Internet, and to allow the flexibility necessary to deal with multiple different dimensions of Internet growth. User Documents Revisions ------------------------ "FYI on Introducing the Internet--A Short Bibliography of Introductory Internetworking Readings for the Network Novice", Ellen Hoffman, Lenore Jackson, 10/13/1992, 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 more formal 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. Internet User Glossary ---------------------- "Internet Users' Glossary", G. Malkin, T. Parker, 10/01/1992, There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because they are referenced by other entries. Whois and Network Information Lookup Service -------------------------------------------- "Architecture of the Whois++ Index Service", C. Weider, J. Fullton, S. Spero,, 11/23/1992, Abstract not provided. X.25 Management Information Base -------------------------------- "SNMP MIB extension for MultiProtocol Interconnect over X.25", Dean Throop, 06/10/1992, 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 MultiProtocol Interconnect (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", "SNMP MIB extension for LAPB", and the "Definitions of Managed Objects for RS-232-like Hardware Devices", combine to allow management of the traffic over an X.25 protocol stack. X.400 Operations ---------------- "Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)", Claudio Allocchio, 12/15/1992, 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 the Mail-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. "Routing coordination for X.400 MHS services within a multi protocol / multi network environment", U. Eppenberger, 12/18/1992, This document defines a document format for static routing for X.400 systems as a short term solution. It proposes a strategy for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. Document formats and coordination procedures bridge the gap until an X.500 directory service is ready to store the needed connectivity and routing information. The format has been designed to allow the information to be stored in a X.500 directory service while managers without directory service access may still use a table based approach. "Operational Requirements for X.400 Management Domains in the GO-MHS Community", Robert Hagens, Alf Hansen, 12/21/1992, Abstract not provided. "X.400 use of extended character sets", Harald Alvestrand, 11/13/1992, Since 1988, X.400 has had the capacity for carrying a large number of different character sets in a message by using the body part "GeneralText" defined by ISO/IEC 10021-7. Since 1992, the Internet also has the means of passing around messages containing multiple character sets, by using the mechanism defined in RFC-MIME. This document defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. "Using the Internet DNS to maintain RFC1327 Address Mapping Tables and X.400 Routing Informations", C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens,, 09/23/1992, RFC1327 describes a set of mappings between the X.400 (1984/88) series of protocols and the RFC822 mail protocol, or protocols derived from RFC822. That document addresses conversion of services, addresses, message envelopes, and message bodies between the two mail systems. This document is concerned with one aspect of RFC1327: the mechanism for mapping between X.400 O/R addresses and RFC822 domain names. As described in Appendix F of RFC1327, implementation of the mappings requires a database which maps between X.400 O/R addresses and domain names, and this database is statically defined. "Postmaster Convention for X.400 Operations", C. A. Cargille, 11/23/1992, Both RFC822 and 1173 (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 RFC1327 mapping rules (and therefore which appear to have normal RFC822-style addresses). "Assertion of C=US; A=", E. Stefferud, 12/11/1992, This (draft) memo establishes an Internet Based X.400 Administrative Management Domain (ADMD) with the name shown in APPENDIX A, for use in the United States of America (C=US), according to the applicable rules of CCITT Recommendations and ISO Standards, and in keeping with existing regulatory practices in the United States of America. It also establishes a naming authority under the Internet Assigned Numbers Authority (IANA) to register and openly publish Private Management Domain (PRMD) names subordinate to A= under C=US.