Liste des RFC (Request For Comments) [ Page 1/ 467 ] ☼ CFMFrance.com | ColdFusion CodeS SourceS | 92 sources Cold Fusion, CFM, Source, Code, Programmation, Cours , Tutorial, Tutoriaux etc...

Liste des RFC page 1 / 467

Liste des RFC page 1 sur 467

Pub

RFC4879- Clarification of the Third Party Disclosure Procedure in RFC 3979
This document clarifies and updates a single sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC4877- Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture
This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS TRACK]

RFC4874- Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS TRACK]

RFC4867- RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. [STANDARDS TRACK]

RFC4856- Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences
This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP. [STANDARDS TRACK]

RFC4855- Media Type Registration of RTP Payload Formats
This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS TRACK]

RFC4853- Cryptographic Message Syntax (CMS) Multiple Signer Clarification
This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. [STANDARDS TRACK]

RFC4852- IPv6 Enterprise Network Analysis - IP Layer 3 Focus
This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. This memo provides information for the Internet community.

RFC4850- Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture
The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. [STANDARDS TRACK]

RFC4842- Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS TRACK]

[Page 1 Page 2 Page 3 Page 4 Page 5 Page 6 Page 7 Page 8 Page 9 Page 10]

10 pages suivantes (11) : dernière page