Network Working Group                                          S. Ginoza
Request for Comments: 3499                                           ISI
Category: Informational                                    December 2003
Network Working Group                                          S. Ginoza
Request for Comments: 3499                                           ISI
Category: Informational                                    December 2003

Request for Comments Summary


RFC Numbers 3400-3499


Status of This Memo


This RFC is a slightly annotated list of the 100 RFCs from RFC 3400 through RFC 3499. This is a status report on these RFCs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

此RFC是RFC 3400到RFC 3499中100个RFC的略带注释的列表。这是这些RFC的状态报告。本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice


Copyright (C) The Internet Society (2003). All Rights Reserved.




Many RFCs, but not all, are Proposed Standards, Draft Standards, or Standards. Since the status of these RFCs may change during the standards processing, we note here only that they are on the standards track. Please see the latest edition of "Internet Official Protocol Standards" for the current state and status of these RFCs. In the following, RFCs on the standards track are marked [STANDARDS TRACK].


RFC     Author          Date            Title
---     ------          ----            -----
RFC     Author          Date            Title
---     ------          ----            -----

3499 Ginoza Request for Comments Summary

3499 Ginoza征求意见摘要

This memo.


3498 Kuhfeld Mar 2003 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures

3498 Kuhfeld Mar 2003同步光网络(SONET)线性自动保护交换(APS)体系结构的受管对象定义

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS TRACK]


3497 Gharai Mar 2003 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video

3497 Gharai 2003年3月电影电视工程师协会(SMPTE)292M视频RTP有效载荷格式

This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS TRACK]

本备忘录规定了用于封装未压缩高清晰度电视(HDTV)的RTP有效载荷格式,该格式由美国电影电视工程师协会(SMPTE)标准SMPTE 292M定义。SMPTE是运动成像行业的主要标准化机构,SMPTE 292M标准定义了用于本地HDTV传输的位串行数字接口。[标准轨道]

3496 Malis Mar 2003 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering

3496 Malis Mar 2003协议扩展,用于支持异步传输模式(ATM)服务类感知多协议标签交换(MPLS)流量工程

This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.


3495 Beser Mar 2003 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration

用于CableLabs客户端配置的3495 Beser Mar 2003动态主机配置协议(DHCP)选项

This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS TRACK]


3494 Zeilenga Mar 2003 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status

3494 Zeilenga 2003年3月轻型目录访问协议版本2(LDAPv2)恢复到历史状态

This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community.

本文档建议停用轻量级目录访问协议(LDAPv2)版本2和其他相关规范,并讨论了这样做的原因。本文件建议将RFC 1777、1778、1779、1781和2559(以及它们取代的文件)移至历史状态。本备忘录为互联网社区提供信息。

3493 Gilligan Mar 2003 Basic Socket Interface Extensions for IPv6

3493 Gilligan 2003年3月IPv6基本套接字接口扩展

The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.

TCP/IP应用程序的实际标准应用程序接口(API)是“套接字”接口。尽管此API是在20世纪80年代早期为Unix开发的,但它也已在各种非Unix系统上实现。使用sockets API编写的TCP/IP应用程序在过去具有高度的可移植性,我们希望IPv6应用程序具有同样的可移植性。但是需要对套接字API进行更改以支持IPv6,本备忘录描述了这些更改。其中包括用于承载IPv6地址的新套接字地址结构、新的地址转换函数和一些新的套接字选项。这些扩展旨在提供对TCP和UDP应用程序所需的基本IPv6功能(包括多播)的访问,同时将对系统的更改降至最低,并为现有IPv4应用程序提供完全的兼容性。高级IPv6功能的其他扩展(原始套接字和对IPv6扩展头的访问)在另一个文档中定义。本备忘录为互联网社区提供信息。

3492 Costello Mar 2003 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)

3492 Costello Mar 2003 Punycode:应用程序中国际化域名的Unicode引导字符串编码(IDNA)

Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS TRACK]


3491 Hoffman Mar 2003 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)

3491 Hoffman 2003年3月Nameprep:国际化域名(IDN)的Stringprep配置文件

This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS TRACK]


3490 Faltstrom Mar 2003 Internationalizing Domain Names in Applications (IDNA)

3490 Faltstrom 2003年3月应用程序域名国际化(IDNA)

Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS TRACK]


3489 Rosenberg Mar 2003 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

