| |
| RFC 3901 | DNS IPv6 Transport Operational Guidelines |
| |
| Authors: | A. Durand, J. Ihren. |
| Date: | September 2004 |
| Formats: | txt json html |
| Also: | BCP 0091 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3901 |
|
This memo provides guidelines and Best Current Practice for operatingDNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. |
|
| |
| RFC 3902 | The "application/soap+xml" media type |
| |
| Authors: | M. Baker, M. Nottingham. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3902 |
|
This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. |
|
| |
| RFC 3903 | Session Initiation Protocol (SIP) Extension for Event State Publication |
| |
|
|
This document describes an extension to the Session InitiationProtocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information.
The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. |
|
| |
| RFC 3904 | Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks |
| |
| Authors: | C. Huitema, R. Austein, S. Satapati, R. van der Pol. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3904 |
|
This document analyzes issues involved in the transition of"unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. |
|
| |
| RFC 3905 | A Template for IETF Patent Disclosures and Licensing Declarations |
| |
| Authors: | V. See, Ed.. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3905 |
|
This document describes a proposal for one form of a template forIETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. |
|
| |
| RFC 3906 | Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels |
| |
| Authors: | N. Shen, H. Smit. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3906 |
|
This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by TrafficEngineering. |
|
| |
| RFC 3909 | Lightweight Directory Access Protocol (LDAP) Cancel Operation |
| |
| Authors: | K. Zeilenga. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3909 |
|
This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. |
|
| |
| RFC 3910 | The SPIRITS (Services in PSTN requesting Internet Services) Protocol |
| |
| Authors: | V. Gurbani, Ed., A. Brusilovsky, I. Faynberg, J. Gato, H. Lu, M. Unmehopa. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3910 |
|
This document describes the Services in PSTN (Public SwitchedTelephone Network) requesting Internet Services (SPIRITS) protocol.The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the IntelligentNetwork (IN) entities. Internet Call Waiting and Internet Caller-IDDelivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built. |
|
| |
| RFC 3911 | The Session Initiation Protocol (SIP) "Join" Header |
| |
| Authors: | R. Mahy, D. Petrie. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3911 |
|
This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call CenterMonitoring". Note that definition of these example features is non- normative. |
|
| |
| RFC 3912 | WHOIS Protocol Specification |
| |
|
|
This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. |
|
| |
| RFC 3913 | Border Gateway Multicast Protocol (BGMP): Protocol Specification |
| |
| Authors: | D. Thaler. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3913 |
|
This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast"(SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., withUnicast-Prefix-Based Multicast addressing) with different domains.Each of these domains then becomes the root of the shared domain- trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. |
|
| |
| RFC 3914 | Open Pluggable Edge Services (OPES) Treatment of IAB Considerations |
| |
| Authors: | A. Barbir, A. Rousskov. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3914 |
|
IETF Internet Architecture Board (IAB) expressed nine architecture- level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. |
|
| |
| RFC 3915 | Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | S. Hollenbeck. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3915 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by theInternet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. |
|
| |
| RFC 3916 | Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) |
| |
| Authors: | X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed.. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3916 |
|
This document describes base requirements for the Pseudo-WireEmulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, andFrame Relay. Requirements for pseudo-wire emulation of TDM (i.e.,"synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. |
|
| |
| RFC 3917 | Requirements for IP Flow Information Export (IPFIX) |
| |
| Authors: | J. Quittek, T. Zseby, B. Claise, S. Zander. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3917 |
|
This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. |
|
| |
| RFC 3918 | Methodology for IP Multicast Benchmarking |
| |
| Authors: | D. Stopp, B. Hickman. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3918 |
|
The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETFBenchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
The BMWG produces two major classes of documents: BenchmarkingTerminology documents and Benchmarking Methodology documents. TheTerminology documents present the benchmarks and other related terms.The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. |
|
| |
| RFC 3919 | Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS) |
| |
| Authors: | E. Stephan, J. Palet. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3919 |
|
This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895].
This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] 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 RMON related IPv6 and MPLS protocol information. |
|
| |
| RFC 3920 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
|
|
This memo defines the core features of the Extensible Messaging andPresence Protocol (XMPP), a protocol for streaming Extensible MarkupLanguage (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. |
|
| |
| RFC 3921 | Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence |
| |
| Authors: | P. Saint-Andre, Ed.. |
| Date: | October 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6121 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3921 |
|
This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. |
|
| |
| RFC 3922 | Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) |
| |
| Authors: | P. Saint-Andre. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3922 |
|
This memo describes a mapping between the Extensible Messaging andPresence Protocol (XMPP) and the Common Presence and InstantMessaging (CPIM) specifications. |
|
| |
| RFC 3923 | End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3923 |
|
This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). |
|
| |
| RFC 3924 | Cisco Architecture for Lawful Intercept in IP Networks |
| |
| Authors: | F. Baker, B. Foster, C. Sharp. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3924 |
|
For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. |
|
| |
| RFC 3925 | Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) |
| |
| Authors: | J. Littlefield. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3925 |
|
The Dynamic Host Configuration Protocol (DHCP) options for VendorClass and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. |
|
| |
| RFC 3926 | FLUTE - File Delivery over Unidirectional Transport |
| |
| Authors: | T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh. |
| Date: | October 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6726 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3926 |
|
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous LayeredCoding, the base protocol designed for massively scalable multicast distribution. |
|
| |
| RFC 3927 | Dynamic Configuration of IPv4 Link-Local Addresses |
| |
| Authors: | S. Cheshire, B. Aboba, E. Guttman. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3927 |
|
To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as aDynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available.It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. |
|
| |
| RFC 3928 | Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP) |
| |
| Authors: | R. Megginson, Ed., M. Smith, O. Natkovich, J. Parham. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3928 |
|
This document defines the Lightweight Directory Access Protocol(LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. |
|
| |
| RFC 3929 | Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF |
| |
|
|
This document proposes an experimental set of alternative decision- making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. |
|
| |
| RFC 3930 | The Protocol versus Document Points of View in Computer Protocols |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3930 |
|
This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. |
|
| |
| RFC 3931 | Layer Two Tunneling Protocol - Version 3 (L2TPv3) |
| |
|
|
This document describes "version 3" of the Layer Two TunnelingProtocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between twoIP nodes. Additional documents detail the specifics for each data link type being emulated. |
|
| |
| RFC 3932 | The IESG and RFC Editor Documents: Procedures |
| |
|
|
This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.
This document updates procedures described in RFC 2026 and RFC 3710. |
|
| |
| RFC 3933 | A Model for IETF Process Experiments |
| |
| Authors: | J. Klensin, S. Dawkins. |
| Date: | November 2004 |
| Formats: | txt html json |
| Also: | BCP 0093 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3933 |
|
The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification.The first mechanism has often proven to be too lightweight, the second too heavyweight.
This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. |
|
| |
| RFC 3934 | Updates to RFC 2418 Regarding the Management of IETF Mailing Lists |
| |
|
|
This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. |
|
| |
| RFC 3935 | A Mission Statement for the IETF |
| |
|
|
This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. |
|
| |
| RFC 3936 | Procedures for Modifying the Resource reSerVation Protocol (RSVP) |
| |
|
|
This memo specifies procedures for modifying the Resource reSerVationProtocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. |
|
| |
| RFC 3937 | A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC) |
| |
| Authors: | M. Steidl. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3937 |
|
This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International PressTelecommunications Council (IPTC). These resources include XML DataType Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. |
|
| |
| RFC 3938 | Video-Message Message-Context |
| |
|
|
The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message".
A receiving user agent (UA) may use this information as a hint to optimally present the message. |
|
| |
| RFC 3939 | Calling Line Identification for Voice Mail Messages |
| |
| Authors: | G. Parsons, J. Maruszak. |
| Date: | December 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3939 |
|
This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID andCalled_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message.Caller-name provides the name of the person sending the message. |
|
| |
| RFC 3940 | Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5740 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3940 |
|
This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such asTransmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. |
|
| |
| RFC 3941 | Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5401 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3941 |
|
This document discusses the creation of negative-acknowledgment(NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. |
|
| |
| RFC 3942 | Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options |
| |
|
|
This document updates RFC 2132 to reclassify Dynamic HostConfiguration Protocol version 4 (DHCPv4) option codes 128 to 223(decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. |
|
| |
| RFC 3943 | Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) |
| |
|
|
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. |
|
| |
| RFC 3944 | H.350 Directory Services |
| |
| Authors: | T. Johnson, S. Okubo, S. Campos. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3944 |
|
The International Telecommunications Union Standardization Sector(ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store.
Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T RecommendationsH.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. |
|
| |
| RFC 3945 | Generalized Multi-Protocol Label Switching (GMPLS) Architecture |
| |
|
|
Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects(PXCs), optical cross-connects (OXCs), etc. that will use GeneralizedMulti-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
This document describes the architecture of GMPLS. GMPLS extendsMPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. |
|
| |
| RFC 3946 | Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control |
| |
| Authors: | E. Mannie, D. Papadimitriou. |
| Date: | October 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4606 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3946 |
|
This document is a companion to the Generalized Multi-Protocol LabelSwitching (GMPLS) signaling. It defines the Synchronous OpticalNetwork (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. |
|
| |
| RFC 3947 | Negotiation of NAT-Traversal in the IKE |
| |
| Authors: | T. Kivinen, B. Swander, A. Huttunen, V. Volpe. |
| Date: | January 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3947 |
|
This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes inInternet Key Exchange (IKE). |
|
| |
| RFC 3948 | UDP Encapsulation of IPsec ESP Packets |
| |
| Authors: | A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3948 |
|
This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets insideUDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used withInternet Key Exchange (IKE). |
|
| |
| RFC 3949 | File Format for Internet Fax |
| |
| Authors: | R. Buckley, D. Venable, L. McIntyre, G. Parsons, J. Rafferty. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 2301 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 3949 |
|
This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.
This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the InternationalTelecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group(JBIG) profiles (Profiles S, F, J) for black-and-white fax and baseJPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C,L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. |
|
| |
| RFC 3950 | Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration |
| |
| Authors: | L. McIntyre, G. Parsons, J. Rafferty. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 3250 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 3950 |
|
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 3951 | Internet Low Bit Rate Codec (iLBC) |
| |
| Authors: | S. Andersen, A. Duric, H. Astrom, R. Hagen, W. Kleijn, J. Linden. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3951 |
|
This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound(GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. |
|
| |
| RFC 3952 | Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech |
| |
| Authors: | A. Duric, S. Andersen. |
| Date: | December 2004 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3952 |
|
This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME andSession Description Protocol (SDP). |
|
| |
| RFC 3953 | Telephone Number Mapping (ENUM) Service Registration for Presence Services |
| |
|
|
This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning presURIs in ENUM. |
|
| |
| RFC 3954 | Cisco Systems NetFlow Services Export Version 9 |
| |
| Authors: | B. Claise, Ed.. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3954 |
|
This document specifies the data export format for version 9 of CiscoSystems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. |
|
| |
| RFC 3955 | Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) |
| |
| Authors: | S. Leinen. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3955 |
|
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. |
|
| |
| RFC 3956 | Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address |
| |
|
|
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. |
|
| |
| RFC 3957 | Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 |
| |
| Authors: | C. Perkins, P. Calhoun. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3957 |
|
Authentication, Authorization, and Accounting (AAA) servers, such asRADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers.Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA SecurityAssociation with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility SecurityAssociations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to createMobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. |
|
| |
| RFC 3958 | Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) |
| |
| Authors: | L. Daigle, A. Newton. |
| Date: | January 2005 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3958 |
|
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines aDynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. |
|
| |
| RFC 3959 | The Early Session Disposition Type for the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3959 |
|
This document defines a new disposition type (early-session) for theContent-Disposition header field in the Session Initiation Protocol(SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. |
|
| |
| RFC 3960 | Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, H. Schulzrinne. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3960 |
|
This document describes how to manage early media in the SessionInitiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. |
|
| |
| RFC 3961 | Encryption and Checksum Specifications for Kerberos 5 |
| |
|
|
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". |
|
| |
| RFC 3962 | Advanced Encryption Standard (AES) Encryption for Kerberos 5 |
| |
|
|
The United States National Institute of Standards and Technology(NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the oldData Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. |
|
| |
| RFC 3963 | Network Mobility (NEMO) Basic Support Protocol |
| |
| Authors: | V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. |
| Date: | January 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3963 |
|
This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. |
|
| |
| RFC 3964 | Security Considerations for 6to4 |
| |
| Authors: | P. Savola, C. Patel. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3964 |
|
The IPv6 interim mechanism 6to4 (RFC3056) uses automaticIPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. |
|
| |
| RFC 3965 | A Simple Mode of Facsimile Using Internet Mail |
| |
| Authors: | K. Toyoda, H. Ohno, J. Murai, D. Wing. |
| Date: | December 2004 |
| Formats: | txt html json |
| Obsoletes: | RFC 2305 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 3965 |
|
This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow.The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet MailExtensions (MIME), and Tagged Image File Format (TIFF) for Facsimile.It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.
This document is a revision of RFC 2305. There have been no technical changes. |
|
| |
| RFC 3966 | The tel URI for Telephone Numbers |
| |
|
|
This document specifies the URI (Uniform Resource Identifier) scheme"tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. |
|
| |
| RFC 3967 | Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level |
| |
|
|
IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards orIETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. |
|
| |
| RFC 3968 | The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) |
| |
|
|
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. |
|
| |
| RFC 3969 | The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) |
| |
|
|
This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS UniformResource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. |
|
| |
| RFC 3970 | A Traffic Engineering (TE) MIB |
| |
|
|
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 for Traffic Engineered(TE) Tunnels; for example, Multi-Protocol Label Switched Paths. |
|
| |
| RFC 3971 | SEcure Neighbor Discovery (SEND) |
| |
|
|
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms forNDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. |
|
| |
| RFC 3972 | Cryptographically Generated Addresses (CGA) |
| |
|
|
This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. |
|
| |
| RFC 3973 | Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Dense Mode(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. |
|
| |
| RFC 3974 | SMTP Operational Experience in Mixed IPv4/v6 Environments |
| |
| Authors: | M. Nakamura, J. Hagino. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3974 |
|
This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.
This document does not define any new protocol. |
|
| |
| RFC 3975 | OMA-IETF Standardization Collaboration |
| |
| Authors: | G. Huston, Ed., I. Leuca, Ed.. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3975 |
|
This document describes the standardization collaboration between theOpen Mobile Alliance (OMA) and the Internet Engineering Task Force(IETF). |
|
| |
| RFC 3976 | Interworking SIP and Intelligent Network (IN) Applications |
| |
| Authors: | V. K. Gurbani, F. Haerens, V. Rastogi. |
| Date: | January 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3976 |
|
Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from SessionInitiation Protocol (SIP) endpoints for an IP-host-to-phone call.The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in thePSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). |
|
| |
| RFC 3977 | Network News Transfer Protocol (NNTP) |
| |
|
|
The Network News Transfer Protocol (NNTP) has been in use in theInternet for a decade, and remains one of the most popular protocols(by volume) in use today. This document is a replacement forRFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. |
|
| |
| RFC 3978 | IETF Rights in Contributions |
| |
|
|
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC2026. |
|
| |
| RFC 3979 | Intellectual Property Rights in IETF Technology |
| |
|
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet.This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 ofRFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC2028, for all purposes, including reference [2] in RFC 2418. |
|
| |
| RFC 3980 | T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names |
| |
|
|
Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information TechnologyStandards (INCITS) T11 - Fibre Channel (FC) protocols and used bySerial Attached SCSI (SAS). This document updates RFC 3720. |
|
| |
| RFC 3981 | IRIS: The Internet Registry Information Service (IRIS) Core Protocol |
| |
|
|
This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in theExtensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. |
|
| |
| RFC 3982 | IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS) |
| |
| Authors: | A. Newton, M. Sanz. |
| Date: | January 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3982 |
|
This document describes an Internet Registry Information Service(IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. |
|
| |
| RFC 3983 | Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) |
| |
|
|
This document specifies how to use the Blocks Extensible ExchangeProtocol (BEEP) as the application transport substrate for theInternet Registry Information Service (IRIS). |
|
| |
| RFC 3984 | RTP Payload Format for H.264 Video |
| |
| Authors: | S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6184 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3984 |
|
This memo describes an RTP Payload format for the ITU-TRecommendation H.264 video codec and the technically identicalISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network AbstractionLayer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, toInternet video streaming with interleaved transmission, to high bit- rate video-on-demand. |
|
| |
| RFC 3985 | Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture |
| |
| Authors: | S. Bryant, Ed., P. Pate, Ed.. |
| Date: | March 2005 |
| Formats: | txt html json |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3985 |
|
This document describes an architecture for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of services such asFrame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. |
|
| |
| RFC 3986 | Uniform Resource Identifier (URI): Generic Syntax |
| |
|
|
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on theInternet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. |
|
| |
| RFC 3987 | Internationalized Resource Identifiers (IRIs) |
| |
| Authors: | M. Duerst, M. Suignard. |
| Date: | January 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3987 |
|
This document defines a new protocol element, the InternationalizedResource Identifier (IRI), as a complement to the Uniform ResourceIdentifier (URI). An IRI is a sequence of characters from theUniversal Character Set (Unicode/ISO 10646). A mapping from IRIs toURIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.
The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. |
|
| |
| RFC 3988 | Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol |
| |
| Authors: | B. Black, K. Kompella. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3988 |
|
Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the LabelDistribution Protocol (LDP) does not have the ability to signal theMTU for a Label Switched Path (LSP) to the ingress Label SwitchingRouter (LSR). In the absence of this functionality, the MTU for eachLSP must be statically configured by network operators or by equivalent off-line mechanisms.
This document specifies experimental extensions to LDP in support ofLSP MTU discovery. |
|
| |
| RFC 3989 | Middlebox Communications (MIDCOM) Protocol Semantics |
| |
| Authors: | M. Stiemerling, J. Quittek, T. Taylor. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5189 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3989 |
|
This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from theMIDCOM requirements, from the MIDCOM framework, and from working group decisions. |
|
| |
| RFC 3990 | Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement |
| |
| Authors: | B. O'Hara, P. Calhoun, J. Kempf. |
| Date: | February 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3990 |
|
This document describes the Configuration and Provisioning forWireless Access Points (CAPWAP) problem statement. |
|
| |
| RFC 3991 | Media Gateway Control Protocol (MGCP) Redirect and Reset Package |
| |
| Authors: | B. Foster, F. Andreasen. |
| Date: | February 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3991 |
|
The base Media Gateway Control Protocol (MGCP) specification (RFC3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. |
|
| |
| RFC 3992 | Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism |
| |
| Authors: | B. Foster, F. Andreasen. |
| Date: | February 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3992 |
|
A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. |
|
| |
| RFC 3993 | Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option |
| |
| Authors: | R. Johnson, T. Palaniappan, M. Stapp. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3993 |
|
This memo defines a new Subscriber-ID suboption for the Dynamic HostConfiguration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable"Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. |
|
| |
| RFC 3994 | Indication of Message Composition for Instant Messaging |
| |
| Authors: | H. Schulzrinne. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3994 |
|
In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. |
|
| |
| RFC 3995 | Internet Printing Protocol (IPP): Event Notifications and Subscriptions |
| |
|
|
This document describes an OPTIONAL extension to the InternetPrinting Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).This extension allows a client to subscribe to printing relatedEvents. Subscriptions are modeled as Subscription Objects. TheSubscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or PullDelivery Method (i.e., protocol).
A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting aJob with subscription information. A client associates SubscriptionObjects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for SubscriptionObjects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. |
|
| |
| RFC 3996 | Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications |
| |
| Authors: | R. Herriot, T. Hastings, H. Lewis. |
| Date: | March 2005 |
| Formats: | txt json html |
| Updates: | RFC 2911 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3996 |
|
This document describes an extension to the Internet PrintingProtocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the"Internet Printing Protocol (IPP): Event Notifications andSubscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. TheNotification Recipient, acting as a client, fetches (pulls) EventNotifications by using the Get-Notifications operation defined in this document. |
|
| |
| RFC 3997 | Internet Printing Protocol (IPP): Requirements for IPP Notifications |
| |
| Authors: | T. Hastings, Ed., R. K. deBry, H. Lewis. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3997 |
|
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPPService. |
|
| |
| RFC 3998 | Internet Printing Protocol (IPP): Job and Printer Administrative Operations |
| |
| Authors: | C. Kugler, H. Lewis, T. Hastings, Ed.. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3998 |
|
This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet PrintingProtocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in.
Printer operations: Job operations:Enable-Printer and Disable-Printer Reprocess-JobPause-Printer-After-Current-Job Cancel-Current-JobHold-New-Jobs and Release-Held-New-Jobs Suspend-Current-JobDeactivate-Printer and Activate-Printer Resume-JobRestart-Printer Promote-JobShutdown-Printer and Startup-Printer Schedule-Job-After |
|
