|
|
|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
|
||||||
| RFC 2801 |
 Internet Open Trading Protocol - IOTP Version 1.0
|
|
Summary Publication date: Apr 2000 The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure Channel Credit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the Payment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. |
| RFC 2802 |
Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)
|
|
Summary Publication date: Apr 2000 A syntax and procedures are described for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). |
| RFC 2803 |
Digest Values for DOM (DOMHASH)
|
|
Summary Publication date: Apr 2000 This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects. |
| RFC 2804 |
IETF Policy on Wiretapping
|
|
Summary Publication date: May 2000 The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. |
| RFC 2805 |
Media Gateway Control Protocol Architecture and Requirements
|
|
Summary Publication date: Apr 2000 This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway. |
| RFC 2806 |
URLs for Telephone Calls
|
|
Summary Publication date: Apr 2000 This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers. |
| RFC 2807 |
XML Signature Requirements
|
|
Summary Publication date: Jul 2000 This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. |
| RFC 2808 |
The SecurID(r) SASL Mechanism
|
|
Summary Publication date: Apr 2000 SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC 2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL. |
| RFC 2809 |
Implementation of L2TP Compulsory Tunneling via RADIUS
|
|
Summary Publication date: Apr 2000 This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents. |
| RFC 2810 |
Internet Relay Chat: Architecture
|
|
Summary Publication date: Apr 2000 The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves. First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. |
| RFC 2811 |
Internet Relay Chat: Channel Management
|
|
Summary Publication date: Apr 2000 One of the most notable characteristics of the IRC (Internet Relay Chat) protocol is to allow for users to be grouped in forums, called channels, providing a mean for multiple users to communicate together. There was originally a unique type of channels, but with the years, new types appeared either as a response to a need, or for experimental purposes. This document specifies how channels, their characteristics and properties are managed by IRC servers. |
| RFC 2812 |
Internet Relay Chat: Client Protocol
|
|
Summary Publication date: Apr 2000 The IRC (Internet Relay Chat) protocol is for use with text based conferencing; the simplest client being any socket program capable of connecting to the server. This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture [IRC-ARCH]. |
| RFC 2813 |
Internet Relay Chat: Server Protocol
|
|
Summary Publication date: Apr 2000 While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network. This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently. First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification. |
| RFC 2814 |
SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
|
|
Summary Publication date: May 2000 This document describes a signaling method and protocol for RSVP- based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee. |
| RFC 2815 |
Integrated Service Mappings on IEEE 802 Networks
|
|
Summary Publication date: May 2000 This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches. These mappings are one component of the Integrated Services over IEEE 802 LANs framework. |
| RFC 2816 |
A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies
|
|
Summary Publication date: May 2000 This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches. It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol (RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13]. |
| RFC 2817 |
Upgrading to TLS Within HTTP/1.1
|
|
Summary Publication date: May 2000 This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address. Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to- end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens. This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace (http://example.org/ and https://example.org/ are not equivalent). |
| RFC 2818 |
HTTP Over TLS
|
|
Summary Publication date: May 2000 This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC 2817]. |
| RFC 2819 |
Remote Network Monitoring Management Information Base
|
|
Summary Publication date: May 2000 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 remote network monitoring devices. This memo obsoletes RFC 1757. This memo extends that specification by documenting the RMON MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. |
| RFC 2820 |
Access Control Requirements for LDAP
|
|
Summary Publication date: May 2000 This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories. |
| RFC 2821 |
Simple Mail Transfer Protocol
|
|
Summary Publication date: Apr 2001 This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following: - the original SMTP (Simple Mail Transfer Protocol) specification of RFC 821 [30], - domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27], - the clarifications and applicability statements in RFC 1123 [2], and - material drawn from the SMTP Extension mechanisms [19]. It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by 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. |
| RFC 2822 |
Internet Message Format
|
|
Summary Publication date: Apr 2001 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 (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
| RFC 2823 |
PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing
|
|
Summary Publication date: May 2000 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 [2] and 2615 [3] provide a means to carry PPP over Synchronous Optical Network (SONET) [4] and Synchronous Digital Hierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL) [6]. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. |
| RFC 2824 |
Call Processing Language Framework and Requirements
|
|
Summary Publication date: May 2000 A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language. |
| RFC 2825 |
A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols
|
|
Summary Publication date: May 2000 The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today's URLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development. There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users. This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. |
| RFC 2826 |
IAB Technical Comment on the Unique DNS Root
|
|
Summary Publication date: May 2000 To remain a global network, the Internet requires the existence of a globally unique public name space. The DNS name space is a hierarchical name space derived from a single, globally unique root. This is a technical constraint inherent in the design of the DNS. Therefore it is not technically feasible for there to be more than one root in the public DNS. That one root must be supported by a set of coordinated root servers administered by a unique naming authority. Put simply, deploying multiple public DNS roots would raise a very strong possibility that users of different ISPs who click on the same link on a web page could end up at different destinations, against the will of the web page designers. This does not preclude private networks from operating their own private name spaces, but if they wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy, and in particular from the coordinated root servers of the global DNS naming hierarchy. |
| RFC 2827 |
Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
|
|
Summary Publication date: May 2000 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 2828 |
Internet Security Glossary
|
|
Summary Publication date: May 2000 This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion, ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future. |
| RFC 2829 |
Authentication Methods for LDAP
|
|
Summary Publication date: May 2000 This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations. |
| RFC 2830 |
Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
|
|
Summary Publication date: May 2000 This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of an LDAP extended request. |
| RFC 2831 |
Using Digest Authentication as a SASL Mechanism
|
|
Summary Publication date: May 2000 This specification defines how HTTP Digest Authentication [Digest] can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. |
| RFC 2832 |
NSI Registry Registrar Protocol (RRP) Version 1.1.0
|
|
Summary Publication date: May 2000 This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This protocol was developed by the Network Solutions Registry for use within the Shared Registration System and is being published "as-is" to document the protocol implementation developed by the Network Solutions, Inc. Registry. Internet domain name registration typically involves three entities: a registrant who wishes to register a domain name, a registrar who provides services to the registrant, and a registry that provides services to the registrar while serving as the authoritative repository of all functional information required to resolve names registered in the registry's TLDs. This document describes a protocol for registry-registrar communication only. The protocol does not provide any registrant services. This document is being discussed on the "rrp" mailing list. To join the list, send a message to |
| RFC 2833 |
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
|
|
Summary Publication date: May 2000 This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. |
| RFC 2834 |
ARP and IP Broadcast over HIPPI-800
|
|
Summary Publication date: May 2000 This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC 2067 "IP over HIPPI") obsoletes RFC 1374. |
| RFC 2835 |
IP and ARP over HIPPI-6400 (GSN)
|
|
Summary Publication date: May 2000 The ANSI T11.1 task force has standardized HIPPI-6400 also known as Gigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified in HIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3]. HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs [10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2]. T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI- 6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. |
| RFC 2836 |
Per Hop Behavior Identification Codes
|
|
Summary Publication date: May 2000 This document defines a binary encoding to uniquely identify PHBs and/or sets of PHBs in protocol messages. |
| RFC 2837 |
Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard
|
|
Summary Publication date: May 2000 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. |
| RFC 2838 |
Uniform Resource Identifiers for Television Broadcasts
|
|
Summary Publication date: May 2000 World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in [RFC 2396]. This document describes a widely-implemented URI scheme to refer to such broadcasts. |
| RFC 2839 |
Internet Kermit Service
|
|
Summary Publication date: May 2000 This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. The Internet Kermit Service provides access to both authenticated and anonymous users. The use of Kermit protocol over a Telnet connection provides several advantages over FTP, including easy traversal of firewalls, transfers over multiple transports, and security via a combination of supported Telnet authentication and encryption option negotiations, plus significant functional benefits. While this document describes a new service for the Internet, the clients for this service already exist on most platforms in the form of Telnet clients that support the Kermit file transfer protocol. These clients are available not only from Columbia University's Kermit Project but also numerous third parties. |
| RFC 2840 |
TELNET KERMIT OPTION
|
|
Summary Publication date: May 2000 This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. |
| RFC 2841 |
IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)
|
|
Summary Publication date: Nov 2000 This document describes the use of keyed SHA1 with the IP Authentication Header. |
| RFC 2842 |
Capabilities Advertisement with BGP-4
|
|
Summary Publication date: May 2000 Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. |
| RFC 2843 |
Proxy-PAR
|
|
Summary Publication date: May 2000 Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment. The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR primarily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI. In addition, Proxy-PAR-capable servers provide filtering based on VPN IDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients. |
| RFC 2844 |
OSPF over ATM and Proxy-PAR
|
|
Summary Publication date: May 2000 This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy-PAR. These recommendations require no protocol changes and allow simpler, more efficient and cost- effective network designs. It is recommended that OSPF implementations should be able to support logical interfaces, each consisting of one or more virtual circuits and used either as numbered logical point-to-point links (one VC), logical NBMA networks (more than one VC) or Point-to-MultiPoint networks (more than one VC), where a solution simulating broadcast interfaces is not appropriate. PAR can help distribute across the ATM cloud configuration setup and changes of such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be used to exchange this information between the ATM cloud and the routers connected to it. |
| RFC 2845 |
Secret Key Transaction Authentication for DNS (TSIG)
|
|
Summary Publication date: May 2000 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. |
| RFC 2846 |
GSTN Address Element Extensions in E-mail Services
|
|
Summary Publication date: Jun 2000 There are numerous applications where there is a need for interaction between the GSTN addressing and Internet addressing. This memo defines a full syntax for one specific case, where there is a need to represent GSTN addresses within Internet e-mail addresses. This full syntax is a superset of a minimal syntax which has been defined in [1]. |
| RFC 2847 |
LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
|
|
Summary Publication date: Jun 2000 This memorandum describes a method whereby one can use GSS-API [RFC 2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol [RFC 2246]. The method leverages the existing Simple Public Key Mechanism (SPKM) [RFC 2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM. |
| RFC 2848 |
The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
|
|
Summary Publication date: Jun 2000 This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols. |
| RFC 2849 |
The LDAP Data Interchange Format (LDIF) - Technical Specification
|
|
Summary Publication date: Jun 2000 This document describes a file format suitable for describing directory information or modifications made to directory information. The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information between LDAP-based directory servers, or to describe a set of changes which are to be applied to a directory. |
| RFC 2850 |
Charter of the Internet Architecture Board (IAB)
|
|
Summary Publication date: May 2000 This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. |
| RFC 2851 |
Textual Conventions for Internet Network Addresses
|
|
Summary Publication date: Jun 2000 This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations. This work is output from the Operations and Management Area "IPv6MIB" design team. |
| RFC 2852 |
Deliver By SMTP Service Extension
|
|
Summary Publication date: Jun 2000 This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued. This extension should not be viewed as a vehicle for requesting "priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a Deliver By request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period. A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond 17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a "delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems. |
| RFC 2853 |
Generic Security Service API Version 2 : Java Bindings
|
|
Summary Publication date: Jun 2000 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 2743 [GSSAPIv2-UPDATE]. 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]. |
| RFC 2854 |
The 'text/html' Media Type
|
|
Summary Publication date: Jun 2000 This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations; it is intended to obsolete the previous IETF documents defining HTML, including RFC 1866, RFC 1867, RFC 1980, RFC 1942 and RFC 2070, and to remove HTML from IETF Standards Track. This document was prepared at the request of the W3C HTML working group. Please send comments to www-html@w3.org, a public mailing list with archive at |
| RFC 2855 |
DHCP for IEEE 1394
|
|
Summary Publication date: Jun 2000 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. This memo describes the 1394 specific usage of some fields of DHCP messages. |
| RFC 2856 |
Textual Conventions for Additional High Capacity Data Types
|
|
Summary Publication date: Jun 2000 This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. The definitions contained in this document represent a short term solution which may be deprecated in the future. |
| RFC 2857 |
The Use of HMAC-RIPEMD-160-96 within ESP and AH
|
|
Summary Publication date: Jun 2000 This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. |
| RFC 2858 |
Multiprotocol Extensions for BGP-4
|
|
Summary Publication date: Jun 2000 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. This document obsoletes RFC 2283. |
| RFC 2859 |
A Time Sliding Window Three Colour Marker (TSWTCM)
|
|
Summary Publication date: Jun 2000 This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner [RFC 2475, RFC 2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB) [AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate (CTR) and Peak Target Rate (PTR). |
| RFC 2860 |
Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
|
|
Summary Publication date: Jun 2000 This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. |
| RFC 2861 |
TCP Congestion Window Validation
|
|
Summary Publication date: Jun 2000 TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD. |
| RFC 2862 |
RTP Payload Format for Real-Time Pointers
|
|
Summary Publication date: Jun 2000 This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism. |
| RFC 2863 |
The Interfaces Group MIB
|
|
Summary Publication date: Jun 2000 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 [17], 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 MIB-II model of the ' interfaces' group. This memo obsoletes RFC 2233, the previous version of the Interfaces Group MIB. |
| RFC 2864 |
The Inverted Stack Table Extension to the Interfaces Group MIB
|
|
Summary Publication date: Jun 2000 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 which provide an inverted mapping of the interface stack table used for managing network interfaces. |
| RFC 2865 |
Remote Authentication Dial In User Service (RADIUS)
|
|
Summary Publication date: Jun 2000 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. |
| RFC 2866 |
RADIUS Accounting
|
|
Summary Publication date: Jun 2000 This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. |
| RFC 2867 |
RADIUS Accounting Modifications for Tunnel Protocol Support
|
|
Summary Publication date: Jun 2000 This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks. |
| RFC 2868 |
RADIUS Attributes for Tunnel Protocol Support
|
|
Summary Publication date: Jun 2000 This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. |
| RFC 2869 |
RADIUS Extensions
|
|
Summary Publication date: Jun 2000 This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2]. |
| RFC 2870 |
Root Name Server Operational Requirements
|
|
Summary Publication date: Jun 2000 As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details. |
| RFC 2871 |
A Framework for Telephony Routing over IP
|
|
Summary Publication date: Jun 2000 This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. |
| RFC 2872 |
Application and Sub Application Identity Policy Element for Use with RSVP
|
|
Summary Publication date: Jun 2000 RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. |
| RFC 2873 |
TCP Processing of the IPv4 Precedence Field
|
|
Summary Publication date: Jun 2000 This memo describes a conflict between TCP [RFC 793] and DiffServ [RFC 2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC 791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict. Because the IPv6 [RFC 2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet. |
| RFC 2874 |
DNS Extensions to Support IPv6 Address Aggregation and Renumbering
|
|
Summary Publication date: Jul 2000 This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. |
| RFC 2875 |
Diffie-Hellman Proof-of-Possession Algorithms
|
|
Summary Publication date: Jul 2000 This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of- possession rather than general purpose signing. |
| RFC 2876 |
Use of the KEA and SKIPJACK Algorithms in CMS
|
|
Summary Publication date: Jul 2000 This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. |
| RFC 2877 |
5250 Telnet Enhancements
|
|
Summary Publication date: Jul 2000 This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described. By allowing a Telnet client to select the device name, the 5250 Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are 1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing, 2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange. Applications may need to use system API's on the AS/400 in order to extract Telnet session settings from the device name description. Refer to the Retrieve Device Description (QDCRDEVD) API described in the AS/400 System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates. This memo describes how the IBM 5250 Telnet server supports Work Station Function (WSF) printers using 5250 Display Station Pass- Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session. |
| RFC 2878 |
PPP Bridging Control Protocol (BCP)
|
|
Summary Publication date: Jul 2000 The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 1638, which was based on the IEEE 802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs. |
| RFC 2879 |
Content Feature Schema for Internet Fax (V2)
|
|
Summary Publication date: Aug 2000 This document defines a content media feature schema for Internet fax. It is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531. |
| RFC 2880 |
Internet Fax T.30 Feature Mapping
|
|
Summary Publication date: Aug 2000 This document describes how to map Group 3 fax capability identification bits, described in ITU T.30 [6], into the Internet fax feature schema described in "Content feature schema for Internet fax" [4]. This is a companion to the fax feature schema document [4], which itself defines a profile of the media feature registration mechanisms [1,2,3], for use in performing capability identification between extended Internet fax systems [5]. |
| RFC 2881 |
Network Access Server Requirements Next Generation (NASREQNG) NAS Model
|
|
Summary Publication date: Jul 2000 This document describes the terminology and gives a model of typical Network Access Server (NAS). The purpose of this effort is to set the reference space for describing and evaluating NAS service protocols, such as RADIUS (RFCs 2865, 2866) [1], [2] and follow-on efforts like AAA Working Group, and the Diameter protocol [3]. These are protocols for carrying user service information for authentication, authorization, accounting, and auditing, between a Network Access Server which desires to authenticate its incoming calls and a shared authentication server. |
| RFC 2882 |
Network Access Servers Requirements: Extended RADIUS Practices
|
|
Summary Publication date: Jul 2000 This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment. |
| RFC 2883 |
An Extension to the Selective Acknowledgement (SACK) Option for TCP
|
|
Summary Publication date: Jul 2000 This note defines an extension of the Selective Acknowledgement (SACK) Option [RFC 2018] for TCP. RFC 2018 specified the use of the SACK option for acknowledging out-of-sequence data not covered by TCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts. |
| RFC 2884 |
Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks
|
|
Summary Publication date: Jul 2000 This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. ECN is an end-to-end congestion avoidance mechanism proposed by [6] and incorporated into RFC 2481[7]. We study the behavior of ECN for both bulk and transactional transfers. Our experiments show that there is improvement in throughput over NON ECN (TCP employing any of Reno, SACK/FACK or NewReno congestion control) in the case of bulk transfers and substantial improvement for transactional transfers. |
| RFC 2885 |
Megaco Protocol version 0.8
|
|
Summary Publication date: Aug 2000 This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. A merged document presenting the Megaco protocol with the Errata incorporated will be available shortly. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. |
| RFC 2886 |
Megaco Errata
|
|
Summary Publication date: Aug 2000 This document records the errors found in the Megaco/H.248 protocol document [2], along with the changes proposed in the text of that document to resolve them. |
| RFC 2887 |
The Reliable Multicast Design Space for Bulk Data Transfer
|
|
Summary Publication date: Aug 2000 The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions. |
| RFC 2888 |
Secure Remote Access with L2TP
|
|
Summary Publication date: Aug 2000 L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator (LAC) to be near remote clients, while allowing PPP termination server (LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to control Authentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access and IPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote Access Server (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach. |
| RFC 2889 |
Benchmarking Methodology for LAN Switching Devices
|
|
Summary Publication date: Aug 2000 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 2544 [3] 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. A previous document, "Benchmarking Terminology for LAN Switching Devices" [2], defined many of the terms that are used in this document. The terminology document SHOULD be consulted before attempting to make use of this document. |
| RFC 2890 |
Key and Sequence Number Extensions to GRE
|
|
Summary Publication date: Sep 2000 GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. |
| RFC 2891 |
LDAP Control Extension for Server Side Sorting of Search Results
|
|
Summary Publication date: Aug 2000 This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted. Other permissible controls on search operations are not defined in this extension. The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation. |
| RFC 2892 |
The Cisco SRP MAC Layer Protocol
|
|
Summary Publication date: Aug 2000 This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). The primary requirements for SRP are as follows: - Efficient use of bandwidth using: spatial reuse of bandwidth local reuse of bandwidth minimal protocol overhead - Support for priority traffic - Scalability across a large number of nodes or stations attached to a ring - "Plug and play" design without a software based station management transfer (SMT) protocol or ring master negotiation as seen in other ring based MAC protocols [1][2] - Fairness among nodes using the ring - Support for ring based redundancy (error detection, ring wrap, etc.) similar to that found in SONET BLSR specifications. - Independence of physical layer (layer 1) media type. This document defines the terminology used with SRP, packet formats, the protocol format, protocol operation and associated protocol finite state machines. |
| RFC 2893 |
Transition Mechanisms for IPv6 Hosts and Routers
|
|
Summary Publication date: Aug 2000 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933. |
| RFC 2894 |
Router Renumbering for IPv6
|
|
Summary Publication date: Aug 2000 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. |
| RFC 2895 |
Remote Network Monitoring MIB Protocol Identifier Reference
|
|
Summary Publication date: Aug 2000 This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network Monitoring Management Information Base) [RFC 2021]. The definitions for the standard protocol directory base layer identifiers are also included. The first version of the RMON Protocol Identifiers Document [RFC 2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON Protocol Identifier Macros document [RFC 2896] now contains the non-normative portion of that specification. This document obsoletes RFC 2074. |
| RFC 2896 |
Remote Network Monitoring MIB Protocol Identifier Macros
|
|
Summary Publication date: Aug 2000 This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC 2021] and the RMON Protocol Identifier Reference [RFC 2895]. This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC 2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document. The first version of the RMON Protocol Identifiers Document [RFC 2074] has been split into a standards-track Reference portion [RFC 2895], and an "RMON Protocol Identifier Macros", document (this document) which contains the non-normative portion of that specification. |
| RFC 2897 |
Proposal for an MGCP Advanced Audio Package
|
|
Summary Publication date: Aug 2000 This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This event package provides support for the standard IVR (Interactive Voice Response) operations of PlayAnnouncement, PlayCollect, and PlayRecord. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides audio variables, control of audio interruptibility, digit buffer control, special key sequences, and support for reprompting during data collection. It also provides an arbitrary number of user defined qualifiers to be used in resolving complex audio structures. For example, the user could define qualifiers for any or all of the following: language, accent, audio file format, gender, speaker, or customer. |
| RFC 2898 |
PKCS #5: Password-Based Cryptography Specification Version 2.0
|
|
Summary Publication date: Sep 2000 This memo represents a republication of PKCS #5 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys, as in PKCS #8 [25]. It is expected that application standards and implementation profiles based on these specifications may include additional constraints. Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols [4][5][26] are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope. |
| RFC 2899 |
Request for Comments Summary RFC Numbers 2800-2899
|
|
Summary Publication date: May 2001 This RFC is a slightly annotated list of the 100 RFCs from RFC 2800 through RFCs 2899. This is a status report on these RFCs. |
| RFC 2900 |
Internet Official Protocol Standards
|
|
Summary Publication date: Aug 2001 This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