3489 Rosenberg 2003年3月STUN-通过网络地址转换器(NAT)简单遍历用户数据报协议(UDP)

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS TRACK]


3488 Wu Feb 2003 Cisco Systems Router-port Group Management Protocol (RGMP)

3488 Wu 2003年2月思科系统路由器端口组管理协议(RGMP)

This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.

本文档介绍路由器端口组管理协议(RGMP)。此协议由Cisco Systems开发,用于多播路由器和交换机之间,以限制交换机中的多播数据包转发到可能需要数据包的路由器。

RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community.


3487 Schulzrinne Feb 2003 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)

3487 Schulzrinne 2003年2月会话启动协议(SIP)的资源优先级机制要求

This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community.


3486 Camarillo Feb 2003 Compressing the Session Initiation Protocol (SIP)

3486 Camarillo 2003年2月压缩会话启动协议(SIP)

This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS TRACK]


3485 Garcia-Martin Feb 2003 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)

3485 Garcia Martin 2003年2月会话启动协议(SIP)和会话描述协议(SDP)信令压缩静态字典(SigComp)

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS TRACK]


3484 Draves Feb 2003 Default Address Selection for Internet Protocol version 6 (IPv6)

3484 Draves 2003年2月Internet协议版本6(IPv6)的默认地址选择

This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.


All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS TRACK]


3483 Rawlins Mar 2003 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR)

3483 Rawlins 2003年3月带有政策供应的公共开放政策服务政策使用反馈框架(COPS-PR)

Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community.

公共开放策略服务(COPS)协议(RFC 2748)定义了向策略决策点(PDP)报告信息的能力。报告信息的类型包括成功、失败和已安装状态的记帐。本文档重点介绍COPS报告类型的会计,以及监控和报告已安装状态的使用反馈的必要框架。本备忘录为互联网社区提供信息。

3482 Foster Feb 2003 Number Portability in the Global Switched Telephone Network (GSTN): An Overview

3482 Foster Feb 2003全球交换电话网(GSTN)中的号码可携性:概述

This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN).


NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community.

NP是一项法规要求,旨在通过允许最终用户在更换服务提供商的同时保留电话号码,实现本地电话服务竞争的自由化。NP将拨打的E.164号码的基本性质从分层物理路由地址更改为虚拟地址,因此需要将后者透明地转换为前者。此外,还存在各种监管约束,这些约束为NP实施确定了相关参数,其中大多数并非特定于网络技术。因此,与适用的监管约束一致的NP行为的实施,以及与现有GSTN NP实施互操作的需要,是IETF正在进行的IP电话工作的许多领域的相关主题。本备忘录为互联网社区提供信息。

3481 Inamura, Ed. Feb 2003 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks

3481 Inamura,Ed.2003年2月第二代(2.5G)和第三代(3G)无线网络上的TCP

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.


3480 Kompella Feb 2003 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)

3480 Kompella 2003年2月在CR-LDP(约束路由标签分发协议)中发送未编号链路

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS TRACK]

多协议标签交换流量工程(MPLS TE)使用的当前信令不支持未编号的链路。本文档定义了约束路由标签分发协议(CR-LDP)的程序和扩展,CR-LDP是支持无编号链路所需的MPLS TE信令协议之一。[标准轨道]

3479 Farrel, Ed. Feb 2003 Fault Tolerance for the Label Distribution Protocol (LDP)

3479 Farrel,Ed.2003年2月标签分发协议(LDP)的容错

Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks.


The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations.

FT LSR的各个组件(包括标签分发协议(LDP)、交换硬件和TCP)如何实现FT的细节是具体实现的。本文件确定了RFC 3036“LDP规范”中LDP规范中的问题,这些问题使得难以使用当前LDP协议实现FT LSR,并定义了LDP规范的增强功能,以简化此类FT LSR实现。

The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS TRACK]

这里描述的问题和扩展同样适用于RFC 3212,“使用LDP的基于约束的LSP设置”(CR-LDP)。[标准轨道]

3478 Leelanivas Feb 2003 Graceful Restart Mechanism for Label Distribution Protocol

3478 Leelanivas 2003年2月标签分发协议的优雅重启机制

This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart.


The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.


The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart.


The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS TRACK]


3477 Kompella Jan 2003 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)

3477 Kompella Jan 2003资源预留协议中的信令未编号链路-流量工程(RSVP-TE)

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS TRACK]

