| |
| RFC 3201 | Definitions of Managed Objects for Circuit to Interface Translation |
| |
| Authors: | R. Steinberger, O. Nicklass. |
| Date: | January 2002 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3201 |
|
This memo defines an extension 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 insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existingMIB modules. |
|
| |
| RFC 3202 | Definitions of Managed Objects for Frame Relay Service Level Definitions |
| |
| Authors: | R. Steinberger, O. Nicklass. |
| Date: | January 2002 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3202 |
|
This memo defines an extension 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 FrameRelay Service Level Definitions. |
|
| |
| RFC 3203 | DHCP reconfigure extension |
| |
| Authors: | Y. T'Joens, C. Hublet, P. De Schrijver. |
| Date: | December 2001 |
| Formats: | txt html json |
| Updated by: | RFC 6704 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3203 |
|
This document defines extensions to DHCP (Dynamic Host ConfigurationProtocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described. |
|
| |
| RFC 3204 | MIME media types for ISUP and QSIG Objects |
| |
| Authors: | E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun. |
| Date: | December 2001 |
| Formats: | txt json html |
| Updated by: | RFC 3459, RFC 5621 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3204 |
|
This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identifyISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. |
|
| |
| RFC 3205 | On the use of HTTP as a Substrate |
| |
|
|
Recently there has been widespread interest in using HypertextTransfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. |
|
| |
| RFC 3206 | The SYS and AUTH POP Response Codes |
| |
| Authors: | R. Gellens. |
| Date: | February 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3206 |
|
This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. |
|
| |
| RFC 3207 | SMTP Service Extension for Secure SMTP over Transport Layer Security |
| |
|
|
This document describes an extension to the SMTP (Simple MailTransfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. |
|
| |
| RFC 3208 | PGM Reliable Transport Protocol Specification |
| |
| Authors: | T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano. |
| Date: | December 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3208 |
|
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. |
|
| |
| RFC 3209 | RSVP-TE: Extensions to RSVP for LSP Tunnels |
| |
| Authors: | D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. |
| Date: | December 2001 |
| Formats: | txt json html |
| Updated by: | RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3209 |
|
This document describes the use of RSVP (Resource ReservationProtocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.
We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. |
|
| |
| RFC 3210 | Applicability Statement for Extensions to RSVP for LSP-Tunnels |
| |
| Authors: | D. Awduche, A. Hannan, X. Xiao. |
| Date: | December 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3210 |
|
This memo discusses the applicability of "Extensions to RSVP(Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. |
|
| |
| RFC 3211 | Password-based Encryption for CMS |
| |
|
|
This document provides a method of encrypting data using user- supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. |
|
| |
| RFC 3212 | Constraint-Based LSP Setup using LDP |
| |
| Authors: | B. Jamoussi, Ed., L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A. Malis. |
| Date: | January 2002 |
| Formats: | txt html json |
| Updated by: | RFC 3468, RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3212 |
|
This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol).
This specification proposes an end-to-end setup mechanism of a CR-LSP initiated by the ingress LSR (Label Switching Router). We also specify mechanisms to provide means for reservation of resources using LDP. |
|
| |
| RFC 3213 | Applicability Statement for CR-LDP |
| |
| Authors: | J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright. |
| Date: | January 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3213 |
|
This document discusses the applicability of Constraint-Based LSPSetup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. |
|
| |
| RFC 3214 | LSP Modification Using CR-LDP |
| |
| Authors: | J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3214 |
|
This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-basedRouted Label Switched Paths) using CR-LDP (Constraint-based RoutedLabel Distribution Protocol) without service interruption. After aCR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP. The LSP modification feature can be supported by CR-LDP by use of the _modify_value for the _action indicator flag_ in the LSPID TLV. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved. |
|
| |
| RFC 3215 | LDP State Machine |
| |
| Authors: | C. Boscher, P. Cheval, L. Wu, E. Gray. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3215 |
|
This document provides state machine tables for ATM (AsynchronousTransfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations.
We begin in section 1 by defining a list of terminologies. Then in section 2, we propose two sets of state machine tables for ATM switchLSRs that use downstream-on-demand mode, one method can be used for non-vc merge capable ATM LSRs, while the other one can be used for the vc-merge capable ATM LSRs. In section 3, we provides a state machine for downstream unsolicited mode ATM LSRs.
We focus on the LDP state machines and the associated control blocks used for establishing and maintaining LSPs. We do not describe state machines for the "LDP controller" that is in charge of LDP session initialization, address mapping messages management, routing interface, etc. that is defined in the LDP specification.
Even though the state machines in this document are specific forATM-LSR, they can be easily adapted for other types of LSRs. |
|
| |
| RFC 3216 | SMIng Objectives |
| |
| Authors: | C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss. |
| Date: | December 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3216 |
|
This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations.
The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives. |
|
| |
| RFC 3217 | Triple-DES and RC2 Key Wrapping |
| |
| Authors: | R. Housley. |
| Date: | December 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3217 |
|
This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. These key wrap algorithms were originally published in section 12.6 of RFC 2630. They are republished since these key wrap algorithms have been found to be useful in contexts beyond those supported by RFC 2630. |
|
| |
| RFC 3218 | Preventing the Million Message Attack on Cryptographic Message Syntax |
| |
| Authors: | E. Rescorla. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3218 |
|
This memo describes a strategy for resisting the Million MessageAttack. |
|
| |
| RFC 3219 | Telephony Routing over IP (TRIP) |
| |
| Authors: | J. Rosenberg, H. Salama, M. Squire. |
| Date: | January 2002 |
| Formats: | txt json html |
| Updated by: | RFC 8602 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3219 |
|
This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations.TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol.
The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4. |
|
| |
| RFC 3220 | IP Mobility Support for IPv4 |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 3221 | Commentary on Inter-Domain Routing in the Internet |
| |
| Authors: | G. Huston. |
| Date: | December 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3221 |
|
This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined.
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. |
|
| |
| RFC 3222 | Terminology for Forwarding Information Base (FIB) based Router Performance |
| |
| Authors: | G. Trotter. |
| Date: | December 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3222 |
|
This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. |
|
| |
| RFC 3224 | Vendor Extensions for Service Location Protocol, Version 2 |
| |
|
|
This document specifies how the features of the Service LocationProtocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The ServiceLocation Protocol." |
|
| |
| RFC 3225 | Indicating Resolver Support of DNSSEC |
| |
|
|
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. |
|
| |
| RFC 3226 | DNSSEC and IPv6 A6 aware server/resolver message size requirements |
| |
|
|
This document mandates support for EDNS0 (Extension Mechanisms forDNS) in DNS entities claiming to support either DNS SecurityExtensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updatesRFC 2535 and RFC 2874, by adding new requirements. |
|
| |
| RFC 3227 | Guidelines for Evidence Collection and Archiving |
| |
| Authors: | D. Brezinski, T. Killalea. |
| Date: | February 2002 |
| Formats: | txt html json |
| Also: | BCP 0055 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3227 |
|
A "security incident" as defined in the "Internet Security Glossary",RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident.
If evidence collection is done correctly, it is much more useful in apprehending the attacker, and stands a much greater chance of being admissible in the event of a prosecution. |
|
| |
| RFC 3228 | IANA Considerations for IPv4 Internet Group Management Protocol (IGMP) |
| |
|
|
This memo requests that the IANA create a registry for fields in theIGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. |
|
| |
| RFC 3229 | Delta encoding in HTTP |
| |
| Authors: | J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3229 |
|
This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1.
Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding." |
|
| |
| RFC 3230 | Instance Digests in HTTP |
| |
| Authors: | J. Mogul, A. Van Hoff. |
| Date: | January 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3230 |
|
HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1(Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. |
|
| |
| RFC 3231 | Definitions of Managed Objects for Scheduling Management Operations |
| |
| Authors: | D. Levi, J. Schoenwaelder. |
| Date: | January 2002 |
| Formats: | txt json html |
| Obsoletes: | RFC 2591 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3231 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times.
This document obsoletes RFC 2591. |
|
| |
| RFC 3232 | Assigned Numbers: RFC 1700 is Replaced by an On-line Database |
| |
|
|
This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. |
|
| |
| RFC 3233 | Defining the IETF |
| |
| Authors: | P. Hoffman, S. Bradner. |
| Date: | February 2002 |
| Formats: | txt html json |
| Also: | BCP 0058 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3233 |
|
This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many importantIETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. |
|
| |
| RFC 3234 | Middleboxes: Taxonomy and Issues |
| |
| Authors: | B. Carpenter, S. Brim. |
| Date: | February 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3234 |
|
This document is intended as part of an IETF discussion about"middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. |
|
| |
| RFC 3235 | Network Address Translator (NAT)-Friendly Application Design Guidelines |
| |
| Authors: | D. Senie. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3235 |
|
This document discusses those things that application designers might wish to consider when designing new protocols. While many commonInternet applications will operate cleanly in the presence of NetworkAddress Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). |
|
| |
| RFC 3236 | The 'application/xhtml+xml' Media Type |
| |
| Authors: | M. Baker, P. Stark. |
| Date: | January 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3236 |
|
This document defines the 'application/xhtml+xml' MIME media type forXHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers'text/html'. |
|
| |
| RFC 3237 | Requirements for Reliable Server Pooling |
| |
| Authors: | M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman. |
| Date: | January 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3237 |
|
This document defines a basic set of requirements for reliable server pooling.
The goal of Reliable Server Pooling (RSerPool) is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. |
|
| |
| RFC 3238 | IAB Architectural and Policy Considerations for Open Pluggable Edge Services |
| |
| Authors: | S. Floyd, L. Daigle. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3238 |
|
This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering ofOpen Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. |
|
| |
| RFC 3239 | Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations |
| |
| Authors: | C. Kugler, H. Lewis, T. Hastings. |
| Date: | February 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3239 |
|
This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet PrintingProtocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects.The remaining operations operate on a new Device object that more closely models a single output device. |
|
| |
| RFC 3240 | Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration |
| |
| Authors: | D. Clunie, E. Cordonnier. |
| Date: | February 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3240 |
|
This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine).The baseline encoding is defined by the DICOM Standards Committee in"Digital Imaging and Communications in Medicine". |
|
| |
| RFC 3241 | Robust Header Compression (ROHC) over PPP |
| |
|
|
This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over thePoint-to-Point Protocol (PPP). It defines extensions to the PPPControl Protocols for IPv4 and IPv6. |
|
| |
| RFC 3242 | RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP |
| |
| Authors: | L-E. Jonsson, G. Pelletier. |
| Date: | April 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4362 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3242 |
|
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. |
|
| |
| RFC 3243 | RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression |
| |
| Authors: | L-E. Jonsson. |
| Date: | April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3243 |
|
This document contains requirements for the 0-byte IP/UDP/RTP(Internet Protocol/User Datagram Protocol/Real-Time TransportProtocol) header compression scheme to be developed by the RobustHeader Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general. |
|
| |
| RFC 3244 | Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols |
| |
| Authors: | M. Swift, J. Trostle, J. Brezak. |
| Date: | February 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3244 |
|
This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. |
|
| |
| RFC 3245 | The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) |
| |
| Authors: | J. Klensin, Ed., IAB. |
| Date: | March 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3245 |
|
RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB.It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T StudyGroup 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community. |
|
| |
| RFC 3246 | An Expedited Forwarding PHB (Per-Hop Behavior) |
| |
| Authors: | B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis. |
| Date: | March 2002 |
| Formats: | txt json html |
| Obsoletes: | RFC 2598 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3246 |
|
This document defines a PHB (per-hop behavior) called ExpeditedForwarding (EF). The PHB is a basic building block in theDifferentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. |
|
| |
| RFC 3247 | Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) |
| |
| Authors: | A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan. |
| Date: | March 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3247 |
|
This document was written during the process of clarification ofRFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revisedEF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. |
|
| |
| RFC 3248 | A Delay Bound alternative revision of RFC 2598 |
| |
| Authors: | G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein. |
| Date: | March 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3248 |
|
For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At thePittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF)Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in theDiffServ group. At the San Diego IETF meeting in December 2000 theDiffServ working group decided to pursue an alternative re-expression of the EF PHB. |
|
| |
| RFC 3249 | Implementers Guide for Facsimile Using Internet Mail |
| |
| Authors: | V. Cancio, M. Moldovan, H. Tamura, D. Wing. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3249 |
|
This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. |
|
| |
| RFC 3250 | Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration |
| |
| Authors: | L. McIntyre, G. Parsons, J. Rafferty. |
| Date: | September 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3250 |
|
This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax and its extensions. |
|
| |
| RFC 3251 | Electricity over IP |
| |
| Authors: | B. Rajagopalan. |
| Date: | 1 April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3251 |
|
Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question.
This document has also been written as a public service. The "Sub-IP" area has been formed to give equal opportunity to those working on technologies outside of traditional IP networking to write complicated IETF documents. There are possibly many who are wondering how to exploit this opportunity and attain high visibility.Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS control for random technologies) as highly amenable for producing a countless number of unimplementable documents. This document illustrates the key ingredients that go into producing any "foo- over-MPLS" document and may be used as a template for all such work. |
|
| |
| RFC 3252 | Binary Lexical Octet Ad-hoc Transport |
| |
| Authors: | H. Kennedy. |
| Date: | 1 April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3252 |
|
This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. |
|
| |
| RFC 3253 | Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) |
| |
| Authors: | G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead. |
| Date: | March 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3253 |
|
This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning. |
|
| |
| RFC 3254 | Definitions for talking about directories |
| |
| Authors: | H. Alvestrand. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3254 |
|
When discussing systems for making information accessible through theInternet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use.
For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability.
This document discusses one group of such systems which is known under the term, "directories". |
|
| |
| RFC 3255 | Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads |
| |
| Authors: | N. Jones, C. Murton. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3255 |
|
This document describes an extension to the mapping of Point-to-PointProtocol (PPP) into Synchronous Optical NETwork/Synchronous DigitalHierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. |
|
| |
| RFC 3256 | The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option |
| |
| Authors: | D. Jones, R. Woundy. |
| Date: | April 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3256 |
|
This document proposes a new sub-option to the DHCP (Dynamic HostConfiguration Protocol) Relay Agent Information Option. This new sub-option is for use with DOCSIS (Data-Over-Cable Service InterfaceSpecifications) cable modems and describes a "device class" to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signaling, and the RelayAgent forwards the device class information to the DHCP Server which can then make a policy decision based on it. |
|
| |
| RFC 3257 | Stream Control Transmission Protocol Applicability Statement |
| |
| Authors: | L. Coene. |
| Date: | April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3257 |
|
This document describes the applicability of the Stream ControlTransmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) &Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. |
|
| |
| RFC 3258 | Distributing Authoritative Name Servers via Shared Unicast Addresses |
| |
| Authors: | T. Hardie. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3258 |
|
This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. |
|
| |
| RFC 3259 | A Message Bus for Local Coordination |
| |
| Authors: | J. Ott, C. Perkins, D. Kutscher. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3259 |
|
The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. |
|
| |
| RFC 3260 | New Terminology and Clarifications for Diffserv |
| |
|
|
This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC2597. When RFCs 2474 and 2597 advance on the standards track, andRFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the newRFCs. |
|
| |
| RFC 3261 | SIP: Session Initiation Protocol |
| |
| Authors: | J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. |
| Date: | June 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 2543 |
| Updated by: | RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3261 |
|
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types.SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. |
|
| |
| RFC 3262 | Reliability of Provisional Responses in Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | June 2002 |
| Formats: | txt json html |
| Obsoletes: | RFC 2543 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3262 |
|
This document specifies an extension to the Session InitiationProtocol (SIP) providing reliable provisional response messages.This extension uses the option tag 100rel and defines the ProvisionalResponse ACKnowledgement (PRACK) method. |
|
| |
| RFC 3263 | Session Initiation Protocol (SIP): Locating SIP Servers |
| |
|
|
The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. |
|
| |
| RFC 3264 | An Offer/Answer Model with Session Description Protocol (SDP) |
| |
|
|
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol(SIP). |
|
| |
| RFC 3265 | Session Initiation Protocol (SIP)-Specific Event Notification |
| |
|
|
This document describes an extension to the Session InitiationProtocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.
Concrete uses of the mechanism described in this document may be standardized in the future.
Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. |
|
| |
| RFC 3266 | Support for IPv6 in Session Description Protocol (SDP) |
| |
|
|
This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP).Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. |
|
| |
| RFC 3267 | Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs |
| |
| Authors: | J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. |
| Date: | June 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4867 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3267 |
|
This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both theRTP payload format and the storage format. |
|
| |
| RFC 3268 | Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) |
| |
|
|
This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) areRC2, RC4, International Data Encryption Algorithm (IDEA), DataEncryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. |
|
| |
| RFC 3269 | Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents |
| |
| Authors: | R. Kermode, L. Vicisano. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3269 |
|
This document provides general guidelines to assist the authors ofReliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. |
|
| |
| RFC 3270 | Multi-Protocol Label Switching (MPLS) Support of Differentiated Services |
| |
| Authors: | F. Le Faucheur, Ed., L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. |
| Date: | May 2002 |
| Formats: | txt html json |
| Updates: | RFC 3032 |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3270 |
|
This document defines a flexible solution for support ofDifferentiated Services (Diff-Serv) over Multi-Protocol LabelSwitching (MPLS) networks.
This solution allows the MPLS network administrator to select howDiff-Serv Behavior Aggregates (BAs) are mapped onto Label SwitchedPaths (LSPs) so that he/she can best match the Diff-Serv, TrafficEngineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. |
|
| |
| RFC 3271 | The Internet is for Everyone |
| |
| Authors: | V. Cerf. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3271 |
|
This document expresses the Internet Society's ideology that theInternet really is for everyone. However, it will only be such if we make it so. |
|
| |
| RFC 3272 | Overview and Principles of Internet Traffic Engineering |
| |
| Authors: | D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. |
| Date: | May 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9522 |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3272 |
|
This memo describes the principles of Traffic Engineering (TE) in theInternet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. |
|
| |
| RFC 3273 | Remote Network Monitoring Management Information Base for High Capacity Networks |
| |
|
|
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 (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. |
|
| |
| RFC 3274 | Compressed Data Content Type for Cryptographic Message Syntax (CMS) |
| |
| Authors: | P. Gutmann. |
| Date: | June 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3274 |
|
This document defines a format for using compressed data as aCryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). |
|
| |
| RFC 3275 | (Extensible Markup Language) XML-Signature Syntax and Processing |
| |
| Authors: | D. Eastlake 3rd, J. Reagle, D. Solo. |
| Date: | March 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 3075 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 3275 |
|
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. |
|
| |
| RFC 3276 | Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing |
| |
|
|
This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-PairHigh-Speed Digital Subscriber Line (SHDSL) interfaces. |
|
| |
| RFC 3277 | Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance |
| |
| Authors: | D. McPherson. |
| Date: | April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3277 |
|
This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. |
|
| |
| RFC 3278 | Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Blake-Wilson, D. Brown, P. Lambert. |
| Date: | April 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5753 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3278 |
|
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.
The readers attention is called to the Intellectual Property Rights section at the end of this document. |
|
| |
| RFC 3279 | Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in theInternet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs).Certificates include the public key of the named subject. |
|
| |
| RFC 3280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This memo profiles the X.509 v3 certificate and X.509 v2 CertificateRevocation List (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. AnASN.1 module and examples are provided in the appendices. |
|
| |
| RFC 3281 | An Internet Attribute Certificate Profile for Authorization |
| |
| Authors: | S. Farrell, R. Housley. |
| Date: | April 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5755 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3281 |
|
This specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. |
|
| |
| RFC 3282 | Content Language Headers |
| |
|
|
This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC822-like headers, like MIME body parts or Web documents, and an"Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. |
|
| |
| RFC 3283 | Guide to Internet Calendaring |
| |
| Authors: | B. Mahoney, G. Babics, A. Taler. |
| Date: | June 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3283 |
|
This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), andRFC 2447 (iMIP). The work in progress addressed is "Calendar AccessProtocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. |
|
| |
| RFC 3284 | The VCDIFF Generic Differencing and Compression Data Format |
| |
| Authors: | D. Korn, J. MacDonald, J. Mogul, K. Vo. |
| Date: | June 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3284 |
|
This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. |
|
| |
| RFC 3285 | Using Microsoft Word to create Internet Drafts and RFCs |
| |
|
|
This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. |
|
| |
| RFC 3286 | An Introduction to the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | L. Ong, J. Yoakum. |
| Date: | May 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3286 |
|
This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. |
|
| |
| RFC 3287 | Remote Monitoring MIB Extensions for Differentiated Services |
| |
| Authors: | A. Bierman. |
| Date: | July 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3287 |
|
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 monitoringDifferentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2(Remote Network Monitoring Management Version 2) MIB. |
|
| |
| RFC 3288 | Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) |
| |
| Authors: | E. O'Tuathail, M. Rose. |
| Date: | June 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4227 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3288 |
|
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network.
The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. |
|
| |
| RFC 3289 | Management Information Base for the Differentiated Services Architecture |
| |
| Authors: | F. Baker, K. Chan, A. Smith. |
| Date: | May 2002 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3289 |
|
This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated ServicesArchitecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. |
|
| |
| RFC 3290 | An Informal Management Model for Diffserv Routers |
| |
| Authors: | Y. Bernet, S. Blake, D. Grossman, A. Smith. |
| Date: | May 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3290 |
|
This document proposes an informal management model of DifferentiatedServices (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements(e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers.It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. |
|
| |
| RFC 3291 | Textual Conventions for Internet Network Addresses |
| |
| Authors: | M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. |
| Date: | May 2002 |
| Formats: | txt html json |
| Obsoletes: | RFC 2851 |
| Obsoleted by: | RFC 4001 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3291 |
|
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations.
This document obsoletes RFC 2851. |
|
| |
| RFC 3292 | General Switch Management Protocol (GSMP) V3 |
| |
| Authors: | A. Doria, F. Hellstrand, K. Sundell, T. Worster. |
| Date: | June 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3292 |
|
This document describes the General Switch Management ProtocolVersion 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch.The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources andQoS features. |
|
| |
| RFC 3293 | General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP) |
| |
| Authors: | T. Worster, A. Doria, J. Buerkle. |
| Date: | June 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3293 |
|
This memo specifies the encapsulation of GSMP (General SwitchManagement Protocol) packets in ATM (Asynchronous Transfer Mode),Ethernet and TCP (Transmission Control Protocol). |
|
| |
| RFC 3294 | General Switch Management Protocol (GSMP) Applicability |
| |
| Authors: | A. Doria, K. Sundell. |
| Date: | June 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3294 |
|
This memo provides an overview of the GSMP (General Switch ManagementProtocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in anATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. |
|
| |
| RFC 3295 | Definitions of Managed Objects for the General Switch Management Protocol (GSMP) |
| |
| Authors: | H. Sjostrand, J. Buerkle, B. Srinivasan. |
| Date: | June 2002 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3295 |
|
This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for theGeneral Switch Management Protocol (GSMP). |
|
| |
| RFC 3296 | Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories |
| |
| Authors: | K. Zeilenga. |
| Date: | July 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3296 |
|
This document details schema and protocol elements for representing and managing named subordinate references in Lightweight DirectoryAccess Protocol (LDAP) Directories. |
|
| |
| RFC 3297 | Content Negotiation for Messaging Services based on Email |
| |
| Authors: | G. Klyne, R. Iwazaki, D. Crocker. |
| Date: | July 2002 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3297 |
|
This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email.
Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet email. |
|
| |
| RFC 3298 | Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements |
| |
| Authors: | I. Faynberg, J. Gato, H. Lu, L. Slutsman. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3298 |
|
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public SwitchedTelephone Network (PSTN) and necessitate the interactions between thePSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, andInternet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlierIETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. |
|
| |
| RFC 3299 | Request for Comments Summary RFC Numbers 3200-3299 |
| |
| Authors: | S. Ginoza. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3299 |
|
|
|
