| |
| RFC 3600 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3601 | Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses |
| |
| Authors: | C. Allocchio. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3601 |
|
This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply. |
|
| |
| RFC 3602 | The AES-CBC Cipher Algorithm and Its Use with IPsec |
| |
| Authors: | S. Frankel, R. Glenn, S. Kelly. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3602 |
|
This document describes the use of the Advanced Encryption Standard(AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). |
|
| |
| RFC 3603 | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
| Authors: | W. Marshall, Ed., F. Andreasen, Ed.. |
| Date: | October 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5503 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3603 |
|
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
|
| |
| RFC 3604 | Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) |
| |
| Authors: | H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3604 |
|
This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification. |
|
| |
| RFC 3605 | Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) |
| |
| Authors: | C. Huitema. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3605 |
|
The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. |
|
| |
| RFC 3606 | Definitions of Supplemental Managed Objects for ATM Interface |
| |
| Authors: | F. Ly, M. Noto, A. Smith, E. Spiegel, K. Tesink. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3606 |
|
This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, theATM-MIB, to provide additional support for the management of ATMSwitched Virtual Connections (SVCs) and ATM Permanent VirtualConnections (PVCs). |
|
| |
| RFC 3607 | Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool |
| |
| Authors: | M. Leech. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3607 |
|
This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences. |
|
| |
| RFC 3608 | Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration |
| |
| Authors: | D. Willis, B. Hoeneisen. |
| Date: | October 2003 |
| Formats: | txt json html |
| Updated by: | RFC 5630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3608 |
|
This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain. |
|
| |
| RFC 3609 | Tracing Requirements for Generic Tunnels |
| |
| Authors: | R. Bonica, K. Kompella, D. Meyer. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3609 |
|
This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding.
The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers.Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by anIP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path. |
|
| |
| RFC 3610 | Counter with CBC-MAC (CCM) |
| |
| Authors: | D. Whiting, R. Housley, N. Ferguson. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3610 |
|
Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES). |
|
| |
| RFC 3611 | RTP Control Protocol Extended Reports (RTCP XR) |
| |
| Authors: | T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed.. |
| Date: | November 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3611 |
|
This document defines the Extended Report (XR) packet type for theRTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the SessionDescription Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used byRTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics(MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. |
|
| |
| RFC 3612 | Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) |
| |
| Authors: | A. Farrel. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3612 |
|
This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212,"Constraint-Based LSP Setup Using LDP". |
|
| |
| RFC 3613 | Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE) |
| |
| Authors: | R. Morgan, K. Hazelton. |
| Date: | October 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3613 |
|
This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE).This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates. |
|
| |
| RFC 3614 | A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG) |
| |
| Authors: | J. Smith. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3614 |
|
This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG. |
|
| |
| RFC 3615 | A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging |
| |
| Authors: | J. Gustin, A. Goyens. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3615 |
|
This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT. |
|
| |
| RFC 3616 | A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA) |
| |
| Authors: | F. Bellifemine, I. Constantinescu, S. Willmott. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3616 |
|
This document describes a Uniform Resource Name NamespaceIdentification (URN NID) for the Foundation for Intelligent PhysicalAgents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology. |
|
| |
| RFC 3617 | Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) |
| |
| Authors: | E. Lear. |
| Date: | October 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3617 |
|
The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time.While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability. |
|
| |
| RFC 3618 | Multicast Source Discovery Protocol (MSDP) |
| |
| Authors: | B. Fenner, Ed., D. Meyer, Ed.. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3618 |
|
The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent MulticastSparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend onRPs in other domains. This document reflects existing MSDP implementations. |
|
| |
| RFC 3619 | Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 |
| |
| Authors: | S. Shah, M. Yip. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3619 |
|
This document describes the Ethernet Automatic Protection Switching(EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided bySONET rings, at a lower cost and with fewer constraints (e.g., ring size). |
|
| |
| RFC 3620 | The TUNNEL Profile |
| |
|
|
This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall. |
|
| |
| RFC 3621 | Power Ethernet MIB |
| |
| Authors: | A. Berger, D. Romascanu. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3621 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This document proposes an extension to the Ethernet-like InterfacesMIB with a set of objects for managing Power Sourcing Equipment(PSE). |
|
| |
| RFC 3622 | A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project |
| |
| Authors: | M. Mealling. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3622 |
|
This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity. |
|
| |
| RFC 3623 | Graceful OSPF Restart |
| |
| Authors: | J. Moy, P. Pillay-Esnault, A. Lindem. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3623 |
|
This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This is called "graceful restart" or"non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. |
|
| |
| RFC 3624 | The Media Gateway Control Protocol (MGCP) Bulk Audit Package |
| |
| Authors: | B. Foster, D. Auerbach, F. Andreasen. |
| Date: | November 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3624 |
|
The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints.It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints. |
|
| |
| RFC 3625 | The QCP File Format and Media Types for Speech Data |
| |
| Authors: | R. Gellens, H. Garudadri. |
| Date: | September 2003 |
| Formats: | txt json html |
| Updates: | RFC 3555 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3625 |
|
RFC 2658 specifies the streaming format for 3GPP2 13K vocoder (HighRate Speech Service Option 17 for Wideband Spread SpectrumCommunications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder(EVRC) and Selectable Mode Vocoders (SMV) data. (For example,Eudora(r), QuickTime(r), and cmda2000(r) handsets).
This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types forEVRC and SMV (respectively) data stored in this format. |
|
| |
| RFC 3626 | Optimized Link State Routing Protocol (OLSR) |
| |
| Authors: | T. Clausen, Ed., P. Jacquet, Ed.. |
| Date: | October 2003 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3626 |
|
This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context. |
|
| |
| RFC 3627 | Use of /127 Prefix Length Between Routers Considered Harmful |
| |
|
|
In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers.Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers. |
|
| |
| RFC 3628 | Policy Requirements for Time-Stamping Authorities (TSAs) |
| |
| Authors: | D. Pinkas, N. Pope, J. Ross. |
| Date: | November 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3628 |
|
This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document. |
|
| |
| RFC 3629 | UTF-8, a transformation format of ISO 10646 |
| |
|
|
ISO/IEC 10646-1 defines a large character set called the UniversalCharacter Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.This memo obsoletes and replaces RFC 2279. |
|
| |
| RFC 3630 | Traffic Engineering (TE) Extensions to OSPF Version 2 |
| |
|
|
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link StateAdvertisements. |
|
| |
| RFC 3631 | Security Mechanisms for the Internet |
| |
| Authors: | S. Bellovin, Ed., J. Schiller, Ed., C. Kaufman, Ed.. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3631 |
|
Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself.However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each. |
|
| |
| RFC 3632 | VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 |
| |
| Authors: | S. Hollenbeck, S. Veeramachaneni, S. Yalamanchilli. |
| Date: | November 2003 |
| Formats: | txt html json |
| Updates: | RFC 2832 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3632 |
|
This document updates version 1.1.0 of the Network Solutions Inc.(NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of theVeriSign Registry Registrar Protocol. |
|
| |
| RFC 3633 | IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 |
| |
|
|
The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host ConfigurationProtocol (DHCP). This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. |
|
| |
| RFC 3634 | Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option |
| |
| Authors: | K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3634 |
|
This document defines a new sub-option for the CableLabs ClientConfiguration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center(KDC) servers. |
|
| |
| RFC 3635 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces. |
|
| |
| RFC 3636 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 MediumAttachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515. |
|
| |
| RFC 3637 | Definitions of Managed Objects for the Ethernet WAN Interface Sublayer |
| |
| Authors: | C.M. Heard, Ed.. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3637 |
|
This document 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 theEthernet Wide Area Network (WAN) Interface Sublayer (WIS).
The MIB module defined in this memo is an extension of theSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Interface MIB and is implemented in conjunction with it and with theEthernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB. |
|
| |
| RFC 3638 | Applicability Statement for Reclassification of RFC 1643 to Historic Status |
| |
|
|
This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation. |
|
| |
| RFC 3639 | Considerations on the use of a Service Identifier in Packet Headers |
| |
| Authors: | M. St. Johns, Ed., G. Huston, Ed., IAB. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3639 |
|
This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number. |
|
| |
| RFC 3640 | RTP Payload Format for Transport of MPEG-4 Elementary Streams |
| |
| Authors: | J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric. |
| Date: | November 2003 |
| Formats: | txt html json |
| Updated by: | RFC 5691 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3640 |
|
The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29WG11) is a working group in ISO that produced the MPEG-4 standard.MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non- multiplexed MPEG-4 elementary stream. |
|
| |
| RFC 3641 | Generic String Encoding Rules (GSER) for ASN.1 Types |
| |
|
|
This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type. |
|
| |
| RFC 3642 | Common Elements of Generic String Encoding Rules (GSER) Encodings |
| |
| Authors: | S. Legg. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3642 |
|
The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes. |
|
| |
| RFC 3643 | Fibre Channel (FC) Frame Encapsulation |
| |
| Authors: | R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3643 |
|
This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames. |
|
| |
| RFC 3644 | Policy Quality of Service (QoS) Information Model |
| |
| Authors: | Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3644 |
|
This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies.This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol. |
|
| |
| RFC 3645 | Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) |
| |
| Authors: | S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall. |
| Date: | October 2003 |
| Formats: | txt html json |
| Updates: | RFC 2845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3645 |
|
The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security ServiceApplication Program Interface (GSS-API) (RFC2743). This document updates RFC 2845. |
|
| |
| RFC 3646 | DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | R. Droms, Ed.. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3646 |
|
This document describes Dynamic Host Configuration Protocol for IPv6(DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client. |
|
| |
| RFC 3647 | Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
| |
| Authors: | S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. |
| Date: | November 2003 |
| Formats: | txt json html |
| Obsoletes: | RFC 2527 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3647 |
|
This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. |
|
| |
| RFC 3648 | Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol |
| |
| Authors: | J. Whitehead, J. Reschke, Ed.. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3648 |
|
This specification extends the Web Distributed Authoring andVersioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. |
|
| |
| RFC 3649 | HighSpeed TCP for Large Congestion Windows |
| |
| Authors: | S. Floyd. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3649 |
|
The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals.
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the currentStandard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community. |
|
| |
| RFC 3650 | Handle System Overview |
| |
| Authors: | S. Sun, L. Lannom, B. Boesch. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3650 |
|
This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. TheHandle System is a general-purpose global name service that allows secured name resolution and administration over networks such as theInternet. The Handle System manages handles, which are unique names for digital objects and other Internet resources. |
|
| |
| RFC 3651 | Handle System Namespace and Service Definition |
| |
| Authors: | S. Sun, S. Reilly, L. Lannom. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3651 |
|
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document provides a detailed description of theHandle System namespace, and its data, service, and operation models.The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by theHandle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol. |
|
| |
| RFC 3652 | Handle System Protocol (ver 2.1) Specification |
| |
| Authors: | S. Sun, S. Reilly, L. Lannom, J. Petrone. |
| Date: | November 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3652 |
|
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle.It also defines the messages exchanged between the client and server for any handle operation. |
|
| |
| RFC 3653 | XML-Signature XPath Filter 2.0 |
| |
| Authors: | J. Boyer, M. Hughes, J. Reagle. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3653 |
|
XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles.
This document is the W3C XML Signature XPath-Filter 2.0Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as aW3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web. |
|
| |
| RFC 3654 | Requirements for Separation of IP Control and Forwarding |
| |
| Authors: | H. Khosravi, Ed., T. Anderson, Ed.. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3654 |
|
This document introduces the Forwarding and Control ElementSeparation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device. |
|
| |
| RFC 3655 | Redefinition of DNS Authenticated Data (AD) bit |
| |
|
|
This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy. |
|
| |
| RFC 3656 | The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol |
| |
|
|
As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery.
The Mailbox Update (MUPDATE) protocol allows a group of InternetMessage Access Protocol (IMAP) or Post Office Protocol - Version 3(POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol. |
|
| |
| RFC 3657 | Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Moriai, A. Kato. |
| Date: | January 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3657 |
|
This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic MessageSyntax (CMS). |
|
| |
| RFC 3658 | Delegation Signer (DS) Resource Record (RR) |
| |
|
|
The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference.
This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035,RFC 2535, RFC 3008 and RFC 3090. |
|
| |
| RFC 3659 | Extensions to FTP |
| |
|
|
This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. |
|
| |
| RFC 3660 | Basic Media Gateway Control Protocol (MGCP) Packages |
| |
|
|
This document provides a basic set of Media Gateway Control Protocol(MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (DualTone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages. |
|
| |
| RFC 3661 | Media Gateway Control Protocol (MGCP) Return Code Usage |
| |
| Authors: | B. Foster, C. Sivachelvan. |
| Date: | December 2003 |
| Formats: | txt html json |
| Updates: | RFC 3435 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3661 |
|
This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP)Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that theCall Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency. |
|
| |
| RFC 3662 | A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services |
| |
| Authors: | R. Bless, K. Nichols, K. Wehrle. |
| Date: | December 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8622 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3662 |
|
This document proposes a differentiated services per-domain behavior(PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best- effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. |
|
| |
| RFC 3663 | Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | A. Newton. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3663 |
|
Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP)Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available. |
|
| |
| RFC 3664 | The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) |
| |
|
|
Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, called AES-XCBC-PRF-128. |
|
| |
| RFC 3665 | Session Initiation Protocol (SIP) Basic Call Flow Examples |
| |
| Authors: | A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. |
| Date: | December 2003 |
| Formats: | txt html json |
| Also: | BCP 0075 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3665 |
|
This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents andClients, SIP Proxy and Redirect Servers. Scenarios include SIPRegistration and SIP session establishment. Call flow diagrams and message details are shown. |
|
| |
| RFC 3666 | Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows |
| |
| Authors: | A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. |
| Date: | December 2003 |
| Formats: | txt json html |
| Also: | BCP 0076 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3666 |
|
This document contains best current practice examples of SessionInitiation Protocol (SIP) call flows showing interworking with thePublic Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways.Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP.PSTN telephony protocols are illustrated using ISDN (IntegratedServices Digital Network), ISUP (ISDN User Part), and FGB (FeatureGroup B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown. |
|
| |
| RFC 3667 | 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 3668, replaces Section 10 of RFC2026. |
|
| |
| RFC 3668 | 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 3667, 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 3669 | Guidelines for Working Groups on Intellectual Property Issues |
| |
| Authors: | S. Brim. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3669 |
|
This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. |
|
| |
| RFC 3670 | Information Model for Describing Network Device QoS Datapath Mechanisms |
| |
| Authors: | B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss. |
| Date: | January 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3670 |
|
The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services.
This document should be used with the QoS Policy Information Model(QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices.Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices.
This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository. |
|
| |
| RFC 3671 | Collective Attributes in the Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | K. Zeilenga. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3671 |
|
X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory AccessProtocol). This document provides schema definitions for collective attributes for use in LDAP. |
|
| |
| RFC 3672 | Subentries in the Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | K. Zeilenga. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3672 |
|
In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with theLightweight Directory Access Protocol (LDAP). |
|
| |
| RFC 3673 | Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes |
| |
| Authors: | K. Zeilenga. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3673 |
|
The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes. |
|
| |
| RFC 3674 | Feature Discovery in Lightweight Directory Access Protocol (LDAP) |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms. |
|
| |
| RFC 3675 | .sex Considered Dangerous |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3675 |
|
Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view. |
|
| |
| RFC 3676 | The Text/Plain Format and DelSp Parameters |
| |
|
|
This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting.
This document supersedes the one specified in RFC 2646, "TheText/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. |
|
| |
| RFC 3677 | IETF ISOC Board of Trustee Appointment Procedures |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | December 2003 |
| Formats: | txt json html |
| Also: | BCP 0077 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3677 |
|
This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment. |
|
| |
| RFC 3678 | Socket Interface Extensions for Multicast Source Filters |
| |
| Authors: | D. Thaler, B. Fenner, B. Quinn. |
| Date: | January 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3678 |
|
The Internet Group Management Protocol (IGMPv3) for IPv4 and theMulticast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications.
This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications. |
|
| |
| RFC 3679 | Unused Dynamic Host Configuration Protocol (DHCP) Option Codes |
| |
|
|
Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic HostConfiguration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future.
The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. |
|
| |
| RFC 3680 | A Session Initiation Protocol (SIP) Event Package for Registrations |
| |
|
|
This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations.Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. |
|
| |
| RFC 3681 | Delegation of E.F.F.3.IP6.ARPA |
| |
|
|
This document discusses the need for delegation of theE.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for6bone addresses, and makes specific recommendations for the process needed to accomplish this. |
|
| |
| RFC 3682 | The Generalized TTL Security Mechanism (GTSM) |
| |
| Authors: | V. Gill, J. Heasley, D. Meyer. |
| Date: | February 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5082 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3682 |
|
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),Bidirectional Forwarding Detection, and Label Distribution Protocol(LDP) (RFC 3036). While the Generalized TTL Security Mechanism(GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. |
|
| |
| RFC 3683 | A Practice for Revoking Posting Rights to IETF Mailing Lists |
| |
|
|
All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion.An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. |
|
| |
| RFC 3684 | Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) |
| |
| Authors: | R. Ogier, F. Templin, M. Lewis. |
| Date: | February 2004 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3684 |
|
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree(providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification ofDijkstra's algorithm. To minimize overhead, each node reports only*part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results inHELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. |
|
| |
| RFC 3685 | SIEVE Email Filtering: Spamtest and VirusTest Extensions |
| |
|
|
The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. |
|
| |
| RFC 3686 | Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) |
| |
| Authors: | R. Housley. |
| Date: | January 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3686 |
|
This document describes the use of Advanced Encryption Standard (AES)Counter Mode, with an explicit initialization vector, as an IPsecEncapsulating Security Payload (ESP) confidentiality mechanism. |
|
| |
| RFC 3687 | Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules |
| |
| Authors: | S. Legg. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3687 |
|
The syntaxes of attributes in a Lightweight Directory Access Protocol(LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes.Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. |
|
| |
| RFC 3688 | The IETF XML Registry |
| |
|
|
This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, andResource Description Framework (RDF) Schemas. |
|
| |
| RFC 3689 | General Requirements for Emergency Telecommunication Service (ETS) |
| |
| Authors: | K. Carlberg, R. Atkinson. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3689 |
|
This document presents a list of general requirements in support ofEmergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). |
|
| |
| RFC 3690 | IP Telephony Requirements for Emergency Telecommunication Service (ETS) |
| |
| Authors: | K. Carlberg, R. Atkinson. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3690 |
|
This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within the context of IP telephony.It is an extension to the general requirements presented in RFC 3689.Solutions to these requirements are not presented in this document. |
|
| |
| RFC 3691 | Internet Message Access Protocol (IMAP) UNSELECT command |
| |
| Authors: | A. Melnikov. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3691 |
|
This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. |
|
| |
| RFC 3692 | Assigning Experimental and Testing Numbers Considered Useful |
| |
|
|
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified. |
|
| |
| RFC 3693 | Geopriv Requirements |
| |
| Authors: | J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. |
| Date: | February 2004 |
| Formats: | txt json html |
| Updated by: | RFC 6280, RFC 7459 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3693 |
|
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.
This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. |
|
| |
| RFC 3694 | Threat Analysis of the Geopriv Protocol |
| |
| Authors: | M. Danley, D. Mulligan, J. Morris, J. Peterson. |
| Date: | February 2004 |
| Formats: | txt html json |
| Updated by: | RFC 6280 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3694 |
|
This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. |
|
| |
| RFC 3695 | Compact Forward Error Correction (FEC) Schemes |
| |
|
|
This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FECPayload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.
This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. |
|
| |
| RFC 3696 | Application Techniques for Checking and Transformation of Names |
| |
| Authors: | J. Klensin. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3696 |
|
Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. |
|
| |
| RFC 3697 | IPv6 Flow Label Specification |
| |
| Authors: | J. Rajahalme, A. Conta, B. Carpenter, S. Deering. |
| Date: | March 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6437 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3697 |
|
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document.
The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. |
|
| |
| RFC 3698 | Lightweight Directory Access Protocol (LDAP): Additional Matching Rules |
| |
|
|
This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. |
|