多协议标签交换流量工程(MPLS TE)使用的当前信令不支持未编号的链路。本文档定义了用于标签交换路径(LSP)隧道(RSVP-TE)的资源预留协议(RSVP)的程序和扩展,RSVP-TE是MPLS TE信令协议之一,支持无编号链路所需。[标准轨道]

3476 Rajagopalan Mar 2003 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling

3476 Rajagopalan 2003年3月关于光纤UNI信令的标签分发协议(LDP)、资源预留协议(RSVP)和资源预留协议流量工程(RSVP-TE)扩展的IANA分配的文件

The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community.


3475 Aboul-Magd Mar 2003 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)

3475 Aboul Magd 2003年3月,关于使用LDP(CR-LDP)扩展的基于约束的LSP设置IANA分配的文件,用于自动交换光网络(ASON)

Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community.


3474 Lin Mar 2003 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)

3474 Lin 2003年3月关于通用多协议标签交换(GMPLS)资源预留协议的IANA分配文件-自动交换光网络(ASON)的流量工程(RSVP-TE)使用和扩展

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs).


This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.


This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.

本文件建议适当扩展,以解决ITU-T研究组15为支持ITU ASON标准化工作而确定和传达的额外要求。本备忘录为互联网社区提供信息。

3473 Berger Jan 2003 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions

3473 Berger Jan 2003广义多协议标签交换(GMPLS)信令资源预留协议流量工程(RSVP-TE)扩展

This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS TRACK]


3472 Ashwood-Smith Jan 2003 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions

3472 Ashwood Smith Jan 2003广义多协议标签交换(GMPLS)基于信令约束的路由标签分发协议(CR-LDP)扩展

This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS TRACK]


3471 Berger Jan 2003 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description

3471 Berger Jan 2003通用多协议标签交换(GMPLS)信令功能描述

This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS TRACK]


3470 Hollenbeck Jan 2003 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols

3470 Hollenbeck 2003年1月IETF协议中可扩展标记语言(XML)使用指南

The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.


There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.


3469 Sharma, Ed. Feb 2003 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery

3469 Sharma,Ed.2003年2月基于多协议标签交换(MPLS)的恢复框架

Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community.


3468 Andersson Feb 2003 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols

3468 Andersson 2003年2月多协议标签交换(MPLS)工作组关于MPLS信令协议的决定

This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community.

本文件记录了IETF内多协议标签交换(MPLS)工作组达成的共识,即将其工作重点放在“资源预留协议(RSVP)-TE:标签交换路径(LSP)隧道的RSVP扩展”(RFC 3209)作为用于流量工程应用的MPLS信令协议,不承担与“使用标签分发协议(LDP)的基于约束的LSP设置”(RFC 3212)相关的新工作。IESG已接受第6节的建议。本备忘录为互联网社区提供信息。

3467 Klensin Feb 2003 Role of the Domain Name System (DNS)

3467 Klensin 2003年2月域名系统(DNS)的作用

This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.


3466 Day Feb 2003 A Model for Content Internetworking (CDI)


Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community.


3465 Allman Feb 2003 TCP Congestion Control with Appropriate Byte Counting (ABC)

3465 Allman Feb 2003 TCP拥塞控制与适当的字节计数(ABC)

This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community.


3464 Moore Jan 2003 An Extensible Message Format for Delivery Status Notifications

3464 Moore Jan 2003用于传递状态通知的可扩展消息格式

This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.


Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS TRACK]


3463 Vaudreuil Jan 2003 Enhanced Mail System Status Codes

3463 Vaudreuil 2003年1月增强型邮件系统状态代码

This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS TRACK]


3462 Vaudreuil Jan 2003 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages

3462 Vaudreuil Jan 2003用于报告邮件系统管理邮件的多部分/报告内容类型

The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.


This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS TRACK]


3461 Moore Jan 2003 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)

3461 Moore 2003年1月用于传递状态通知(DSN)的简单邮件传输协议(SMTP)服务扩展

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS TRACK]


3460 Moore Jan 2003 Policy Core Information Model (PCIM) Extensions


This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS TRACK]

本文档指定了对策略核心信息模型(PCIM,RFC 3060)的一些更改。包括两种类型的更改。首先,引入了几个全新的元素,例如,用于头过滤的类,这些类将PCIM扩展到以前未涉及的领域。其次,在某些情况下,PCIM的元素(例如,策略规则优先级)被弃用,而替换元素被定义(在本例中,优先级与引用策略规则的关联相关联)。这两种类型的更改都是以这样一种方式进行的,即尽可能保留与原始PCIM模型实现的互操作性。本文档更新了RFC 3060。[标准轨道]

