|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 2201 |
 Core Based Trees (CBT) Multicast Routing Architecture
|
|
Summary Publication date: Sep 1997 CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. Most multicast algorithms build one multicast tree per sender (subnetwork), the tree being rooted at the sender's subnetwork. The primary advantage of the shared tree approach is that it typically offers more favourable scaling characteristics than all other multicast algorithms. The CBT protocol [1] is a network layer multicast routing protocol that builds and maintains a shared delivery tree for a multicast group. The sending and receiving of multicast data by hosts on a subnetwork conforms to the traditional IP multicast service model [2]. CBT is progressing through the IDMR working group of the IETF. The CBT protocol is described in an accompanying document [1]. For this, and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr |
| RFC 2202 |
Test Cases for HMAC-MD5 and HMAC-SHA-1
|
|
Summary Publication date: Sep 1997 This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. Both constructs are used by IPSEC [OG,CG] and other protocols to authenticate messages. The test cases and results provided in this document are meant to be used as a conformance test for HMAC-MD5 and HMAC-SHA-1 implementations. |
| RFC 2203 |
RPCSEC_GSS Protocol Specification
|
|
Summary Publication date: Sep 1997 This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). |
| RFC 2204 |
ODETTE File Transfer Protocol
|
|
Summary Publication date: Sep 1997 This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community. |
| RFC 2205 |
Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
|
|
Summary Publication date: Sep 1997 This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. |
| RFC 2206 |
RSVP Management Information Base using SMIv2
|
|
Summary Publication date: Sep 1997 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. |
| RFC 2207 |
RSVP Extensions for IPSEC Data Flows
|
|
Summary Publication date: Sep 1997 This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). RSVP Version 1 as currently specified can support the IPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with both IPv4 and IPv6. |
| RFC 2208 |
Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment
|
|
Summary Publication date: Sep 1997 This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto the Internet standards track. |
| RFC 2209 |
Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules
|
|
Summary Publication date: Sep 1997 This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. This memo provides a generic description of the rules for the operation of Version 1 of RSVP [RFC 2205]. It is intended to outline a set of algorithms that will accomplish the needed function, omitting many details. |
| RFC 2210 |
The Use of RSVP with IETF Integrated Services
|
|
Summary Publication date: Sep 1997 This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. The RSVP protocol defines several data objects which carry resource reservation information but are opaque to RSVP itself. The usage and data format of those objects is given here. |
| RFC 2211 |
Specification of the Controlled-Load Network Element Service
|
|
Summary Publication date: Sep 1997 This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded. |
| RFC 2212 |
Specification of Guaranteed Quality of Service
|
|
Summary Publication date: Sep 1997 This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in reference [1]. |
| RFC 2213 |
Integrated Services Management Information Base using SMIv2
|
|
Summary Publication date: Sep 1997 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. |
| RFC 2214 |
Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2
|
|
Summary Publication date: Sep 1997 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. Comments should be made to the Integrated Services Working Group, intserv@isi.edu. |
| RFC 2215 |
General Characterization Parameters for Integrated Service Network Elements
|
|
Summary Publication date: Sep 1997 This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. General parameters are those with common, shared definitions across all QoS control services. |
| RFC 2216 |
Network Element Service Specification Template
|
|
Summary Publication date: Sep 1997 This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications). |
| RFC 2217 |
Telnet Com Port Control Option
|
|
Summary Publication date: Oct 1997 This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. |
| RFC 2218 |
A Common Schema for the Internet White Pages Service
|
|
Summary Publication date: Oct 1997 This work is the result of the IETF Integrated Directory Services (IDS) Working Group. The IDS Working Group proposes a standard specification for a simple Internet White Pages service by defining a common schema for use by the various White Pages servers. This schema is independent of specific implementations of the White Pages service. This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. It does not describe how to represent other objects in the White Pages service. Further, it does not address the search sort expectations within a particular service. |
| RFC 2219 |
Use of DNS Aliases for Network Services
|
|
Summary Publication date: Oct 1997 It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC 1034, RFC 1035]) to refer to network services such as anonymous FTP [RFC 959] servers, Gopher [RFC 1436] servers, and most notably World-Wide Web HTTP [RFC 1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World- Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as the Server Location Resource Records (DNS SRV) [RFC 2052] work. |
| RFC 2220 |
The Application/MARC Content-type
|
|
Summary Publication date: Oct 1997 This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. |
| RFC 2221 |
IMAP4 Login Referrals
|
|
Summary Publication date: Oct 1997 When dealing with large amounts of users and many IMAP4 [RFC 2060] servers, it is often necessary to move users from one IMAP4 server to another. For example, hardware failures or organizational changes may dictate such a move. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. A referral mechanism can provide efficiencies over the alternative 'proxy method', in which the local IMAP4 server contacts the remote server on behalf of the client, and then transfers the data from the remote server to itself, and then on to the client. The referral mechanism's direct client connection to the remote server is often a more efficient use of bandwidth, and does not require the local server to impersonate the client when authenticating to the remote server. |
| RFC 2222 |
Simple Authentication and Security Layer (SASL)
|
|
Summary Publication date: Oct 1997 This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection. |
| RFC 2223 |
Instructions to RFC Authors
|
|
Summary Publication date: Oct 1997 This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. |
| RFC 2224 |
NFS URL Scheme
|
|
Summary Publication date: Oct 1997 A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, "Uniform Resource Locators (URL)". This scheme uses the public filehandle and multi-component lookup [RFC 2054, RFC 2055] to access server data with a minimum of protocol overhead. The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC 1094] and version 3 [RFC 1813], both built on ONC RPC [RFC 1831] at its associated eXternal Data Representation (XDR) [RFC 1832] and Binding Protocol [RFC 1833]. |
| RFC 2225 |
Classical IP and ARP over ATM
|
|
Summary Publication date: Apr 1998 This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 5. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many Ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers operating in the "classical" LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references for more detailed information about ATM implementation agreements and standards. |
| RFC 2226 |
IP Broadcast over ATM Networks
|
|
Summary Publication date: Oct 1997 This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group. An understanding of the services provided by RFC 2022 is assumed. |
| RFC 2227 |
Simple Hit-Metering and Usage-Limiting for HTTP
|
|
Summary Publication date: Oct 1997 This document proposes a simple extension to HTTP, using a new "Meter" header, which permits a limited form of demographic information (colloquially called "hit-counts") to be reported by caches to origin servers, in a more efficient manner than the "cache-busting" techniques currently used. It also permits an origin server to control the number of times a cache uses a cached response, and outlines a technique that origin servers can use to capture referral information without "cache-busting." |
| RFC 2228 |
FTP Security Extensions
|
|
Summary Publication date: Oct 1997 This document defines extensions to the FTP specification STD 9, RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. The following new optional commands are introduced in this specification: AUTH (Authentication/Security Mechanism), ADAT (Authentication/Security Data), PROT (Data Channel Protection Level), PBSZ (Protection Buffer Size), CCC (Clear Command Channel), MIC (Integrity Protected Command), CONF (Confidentiality Protected Command), and ENC (Privacy Protected Command). A new class of reply types (6yz) is also introduced for protected replies. None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands. Note that this specification is compatible with STD 9, RFC 959. |
| RFC 2229 |
A Dictionary Server Protocol
|
|
Summary Publication date: Oct 1997 The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. |
| RFC 2230 |
Key Exchange Delegation Record for the DNS
|
|
Summary Publication date: Nov 1997 This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. It can be used with several security services. For example, a system seeking to use IP Security [RFC- 1825, RFC 1826, RFC 1827] to protect IP packets for a given destination can use this mechanism to determine the set of authorised remote key exchanger systems for that destination. |
| RFC 2231 |
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
|
|
Summary Publication date: Nov 1997 This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to provide (1) a means to specify parameter values in character sets other than US-ASCII, (2) to specify the language to be used should the value be displayed, and (3) a continuation mechanism for long parameter values to avoid problems with header line wrapping. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. |
| RFC 2232 |
Definitions of Managed Objects for DLUR using SMIv2
|
|
Summary Publication date: Nov 1997 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. |
| RFC 2233 |
The Interfaces Group MIB using SMIv2
|
|
Summary Publication date: Nov 1997 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media- specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork- layer. It specifies clarifications to, and extensions of, the architectural issues within the previous model used for the 'interfaces' group. This memo also includes a MIB module. As well as including new MIB definitions to support the architectural extensions, this MIB module also re-specifies the 'interfaces' group of MIB-II in a manner that is both compliant to the SNMPv2 SMI and semantically- identical to the existing SNMPv1-based definitions. |
| RFC 2234 |
Augmented BNF for Syntax Specifications: ABNF
|
|
Summary Publication date: Nov 1997 Internet technical specifications often need to define a format syntax and are free to employ whatever notation their authors deem useful. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. It balances compactness and simplicity, with reasonable representational power. In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC 733 and then RFC 822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. Appendix A (Core) supplies rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. It is provided as a convenience and is otherwise separate from the meta language defined in the body of this document, and separate from its formal status. |
| RFC 2235 |
Hobbes' Internet Timeline
|
|
Summary Publication date: Nov 1997 This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. |
| RFC 2236 |
Internet Group Management Protocol, Version 2
|
|
Summary Publication date: Nov 1997 This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s). |
| RFC 2237 |
Japanese Character Encoding for Internet Messages
|
|
Summary Publication date: Nov 1997 This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. |
| RFC 2238 |
Definitions of Managed Objects for HPR using SMIv2
|
|
Summary Publication date: Nov 1997 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. |
| RFC 2239 |
Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2
|
|
Summary Publication date: Nov 1997 This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. |
| RFC 2240 |
A Legal Basis for Domain Name Allocation
|
|
Summary Publication date: Nov 1997 The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. |
| RFC 2241 |
DHCP Options for Novell Directory Services
|
|
Summary Publication date: Nov 1997 This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. The first option carries a list of NDS servers. The second option carries the name of the client's NDS tree. The third carries the initial NDS context. These three options provide an NDS client with enough information to connect to an NDS tree without manual configuration of the client. |
| RFC 2242 |
NetWare/IP Domain Name and Information
|
|
Summary Publication date: Nov 1997 The Dynamic Host Configuration Protocol (DHCP) [RFC 2131] provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP includes options for specific configuration parameters [RFC 2132]. This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. |
| RFC 2243 |
OTP Extended Responses
|
|
Summary Publication date: Nov 1997 This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. Codings for the two mandatory OTP data formats using this new type of response are presented. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. |
| RFC 2244 |
ACAP -- Application Configuration Access Protocol
|
|
Summary Publication date: Nov 1997 The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted. |
| RFC 2245 |
Anonymous SASL Mechanism
|
|
Summary Publication date: Nov 1997 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using "anonymous" as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. |
| RFC 2246 |
The TLS Protocol Version 1.0
|
|
Summary Publication date: Jan 1999 This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
| RFC 2247 |
Using Domains in LDAP/X.500 Distinguished Names
|
|
Summary Publication date: Jan 1998 The Lightweight Directory Access Protocol (LDAP) uses X.500- compatible distinguished names [3] for providing unique identification of entries. This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. |
| RFC 2248 |
Network Services Monitoring MIB
|
|
Summary Publication date: Jan 1998 A networked application is a realization of some well defined service on one or more host computers that is accessible via some network, uses some network for its internal operations, or both. There are a wide range of networked applications for which it is appropriate to provide SNMP monitoring of their network usage. This includes applications using both TCP/IP and OSI networking. This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application-specific monitoring and management. Two examples of this are MIBs defining additional variables for monitoring a Message Transfer Agent (MTA) service or a Directory Service Agent (DSA) service. It is expected that further MIBs of this nature will be specified. This MIB does not attempt to provide facilities for management of the host or hosts the network service application runs on, nor does it provide facilities for monitoring applications that provide something other than a network service. Host resource and general application monitoring is handled by the Host Resources MIB at present; development of an additional application MIB is currently underway in the IETF. |
| RFC 2249 |
Mail Monitoring MIB
|
|
Summary Publication date: Jan 1998 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. |
| RFC 2250 |
RTP Payload Format for MPEG1/MPEG2 Video
|
|
Summary Publication date: Jan 1998 This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms in Section 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added. |
| RFC 2251 |
Lightweight Directory Access Protocol (v3)
|
|
Summary Publication date: Dec 1997 The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). This protocol is specifically targeted at management applications and browser applications that provide read/write interactive access to directories. When used with a directory supporting the X.500 protocols, it is intended to be a complement to the X.500 DAP. |
| RFC 2252 |
Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
|
|
Summary Publication date: Dec 1997 The Lightweight Directory Access Protocol (LDAP) [1] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. The syntaxes defined in this document are referenced by this and other documents that define attribute types. This document also defines the set of attribute types which LDAP servers should support. |
| RFC 2253 |
Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
|
|
Summary Publication date: Dec 1997 The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. |
| RFC 2254 |
The String Representation of LDAP Search Filters
|
|
Summary Publication date: Dec 1997 The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This document replaces RFC 1960, extending the string LDAP filter definition to include support for LDAP version 3 extended match filters, and including support for representing the full range of possible LDAP search filters. |
| RFC 2255 |
The LDAP URL Format
|
|
Summary Publication date: Dec 1997 LDAP is the Lightweight Directory Access Protocol, defined in [1], [2] and [3]. This document describes a format for an LDAP Uniform Resource Locator. The format describes an LDAP search operation to perform to retrieve information from an LDAP directory. This document replaces RFC 1959. It updates the LDAP URL format for version 3 of LDAP and clarifies how LDAP URLs are resolved. This document also defines an extension mechanism for LDAP URLs, so that future documents can extend their functionality, for example, to provide access to new LDAPv3 extensions as they are defined. |
| RFC 2256 |
A Summary of the X.500(96) User Schema for use with LDAPv3
|
|
Summary Publication date: Dec 1997 This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. This is the most widely used schema for LDAP/X.500 directories, and many other schema definitions for white pages objects use it as a basis. This document does not cover attributes used for the administration of X.500 directory servers, nor does it include attributes defined by other ISO/ITU-T documents. |
| RFC 2257 |
Agent Extensibility (AgentX) Protocol Version 1
|
|
Summary Publication date: Jan 1998 This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. |
| RFC 2258 |
Internet Nomenclator Project
|
|
Summary Publication date: Jan 1998 The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. Each CCSO server has a database schema that is tailored to the needs of the organization that owns it. The project is integrating the different database schema into one query service. The Internet Nomenclator Project will provide fast cross-server searches for locating people on the Internet. It augments existing CCSO services by supplying schema integration, more extensive indexing, and two kinds of caching -- all this in a system that scales as the number of CCSO servers grows. One of the best things about the system is that administrators can incorporate their CCSO servers into Nomenclator without changing the servers. All Nomenclator needs is basic information about the server. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. |
| RFC 2259 |
Simple Nomenclator Query Protocol (SNQP)
|
|
Summary Publication date: Jan 1998 The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. The protocol is useful to services that search many data repositories for query responses. Clients can pose queries on relations, list descriptions of relations, and obtain advice on reducing the search time and cost of their queries. Clients are informed of the age of information in caches, and may request more recent information. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so services can use SNQP with a variety of back-end servers, e.g. relational database servers, CCSO servers, and servers providing relational views of X.500. SNQP is an ASCII protocol in the request-reply style of SMTP. It was specifically designed for use with the Nomenclator name and information service, and has been useful elsewhere. |
| RFC 2260 |
Scalable Support for Multi-homed Multi-provider Connectivity
|
|
Summary Publication date: Jan 1998 This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. |
| RFC 2261 |
An Architecture for Describing SNMP Management Frameworks
|
|
Summary Publication date: Jan 1998 This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
| RFC 2262 |
Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
|
|
Summary Publication date: Jan 1998 This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC 2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
| RFC 2263 |
SNMPv3 Applications
|
|
Summary Publication date: Jan 1998 This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC 2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
| RFC 2264 |
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
|
|
Summary Publication date: Jan 1998 This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC 2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
| RFC 2265 |
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
|
|
Summary Publication date: Jan 1998 This document describes the View-based Access Control Model for use in the SNMP architecture [RFC 2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
| RFC 2266 |
Definitions of Managed Objects for IEEE 802.12 Repeater Devices
|
|
Summary Publication date: Jan 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 network repeaters based on IEEE 802.12. |
| RFC 2267 |
Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
|
|
Summary Publication date: Jan 1998 Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. |
| RFC 2268 |
A Description of the RC2(r) Encryption Algorithm
|
|
Summary Publication date: Mar 1998 This memo is an RSA Laboratories Technical Note. It is meant for informational use by the Internet community. This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. The input and output block sizes are 64 bits each. The key size is variable, from one byte up to 128 bytes, although the current implementation uses eight bytes. The algorithm is designed to be easy to implement on 16-bit microprocessors. On an IBM AT, the encryption runs about twice as fast as DES (assuming that key expansion has been done). |
| RFC 2269 |
Using the MARS Model in non-ATM NBMA Networks
|
|
Summary Publication date: Jan 1998 Initially developed for IP over ATM, the RFC 2022 (MARS) model is also applicable to other NBMA networks that provide the equivalent of switched, point to multipoint connections. This short document is intended to state the obvious equivalences, and explain the less obvious implications. No changes to the MARS model per se are suggested or required. RFC 2022 is not required over NBMA networks that offer Ethernet-like group addressing functionality. |
| RFC 2270 |
Using a Dedicated AS for Sites Homed to a Single Provider
|
|
Summary Publication date: Jan 1998 With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC 1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC 1930. |
| RFC 2271 |
An Architecture for Describing SNMP Management Frameworks
|
|
Summary Publication date: Jan 1998 This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. |
| RFC 2272 |
Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
|
|
Summary Publication date: Jan 1998 This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC 2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. |
| RFC 2273 |
SNMPv3 Applications
|
|
Summary Publication date: Jan 1998 This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC 2271]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. |
| RFC 2274 |
User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
|
|
Summary Publication date: Jan 1998 This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC 2271]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. |
| RFC 2275 |
View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
|
|
Summary Publication date: Jan 1998 This document describes the View-based Access Control Model for use in the SNMP architecture [RFC 2271]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. |
| RFC 2276 |
Architectural Principles of Uniform Resource Name Resolution
|
|
Summary Publication date: Jan 1998 This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately. |
| RFC 2277 |
IETF Policy on Character Sets and Languages
|
|
Summary Publication date: Jan 1998 The Internet is international. With the international Internet follows an absolute requirement to interchange data in a multiplicity of languages, which in turn utilize a bewildering number of characters. This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. The document is very much based upon the recommendations of the IAB Character Set Workshop of February 29-March 1, 1996, which is documented in RFC 2130 [WR]. This document attempts to be concise, explicit and clear; people wanting more background are encouraged to read RFC 2130. The document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in [RFC 2119]. In this case, 'the specification' as used by RFC 2119 refers to the processing of protocols being submitted to the IETF standards process. |
| RFC 2278 |
IANA Charset Registration Procedures
|
|
Summary Publication date: Jan 1998 MIME [RFC 2045, RFC 2046, RFC 2047, RFC 2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. In particular, the general applicability and appropriateness of a given registered charset is a protocol issue, not a registration issue, and is not dealt with by this registration procedure. |
| RFC 2279 |
UTF-8, a transformation format of ISO 10646
|
|
Summary Publication date: Jan 1998 ISO/IEC 10646-1 defines a multi-octet character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. |
| RFC 2280 |
Routing Policy Specification Language (RPSL)
|
|
Summary Publication date: Jan 1998 This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. |
| RFC 2281 |
Cisco Hot Standby Router Protocol (HSRP)
|
|
Summary Publication date: Mar 1998 The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. Multiple routers participate in this protocol and in concert create the illusion of a single virtual router. The protocol insures that one and only one of the routers is forwarding packets on behalf of the virtual router. End hosts forward their packets to the virtual router. The router forwarding packets is known as the active router. A standby router is selected to replace the active router should it fail. The protocol provides a mechanism for determining active and standby routers, using the IP addresses on the participating routers. If an active router fails a standby router can take over without a major interruption in the host's connectivity. This memo also discusses the ARP, MAC address, and security issues with this protocol. |
| RFC 2282 |
IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees
|
|
Summary Publication date: Feb 1998 The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. |
| RFC 2283 |
Multiprotocol Extensions for BGP-4
|
|
Summary Publication date: Feb 1998 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. |
| RFC 2284 |
PPP Extensible Authentication Protocol (EAP)
|
|
Summary Publication date: Mar 1998 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. |
| RFC 2285 |
Benchmarking Terminology for LAN Switching Devices
|
|
Summary Publication date: Feb 1998 This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. Although it might be found useful to apply some of the terms defined here to a broader range of network interconnect devices, this RFC primarily deals with devices which switch frames at the Medium Access Control (MAC) layer. It defines terms in relation to the traffic put to use when benchmarking switching devices, forwarding performance, congestion control, latency, address handling and filtering. |
| RFC 2286 |
Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
|
|
Summary Publication date: Feb 1998 This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are two constructs of the HMAC [HMAC] message authentication function using the RIPEMD-160 and RIPEMD-128 [RIPE] hash functions. The test cases and results provided in this document are meant to be used as a conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128 implementations. |
| RFC 2287 |
Definitions of System-Level Managed Objects for Applications
|
|
Summary Publication date: Feb 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 basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. More specifically, the managed objects are restricted to information that can be determined from the system itself and which does not require special instrumentation within the applications to make the information available. This memo does not specify a standard for the Internet community. |
| RFC 2288 |
Using Existing Bibliographic Identifiers as Uniform Resource Names
|
|
Summary Publication date: Feb 1998 A system for Uniform Resource Names (URNs) must be capable of supporting identifiers from existing widely-used naming systems. This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. |
| RFC 2289 |
A One-Time Password System
|
|
Summary Publication date: Feb 1998 This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. OTP evolved from the S/KEY (S/KEY is a trademark of Bellcore) One-Time Password System that was released by Bellcore and is described in references [3] and [5]. |
| RFC 2290 |
Mobile-IPv4 Configuration Option for PPP IPCP
|
|
Summary Publication date: Feb 1998 Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point- to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. |
| RFC 2291 |
Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
|
|
Summary Publication date: Feb 1998 Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. |
| RFC 2292 |
Advanced Sockets API for IPv6
|
|
Summary Publication date: Feb 1998 Specifications are in progress for changes to the sockets API to support IP version 6 [RFC 2133]. These changes are for TCP and UDP- based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. But another class of applications exists that will also be run under IPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC 2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too. |
| RFC 2293 |
Representing Tables and Subtrees in the X.500 Directory
|
|
Summary Publication date: Mar 1998 This document defines techniques for representing two types of information mapping in the OSI Directory [1]. 1. Mapping from a key to a value (or set of values), as might be done in a table lookup. 2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. These techniques were developed for supporting MHS use of Directory [2], but are specified separately as they have more general applicability. |
| RFC 2294 |
Representing the O/R Address hierarchy in the X.500 Directory Information Tree
|
|
Summary Publication date: Mar 1998 This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including: o Support for MHS Routing [4]. o Support for X.400/RFC 822 address mappings [2, 5]. |
| RFC 2295 |
Transparent Content Negotiation in HTTP
|
|
Summary Publication date: Mar 1998 HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. |
| RFC 2296 |
HTTP Remote Variant Selection Algorithm -- RVSA/1.0
|
|
Summary Publication date: Mar 1998 HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. |
| RFC 2297 |
Ipsilon's General Switch Management Protocol Specification Version 2.0
|
|
Summary Publication date: Mar 1998 This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC 1987]. The major enhancement is the addition of Quality of Service (QoS) messages. Other improvements have been made to the protocol resulting from operational experience. GSMP is a general purpose protocol to control an ATM switch. It allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; and request statistics. |
| RFC 2298 |
An Extensible Message Format for Message Disposition Notifications
|
|
Summary Publication date: Mar 1998 This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. |
| RFC 2299 |
Request for Comments Summary
|
|
Summary Publication date: Jan 1999 This RFC is a slightly annotated list of the 100 RFCs from RFC 2200 through RFCs 2299. This is a status report on these RFCs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
| RFC 2300 |
Internet Official Protocol Standards
|
|
Summary Publication date: May 1998 This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. |
