Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. The Internet and the Millennium Problem (2000) ---------------------------------------------- "The Internet and the Millenium Problem (Year 2000)", Philip Nesser II, 11/16/1998, The Year 2000 Working Group(WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of 'period' problems were discovered, where a time field would 'roll over' as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. Application Configuration Access Protocol (acap) ------------------------------------------------ "ACAP TYPE Extension", R. Earhart, 03/13/1998, The Application Configuration Access Protocol [ACAP] defines rough typing information in the form of an attribute naming convention. This extension to ACAP allows a MIME content-type/subtype with parameters to be associated with a given piece of data, providing knowledgeable clients with useful information in a way which maintains compatability with innocent clients and servers. "ACAP Authorization Identifier Datasets Classes", S. Hole, 03/12/1998, Most distributed (client/server) applications require an authentication process between the client and the server before the server will grant access to its managed resources. Many applications provide varying levels of access to server resources based on a combination of authentication credentials and access control rules. The collection of information used to control access to resources is called ''authorization information''. "ACAP Personal Addressbook Dataset Class", Steven Hubert, Chris Newman, 03/05/1998, IMAP [IMAP4] allows nomadic users to access their mail store from any client, but it does not support storage of personal addressbooks. Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of personal addressbooks. While ACAP permits the definition of vendor specific solutions to this problem, having a standard addressbook dataset class permits clients from different vendors to interoperably share the same personal addressbooks. This specification defines a standard dataset class for personal addressbooks. "ACAP Application Options Dataset Class", S. Hole, 03/05/1998, The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of application option, configuration and preference information. The generalized form of this runtime configuration is called ''options''. Options consist of any type of structured or unstructured data that an application requires to operate in a user specific manner. "ACAP Media Type Dataset Class", Chris Newman, 03/05/1998, With the definition of standardized media types in MIME [MIME-IMT] it has become necessary to keep mapping tables which translate between the standard media type names, commonly used file name extensions, any platform specific typing mechanism, and helper applications to view, compose, edit or print media types. Supplying a set of site defaults is useful so that users won't have to configure well-known types. The mailcap mechanism [MAILCAP] provides some of this functionality in a homogeneous environment with a shared file system, and both the Macintosh program ''Internet Config'' and the Windows Registry have had some success in consolidating these tables for multiple applications on a single machine. But neither of these addresses the problems of multi- platform users or a heterogeneous environment. ACAP provides precisely the right facilities for this need. ACAP's dataset structure is extensible and ACAP's inheritance feature is ideal for enterprise default settings with per-user customization. "ACAP personal dictionary dataset class", Cyrus Daboo, 03/12/1998, The Application Configuration Access Protocol [ACAP] is designed to support remote storage and access of common application option, configuration and preference information. Its main benefits are in providing a way for users to gain access to personal information from any computer at a location supporting an internet connection, by keeping this information stored centrally on a server. Additionally, it allows 'kiosk' style use of computers so that users do not need to store data locally on a shared or public workstation or network computer. This specification defines a standard dataset class for personal dictionaries that would allow users to keep one or more 'user dictionaries' stored on an ACAP server for access by any ACAP-aware application that requires such information, for example any application that uses a spell checker. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for the ADSL Lines", F. Ly, Greg Bathrick, 11/17/1998, This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model [9]. The ADSL standard describes ATU-C and ATU-R as two sides of the ADSL line. This MIB covers both ATU-C and ATU-R agent's perspectives. Each instance defined in the MIB represents a single ADSL line. It should be noted that much of the content for the first version (v00) of this document came from work completed by the ADSL Forum's Network Management working group and documented in ADSL Forum TR-006 'SNMP-based ADSL Line MIB'[9]. See Acknowledgement Section for a list of individuals involved with this effort. Authenticated Firewall Traversal (aft) -------------------------------------- "Challenge-Handshake Authentication Protocol for SOCKS V5", M. VanHeyningen, 01/07/1998, This document specifies the integration of authentication based on Challenge-Handshake Authenticaton Protocol into SOCKS Version 5. The primary algorithm to be used is HMAC-MD5, although the framework is general enough to permit use of MD5 or other keyed hash algorithms. This document describes the message formats and protocol details of incorporating CHAP into the SOCKS V5 authentication ''subnegotiation.'' Support is included for authentication of server to client as well as client to server. "SOCKS Protocol Version 5", Marc VanHeyningen, 06/26/1998, The use of network firewalls, systems that effectively isolate an organizations internal network structure from an exterior network, such as the INTERNET is becoming increasingly popular. "SOCKS V5 UDP and Multicast Extensions to Facilitate Multicast Firewall Traversal", D. Chouinard, 11/18/1997, This proposal creates a mechanism for managing the ingress or egress of IP multicast through a firewall. It does this by defining extensions to the existing SOCKS V5 protocol [RFC-1928], which provides a framework for doing user-level, authenticated firewall traversal of unicast TCP and UDP traffic. However, because the current UDP support in SOCKS V5 has scalability problems as well as other deficiencies -- and these need to be addressed before multicast support can be achieved -- the extensions are defined in two parts: Base-level UDP extensions, and Multicast UDP extensions. Using the SOCKS framework for managing multicast flows in/out of an organization, offers numerous security advantages over what is possible with a conventional firewall approach. These are spelled out in the draft. "SOCKS V5 Protocol extension for Multiple Firewalls Traversal", Makoto Kayashima, Tsukasa Ogino, Masato Terada, Yoichi Fujiyama, 11/26/1997, This document provides the extended specification of SOCKS Version 5 which enable to use multiple firewalls traversal. In this protocol, client does subnegotiation with all servers on the communication path, and each server relays the connection after subnegotiation. "EAP Authentication for SOCKS Version 5", Glen Zorn, Pat Calhoun, Jeff Haag, 03/06/1998, This document defines how EAP [5] (Extensible Authentication Protocol) can be used with the SOCKS V5 protocol. EAP was defined to allow any authentication mechanism to be used without any modification to the authentication protocol (i.e. CHAP, OTP). "Multi-Authentication Framework Method for SOCKS V5", J. Michener, Dan Fritch, 03/13/1998, SOCKS V5 [RFC 1928] provides a means to select one from among a number of authentication methods, but does not provide any means for utilizing multiple authentication methods to obtain desired authentication properties. This document specifies the Multi- Authentication Framework Method (MAF) which is a method extension to SOCKS Version 5 to support the efficient management of composite authentication protocols composed of more than one authentication methods. MAF is a client-initiated but server managed framework. MAF relies upon a trusted Authentication Management Server (AMS) to select the authentication methods to be invoked, order them as appropriate, and assign integrity grades to the final authentication after all methods invoked have been completed. "GSS-API Authentication Method for SOCKS Version 5",, 11/23/1998, The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial SOCKS connection setup. This document provides the specification for the SOCKS V5 GSS-API authentication protocol, the use of the Simple and Protected GSS-API Negotiation (SPNEGO) mechanism, and defines a GSS-API-based encapsulation for provision of integrity and optional confidentiality. SNMP Agent Extensibility (agentx) --------------------------------- "Definitions of Managed Objects for Extensible SNMP Agents", Maria Greene, S. Gudur, 04/15/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. Application MIB (applmib) ------------------------- "Application Management MIB", Jonathan Saperia, Cheryl Krupczak, Randy Presuhn, C. Kalbfleisch, 11/18/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the System Application MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed. "Definitions of Managed Objects for WWW Services", C. Kalbfleisch, H. Hazewinkel, J. Schoenwaelder, 10/28/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. Access, Searching and Indexing of Directories (asid) ---------------------------------------------------- "Definition of the inetOrgPerson Object Class", Mark Smith, 11/18/1998, While the X.500 standards [X500] define many useful attribute types and object classes, they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. AToM MIB (atommib) ------------------ "Definitions of Supplemental Managed Objects for ATM Management", Kaj Tesink, Andrew Smith, E. Spiegel, F. Ly, M. Noto, 09/04/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", Kaj Tesink, E. Spiegel, M. Noto, 11/09/1998, This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. "Definitions of Tests for ATM Management", Kaj Tesink, M. Noto, 09/14/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services in addition to those defined in the ATM MIB [16], to provide support for the management of ATM Loopback Tests. "Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks", Keith McCloghrie, Juha Heinanen, A. Prasad, W. Greene, 10/05/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. The accounting data is collected into files for later retrieval via a file transfer protocol. For information on data which can be collected for ATM networks, see [19]. "Definitions of Managed Objects for ATM Management", Kaj Tesink, 11/09/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. This memo replaces RFC1695[24].Changes relative to RFC1695 are summarized in the MIB module's REVISION clause. Textual Conventions used in this MIB are defined in [6] and [19]. "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", Kaj Tesink, 11/17/1998, This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. "Definitions of Managed Objects for the SONET/SDH Interface Type", Kaj Tesink, 11/16/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types [24][25]. Textual Conventions used in this MIB are defined in [6] and [36]. This memo replaces RFC1595 [30]. Changes relative to RFC1595 are summarized in the MIB module's REVISION clause. "Accounting Information for ATM Networks", Keith McCloghrie, Juha Heinanen, A. Prasad, W. Greene, 10/05/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. A separate memo [16] defines managed objects, in a manner independent of the type of network, for controlling the selection, collection and storage of accounting information into files for later retrieval via a file transfer protocol. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. "Managed Objects for Recording ATM Performance History Data Based on 15 Minute Intervals", G. Mouradian, 05/13/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to record and retrieve ATM performance history data recorded in 15 minute interval. The functionality defined in this document is intended to satisfy the requirements defined by the ATM Forum in [9]. Audio/Video Transport (avt) --------------------------- "RTP Payload Format for H.263 Video Streams", C. Zhu, 09/11/1997, This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries. "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", V. Jacobson, Stephen Casner, 07/29/1998, This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). "Real-Time Transport Protocol Management Information Base", I. Suconick, M. Baugher, B. Strahm, 11/23/1998, This memo defines an experimental Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Real-Time Transport Protocol systems [1]. Comments should be made to the IETF Audio/Video Transport Working Group at rem-conf@es.net. This memo does not specify a standard for the Internet community. "RTP Profile for Audio and Video Conferences with Minimal Control", H. Schulzrinne, 11/23/1998, This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. The revision process is not yet complete; some changes which have been discussed and tentatively accepted in meetings of the Audio/Video Transport working group have not yet been incorporated into this draft. This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. "RTP Payload for DTMF Digits", H. Schulzrinne, 11/23/1998, This memo describes how to carry dual-tone multifrequency (DTMF) signaling and other tone signals in RTP packets. "An RTP Payload Format for Generic Forward Error Correction", Jonathan Rosenberg, H. Schulzrinne, 11/10/1998, This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the pay- load and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. "New Results in RTP Scalability", Jonathan Rosenberg, H. Schulzrinne, 12/03/1997, Recently, a number of problems related to RTP scalability to large multicast groups have been identified. The main problem, congestion of RTCP packets due to near-simultaneous joins, has been resolved in previous work. In this document, we present some additional problems and describe the solutions. In particular, we discuss the problem of BYE floods and premature timeouts. To resolve the BYE flood problem, we propose a BYE reconsideration mechanism. To help alleviate prema- ture timeouts, we propose a reverse timer reconsideration algorithm. Both algorithms are simple, and require minimal state and computa- tion. "Guidelines for Writers of RTP Payload Format Specifications", Mark Handley, 11/16/1998, This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifica- tions in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. "RTP: A Transport Protocol for Real-Time Applications", V. Jacobson, Stephen Casner, R. Frederick, H. Schulzrinne, 11/23/1998, This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real- time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "RTP Payload Format for X Protocol Media Streams", Lassaad Gannoun, 03/11/1998, This document specifies the payload format for encapsulating X-protocol streams in the Realtime Transport Protocol (RTP). This specification is intended for X-protocol media streams that are not already handled by other RTP payload specifications. This specification gives details of the payload format of X-protocol data requests that are carried over RTP/UDP/IP in a shared window session. Multiple X protocol requests can be carried over an RTP packet as well as one X protocol request can be carried over multiple RTP packets. a shared window header is defined within the RTP payload to carry X protocol media requests. An RTCP join and RTP reply packets are specified to allow a latecomer to join an on-going session. This specification is intended for streaming stored X Window protocol data as well as live X protocol data requests. "RTP payload format for MPEG-4 Elementary Streams", H. Schulzrinne, D. Hoffman, M. Speer, R. Civanlar, Andrea Basso, Vahe Balabanian, Carsten Herpel, 03/13/1998, This memorandum describes a scheme to encapsulate MPEG-4 Elementary Streams into RTP packets. Two approaches are described. The first allows to map one MPEG-4 Elementary Stream to one RTP session, for maximum compatibility to the design principles of RTP. The second responds to the observation that MPEG-4 applications may well consist of such a large number of streams that the encapsulation of a bundle of Elementary Streams in one RTP session is required. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "The Role of DMIF in Support of RTP MPEG-4 Payloads", Vahe Balabanian, 03/13/1998, This memorandum describes how RTP carrying MPEG-4 payloads interacts with the MPEG-4 Access Unit layer through the MPEG (Delivery Multimedia Integration Framework) DMIF. DMIF is used to pass information essential for the packing and unpacking of MPEG-4 streams into RTP as well as for adjusting the MPEG-4 AL-PDU lengths to be within the path MTU. DMIF interprets the RTCP reports by comparing its statistics to the requested MPEG-4 media based QoS. If the statistics fail to meet the requested QoS then action is taken to either continue with the impaired perforamce, upgrade the network service class, scale down the stream or delete the stream. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "An RTP Payload Format for User Multiplexing", Jonathan Rosenberg, H. Schulzrinne, 05/19/1998, This memo describes an RTP payload format for multiplexing data from multiple users into a single RTP packet. Such multiplexing is especially useful for transporting voice data between Internet telephony gateways. It causes signif- icant reductions in header overheads and improves scalabil- ity. "RTP Payload for Redundant Audio Data", Mark Handley, C Perkins, I Kouvelas, Colin Perkins, Jean-Chrysostome Bolot, Andres Vega-Garcia, Sacha Fosse-Parisis, V Hardman, 08/10/1998, This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. "Sampling of the Group Membership in RTP", Jonathan Rosenberg, H. Schulzrinne, 11/10/1998, In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. "User Multiplexing in RTP payload between IP Telephony Gateways", Senthil Sengodan, Barani Subbiah, 08/31/1998, This draft proposes a method to multiplex a number of low bit rate audio streams (upto 256) into a single RTP/UDP/IP connection between IP telephony gateways. Audio samples from different users are assem- bled into an RTP payload thus reducing the overhead of RTP/UDP/IP headers. To identify users sharing a single RTP/UDP/IP connection, a 2 byte MINI-Header is proposed. A channel negotiation procedure to assign and release channels on a single UDP connection between gateways is described. "Issues and Options for RTP Multiplexing", Jonathan Rosenberg, H. Schulzrinne, 10/02/1998, This memorandum discusses the issues and options involved in the design of a new transport protocol for multiplexed voice within a single packet. The intended application is the interconnection of devices which provide trunking or long distance telephone service over the Internet. Such devices have many voice connections simultaneously between them. Multiplexing them into the same connection improves on the efficiency, enables the use of low bitrate voice codecs, and improves scalability. Options and issues con- cerning timestamping, payload type identification, length indication, and channel identification are discussed. Sev- eral possible header formats are identified, and their efficiencies are compared. "An RTP Payload Format for Reed Solomon Codes", Jonathan Rosenberg, H. Schulzrinne, 11/10/1998, This document specifies a payload format for forward error correction of media encapsulated in RTP using Reed Solomon codes. The payload format allows end systems to transmit using arbitrary block lengths and codes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. "GeRM: Generic RTP Multiplexing", Mark Handley, 11/12/1998, This document describes GeRM, an RTP payload format for generic multiplexing of multiple RTP streams. This document is a product of the Audio/Video Transport (AVT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author. "RTP Payload format for Interleaved Media", Colin Perkins, 11/18/1998, This memo defines an interleaving scheme for RTP streams. This scheme is derived from the RTP payload format for redundant audio data [3] and hence is targetted primarily at streamed audio, although it may be of use in other scenarios. "RTP Payloads for Telephone Signal Events", Scott Petrack, 11/23/1998, This note describes two RTP payload formats for in-band telephony signal events (TSE) such as DTMF, dial-tone, ring-tone, off-hook, SIT, etc. One payload is designed to carry a named signal, and the other is designed carry a compact representation of actual audio waveform cadence to be played. The two formats are independent, but they can be used together very usefully within redundant audio payloads; this enables highly efficient and robust transport of telephony network signal events along with a representation of the actual audio media associated to the signal events. Acknowledgements: This internet draft is an extension of H. Schulzrinne's draft ietf-avt-dtmf-00.txt and borrows heavily from it (including copying actual text). The main extensions appearing in this draft are as follows: a) many other telephony call progress tones and signal events have been added to the original DTMF and flash-hook of ietf-avt-dtmf-00.txt (an attempt has been made to align this with [MGCP] and [E.180 supp2] b) a second payload is defined which carries a highly compact frequency representation of the audio waveform of the signal; c) a few clarifications about reliability and redundancy, including how the two payloads will work together. Acknowledgement is also due to [MGCP]; part of this draft is an attempt to use RTP to provide the signal transport required by MGCP, in a way which can be reused by a large class of applications. Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Cell/Call Benchmarking", Cynthia Martin, Jeff Dunn, 11/02/1998, This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of cell- based and call-based switching devices. The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 1944 and 2285. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). "Benchmarking Terminology for Firewall Performance", David Newman, 07/27/1998, This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches and adds terminology specific to firewalls. The primary metrics used in this document are bit forwarding rate and connections. "Benchmarking Methodology for LAN Switching Devices", John Keene, B. Mandeville, 08/10/1998, This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. It extends the methodology already defined for benchmarking network interconnecting devices in RFC 1944 to switching devices. This RFC primarily deals with devices which switch frames at the Medium Access Control (MAC) layer. It provides a methodology for benchmarking switching devices, forwarding performance, congestion control, latency, address handling and filtering. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. Bridge MIB (bridge) ------------------- "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", Keith McCloghrie, P. Langille, A. Rijsinghani, Andrew Smith, Les Bell, 11/23/1998, 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-1998 MAC Bridges and IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging 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. This memo also includes several MIB modules in a manner that is compliant to the SNMPv2 SMI [5]. Calendaring and Scheduling (calsch) ----------------------------------- "Calendar attributes for vCard and LDAP", D. Hennessy, Frank Dawson Jr., Tony Small, 09/23/1998, When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current 'busy time' provides an a priori indication of whether the attendee will be free to participate in the event. In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time. This draft defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include: - Manual transfer of the information; - Personal data exchange using the vCard format; and - Directory lookup using the LDAP protocol. "Internet Calendar Model Specification", John Noerenberg, 11/17/1997, Internet Calendaring and Scheduling protocols require the definition of objects to encapsulate an event to be scheduled, a calendar on which the event will be stored, and means for exchanging these objects across the Internet between calendars on behalf of people for whom the calendars are meaningful. This document gives an abstract model of the objects and the protocols necessary to accomplish this kind of information exchange. It will establish the context in which other Calendaring and Scheduling RFCs can be interpreted. Included are brief introductions to the other components of Internet calendar protocols and definitions of nomenclature common to all documents defining these protocols. Reading this document will enable implementors and users of Internet Calendaring and Scheduling protocols to understand the goals and constraints chosen for related protocols. "CAP Requirements", P. O'Leary, Andre Courtemanche, S. Mansour, Frank Dawson Jr., Doug Royer, Tony Small, 11/23/1998, The Calendar Access Protocol (CAP) is an Internet protocol for accessing an [ICAL] based calendar store (CS) from a calendar user agent (CUA). The purpose of this document is to set forth a list of requirements that CAP MUST address in order to meet the needs of the calendaring and scheduling community. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. Distribution of this document is unlimited. Comments and suggestions for improvement should be sent to the authors. Copyright (C) The Internet Society 1998. All Rights Reserved. "ICalendar Real-time Interoperability Protocol (IRIP)", P. O'Leary, Andre Courtemanche, S. Mansour, 11/20/1998, This document specifies a binding from the iCalendar Transport-independent Interoperability Protocol [ITIP] to a real-time transport. Calendaring entries defined by the iCalendar Object Model [ICAL] are composed using constructs from [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. This document is based on the calendaring and scheduling model defined by [ICMS]. This document is based on discussions within the Internet Engineering Task Force (IETF) Calendaring and Scheduling (CALSCH) working group. More information about the IETF CALSCH working group activities can be found on the IMC website at http://www.imc.org, the IETF website at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents. Distribution of this document is unlimited. Comments and suggestions for improvement should be sent to the authors. "iCalendar v2.0 Formal Public Identifier",, 09/23/1998, The IETF has defined a standard format for exchanging calendaring and scheduling data, called iCalendar. This format is useful for exchange of personal calendar data across the Internet, as well as in non- Internet environments. In a number of environments where the iCalendar will be used, the format type and version needs to be identified. For example, when registering the iCalendar as a format for memory-based 'clipboard' or 'drag/drop' user interface interactions. For these cases, a definitive formal public identifier (FPI) for the iCalendar will be required. This memo defined the FPI to be used when referring to the version 2.0 (the value in the 'VERSION' property) of the iCalendar format. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY' and 'OPTIONAL' in this document are to be interpreted as described in [RFC 2119]. Common Authentication Technology (cat) -------------------------------------- "Integrating Single-use Authentication Mechanisms with Kerberos", Clifford Neuman, Glen Zorn, J. Trostle, Ken Hornstein, 11/24/1998, This document defines extensions to the Kerberos protocol specifi- cation [RFC1510] which provide a method by which a variety of single-use authentication mechanisms may be supported within the protocol. The method defined specifies a standard fashion in which the preauthentication data and error data fields in Kerberos mes- sages may be used to support single-use authentication mechanisms. "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)", C. Adams, 05/01/1998, The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated 'receivers' of the data unit. Thus, it is suitable for applications such as secure electronic mail where data needs to be protected without any on-line connection with the intended recipient(s) of that data. The protection offered by IDUP includes services such as data origin authentication with data integrity, data confidentiality with data integrity, and support for non-repudiation services. Subsequent to being protected, the data unit can be transferred to the recipient(s) - or to an archive - perhaps to be processed ('unprotected') only days or years later. Throughout the remainder of this document, the 'unit' of data described in the above paragraph will be referred to as an IDU (Independent Data Unit). The IDU can be of any size (the application may, if it wishes, split the IDU into pieces and have the protection computed a piece at a time, but the resulting protection token applies to the entire IDU). However, the primary characteristic of an IDU is that it represents a stand-alone unit of data whose protection is entirely independent of any other unit of data. If an application protects several IDUs and sends them all to a single receiver, the IDUs may be unprotected by that receiver in any order over any time span; no logical connection of any kind is implied by the protection process itself. As with RFC-2078, this IDUP-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 "Public Key Cryptography for Initial Authentication in Kerberos", Clifford Neuman, John Wray, Brian Tung, J. Trostle, M. Hur, A. Medvinsky, Sasha Medvinsky, 11/13/1998, This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. "Generic Security Service API Version 2 : C-bindings", John Wray, 11/11/1998, This draft document specifies C language bindings for Version 2 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other drafts [GSSAPI]. It revises RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track. The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of 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. "The Simple and Protected GSS-API Negotiation Mechanism", B. Pinkas, E. Baize, 04/14/1998, This draft document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1]. The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism. The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms. This allows to negotiate different security mechanisms, different options within a given security mechanism or different options from several security mechanisms. Once the common security mechanism is identified, the security mechanism may also negotiate mechanism-specific options during its context establishment. This will be inside the mechanism tokens, and invisible to the SPNEGO protocol. "Extended Generic Security Service APIs: XGSS-APIs Access control and delegation extensions", B. Pinkas, T. Parker, 11/09/1998, The Generic Security Service Application Program Interface (GSS- API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. It defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment. The GSSAPI 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. The primitives of the GSS-API do not currently allow support of security attributes other than a single identity and do not allow fine control of delegation. The additional primitives described in this document provide support for: * the exchange of a variety of security attributes, and the construction of authorization functions using these attributes, including delegated ones, (attribute handling support functions), * fine control over delegation by allowing specification of the delegation method, the acceptor(s) of a security context, their type and the restrictions that may apply (acceptor control and support functions). "Public Key Cryptography for Cross-Realm Authentication in Kerberos", G. Tsudik, Clifford Neuman, B. Sommerfeld, Brian Tung, M. Hur, T. Ryutov, A. Medvinsky, 11/13/1998, This document defines extensions to the Kerberos protocol specification (RFC 1510, 'The Kerberos Network Authentication Service (V5)', September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. "Public Key Utilizing Tickets for Application Servers (PKTAPP)", Clifford Neuman, M. Hur, A. Medvinsky, Alexander Medvinsky, 03/17/1998, Public key based Kerberos for Distributed Authentication[1], (PKDA) proposed by Sirbu & Chuang, describes PK based authentication that eliminates the use of a centralized key distribution center while retaining the advantages of Kerberos tickets. This draft describes how, without any modification, the PKINIT specification[2] may be used to implement the ideas introduced in PKDA. The benefit is that only a single PK Kerberos extension is needed to address the goals of PKINIT & PKDA. "Kerberos Change Password Protocol", M. Horowitz, 08/11/1998, The Kerberos V5 protocol [RFC1510] does not describe any mechanism for users to change their own passwords. In order to promote interoperability between workstations, personal computers, terminal servers, routers, and KDC's from multiple vendors, a common password changing protocol is required. "The Kerberos Network Authentication Service (V5)", Theodore Ts''o, Clifford Neuman, George Kohl, 11/23/1998, This document provides an overview and specification of Version 5 of the Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. This document is not intended to describe Kerberos to the end user, system administrator, or application developer. Higher level papers describing Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], are available elsewhere. "FTP Authentication Using DSA", P. Yee, Russ Housley, W. Nace, 03/05/1998, This document defines a method to secure file transfers using the FTP specification RFC 959, ''FILE TRANSFER PROTOCOL (FTP)'' (October 1985) and RFC 2228 ''FTP Security Extensions'' (October 1997) [1]. This method will use the extensions proposed in the ''FTP Security Extensions'' along with a public/private digital signature. "Generic Security Service Application Program Interface Version 2, Update 1", John Linn, 09/04/1998, The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in [RFC-2078], 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: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This Internet-Draft revises [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. "Kerberos vs firewalls", Assar Westerlund, Johan Danielsson, 12/04/1997, Kerberos[RFC1510] is a protocol for authenticating parties communicating over insecure networks. Firewalling is a technique for achieving an illusion of security by putting restrictions on what kinds of packets and how these are sent between the internal (so called ''secure'') network and the global (or ''insecure'') Internet. "Public Key Cryptography for KDC Recovery in Kerberos V5", J. Trostle, 11/24/1998, This document defines extensions to the Kerberos protocol specification (RFC 1510, 'The Kerberos Network Authentication Service (V5)', September 1993) to enable the recovery of a compromised Kerberos V5 KDC using public key cryptography. The document specifies the recovery protocol which uses preauthentication data fields and error data fields in Kerberos messages to transport recovery data. "Extension to Kerberos V5 For Additional Initial Encryption", J. Trostle, Michael Swift, 06/29/1998, This document defines an extension to the Kerberos protocol specification (RFC 1510) [1] to enable a preauthentication field in the AS_REQ message to carry a ticket granting ticket. The session key from this ticket granting ticket will be used to cryptographically strengthen the initial exchange in either the conventional Kerberos V5 case or in the case the user stores their encrypted private key on the KDC [2]. "Generic Security Service API Version 2 : Java bindings", Jack Kabat, 08/11/1998, The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2078 [GSSAPIv2]. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are The Simple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5 GSS-API Mechanism [KERBV5]. "Access Control Framework for Distributed Applications", Clifford Neuman, T. Ryutov, 11/20/1998, This document describes a unified model to support authorization in a wide range of applications, including metacomputing, remote printing, video conference, and any other application which will require interactions between entities across autonomous security domains. The document proposes requirements for the support of: - flexible and expressive mechanism for representing and evaluating security policies - uniform authorization service interface for facilitating access control decisions for applications and requesting access control information about a particular resource. This specification defines structures and their uses at a level independent of underlying mechanism and programming language environment. This document is accompanied by a second one describing the details of proposed structures and services along with bindings for C language environments. This document is to be found in draft-ietf-cat-gaa-cbind-01.txt. "Generic Authorization and Access control Application Program Interface C-bindings", Clifford Neuman, T. Ryutov, 11/20/1998, The Generic Authorization and Access control Application Programming Interface (GAA API) provides access control services to calling applications. It facilitates access control decisions for applications and allows applications to discover access control policies associated with a targeted resource. The GAA API is usable by multiple applications supporting different kinds of protected objects. The GAA API design supports: - a variety of security mechanisms based on public or secret key cryptosystems - different authorization models - heterogeneous security policies - various access rights This document specifies C language bindings for the GAA API, which is described at a language-independent conceptual level in draft-ietf-cat-acc-cntrl-frmw-01.txt "The Kerberos Version 5 GSSAPI Mechanism, Version 2", Tom Yu, 11/23/1998, This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFC 2078) when using Kerberos Version 5 technology (as specified in RFC 1510). This obsoletes RFC 1964. Content Negotiation (conneg) ---------------------------- "Media Feature Tag Registration Procedure", E. Hardie, K. Holtman, A. Mutz, 07/28/1998, Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved. Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration. This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. "Media Features for Display, Print, and Fax", Larry Masinter, K. Holtman, A. Mutz, Dan Wing, 09/09/1998, This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. These features are registered for use within the framework of [REG]. "Requirements for protocol-independent content negotiation", G. Klyne, 12/29/1997, A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1, 2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers. The case for a cross-protocol negotiation framework is set out in [4]. This draft sets out terminology, an abstract framework and requirements for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The requirements set out the desired properties of a content negotiation mechanism. "An algebra for describing media feature sets", G. Klyne, 08/07/1998, A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3]. This document describes an algebra and syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. This document also outlines an algorithm for feature set matching. "A syntax for describing media feature sets", G. Klyne, 11/16/1998, A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3]. "W3C Composite Capability/Preference Profiles", G. Klyne, 10/21/1998, This document suggests some possible areas for extending the IETF 'conneg' working group's capability description framework, described in [2,3,4]. The suggested areas for extension have been motivated by WWW Consortium (W3C) work on Composite Capability/Preference Profiles (CCPP) [5] that parallels some aspects of IETF 'conneg' work. It is presented as a discussion document, with a view to maybe integrating some of these ideas into ongoing 'conneg' work. Dynamic Host Configuration (dhc) -------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", C Perkins, Jim Bound, 07/07/1998, The Dynamic Host Configuration Protocol (DHCPv6) provides a framework for passing configuration information, via extensions, to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol should be considered a stateful counterpart to the IPv6 Stateless Address Autoconfiguration protocol specification, and can be used separately or together with the latter to obtain configuration information. "Procedure for Defining New DHCP Options", Ralph Droms, 11/10/1998, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the 'options' field of the DHCP message. The data items themselves are also called 'options.' New DHCP options may be defined after the publication of the DHCP specification to accommodate requirements for conveyance of new configuration parameters. This document describes the procedure for defining new DHCP options. "Interaction between DHCP and DNS", Y Rekhter, 03/05/1998, DHCP provides a powerful mechanism for IP host autoconfiguration. However, the autoconfiguration provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained by DNS. This document specifies how DHCP clients and servers should use the Dynamic DNS Updates mechanism to update the DNS name to address and address to name mapping, so that the mappings for DHCP clients would be consistent with the IP addresses that the clients acquire via DHCP. "Authentication for DHCP Messages", Ralph Droms, William Arbaugh, 11/18/1998, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. "Extensions for the Dynamic Host Configuration Protocol for IPv6", C Perkins, 07/08/1998, This document specifies the current set of DHCPv6 extensions. This document will be periodically updated as new extensions are defined. Each superseding document will include the entire current list of valid extensions. The method for specifying new extensions is also included in this document. "DHCP Options for Service Location Protocol", C Perkins, Erik Guttman, 11/23/1998, The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. "The User Class Option for DHCP", Ralph Droms, G. Stump, 11/20/1998, This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an NVT ASCII text object that represents the user class of which the client is a member. "DHCP Relay Agent Information Option", M. Patrick, 11/16/1998, Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The 'Relay Agent Information' option is organized as a single DHCP option that contains one or more 'sub-options' that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a 'circuit ID' for the incoming circuit, a 'remote ID' which provides a trusted identifier for the remote high-speed modem, and the 'subnet mask' of the logical IP subnet from which the relay agent received the client DHCP packet. "Multicast Address Allocation Configuration Options", Steve Hanna, B. Patel, M. Shah, 08/10/1998, This document describes DHCP options that may be used to provide access to Multicast Address Allocation servers, such as MDHCP servers. "The Server Selection Option for DHCP", Ralph Droms, G. Stump, P. Gupta, 11/20/1998, This option is provided by DHCP servers to DHCP clients so that clients may optionally select from among multiple offers received from DHCP servers in the network offer from a DHCP. The information contained in this option is an hex value that represents an integer value indicating the priority of the offer in which this option is contained. "The Domain Search Option for DHCP", P. Gupta, 11/18/1998, This document defines a new DHCP option which is passed form the DHCP Server to the DHCP Client to configure the domain search list which is used by the clients to resolve hostnames in the Domain Name System[3]. "DHCP Failover Protocol", Ralph Droms, Bernard Volz, K. Kinnear, Arun Kapur, Mark Stapp, Greg Rabil, Mike Dooley, Steve Gonczi, 11/23/1998, DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide this synchronization between two servers. One server is designated the 'Primary' server, the other is the 'Secondary' server. Additionally, this document describes a protocol for the automatic transfer of control from the primary to the secondary in the case of failure (failover), as well as a network partition. This document further develops the concepts presented in draft-ietf- dhc-failover-02.txt. "DHCP Continuation Option Code", Angelos Keromytis, William Arbaugh, 11/24/1997, The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Currently options are limited to an information size of 256 bytes because of the one-octet size of the length field. This document defines a new option that permits the continuation of the previous option information. "The Autonomous System Option for DHCP", W.D Lazear, 02/10/1998, This document describes a configuration option that may be used by hosts acting as IP forwarders. The option contains information about the autonomous system in which the host resides and may be required by routing protocols. "The Server Range Option for DHCP", W.D Lazear, 02/25/1998, This document describes a configuration option that may be used by hosts acting as IP forwarders. The option contains information about the networks adjacent to the host and may be required by routing protocols. "DHCP Safe Failover Protocol", K. Kinnear, 03/12/1998, The DHCP protocol [RFC 2131] [1] allows multiple DHCP servers. A recent draft, the DHCP Failover Protocol [3], has been distributed which is designed to provide a redundant DHCP solution. While clearly a work in progress, it is equally clear that it can be made to work and meet the goals that the authors have set for it. One of the goals of the Failover protocol is that it should avoid duplicate IP address allocations, except under some rare circumstances. While this approach may be quite reasonable in a wide variety of environ- ments, some environments require a DHCP redundancy solution which can (optionally) ensure that no possibility of duplicate IP address allo- cation exists. The Safe Failover protocol is designed to build on top of the Failover protocol, and add to it certain protocol exchanges, prac- tices and algorithms which will create a DHCP redundancy solution which avoids duplicate IP address allocation. "Security Requirements for the DHCP protocol", Ralph Droms, O. Gudmundsson, 03/13/1998, This document addresses the general security requirements of both DHCPv4 and DHCPv6. This document lists security requirements and the the reasons for each requirement. This document does not address how to implement the security requirements. "Dynamic Host Configuration Protocol (DHCP) Server MIB", G. Waters, Richard Barr Hibbs, 05/01/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) servers. "DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients", Ryan Troll, 10/19/1998, Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum. To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automaticly choosing an IP address which will allow them to communicate with other hosts running the same OS. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This draft describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not auto-configure it's own. "DHCP Option for User Authentication Protocol", Steve Drach, 11/12/1998, This document defines a DHCP [1] option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard [2]. "Automaticly Choosing an IP Address in an Ad-Hoc IPv4 Network", Ryan Troll, 10/19/1998, With operating systems appearing in more and more devices, as well as computers appearing in more and more aspects of everyday life, communication between networked devices is increasingly important. The communication mechanism between these devices must be able to not only support the office LAN environment, but must also scale to larger WANS and the internet. This draft describes a method by which a host may automaticly give itself a link-local IPv4 address, so that it will be able to use IP applications in the absence of an IP address management mechanism, such as DHCP. This mechanism is in use today by a few operating systems, and additional information on those implementations is also provided. "DHCP Use of the User Class Option for Address Assignment", Ye Gu, Burcak Beser, Ramesh Vyaghrapuri, 11/03/1998, This document proposes a mechanism that DHCP clients can use optionally to obtain their IP addresses from different address pools configured on a DHCP server. A DHCP client can specify a class to which it belongs. Based on the class, a DHCP server selects the appropriate address pool to assign an address to the client. Differentiated Services (diffserv) ---------------------------------- "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", Fred Baker, Kathleen Nichols, S. Blake, David Black, 10/09/1998, Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. "An Architecture for Differentiated Services", Mark Carlson, Walter Weiss, S. Blake, Z. Wang, David Black, Elwyn Davies, 10/09/1998, This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks. "A Framework for Differentiated Services", Srinivasan Keshav, Dinesh Verma, Mark Carlson, Borje Ohlman, S. Blake, Y. Bernet, James Binder, Z. Wang, Walter Weiss, Elwyn Davies, 10/20/1998, This document provides a general description of issues related to the definition, configuration and management of services enabled by the differentiated services architecture [DSARCH]. This document should be read along with its companion documents, the differentiated services architecture [DSARCH] and the definition of the DS field [DSHEAD]. A glossary of specialist terms used may be found in [DSARCH]. "A Framework for Use of RSVP with Diff-serv Networks", Lixia Zhang, R. Yavatkar, Fred Baker, Peter Ford, Kathleen Nichols, M. Speer, Y. Bernet, 11/20/1998, In the past several years, work on QoS enabled networks led to the development of the Integrated Services (Intserv) architecture [12] and the RSVP signaling protocol [1]. RSVP, as specified, enables applica- tions to signal per-flow requirements to the network. Intserv parame- ters are used to quantify these requirements for the purpose of admis- sion control. However, as work on RSVP and Intserv has proceeded, we have recognized the following basic limitations, which impede deploy- ment of these mechanisms in the Internet at large: 1) The reliance of RSVP on per-flow state and per-flow processing raises scalability concerns in large networks. 2) Today, only a small number of hosts generate RSVP signaling. While this number is expected to grow dramatically, many applications may never generate RSVP signaling. 3) Many applications require a form of QoS, but are unable to express these requirements using the intserv model. At present, the market is pushing for immediate deployment of a QoS solution that addresses the needs of the Internet as well as enter- prise networks. This push has led to the development of Differentiated services (diff-serv). In contrast to RSVP's per-flow orientation, diff-serv networks classify packets to one of a small number of aggre- gated flows, based on the setting of bits in the TOS field of each packet's IP header. Thus, in addition to eliminating the reliance on per-flow state, diff-serv QoS can initially be deployed using top-down provisioning, with no requirement for end-to-end signaling. At the same time however, it is important to assure that the diff-serv mechanisms deployed, interoperate effectively with hosts and networks that provide per-flow QoS in response to end-to-end signaling. This is important, as we believe that in the coming years, there will be a proliferation of applications that depend on QoS and of hosts which will sign "Requirements of Diff-serv Boundary Routers", Francis Reichmeyer, Y. Bernet, David Durham, 11/23/1998, This draft discusses requirements of routers that serve as ingress/egress points to/from differentiated services (diff-serv) networks. We discuss the traffic conditioning components required and associated configuration mechanisms and protocols. We also discuss admission control to diff-serv networks in support of signaled QoS. "Assured Forwarding PHB Group", Fred Baker, Juha Heinanen, John Wroclawski, Walter Weiss, 11/18/1998, This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class. "Management of PHBs", M. Borden, Christopher White, 08/05/1998, The DiffServ Working Group will produce PHBs (Per Hop Behaviors) used to provide differentiated services. Some of these are to be standardized, others may have widespread use and still others may remain experimental. The encoding of the PHB into a codepoint of the DS Field will not be standardized, except for the legacy, precedence PHBs. Therefore a method is needed to coordinate the use of PHBs and codepoints, even if only for the purpose of discussing them. This draft addresses this coordination issue. "An Expedited Forwarding PHB", V. Jacobson, Kathleen Nichols, Kedernath Poduri, 11/16/1998, The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given. A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf Distributed Management (disman) ------------------------------- "Definitions of Managed Objects for the Delegation of Management Scripts", D. Levi, J. Schoenwaelder, 11/23/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. "Distributed Management Framework", Steven Waldbusser, Bob Stewart, Andy Bierman, Maria Greene, 08/31/1998, This memo defines a distributed management architecture for use with the SNMP network management architecture. This memo does not specify a standard for the Internet community. "Expression MIB", Bob Stewart, 11/05/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. "Notification Log MIB", Bob Stewart, 10/13/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119. "Event MIB", Bob Stewart, 10/07/1998, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing monitoring of MIB objects and taking action through events. "Definitions of Managed Objects for Scheduling Management Operations", D. Levi, J. Schoenwaelder, 11/23/1998, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. "Definitions of Managed Objects for Remote Operations Using SMIv2", K. White, 09/04/1998, This memo defines a Management Information Base (MIB) for performing remote operations (ping, traceroute and DNS Lookup) at a remote host. When managing a network it is useful to be able to retrieve the results of either a ping or traceroute operation when performed at a remote host. A DNS Lookup capability is defined to determine the DNS of an address at a remote host. Currently, there exists several enterprise defined MIBs for performing both a remote ping or traceroute operation. The purpose of this memo is to defined a standards-based solution to enable interoperibility. DNS IXFR, Notification, and Dynamic Update (dnsind) --------------------------------------------------- "Secret Key Transaction Signatures for DNS (TSIG)", O. Gudmundsson, P. Vixie, Don Eastlake, B. Wellington, 11/23/1998, This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. "Reserved Top Level DNS Names", D. Eastlake, Aliza Panitz, 11/20/1998, To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. "Local Domain (DNS) Names", Don Eastlake, 11/20/1998, A set of second level domain names are defined under a new top level domain name such that local private DNS zones can be maintained similar to the private IP addresses reserved in [RFC 1918]. These zone locally appear to be part of the global DNS name tree. Additional second level domain names are assigned under this TLD for loopback addresses and IPv6 link and site local addresses. "A New Scheme for the Compression of Domain Names", Peter Koch, 11/18/1998, The compression of domain names in DNS messages was introduced in [RFC1035]. Although some remarks were made about applicability to future defined resource record types, no method has been deployed yet to support interoperable DNS compression for RR types specified since then. This document summarizes current problems and proposes a new compression scheme to be applied to future RR types which supports interoperability. Also, suggestions are made how to deal with RR types defined so far. "Binary Labels in the Domain Name System", M. Crawford, 09/01/1998, This document defines a ``Bit-String Label'' which may appear within domain names. This new label type compactly represents a sequence of ``One-Bit Labels'' and enables resource records to be stored at any bit-boundary in a binary-named section of the domain name tree. "Non-Terminal DNS Name Redirection", M. Crawford, 09/04/1998, This document defines a new DNS Resource Record called ``DNAME'', which provides the capability to map an entire subtree of the DNS name space to another domain. It differs from the CNAME record which maps a single node of the name space. "Extensions to DNS (EDNS1)", P. Vixie, 11/16/1998, This document specifies a number of extensions within the Extended DNS framework defined by [EDNS0], including several new extended label types and the ability to ask multiple questions in a single request. "Extension mechanisms for DNS (EDNS0)", P. Vixie, 09/01/1998, The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted, and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. "A DNS RR for specifying the location of services (DNS SRV)", P. Vixie, A. Gulbrandsen, 11/16/1998, This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). "A DNS RR Type for Lists of IP Address Prefixes (APL RR)", Peter Koch, 11/23/1998, The Domain Name System is primarily used to translate domain names into IPv4 addresses using A RRs. Several approaches exist to describe networks or address ranges. This document proposes a new DNS RR type 'APL' for address prefix lists. Domain Name System Security (dnssec) ------------------------------------ "Mapping Autonomous Systems Number into the Domain Name System", Don Eastlake, 08/02/1997, One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Additions have developed to the Domain Name System to enable it to be used for authenticated public key distribution [RFC 2065]. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS security can be used to distribute their public keys. [Changes from previous version are to accommodate AS numbers larger than 16 bits and to delegate on decimal boundaries rather than binary boundaries.] "Detached Domain Name System (DNS) Information", Don Eastlake, 10/14/1998, A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. "Zone KEY RRSet Signing Procedure", O. Gudmundsson, J Gilmore, 11/19/1997, Under the security extensions to DNS, as defined in RFC 2065 and RFC 2137, a secured zone will have a KEY RRSet associated with the domain name at the apex of the zone. This document covers the manner in which this RRSet is generated, signed, and inserted into the name servers. "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", Don Eastlake, 11/24/1998, A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. "Domain Name System Security Extensions", Don Eastlake, 11/24/1998, Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback on RFC 2065 from early implementers and potential users. "DSA KEYs and SIGs in the Domain Name System (DNS)", Don Eastlake, 10/14/1998, A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. "Storing Certificates in the Domain Name System (DNS)", O. Gudmundsson, D. Eastlake, 11/24/1998, Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). "Indirect KEY RRs in the Domain Name System", D. Eastlake, 11/14/1997, RFC 2065 defines a means for storing cryptogrpahic public keys in the Domain Name System. An additional code point is defined for the KEY resource record (RR) algorithm field to indicate that the key itself is not stored in the KEY RR but is pointed to by the KEY RR. Encodings to indicate different types of key and pointer formats are specified. "DNSsec Authentication Referral Record (AR)", Robert Watson, 11/26/1997, Authentication Referrals allow DNS to refer to authentication mechanisms that supplement or replace the KEY RRs of DNSsec. Five Authentication Service types are defined: DNSsec, Kerberos IV, Kerberos V, Network Information Service (NIS+), and Radius. "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", Don Eastlake, 10/14/1998, A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. "Secret Key Establishment for DNS (TKEY RR)", Don Eastlake, 09/21/1998, [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and securing Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [changes from last draft: add IANA considerations section, make time fields module 2**32, minor edits, update author info, ...] "DNS Operational Security Considerations", Don Eastlake, 11/24/1998, Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. "Secure Domain Name System (DNS) Dynamic Update", Don Eastlake, 08/06/1998, Revised Domain Name System (DNS) protocol extensions to authenticate the data in DNS and provide key distribution services have been defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the original DNS security protocol definition in RFC 2065. In addition, symetric key DNS transaction signatures have been defined in draft- ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were also been defined [RFC 2137] in connection RFC 2065. This document updates secure dynamic update in light of draft-ietf-dnssec-secext2- *.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. "Intermediate Security Failures in DNSSEC", O. Gudmundsson, B. Wellington, 08/06/1998, This document identifies the situations where a signature verification fails in a recursive security aware DNS server, and how DNS servers should handle these cases, and the errors that should be reported to DNS resolvers. This document proposes a new error to be returned by DNSSEC capable servers. A DNSSEC server acting as a recursive server MUST validate the signatures on RRsets in a response it passes on; this draft addresses the case when the data it receives fails signature verification. The end resolver must be notified of this occurence in such a way that it will not confuse it with another error. "Domain Name System (DNS) Security Key Rollover", Don Eastlake, M. Andrews, 10/13/1998, Practical deployment of Domain Name System (DNS) security with good cryptologic practice will involve large volumes of key rollover traffic. A standard format and protocol for such messages is specified. "Simple Secure Domain Name System (DNS) Dynamic Update", B. Wellington, 11/12/1998, This draft proposes an alternative method for performing secure Domain Name System (DNS) dynamic updates. The method described here is both simple and flexible enough to represent any policy decisions. Secure communication based on request/transaction signatures [TSIG] is used to provide authentication and authorization. Detailed Revision/Update of Message Standards (drums) ----------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 08/05/1998, This document is a self-contained specification of the basic protocol for the Internet electronic mail transport, consolidating and updating: - the original SMTP specification of RFC 821 [RFC-821], - domain name system requirements and implications for mail transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - the clarifications and applicability statements in RFC 1123 [RFC-1123], and - material drawn from the SMTP Extension mechanisms [SMTPEXT]. It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123. However, RFC 821 specifies some features that are not in significant use in the Internet of the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821. It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have turned up as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and IMAP [RFC-IMAP4]. Section 2.3 provides definitions of terms specific to this document. Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively. A companion document discusses message headers, message bodies and formats and structures for them, and their relationship - [MSGFMT]. "Mail and Netnews Header Registration Procedure", J. Palme, 01/13/1998, Various IETF standards and http, e-mail and netnews software products use various http, e-mail and netnews header fields. This document specifies a procedure for the registration of http, e-mail and netnews header field names, to reduce the risk that two different products use the same header field name in different ways (homonyms) or that several different header field names are used with identical meaning (synonyms). "Internet Message Format Standard", P. Resnick, 11/23/1998, This standard specifies a syntax for text messages that are sent between computer users, within the framework of 'electronic mail' messages. This standard supersedes the one specified in Request For Comments 822, 'Standard for the Format of ARPA Internet Text Messages' [RFC-822], updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs [STD-3]. This standard specifies a syntax only for text messages. In particular, it makes no provision for the transmission of images, audio, or other sorts of structured data in electronic mail messages. There are several extensions published, such as the MIME document series [RFC-2045, RFC- 2046, RFC-2049], which describe mechanisms for the transmission of such data through electronic mail, either by extending the syntax provided here or by structuring such messages to conform to this syntax. Those mechanisms are outside of the scope of this standard. In the context of electronic mail, messages are viewed as having an envelope and contents. The envelope contains whatever information is needed to accomplish transmission and delivery. (See [SMTP] for a discussion of the envelope.) The contents comprise the object to be delivered to the recipient. This standard applies only to the format and some of the semantics of message contents. It contains no specification of the information in the envelope. However, some message systems may use information from the contents to create the envelope. It is intended that this standard facilitate the acquisition of such information by programs. "Use of Reply-To in Internet E-Mail messages", Robert Elz, 10/30/1997, This draft forms part of a discussion on the appropriate use of the Reply-To header in e-mail messages. This draft argues for one particular proposed definition of the Reply-To header. It is not intended that this document ever become anything more than an Internet-Draft. If adopted, the text here, or a modified version of some parts of it, would be merged into the proposed replacement for RFC822. "The ''Message-ID'' header", J. Palme, 12/03/1997, This is a proposal of a text to include msgfmt in order to clarify the relation between changes in the ''Message-ID'' header and other parts of a message. This information is important, because many mailers use the ''Message-ID'' to eliminate duplicates of the same message, and information may be lost if this is not done the right way. Temporary note This document does not at this time (21 November 1997) represent any consensus opinion in the drums working group. "Reply-To-Meaning Proposal", Chris Newman, 12/03/1997, This is a candidate proposal for one way which the problems with the reply-to header in email could be resolved. Under no circumstances should this be implemented as it is only a candidate for a solution and no decision has yet been made. This proposal distinguishes the different incompatible uses of the Reply-To header with a new Reply-To-Meaning header. This has the advantage of being relatively simple, not invalidating most current practices and allowing mail user agents to present more predictable user interfaces. "Reply-To Personal Proposal", Eric Raymond, 12/04/1997, This proposal describes proposed language for the 822bis draft, draft-ietf-drums-msg-fmt-03.txt, that clarifies the semantics of the Reply-To header. The intention is to clarify the rather vague language in 822bis in a way which preserves compatibility with the largest possible subset of existing mail user agents. This document should be read in conjunction with Jacob Palme's Mail-Followup-To proposal (draft-ietf-drums-mail-followup-to-00.txt), which the working group chair, Jacob Palme and the author regard as a natural complement of this proposal. "The ''Mail-Followup-To'' header", J. Palme, 12/04/1997, This proposal contains a proposed new e-mail header ''Mail-Followup-To'', which is intended to be used instead of the ''Reply-To'' header for suggesting where replies to the group who participates in a discussion should be sent. "Augmented BNF for Syntax Specifications: ABNF", P. Overell, Dave Crocker, 11/20/1998,