3459 Burger Jan 2003 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter

3459 Burger 2003年1月关键内容多用途Internet邮件扩展(MIME)参数

This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.

本文档描述了如何使用一种机制来识别发件人认为在多部分Internet邮件消息中至关重要的身体部位。所描述的机制是内容配置的参数,如RFC 3204所描述的。

By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS TRACK]


3458 Burger Jan 2003 Message Context for Internet Mail

3458 Burger 2003年1月Internet邮件的邮件上下文

This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message.

本备忘录描述了新的RFC 2822消息头“消息上下文”。此标头提供有关消息的上下文和表示特征的信息。

A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS TRACK]


3457 Kelly Jan 2003 Requirements for IPsec Remote Access Scenarios


IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community.


3456 Patel Jan 2003 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode

3456 Patel Jan 2003动态主机配置协议(DHCPv4)IPsec隧道模式的配置

This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS TRACK]


3455 Garcia-Martin Jan 2003 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)

3455 Garcia Martin Jan 2003第三代合作伙伴关系项目(3GPP)会话启动协议(SIP)的专用头(P头)扩展

This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.


3454 Hoffman Dec 2002 Preparation of Internationalized Strings ("stringprep")


This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.


This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS TRACK]


3453 Luby Dec 2002 The Use of Forward Error Correction (FEC) in Reliable Multicast

3453 Luby Dec 2002可靠多播中前向纠错(FEC)的使用

This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community.


3452 Luby Dec 2002 Forward Error Correction (FEC) Building Block

3452 Luby Dec 2002前向纠错(FEC)构造块

This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community.


3451 Luby Dec 2002 Layered Coding Transport (LCT) Building Block

3451 Luby Dec 2002分层编码传输(LCT)构建块

Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community.


3450 Luby Dec 2002 Asynchronous Layered Coding (ALC) Protocol Instantiation

3450 Luby Dec 2002异步分层编码(ALC)协议实例化

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community.


3449 Balakrishnan Dec 2002 TCP Performance Implications of Network Path Asymmetry

3449 Balakrishnan Dec 2002网络路径不对称对TCP性能的影响

This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.


The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link-layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

该文件详细说明了针对这些影响的几种缓解措施,这些措施已在文献中提出或评估,或目前已部署在网络中。这些解决方案使用本地链路层技术、子网和端到端机制的组合,包括:(i)管理用于承载ack的上游瓶颈链路的信道的技术,通常使用报头压缩或降低TCP ack的频率,(ii)处理此减少的ACK频率以保留TCP发送方的应答触发自时钟的技术,以及(iii)反向调度数据和ACK分组以在存在双向通信的情况下提高性能的技术。介绍了每种技术,以及已知问题和使用建议。文件末尾提供了建议摘要。本文件规定了互联网社区的最佳现行做法,并要求进行讨论和提出改进建议。

3448 Handley Jan 2003 TCP Friendly Rate Control (TFRC): Protocol Specification

3448 Handley Jan 2003 TCP友好速率控制(TFRC):协议规范

This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS TRACK]


3447 Jonsson Feb 2003 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1

3447 Jonsson 2003年2月公开密钥加密标准(PKCS)#1:RSA加密规范版本2.1

This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.

本备忘录代表了RSA Laboratories公钥加密标准(PKCS)系列中PKCS#1 v2.1的重新发布,PKCS过程中保留更改控制。本文件正文直接摘自PKCS#1 v2.1文件,并在出版过程中进行了某些更正。本备忘录为互联网社区提供信息。

3446 Kim Jan 2003 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)

3446 Kim Jan 2003使用协议独立多播(PIM)和多播源发现协议(MSDP)的选播渲染点(RP)机制

This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.


3445 Massey Dec 2002 Limiting the Scope of the KEY Resource Record (RR)


This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS TRACK]

本文档将域名系统(DNS)密钥资源记录(RR)限制为仅由域名系统安全扩展(DNSSEC)使用的密钥。原始密钥RR使用子类型存储DNSSEC密钥和任意应用程序密钥。使用相同的记录类型存储DNSSEC和应用程序密钥是错误的。本文档通过在密钥RR数据中重新定义协议八位字节字段,从密钥记录中删除应用程序密钥。由于删除了应用程序密钥,密钥记录中除一个之外的所有标志都变得不必要,并被重新定义。现有的三个应用程序密钥子类型更改为保留,但密钥记录的格式不变。本文件更新了RFC 2535。[标准轨道]

3444 Pras Jan 2003 On the Difference between Information Models and Data Models

3444 Pras 2003年1月关于信息模型和数据模型之间的差异

There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models.


This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.


3443 Agarwal Jan 2003 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks

3443 Agarwal 2003年1月1日多协议标签交换(MPLS)网络中的生存时间(TTL)处理

This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS TRACK]

本文档描述了分层多协议标签交换(MPLS)网络中的生存时间(TTL)处理,其动机是为MPLS标签交换路径形式化TTL透明操作模式。它更新了RFC 3032,“MPLS标签堆栈编码”。管道和均匀模型分层隧道中的TTL处理均以“推送”和“弹出”两种情况为例进行了说明。本文档还补充了RFC 3270“MPLS对差异化服务的支持”,并将该文档中引入的术语与分层MPLS网络中的TTL处理联系在一起。[标准轨道]

3442 Lemon Dec 2002 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4

3442 Lemon Dec 2002动态主机配置协议(DHCP)版本4的无类静态路由选项

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS TRACK]


3441 Kumar Jan 03 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP)

3441 Kumar Jan 03媒体网关控制协议(MGCP)的异步传输模式(ATM)包

This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community.

本文档描述了媒体网关控制协议(MGCP)的异步传输模式(ATM)包。该包包括新的本地连接选项、ATM特定事件和信号以及ATM连接参数。还包括对编解码器和配置文件协商的描述。它扩展了目前正在许多产品中部署的MGCP。实施者应了解IETF Megaco工作组和ITU SG16的发展情况,这两个工作组目前正在研究该协议的潜在后续协议。本备忘录为互联网社区提供信息。

3440 Ly Dec 2002 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines

3440 Y 2002年12月非对称数字用户线路的扩展管理对象定义

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 additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS TRACK]

此备忘录定义了管理信息库(MIB)的一部分,用于Internet社区中的网络管理协议。特别是,它描述了用于管理ADSL线路MIB(RFC 2662)未涵盖的非对称数字用户线路(ADSL)接口的其他托管对象。[标准轨道]

3439 Bush Dec 2002 Some Internet Architectural Guidelines and Philosophy


This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community.

本文件通过概述互联网骨干网络的架构师和设计师应遵守的一些哲学准则,扩展了RFC 1958。我们描述了简单性原则,即复杂性是阻碍有效扩展的主要机制,并讨论了它对大规模互联网主干网的架构、设计和工程问题的影响。本备忘录为互联网社区提供信息。

3438 Townsley Dec 2002 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update

3438 Townsley Dec 2002第二层隧道协议(L2TP)互联网分配号码管理局(IANA)注意事项更新

This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.


3437 Palter Dec 2002 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation

3437 Palter Dec 2002 PPP链路控制协议协商的第二层隧道协议扩展

This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS TRACK]

本文档定义了对第二层隧道协议(L2TP)的扩展,以增强对链路特定点对点协议(PPP)选项的支持。PPP端点通常可以直接访问连接它们的公共物理介质,因此对正在使用的介质有详细的了解。当使用L2TP时,两个PPP对等点不再通过相同的物理介质直接连接。相反,L2TP通过在分组交换网络(如IP)上隧道PPP帧,在部分或全部PPP连接上插入虚拟连接。在某些情况下,L2TP端点可能需要在无法访问正确参与LCP协商所需的所有媒体信息的位置协商PPP链路控制协议(LCP)选项。本文档提供了一种机制,用于在L2TP隧道远端的PPP LCP协商之前,在L2TP端点之间传送所需的LCP选项,以及将协商的LCP选项传送回本机PPP链路所在位置的机制。[标准轨道]

3436 Jungmaier Dec 2002 Transport Layer Security over Stream Control Transmission Protocol

3436 Jungmaier Dec 2002流控制传输协议上的传输层安全

This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.

本文档描述了RFC 2246中定义的传输层安全(TLS)协议在RFC 2960和RFC 3309中定义的流控制传输协议(SCTP)上的使用。

The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance.


Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP-addresses. [STANDARDS TRACK]


3435 Andreasen Jan 03 Media Gateway Control Protocol (MGCP) Version 1.0

3435 Andreasen Jan 03媒体网关控制协议(MGCP)1.0版

This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP.


Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints.


The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. This memo provides information for the Internet community.


3434 Bierman Dec 2002 Remote Monitoring MIB Extensions for High Capacity Alarms

3434 Bierman Dec 2002高容量报警远程监控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 extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS TRACK]

此备忘录定义了管理信息库(MIB)的一部分,用于Internet社区中的网络管理协议。特别是,它描述了用于扩展远程监控(RMON)MIB(RFC 2819)中的报警阈值功能的托管对象,以基于Counter64数据类型提供类似的对象阈值监控。[标准轨道]

3433 Bierman Dec 2002 Entity Sensor Management Information Base


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 extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS TRACK]

此备忘录定义了管理信息库(MIB)的一部分,用于Internet社区中的网络管理协议。特别是,它描述了用于扩展实体MIB(RFC 2737)的托管对象,以提供对物理传感器相关信息的通用访问,这些信息通常存在于网络设备中(例如机箱温度、风扇转速、电源电压)。[标准轨道]

3432 Raisanen Nov 2002 Network performance measurement with periodic streams

3432 Raisanen 2002年11月定期流网络性能测量

This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS TRACK]

本备忘录描述了评估IP网络性能的定期抽样方法和相关指标。首先,备忘录激励定期抽样,并解决其价值问题,作为RFC 2330中所述泊松抽样的替代方案。其优点包括适用于主动和被动测量,模拟恒定比特率(CBR)流量(典型的多媒体通信,或接近CBR,如语音活动检测),以及可以简化分析的几个实例。抽样方法通过强制随机开始时间和有限长度测试来避免可预测性。在描述采样方法和采样度量参数之后,讨论了测量方法和误差。最后,我们提供了有关定期测量的附加信息,包括安全考虑。[标准轨道]

3431 Segmuller Dec 2002 Sieve Extension: Relational Tests


This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS TRACK]

本文档描述RFC 3028中定义的筛邮件过滤语言的关系扩展。此扩展扩展扩展了Sieve中现有的条件测试,以允许使用关系运算符。除了测试其内容外,它还允许测试标头和信封字段中的实体数量。[标准轨道]

3430 Schoenwaelder Dec 2002 Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping

3430 Schoenwaeld Dec 2002基于传输控制协议(TCP)的简单网络管理协议(SNMP)传输映射

This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community.

此备忘录定义了通过TCP使用简单网络管理协议(SNMP)的传输映射。传输映射可用于任何版本的SNMP。本文件扩展了STD 62、RFC 3417中定义的传输映射。这份备忘录为互联网社区定义了一个实验性协议。

3429 Ohta Nov 2002 Assignment of the 'OAM Alert Label' forMultiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions

3429 Ohta 2002年11月为多协议标签交换体系结构(MPLS)操作和维护(OAM)功能分配“OAM警报标签”

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community.

本文档描述了将RFC 3032(MPLS标签堆栈编码)中定义的一个保留标签值分配给用户平面多协议标签交换体系结构(MPLS)OAM功能用于识别MPLS OAM数据包的“操作和维护(OAM)警报标签”。本备忘录为互联网社区提供信息。

3428 Campbell Dec 2002 Session Initiation Protocol (SIP) Extension for Instant Messaging

3428 Campbell Dec 2002即时消息会话启动协议(SIP)扩展

Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.


This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS TRACK]


3427 Mankin Dec 2002 Change Process for the Session Initiation Protocol (SIP)

3427 Mankin Dec 2002会话启动协议(SIP)的更改过程

This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.


3426 Floyd Nov 2002 General Architectural and Policy Considerations


This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community.


3425 Lawrence Nov 2002 Obsoleting IQUERY


The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS TRACK]

RFC 1035中规定的执行反向DNS查找的IQUERY方法尚未普遍实现,并且通常在已实现的地方被禁用。两者都反映了社区的普遍观点,即该概念是不明智的,并且广泛使用的替代方法(使用指针(PTR)查询和反向映射记录)更可取。因此,本文档不推荐IQUERY操作,并声明它已完全过时。本文件更新了RFC1035。[标准轨道]

3424 Daigle Nov 2002 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation

3424 Daigle,2002年11月IAB关于单边自地址固定(UNSAF)跨网络地址转换的注意事项

As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.


This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.


3423 Zhang Nov 2002 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0

3423 Zhang 2002年11月XACCT的网元(CRANE)通用可靠计费协议规范版本1.0

This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.


This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community.


3422 Okamoto Nov 2002 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS)

3422 Okamoto 2002年11月通过同步光网络/同步数字体系(MAPOS)上的多址协议转发媒体访问控制(MAC)帧

This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community.


3421 Zhao Nov 2002 Select and Sort Extensions for the Service Location Protocol (SLP)


This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community.


3420 Sparks Nov 2002 Internet Media Type message/sipfrag

3420 Sparks 2002年11月互联网媒体类型消息/sipfrag

This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS TRACK]


3419 Daniele Dec 2002 Textual Conventions for Transport Addresses

3419 Daniele 2002年12月运输地址的文本约定

This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS TRACK]


3418 Presuhn Dec 2002 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)


This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS TRACK]

本文档定义了描述简单网络管理协议(SNMP)实体行为的托管对象。本文件废除RFC 1907,简单网络管理协议(SNMPv2)版本2的管理信息库。[标准轨道]

3417 Presuhn Dec 2002 Transport Mappings for the Simple Network Management Protocol (SNMP)


This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS TRACK]

本文档定义了通过各种协议传输简单网络管理协议(SNMP)消息。本文件废除了RFC 1906。[标准轨道]

3416 Presuhn Dec 2002 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)


This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS TRACK]

本文档定义了简单网络管理协议(SNMP)的协议操作版本2。它定义了用于发送、接收和处理SNMP PDU的语法和过程元素。本文件废除了RFC 1905。[标准轨道]

3415 Wijnen Dec 2002 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)


This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View-based Access Control Model. This document obsoletes RFC 2575. [STANDARDS TRACK]

本文档描述了在简单网络管理协议(SNMP)体系结构中使用的基于视图的访问控制模型(VACM)。它定义了控制管理信息访问的程序要素。本文档还包括一个管理信息库(MIB),用于远程管理基于视图的访问控制模型的配置参数。本文件淘汰RFC 2575。[标准轨道]

3414 Blumenthal Dec 2002 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

3414 Blumenthal Dec 2002用于简单网络管理协议(SNMPv3)版本3的基于用户的安全模型(USM)

This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS TRACK]

本文档介绍用于SNMP体系结构的简单网络管理协议(SNMP)版本3的基于用户的安全模型(USM)。它定义了用于提供SNMP消息级安全性的过程元素。本文档还包括一个管理信息库(MIB),用于远程监视/管理此安全模型的配置参数。本文件废除了RFC 2574。[标准轨道]

3413 Levi Dec 2002 Simple Network Management Protocol (SNMP) Applications

3413 Levi Dec 2002简单网络管理协议(SNMP)应用程序

This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.

本文档描述了五种类型的简单网络管理协议(SNMP)应用程序,它们使用STD 62、RFC 3411中所述的SNMP引擎。所描述的应用程序类型包括命令生成器、命令响应器、通知发起者、通知接收者和代理转发器。

This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS TRACK]

本文档还定义了管理信息库(MIB)模块,用于指定管理操作的目标、通知筛选和代理转发。本文件淘汰RFC 2573。[标准轨道]

3412 Case Dec 2002 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)


This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS TRACK]

本文档描述了SNMP体系结构中简单网络管理协议(SNMP)消息的消息处理和调度。它定义了将可能多个版本的SNMP消息分派到适当的SNMP消息处理模型以及将PDU分派到SNMP应用程序的过程。本文档还描述了一种消息处理模型——SNMPv3消息处理模型。本文件淘汰了RFC 2572。[标准轨道]

3411 Harrington Dec 2002 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

3411 Harrington Dec 2002描述简单网络管理协议(SNMP)管理框架的体系结构

This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS TRACK]

本文档描述了用于描述简单网络管理协议(SNMP)管理框架的体系结构。该体系结构设计为模块化,以允许SNMP协议标准随着时间的推移而演变。该体系结构的主要部分是包含消息处理子系统、安全子系统和访问控制子系统的SNMP引擎,以及可能提供管理数据特定功能处理的多个SNMP应用程序。本文件淘汰了RFC 2571。[标准轨道]

3410 Case Dec 2002 Introduction and Applicability Statements for Internet Standard Management Framework


The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).


The architecture is designed to be modular to allow the evolution of the Framework over time.


The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.

本文档解释了为什么强烈建议使用SNMPv3而不是SNMPv1或SNMPv2。该文件还建议通过将RFC 1157、1441、1901、1909和1910移至历史状态,使其退役。本文件淘汰了RFC 2570。本备忘录为互联网社区提供信息。

3409 Svanbro Dec 2002 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression

3409 Svanbro 2002年12月鲁棒RTP/UDP/IP报头压缩低层指南

This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community.


3408 Liu Dec 2002 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile

3408 Liu Dec 2002在扩展链路层辅助鲁棒报头压缩(ROHC)配置文件中对双向可靠模式(R模式)的零字节支持

This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS TRACK]

除了RFC 3242中定义的两种模式外,本文档还定义了链路层辅助鲁棒报头压缩(ROHC)配置文件的另一种模式,也称为零字节配置文件。零字节报头压缩的存在是为了防止单个八位字节ROHC报头将分组语音流推送到下一个更高的无线电固定分组大小。它可用于某些广泛部署的老式空中接口。本文档将ROHC双向可靠模式(R模式)的零字节操作添加到RFC 3242中为报头压缩的单向(U模式)和双向乐观(O模式)模式指定的操作中。[标准轨道]

3407 Andreasen Oct 2002 Session Description Protocol (SDP) Simple Capability Declaration

3407 Andreasen 2002年10月会话描述协议(SDP)简单功能声明

This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS TRACK]


3406 Daigle Oct 2002 Uniform Resource Names (URN) Namespace Definition Mechanisms

3406 Daigle Oct 2002统一资源名称(URN)命名空间定义机制

This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

本文档列出了建立统一资源名称(URN)“名称空间”的一般定义和机制。URN工作组在RFC 2141中定义了URN的语法,并在RFC 3401和RFC 3405中为其解析和在Internet应用程序中使用提出了一些机制。整体基于URN结构中单个“名称空间”的概念。除了概念验证名称空间外,RFC 2288还讨论了URN中现有标识符的使用。本文件规定了互联网社区的最佳现行做法,并要求进行讨论和提出改进建议。

3405 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures


This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

本文档是“动态委托发现系统(DDDS)第一部分:综合DDDS”(RFC 3401)中完全指定的系列文档中的第五篇。需要注意的是,如果不阅读其他文档,就不可能阅读和理解本系列中的任何文档。本文件规定了互联网社区的最佳现行做法,并要求进行讨论和提出改进建议。

3404 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application


This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System.


This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK]

本文档是“动态委派发现系统(DDDS)第一部分:综合DDDS”(RFC 3401)中指定的系列的一部分。需要注意的是,如果不阅读其他文档,就不可能阅读和理解本系列中的任何文档。[标准轨道]

3403 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database


This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).


Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK]

由于本文档淘汰了RFC 2915,因此它是NAPTR DNS资源记录的官方规范。它也是“动态委托发现系统(DDDS)第一部分:综合DDDS”(RFC 3401)中完全指定的系列的一部分。需要注意的是,如果不阅读其他文档,就不可能阅读和理解本系列中的任何文档。[标准轨道]

3402 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm


This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK]

本文档描述了用于将动态检索的字符串转换规则应用于应用程序唯一字符串的动态委托发现系统(DDDS)算法。格式良好的转换规则将反映与字符串关联的信息管理的委托。本文档也是“动态委托发现系统(DDDS)第一部分:综合DDDS”(RFC 3401)中完全指定的系列的一部分。需要注意的是,如果不阅读其他文档,就不可能阅读和理解本系列中的任何文档。[标准轨道]

3401 Mealling Oct 2002 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS


This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.

本文档指定了构成完整的动态委派发现系统(DDDS)的确切文档。DDDS是一种抽象算法,用于将动态检索的字符串转换规则应用于应用程序唯一的字符串。本文件连同RFC 3402、RFC 3403和RFC 3404一起,已过时的RFC 2168和RFC 2915,以及RFC 2276的更新。本备忘录为互联网社区提供信息。

3400 Never Issued


RFC 3400 was never issued.

RFC 3400从未发行过。

Security Considerations


Security issues are not discussed in this memo.


Author's Address


Sandy Ginoza University of Southern California Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292

SoeGioZa南加州大学信息科学研究所4676海军路玛丽娜德雷,CA 90292

Phone: (310) 822-1511 EMail:


Full Copyright Statement


Copyright (C) The Internet Society (2003). All Rights Reserved.


This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.






Funding for the RFC Editor function is currently provided by the Internet Society.