RFC 3499 - Request for Comments Summary RFC Numbers 3400-3499 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3499
タイトル : RFC 3499 - コメントの概要RFC番号3400から3499の要求
翻訳編集 : 自動生成

[要約] RFC 3499は、RFC番号3400-3499の要約を提供します。このRFCの目的は、この範囲のRFCの概要を提供し、関連する情報を簡潔にまとめることです。

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のステータスレポートであるRFC 3499.を通じてRFC 3400から100のRFCのわずか注釈付きリストです。このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2003）。全著作権所有。

Note

注意

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は、すべてではなく、標準、ドラフト規格、または規格を提案しています。これらのRFCの状態が標準処理中に変更されることがありますので、我々は、彼らが標準軌道に乗っていることをここにしか注意してください。これらのRFCの現在の状態と状態のための「インターネット公式プロトコル標準」の最新版を参照してください。以下では、標準トラック上のRFCは[STANDARDS TRACK]とマークされています。

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

3499 Ginoza Request for Comments Summary

コメント概要について3499宜野座リクエスト

This memo.

このメモ。

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

同期光ネットワーク（SONET）リニア自動保護スイッチング（APS）アーキテクチャのための管理オブジェクトの3498のKuhfeld 2003の3月の定義

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]

このメモはTCP / IPベースのインターネットでネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、それは（APS）のアーキテクチャを切り替える同期光ネットワーク（SONET）線形自動保護を使用して管理するネットワーク用のオブジェクトを定義します。 [STANDARDS TRACK]

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

映画テレビ技術者協会（SMPTE）292Mビデオのための3497 Gharai 2003年3月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]

このメモは、映画テレビ技術者協会（SMPTE）標準、SMPTE 292Mで定義されている非圧縮の高精細度テレビ（HDTV）をカプセル化するためのRTPペイロード形式を指定します。 SMPTEは、モーションイメージング業界における主要標準化体であり、SMPTE 292M規格は、ローカルエリアHDTVの輸送のためのビットシリアルデジタルインターフェースを定義します。 [STANDARDS TRACK]

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

3496 Malis月非同期転送モード（ATM）サービスクラス対応のマルチプロトコルラベルスイッチング（MPLS）交通工学のサポートのための2003年議定書延長

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.

この文書では、非同期転送モード（ATM）サービスクラス対応のマルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリングをサポートするためのリソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）シグナリングの拡張子を指定します。このメモはインターネットコミュニティのための情報を提供します。

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

CableLabsのクライアント構成のための3495 Beser 2003年3月動的ホスト構成プロトコル（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]

この文書では、CableLabsのアーキテクチャ内に配備様々なデバイスを構成するために使用される動的ホスト構成プロトコル（DHCP）オプションを定義します。 PacketCableのメディアターミナルアダプタ（MTA）：具体的には、ドキュメントはCableLabsのクライアントデバイスの1つのクラスを構成するために使用されるDHCPオプションの内容を説明します。将来のCableLabsクライアントデバイスが開発されているとして、この文書内で定義されたオプションの内容が拡張されます。 [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ギリガン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は、1980年代初頭のUnix用に開発されましたが、それはまた、非Unixシステムの多種多様に実装されています。ソケットAPIを使って書かれたTCP / IPアプリケーションは、過去に移植性の高い学位を享受してきたし、我々は、IPv6アプリケーションと同じポータビリティをしたいと思います。しかし、変更はIPv6をサポートするためのソケットAPIに必要とこのメモは、これらの変更について説明しています。これらは、IPv6アドレス、新しいアドレス変換機能、およびいくつかの新しいソケットオプションを運ぶために新しいソケットアドレス構造体が含まれます。システムへの変更の最小値を導入し、既存のIPv4アプリケーションのための完全な互換性を提供しながら、これらの拡張機能は、マルチキャストなどのTCPおよびUDPアプリケーションで必要な機能の基本的なIPv6へのアクセスを提供するように設計されています。高度なIPv6機能（rawソケットとIPv6拡張ヘッダーへのアクセス）のための追加の拡張機能は、別の文書で定義されています。このメモはインターネットコミュニティのための情報を提供します。

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

3492コステロ2003年3月ピュニコード：アプリケーションにおける国際化ドメイン名の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]

ピュニコードは、アプリケーション（IDNA）で国際化ドメイン名で使用するために設計されたシンプルかつ効率的な転送エンコードの構文です。それはユニークかつ可逆ASCII文字列にUnicode文字列を変換します。 Unicode文字列内のASCII文字は、文字通り表現され、非ASCII文字は、ホスト名のラベル（文字、数字、およびハイフン）で許可されているASCII文字で表現されています。この文書は、基本的なコードポイントの列を一意により大きなセットから引き出されたコードポイントの任意の文字列を表現することを可能にするブートストリングと呼ばれる一般的なアルゴリズムを定義します。ピュニコードはIDNAのために適切な本文書で指定された特定のパラメータ値を使用してブートストリングのインスタンスです。 [STANDARDS TRACK]

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

3491ホフマン2003年3月NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）

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]

この文書では、世界中の一般的なユーザーのために意味をなすかの方法で入力し、名前の比較作業に名前を付ける可能性を高めるために、国際化ドメイン名（IDN）のラベルを準備する方法について説明します。文字列準備プロトコルのこのプロファイルは、ドメインネームシステム（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]

今までは、ASCIIレパートリー以外の文字を使用するには、ドメイン名のための標準的な方法がなかったです。この文書では、標準的な方法でそれらを処理するための国際化ドメイン名（IDN）及び（IDNA）アプリケーションにおける国際化ドメイン名と呼ばれるメカニズムを定義します。 IDNのは、大きなレパートリー（ユニコード）から引き出された文字を使用しますが、IDNAは、非ASCII文字は、すでに今日、いわゆるホスト名で許可されたASCII文字を使って表現することができます。 IDNドメインが既存のインフラストラクチャを変更せずに導入することができるように、この下位互換性の表現は、DNSのような既存のプロトコルに必要とされます。 IDNAはドメイン名のみではなく、フリーテキストを処理するためのものです。 [STANDARDS TRACK]

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

3489ローゼンバーグ2003年3月STUN - ユーザーの簡易トラバーサルネットワークを介してデータグラムプロトコル（UDP）アドレス翻訳者（NATの）

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]

ネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサル翻訳者（NATのを）アドレス（STUN）は、アプリケーションがそれらと公共のインターネット間のNATやファイアウォールの有無と種類を発見することを可能にする軽量なプロトコルです。また、NATによってそれらに割り当てられた公共のインターネットプロトコル（IP）アドレスを決定するアプリケーションのための機能を提供します。 STUNは多くの既存のNATで動作し、それらからの特別な動作を必要としません。その結果、既存のNATのインフラストラクチャを介して動作するため、多種多様なアプリケーションを可能にします。 [STANDARDS TRACK]

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

3488呉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）について説明します。このプロトコルは、シスコシステムズによって開発された、パケットが必要とされ得るそれらのルータにスイッチにマルチキャストパケットの転送を制限するマルチキャストルータとスイッチの間で使用されています。

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

RGMPは、バックボーンのために設計されているが、複数の高速ルータが相互接続されているネットワークを切り替えました。このメモはインターネットコミュニティのための情報を提供します。

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

セッション開始プロトコル（SIP）のためのリソースプライオリティメカニズムのための3487のSchulzrinneと2003の2月要件

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.

この文書では、セッション開始プロトコル（SIP）を使用して、防災通信用の回線交換ネットワーク、エンドシステムおよびプロキシリソースへのアクセスを優先順位付けするための要件をまとめたものです。このメモはインターネットコミュニティのための情報を提供します。

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

セッション開始プロトコル（SIP）を圧縮3486カマリロ2003年2月

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]

この文書は、一つ以上のセッション開始プロトコル（SIP）メッセージのために所望される圧縮をシグナリングするメカニズムを説明しています。 SIPエンティティに圧縮されたSIPメッセージを送信することが適切である場合にも述べています。 [STANDARDS TRACK]

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

3485ガルシア - マーチン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]

セッション開始プロトコル（SIP）は、通信セッションを開始し、管理するためのテキストベースのプロトコルです。プロトコルは、シグナリング圧縮（SigCompの）を使用して圧縮することができます。同様に、セッション記述プロトコル（SDP）は、セッション通知、セッション招待、およびマルチメディアセッション開始の他の形態の目的のために、マルチメディアセッションを記述するためのものテキストベースのプロトコルです。このメモは、SigCompのより高い効率を達成するために使用できるSIP / SDP固有の静的辞書を定義します。辞書は、独立した圧縮アルゴリズムです。 [STANDARDS TRACK]

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

3484インターネットプロトコルバージョン6（IPv6）のためのDraves 2003年2月のデフォルトのアドレス選択に

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.

この文書では、ソースアドレス選択のために、宛先アドレスの選択のために、2つのアルゴリズムを説明しています。アルゴリズムは、すべてのインターネットプロトコルバージョン6（IPv6）の実装のためのデフォルトの動作を指定します。彼らは、アプリケーションや上位層プロトコルによって行われた選択をオーバーライドしない、また彼らは、アドレス選択のためのより高度なメカニズムの開発を排除します。 2つのアルゴリズムを使用すると、管理者はデフォルトの動作をオーバーライドすることができ、ポリシーを提供することを可能にするための任意の機構を含む、共通のコンテキストを共有します。デュアルスタックの実装では、宛先アドレス選択アルゴリズムは、IPv4とIPv6の両方がアドレス考えることができる - 利用可能な送信元アドレスに応じて、アルゴリズムは、IPv4アドレス上のIPv6アドレスを好むかもしれない、またはその逆。

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

この仕様で定義されたホストとルータの両方を含むすべてのIPv6ノードは、デフォルトのアドレス選択を実装する必要があります。 [STANDARDS TRACK]

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

ポリシーのプロビジョニングと共通オープンポリシーサービスのポリシーの使用フィードバックのための3483ローリンズ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

概要：グローバル・交換電話網（GSTN）で3482フォスター2003年2月の番号ポータビリティ

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

この文書では、グローバルにE.164電話番号ポータビリティ（NP）の概要を説明します電話網（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の実装との相互運用の必要性は、IPテレフォニー機能し、進行中のIETFでの多数の分野に関連するトピックです。このメモはインターネットコミュニティのための情報を提供します。

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

3481稲村、エド。 2003年2月TCPセカンド（2.5G）と第3（3G）世代無線ネットワーク上で

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.

この文書では、第2（2.5G）と第3（3G）世代無線ネットワークを含むパスを処理するように適合させるためにTCPを最適化するためのプロファイルを記述する。これは、2.5Gおよび3Gネットワークの関連する特性、及びそのようなネットワークの例の展開の具体的な機能について説明します。その後、このようなパスで開始または終了することが知られているノードに対してTCPアルゴリズムの選択肢を推奨しています、そしてそれはまた、未解決の問題について説明します。このドキュメントで推奨設定オプションは、一般的に近代的なTCPスタックで見つかった、とコミュニティが一般的なインターネット上での使用のために安全と考えて広く利用可能な標準化過程メカニズムされています。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

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

CR-LDP（制約ルーティングラベル配布プロトコル）で3480のKompella 2003年2月シグナリングアンナンバードリンク

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）、無数のリンクをサポートするために必要とされているMPLS TEシグナリングプロトコルのいずれかを定義します。 [STANDARDS TRACK]

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

3479ファレル、エド。ラベル配布プロトコル（LDP）のために2003年2月フォールトトレランス

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.

マルチプロトコルラベルスイッチング（MPLS）システムは、システムのダウンタイムを最小限に保たなければならないコアネットワークに使用されます。多くのMPLSラベルスイッチングルータ（LSRの）は、従って、コアネットワークの高可用性を提供するために、フォールトトレラント（FT）ハードウェアやソフトウェアを利用することができます。

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は、ラベル配布プロトコル（LDP）、スイッチングハードウェア及びTCPを含むFT LSRの様々な構成要素、達成される方法の詳細は、実装固有です。この文書は、RFC 3036でLDP仕様の問題を特定し、それが困難な現在のLDPプロトコルを使用してFT LSRを実装し、そのようなFT LSRの実装を容易にするために、LDP仕様に拡張を定義するために行う、「LDP仕様」、。

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

ここで説明する問題と拡張は、（CR-LDP）RFC 3212、「LDPを使用して制約ベースのLSPのセットアップ」にも同様に適用可能です。 [STANDARDS TRACK]

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.

この文書では、MPLSを維持することができるのLSRに特にそのラベル配布プロトコル（LDP）コンポーネントの再起動により、ルータの（LSRの）コントロールプレーンの再起動をラベルスイッチングに起因するMPLSトラフィックに対する悪影響を最小限に抑えることができますメカニズムを説明します再起動の間で部品を転送します。

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.

（後者のニーズが本書で説明されたメカニズムのサブセットのみを実装するが）、この文書で説明されたメカニズムは、全てのLSR、LDP再始動時転送状態を維持する能力を有するものと有さないものの両方に適用可能です。（再起動を横切って彼らのMPLS転送状態を保存することができないのLSRによってここで説明されたメカニズムは、それらの制御プレーンの再起動によって引き起こされるMPLSトラフィックへの悪影響を低減しないであろう（のサブセット）を支持するが、それらの隣接場合には影響を最小にします単数または複数）は、それらの制御プレーンの再起動を横切って転送状態を維持することができ、ここで説明されたメカニズムを実装します。

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.

メカニズムは、再起動に渡って保持する必要があるかについて最小限の仮定を行う - のメカニズムは、実際のMPLSフォワーディングステートを保存する必要があることを想定しています。メカニズムは、再起動に渡って保持することがLDP関連の状態のいずれかを必要としません。

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]

このドキュメントで説明する手順は、下流迷惑ラベル配布に適用されます。オンデマンドラベル配布の下流にこれらの手順を拡張することは、今後の検討課題です。 [STANDARDS TRACK]

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

3477 Kompella 2003年1月シグナリングアンナンバードリンクリソースでの予約プロトコル - トラフィックエンジニアリング（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）、MPLS TEのシグナリングプロトコルの一つ、のためのリソース予約プロトコル（RSVP）の手順や拡張を定義します。 [STANDARDS TRACK]

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

ラベル配布プロトコル（LDP）、リソース予約プロトコル（RSVP）、およびリソース予約プロトコル - トラフィックエンジニアリングのためのIANA割り当ての3476 Rajagopalan 2003年3月ドキュメント（RSVP-TE）を光UNIシグナリングのための拡張機能

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.

光インターワーキングフォーラム（OIF）は、ラベル配布プロトコル（LDP）と光学ユーザ・ネットワーク・インタフェース（UNI）シグナリングのためのリソース予約プロトコル（RSVP）への拡張を定義しました。これらの拡張機能は、新しいデータ・オブジェクトとエラーコードのセットで構成されています。この文書では、これらの拡張機能について説明します。このメモはインターネットコミュニティのための情報を提供します。

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)

自動光ネットワーク（ASON）を交換するためにLDP（CR-LDP）の拡張機能を使用して制約ベースのLSP設定のためのIANA割り当ての3475のAboul-Magd 2003年3月ドキュメント

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.

自動光ネットワーク（ASON）は光ネットワークの制御プレーンの導入のために、ITU-T研究グループ15によって指定されたアーキテクチャであるスイッチ。 ASONアーキテクチャはASONアーキテクチャのエンティティ間の関係を定義する基準点のセットを指定します。これらの基準点で定義されたインタフェース上でシグナリングする一般化されたマルチプロトコルラベルスイッチング（GMPLS）作業の文脈においてIETFによって定義されるプロトコルを利用することができます。この文書では、ASON基準点で定義されたインタフェース上のシグナリングのためのLDP（CR-LDP）拡張を使用して、制約ベースLSP設定を記述する。文書の目的は、IANAは、CR-LDPの拡張のために必要なコード・ポイントを割り当てることを要求することです。 CR-LDPの拡張を使用するためのプロトコル仕様は、ITU-Tのドキュメントに記載されています。このメモはインターネットコミュニティのための情報を提供します。

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)

スイッチング汎用マルチプロトコルラベルのためのIANA割り当ての3474林2003年3月ドキュメンテーション（GMPLS）リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）使用し、自動的に交換光ネットワークのための拡張機能（ASON）

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).

プロトコル仕様の汎用マルチプロトコルラベルスイッチング（GMPLS）スイートは、異なる技術だけでなく、さまざまなアプリケーションのためのサポートを提供するために定義されています。これらは、同期光ネットワーク/同期デジタル階層（SONET / SDH）に基づいて、TDM接続だけでなく、光トランスポートネットワーク（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.

トラフィックエンジニアリング（RSVP-TE） - この文書では、特にリソース予約プロトコルを使用してGMPLSシグナリング、プロトコルのGMPLSスイートのシグナリング側面に集中します。これは、ASONネットワークの機能をサポートするために、これらのシグナリングプロトコルへの追加の拡張を提案しています。

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のASONの標準化作業を支援するためにITU-T研究グループ15で識別されると伝え追加要件の解決に向けた適切な拡張を提案しています。このメモはインターネットコミュニティのための情報を提供します。

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

3473バーガー2003年1月汎用マルチプロトコルラベルスイッチング（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]

この文書では、マルチプロトコルラベルスイッチングに拡張を記述する（MPLS）リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を一般化MPLSをサポートするために必要なシグナリング。一般MPLSは時分割（例えば、同期光ネットワークと同期デジタル・ハイアラーキ、SONET / SDH）、波長（光ラムダ）と空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を包含するMPLSコントロールプレーンを拡張します。このドキュメントは、拡張子のRSVP-TE具体的な説明を提示しています。一般的な機能の説明は別の文書に記載されています。 [STANDARDS TRACK]

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

3472アッシュウッド・スミス2003年1月汎用マルチプロトコルラベルスイッチング（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]

この文書は（MPLS）をマルチプロトコルラベルスイッチングに一般化MPLSをサポートするために必要なシグナリング制約ベースルーティングラベル配布プロトコル（CR-LDP）の拡張機能について説明します。一般MPLSは時分割（例えば、同期光ネットワークと同期デジタル・ハイアラーキ、SONET / SDH）、波長（光ラムダ）と空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を包含するMPLSコントロールプレーンを拡張します。このドキュメントは、拡張子のCR-LDP具体的な説明を提示しています。一般的な機能の説明は別の文書に記載されています。 [STANDARDS TRACK]

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

機能説明シグナリング3471ベルガー2003年1月汎用マルチプロトコルラベルスイッチング（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]

この文書では、マルチプロトコルラベルスイッチング（MPLS）一般MPLSをサポートするために必要なシグナルの拡張機能について説明します。一般MPLSは時分割（例えば、同期光ネットワークと同期デジタル・ハイアラーキ、SONET / SDH）、波長（光ラムダ）と空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を包含するMPLSコントロールプレーンを拡張します。この文書では、拡張の機能説明を提示しています。プロトコル固有の形式とメカニズム、および技術の特定の詳細が別の文書で指定されています。 [STANDARDS TRACK]

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

IETFプロトコル内の拡張マークアップ言語（XML）の使用のための3470のホレンベック2003年1月のガイドライン

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.

拡張マークアップ言語（XML）は、構造化データのためのフレームワークです。主に構造化文書に焦点を当てたマークアップ言語 - - それは標準一般化マークアップ言語（SGML）から進化しながら、XMLは、構造化データを表現するための広く使用されている機構であると進化してきました。

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.

開発中のインターネットプロトコルのさまざまながあります。多くは、彼らのアプリケーションに関連する構造化データの表現のために必要としています。表現方法としてXMLを使用することに多くの関心が集まっています。この文書では、基本的なXMLの概念を記述するXMLの使用中に様々な選択肢を分析し、IETF標準トラックプロトコル内でXMLを使用するためのガイドラインを提供します。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

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

3469シャルマ、エド。マルチプロトコルラベルのための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.

マルチプロトコルラベルスイッチング（MPLS）は、ネットワーク層ルーティングと転送パラダイムをスワッピングラベルを統合します。信頼性の高いサービスを提供するために、MPLSは異なるパスで運ばトラフィックの保護を提供するために、一連の手順が必要です。これは、ラベルスイッチングルータ（LSRの）支援障害検出、障害通知、および障害回復メカニズム、およびその回復の構成を、シグナリングのサポートをMPLSする必要があります。念頭に置いてこれらの目的で、このドキュメントでは、MPLSベースの回復のためのフレームワークを指定します。再起動の問題は、このフレームワークに含まれていません。このメモはインターネットコミュニティのための情報を提供します。

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

3468・アンダーソン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：ラベルスイッチパスのためのRSVPへの拡張（LSP）トンネル」（RFC 3209 ）トラフィックエンジニアリングアプリケーションのためのMPLSシグナリングプロトコルとして、及び（RFC 3212）「ラベル配布プロトコル（LDP）を使用して、制約ベースのLSPのセットアップ」に関連する新たな努力をしないように。セクション6の勧告はIESGによって受け入れられています。このメモはインターネットコミュニティのための情報を提供します。

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

ドメインネームシステム（DNS）の3467 Klensin 2003年2月の役割

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.

このドキュメントでは、ドメインネームシステム（DNS）の本来の機能と目的をレビュー。これは、DNSが最近適用されており、新しい需要のいくつかはそれのためにその上に配置されるか、または提案される目的の一部でその歴史を対比します。 DNS上でこれらの追加の応力を配置する代替のためのフレームワークは、次に概説します。このドキュメントおよびそのフレームワークを提案したソリューション、時間がそれらを解決するため、我々が直面している問題と可能なアプローチについて、より広く考え始めるようになってきたことだけ強く示唆ではありません。このメモはインターネットコミュニティのための情報を提供します。

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

コンテンツインターネットワーキングのための3466日2003年2月Aモデル（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.

コンテンツ（配信）インターネットワーキング（CDI）時には、以前に「コンテンツピアリング」または「CDNピアリング」と呼ばれる、コンテンツネットワークを相互接続するための技術です。一般的な語彙は、このような相互接続および相互運用を議論するプロセスを支援します。このドキュメントは、コンテンツネットワークとコンテンツのインターネットワーキングを導入し、そしてそのような共通の語彙のための要素を定義します。このメモはインターネットコミュニティのための情報を提供します。

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

適切なバイトカウントと3465オールマン2003年2月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.

このドキュメントでは、TCPが輻輳ウィンドウを大きくする方法に小さな変更を提案しています。むしろ各到着確認応答を一定量混雑ウィンドウを増加させる従来の方法よりも、文書が以前に不承認のバイト各ACKカバーの数の増加を基づか示唆する。この変更は、TCPのパフォーマンスが向上だけでなく、セキュリティホールのTCP受信機があまりにも急速に送信レートを上げるに送信者を誘導するために使用することができます閉じます。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

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

配信状態通知のための3464・ムーア2003年1月アン拡張可能なメッセージフォーマット

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.

このメモは、1人以上の受信者にメッセージを配信しようとする試みの結果を報告するためにメッセージ転送エージェント（MTA）または電子メールゲートウェイによって使用することができる多目的インターネットメール拡張（MIME）コンテンツタイプを定義します。このコンテンツタイプは、現在、インターネット、電子メールで使用される配信状態通知の様々なタイプの機械処理の代替として意図されます。

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]

多くのメッセージが（X.400など、いわゆるシステムの「ローカルエリアネットワーク（LAN）ベース」）は、インターネットや他のメッセージングシステムとの間で送信され、配信状態通知（DSN）のプロトコルをするのに有用であることが設計されていますので、マルチプロトコルのメッセージング環境。この目的のために、このメモで説明されたプロトコルは、通常、インターネットメールで使用されるものに加えて、「外来」アドレスとエラーコードのキャリッジを提供します。追加の属性は、インターネットメールを通じて外国の通知の「トンネリング」をサポートするために定義することができます。 [STANDARDS TRACK]

3463 Vaudreuil Jan 2003 Enhanced Mail System Status Codes

3463ヴォードルイユ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]

この文書では、配信状態報告、追跡、および改善された診断のためのメールシステム内で使用する拡張ステータスコードのセットを定義します。配信状態通知（DSN）配送レポートに提供される他の情報と組み合わせることで、これらのコードは、メッセージの配信ステータスのメディアや言語に依存しないレンダリングを促進します。 [STANDARDS TRACK]

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

3462ヴォードルイユ2003年1月メールシステム管理メッセージの報告のための複合/レポートのコンテンツタイプ

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.

マルチパート/レポートMIME（Multipurpose Internet Mail Extensions）コンテンツタイプは、あらゆる種類の電子メールレポートのための一般的な「家族」や「コンテナ」タイプです。このメモは、配送状態レポートに関して、マルチパート/レポートのコンテンツタイプの使用のみを定義していますが、単一のコンテンツ・タイプは、レポートのすべての種類のために使用されている場合、メール処理プログラムが利益になります。

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]

この文書では、配信ステータスレポートサービスを記述した4つのドキュメントセットの一部です。このコレクションは、簡易メール転送プロトコル（SMTP）配送状態レポート、配信レポートの報告、拡張ステータスコードの列挙、および配信レポートのためのマルチパートの容器、オリジナルメッセージのMIMEコンテンツを要求するための拡張機能、および含み故障の人に優しい要約。 [STANDARDS TRACK]

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

3461ムーア2003年1月のSMTP（Simple Mail Transfer Protocol）配信状態通知のためのサービス拡張（DSNの）

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]

このメモは、（b）は、このような通知は内容を返す必要があるかどうか、SMTPクライアントは、（a）はその配信状態通知（DSN）が一定の条件の下で生成されるように指定することを可能にする簡易メール転送プロトコル（SMTP）サービスへの拡張を定義しますメッセージ、及び（c）付加情報のうち、送信者がDSNが発行された受信者（複数可）、及び元のメッセージが送信されたトランザクションの両方を識別することを可能にするDSNで返されます。 [STANDARDS TRACK]

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

3460ムーア2003年1月方針コア情報モデル（PCIM）の拡張機能

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 [STANDARDS TRACK]

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

3459バーガー2003年1月重要なコンテンツ多目的インターネットメール拡張（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.

この文書では、送信者がマルチパートインターネットメールメッセージで重要と判断した体の部分を識別するためのメカニズムの使用を記載しています。 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]

低い性能のシステムへのゲートウェイサービスを提供する際、送信者が重要と考えるメッセージのどの部分を知ることで、コンテンツゲートウェイは、インテリジェントマルチパートメッセージを処理することができます。重要なコンテンツは、転送するためにどのような部品を決定するために、コンテンツゲートウェイを助けることができます。これは、ゲートウェイが身体の部分を提供しようとする必要がありますどのようにハード示すことができます。これは、低い性能のシステムがメッセージを受信したときに黙って削除しても安全な身体の部分を選択するためのゲートウェイを助けることができます。また、ゲートウェイを助けることができる重要なコンテンツは、受信システムの通知戦略を選びました。送信者は、本体部に何らかの処理を行うために先を見込んであれば同様に、重要なコンテンツは、送信者が受信機が処理しなければならない体の部分をマークすることができます。 [STANDARDS TRACK]

3458 Burger Jan 2003 Message Context for Internet Mail

インターネットメールのための3458バーガー2003年1月メッセージコンテキスト

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]

受信ユーザエージェント（UA）が最適にメッセージを提示するヒントとしてこの情報を使用することができます。 [STANDARDS TRACK]

3457 Kelly Jan 2003 Requirements for IPsec Remote Access Scenarios

IPsecリモートアクセスシナリオのための3457のケリー2003の1月要件

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.

IPsecは、安全なリモートアクセスメカニズムとして多くの約束を提供しています。しかし、それぞれがいくつかの共有した異なるリモートアクセスシナリオの数、およびいくつかのユニークな要件があります。これらの要件の完全な理解は、効果的に、任意の特定のリモートアクセスシナリオのためのメカニズムの特定のセットの適合性を評価するために必要です。この文書では、一般的なリモートアクセスシナリオの数の要件を列挙します。このメモはインターネットコミュニティのための情報を提供します。

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

IPsecトンネルモードの3456パテル2003年1月動的ホスト構成プロトコル（DHCPv4の）構成

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]

このメモはIPsecトンネルモードでホスト構成の要件を探り、および動的ホスト構成プロトコル（DHCPv4のは）コンフィギュレーションのために活用することができる方法を説明します。多くのリモートアクセスのシナリオでは、リモートホストがローカル企業ネットワーク上に存在するように見える作るためのメカニズムは非常に便利です。これは、企業ネットワークからホストに「仮想」アドレスを割り当て、その後、企業のセキュリティゲートウェイにホストのISPに割り当てられたアドレスからのIPsec経由でトラフィックをトンネリングすることによって達成することができます。 IPv4では、DHCPは、リモート・ホスト・コンフィギュレーションを提供します。 [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)

第三世代パートナーシッププロジェクト（3GPP）のためのセッション開始プロトコル（SIP）に3455ガルシア・マーティン2003年1月プライベートヘッダ（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.

この文書では、特定の環境に制限されているそれらの適用と共に、第三世代パートナーシッププロジェクト（3GPP）によって使用されるプライベートセッション開始プロトコル（SIP）のヘッダ（P-ヘッダ）のセットを記述する。 P-ヘッダはパートナーが充電と呼が横断するネットワークに関する情報を含む、使用するネットワーク内の種々の目的のためです。このメモはインターネットコミュニティのための情報を提供します。

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

国際化された文字列の3454ホフマン2002年12月の準備（「文字列前」）

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.

この文書では、世界中の一般的なユーザーのために意味をなすかの方法でその文字列を入力し、文字列の比較作業を可能性を高めるために、Unicodeテキスト文字列を製造するためのフレームワークについて説明します。文字列準備プロトコルは、プロトコル識別子値、会社や個人名、国際化ドメイン名、およびその他のテキスト文字列のために有用です。

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]

この文書では、プロトコルがテキスト文字列を準備する方法を指定しません。プロトコルは、完全処理オプションを指定するために文字列前のプロファイルを作成する必要があります。 [STANDARDS TRACK]

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

3453ルビー2002年12月の信頼できるマルチキャストでの前方誤り訂正（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.

このメモは効率的に提供及び/又はIPマルチキャストを用いて一対多信頼できるデータ転送のための信頼性を増強するための前方誤り訂正（FEC）符号の使用を記載しています。この文脈において、FECコードの重要な特性の一つは、同時に複数の受信機に異なるパケット損失パターンを修復するFECデータを含む同じパケットを使用する能力です。 FECコードとその基本的な性質のいくつかの異なるクラスが記載されており、信頼性の高いマルチキャストプロトコルにFECを実装に関連する用語が導入されます。例としては、FECを運ぶパケットのための可能な抽象フォーマットで提供されています。このメモはインターネットコミュニティのための情報を提供します。

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

3452ルビー2002年12月前方誤り訂正（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.

この文書では、一般的に効率的に提供および/またはデータ転送のための信頼性を強化するために誤り訂正（FEC）コードをフォワードの使用方法について説明します。このドキュメントの主な焦点は、IPマルチキャストを使用して1対多の信頼性の高いデータ転送にFECコードのアプリケーションです。この文書は、特定のFECコードを識別するために必要とされる情報を説明し、どのような情報は、FECコードを使用するアウトオブバンド通信される必要があり、彼らが運ぶ符号化シンボルを識別するために、データパケットにどのような情報が必要とされています。 FEC符号を指定してインターネット割り当て番号機関（IANA）でそれらを登録するための手順も記載されています。この文書では、と合わせて読むと、「信頼性マルチキャストにおける前方誤り訂正（FEC）の使用」というタイトルのコンパニオン文書の用語を使用してしなければなりません。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

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

3451ルビー2002年12月階層符号化トランスポート（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.

階層化符号化トランスポート（LCT）信頼性の高いコンテンツ配信とストリーム配信プロトコルのトランスポートレベルのサポートを提供します。 LCTは、具体的にはIPマルチキャストを使用してプロトコルをサポートするように設計されただけでなく、ユニキャストを使用するプロトコルへのサポートを提供しています。 LCTは、受信機に複数のレート配信を提供し、また、コンテンツの信頼できる配信を提供する符号化技術と互換性のある輻輳制御と互換性があります。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

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

3450ルビー2002年12月非同期階層符号化（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.

この文書では、非同期階層符号化（ALC）プロトコル、大規模なスケーラブルな信頼性の高いコンテンツ配信プロトコルを記述します。非同期階層符号化は階層化符号化トランスポート（LCT）ビルディングブロック、複数のレート混雑制御ビルディングブロックおよび単一の同時受信を無制限にコンテンツの輻輳制御信頼性のある非同期の配信を提供するために、前方誤り訂正（FEC）ビルディングブロックを合成します送信者。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3449 Balakrishnan Dec 2002 TCP Performance Implications of Network Path Asymmetry

ネットワークパスの非対称の3449のバラクリシュナン2002年12月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.

この文書では、不斉効果により発生するTCPのパフォーマンスの問題について説明します。これらの問題は別の根本的な理由のために、帯域幅非対称ネットワークとパケット無線サブネットワークを含むいくつかのアクセスネットワーク、中に発生します。しかし、TCPのパフォーマンス上の最終結果はどちらの場合も同じです：パフォーマンスは、多くの場合、受信側から送信側へのACKフィードバックであるため不完全と変動の大幅低下します。

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.

文書は、どちらかの提案や文学に評価、あるいは現在のネットワークで展開されてきたこれらの効果にいくつかの緩和策について詳しく説明しています。典型的には、ヘッダ圧縮を使用するか、減少させる、ACKを運ぶ上流のボトルネックリンクのために使用されるチャネルを管理するために、（I）技術：これらのソリューションは、以下からなる、ローカルリンク層技術、サブネットワーク、およびエンドツーエンドのメカニズムの組み合わせを使用しますTCP ACKの頻度は、（ii）の技術は、TCP送信者の確認応答トリガ自己クロッキング両者の存在下での性能を改善するために、逆方向のデータとACKパケットをスケジュールする（iii）の技術を維持するために、この減少ACK周波数を処理します-wayトラフィック。それぞれの技術が使用するために、既知の問題、および推奨事項とともに、記載されています。勧告の概要は、ドキュメントの端部に設けられています。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

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

3448 Handleyの2003年1月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]

このドキュメントでは、TCPフレンドリーレート制御（TFRC）を指定します。 TFRCは、ベストエフォート型のインターネット環境で動作するユニキャストフローの輻輳制御機構です。これは、帯域幅を競合するとき、TCPフローを合理的に公平であるが、そのような電話または比較的滑らかな送付レートが重要である場合、メディアストリーミングなどのアプリケーションのためにそれをより適切なものに、TCPに比べて時間をかけてスループットのはるかに低い変動を持っています。 [STANDARDS TRACK]

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

3447ヨンソン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)

プロトコル独立マルチキャスト（PIM）とマルチキャストソース発見プロトコルを使用して3446キム・2003年1月エニーキャストランデブーポイント（RP）メカニズム（MSDP）

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.

この文書では、単一の共有ツリープロトコル独立マルチキャスト - スパースモード（PIM-SM）ドメイン内のグループあたりRendevousポイント（RPS）の任意の数を可能にするメカニズムを説明しています。このメモはインターネットコミュニティのための情報を提供します。

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

KEYリソースレコード（RR）の範囲を限定3445マッセイ2002年12月

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]

この文書では、ドメインネームシステムセキュリティ拡張（DNSSEC）で使用される唯一のキーにドメインネームシステム（DNS）KEYリソースレコード（RR）を制限します。元のキーRRはDNSSECキーと任意のアプリケーションキーの両方を記憶するためにサブタイピングを使用しました。同じレコードタイプでDNSSECとアプリケーションキーの両方を格納することは間違いです。この文書では、KEY RRデータにプロトコルオクテットフィールドを再定義することによってKEYレコードからアプリケーションキーを削除します。アプリケーションキーを削除した結果、KEYレコード内のフラグのうちの1つを除くすべてが不要となり、再定義されています。既存の3つのアプリケーションキーのサブタイプは、予約に変更されますが、キーレコードの形式は変更されません。このドキュメントの更新RFC 2535 [STANDARDS TRACK]

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.

ネットワーク管理における管理対象オブジェクトを定義するための情報モデルとデータモデルの違いについて継続的な混乱がありました。この文書は、情報モデルの世界に収まると（IETFや、国際電気通信連合（ITU）または分散管理タスクフォース（DMTF）など他の機関からの）どのように既存のネットワーク管理モデルの仕様を解析することにより、これらの用語の違いを説明しますデータモデル。

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.

このメモは、テキサス大学オースティン校が主催するインターネットリサーチタスクフォースのネットワーク管理研究グループ（NMRG）（IRTF）の第8回ワークショップの主な結果を文書化します。このメモはインターネットコミュニティのための情報を提供します。

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

（MPLS）ネットワークのマルチプロトコルラベルスイッチングに（TTL）処理を生きて3443 Agarwalさん2003年1月の時間

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処理階層トンネルは「プッシュ」と「ポップ」の両方の場合の例で指定されています。文書はまた、一緒に階層MPLSネットワークにおけるTTL処理と、その文書に導入された用語をRFC 3270、「差別化サービスのMPLSのサポート」とのつながりを補完します。 [STANDARDS TRACK]

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

3442レモン2002年12月動的ホスト構成プロトコル（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]

この文書は、クライアントの静的ルートのリストを設定するには、DHCPサーバーからDHCPクライアントに渡され、新たな動的ホスト構成プロトコル（DHCP）オプションを定義します。これらの経路内のネットワーク宛先は、クラスレスである - 各ルーティングテーブルエントリは、サブネットマスクを含みます。 [STANDARDS TRACK]

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

メディアゲートウェイ制御プロトコルのための3441クマール1月3日、非同期転送モード（ATM）パッケージ（MGCP）

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のLyの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）の一部を定義します。特に、ADSL回線MIB（RFC 2662）でカバーされていない非対称デジタル加入者線（ADSL）のインターフェイスを管理するために使用される追加の管理対象オブジェクトについて説明します。 [STANDARDS TRACK]

3439 Bush Dec 2002 Some Internet Architectural Guidelines and Philosophy

3439のブッシュ2002年12月一部のインターネットの建築ガイドラインと哲学

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 2002年12月レイヤ2トンネリングプロトコル（L2TP）IANA（Internet Assigned Numbers Authority）の考慮事項更新

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.

この文書では、レイヤ2トンネリングプロトコル（L2TP）のためのIANA（Internet Assigned Numbers Authority）に配慮への更新について説明します。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

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

PPPリンク制御プロトコルネゴシエーションのための3437 Palter 2002年12月レイヤ2トンネリングプロトコル拡張機能

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]

この文書では、プロトコル（PPP）オプションをポイントにリンク固有のポイントの強化支援のためのレイヤ2トンネリングプロトコル（L2TP）への拡張を定義します。 PPPのエンドポイントは、通常、それらを接続する共通の物理メディアに直接アクセスすることは、したがって、使用されているメディアについての詳細な知識を持っています。 L2TPが使用される場合、2つのPPPピアは、もはや直接同じ物理媒体を介して接続されていません。代わりに、L2TPは、パケット上のPPPフレームをトンネリングすることによってPPP接続の一部または全部を超える仮想接続は、IPなどのネットワークを切り替える挿入します。いくつかの条件の下で、L2TPエンドポイントは、LCPネゴシエーションで適切な参加のために必要なメディア情報のすべてにアクセスすることがないかもしれない場所でのPPPリンク制御プロトコル（LCP）オプションを交渉する必要があるかもしれません。この文書では、L2TPトンネルの遠端にPPP LCPネゴシエーションの予めL2TPエンドポイントとの間の所望のLCPオプションを通信するための機構、ならびにネイティブPPPリンクが存在する場所に戻っネゴシエートLCPオプションを通信するためのメカニズムを提供します。 [STANDARDS TRACK]

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

ストリーム制御伝送プロトコル上で3436 Jungmaier 2002年12月トランスポート層セキュリティ

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 2960およびRFC 3309で定義されているように、ストリーム制御伝送プロトコル（SCTP）の上に、RFC 2246で定義されているように、トランスポート層セキュリティ（TLS）プロトコルの使用法を説明します。

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.

TLSのユーザは、即ち複数のストリームのサポートは、ラインブロックの先頭及びネットワークレベルのフォールトトレランスを提供するために、マルチホーミングのサポートを避けるために、SCTPによって提供される機能を利用することができます。

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

また、SCTPの拡張の議論はまた、IP-アドレスの動的再構成の特に支援を意味し、サポートされています。 [STANDARDS TRACK]

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

3435アンドレア1月3日メディアゲートウェイコントロールプロトコル（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.

この文書では、アプリケーション・プログラミング・インターフェースと分解マルチメディアゲートウェイの要素の間で使用される対応するプロトコル（MGCP）を記述する。分解マルチメディアゲートウェイは、ボイスオーバーIPへのTDM音声からの呼制御「知性」、およびメディア機能が含まれているメディア・ゲートウェイ、例えば、変換が含まれているコールエージェントで構成されています。

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.

基本的で一般的なMGCPプロトコルは本書で定義されている、しかし、ほとんどのメディア・ゲートウェイは、メディアゲートウェイの特定のタイプでの使用に適したプロトコルへの拡張を定義する1つのまたは複数のMGCPパッケージを、実装する必要があります。このようなパッケージは、別の文書で定義されています。このメモはインターネットコミュニティのための情報を提供します。

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

高容量アラームのための3434のBierman 2002年12月リモートモニタリング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）の一部を定義します。特に、Counter64のデータタイプに基づいて、オブジェクトの同様のしきい値監視を提供するために、リモートモニタリング（RMON）MIB（RFC 2819）に見出されるアラーム閾値機能を拡張するための管理対象オブジェクトを記述する。 [STANDARDS TRACK]

3433 Bierman Dec 2002 Entity Sensor Management Information Base

3433 Bierman 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 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）の一部を定義します。特に、それは多くの場合、ネットワーク機器に見出される物理的センサに関連する情報への一般のアクセスを提供するエンティティMIB（RFC 2737）を拡張するための管理オブジェクトについて説明（例えば、シャーシ温度、ファン回転数、電源電圧など）。 [STANDARDS TRACK]

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、音声アクティビティ検出）、および分析を簡素化することができるいくつかの例で見られるように。サンプリング方法は、ランダムな開始時刻と有限の長さのテストを義務付けることにより、予測可能性を回避します。サンプリング方法とサンプルメトリックパラメータの説明を以下、測定方法および誤差が議論されています。最後に、我々は、セキュリティ上の配慮を含む定期的な測定、に関する追加情報を提供します。 [STANDARDS TRACK]

3431 Segmuller Dec 2002 Sieve Extension: Relational Tests

3431 Segmuller 2002年12月ふるい拡張子：リレーショナルテスト

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で定義されてふるいメールフィルタリング言語へのリレーショナル拡張機能について説明します。彼らのコンテンツをテストすることに加えて、それはまた、ヘッダおよびエンベロープフィールド内のエンティティの数のテストを可能にします。 [STANDARDS TRACK]

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

3430 Schoenwaelder 2002年12月簡易ネットワーク管理プロトコル（SNMP）伝送制御を超えるプロトコル（TCP）トランスポートのマッピング

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（Simple Network Management Protocol）を使用するためのトランスポートマッピングを定義します。トランスポートマッピングは、SNMPのすべてのバージョンで使用することができます。この文書では、STD 62で定義されているトランスポートマッピングを拡張して、RFC 3417このメモは、インターネットコミュニティのためにExperimentalプロトコルを定義します。

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

アーキテクチャ（MPLS）動作及び保守（OAM）機能の切り替え「OAMの警告ラベル」forMultiprotocolラベルの3429太田2002年11月割り当て

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.

この文書は、アーキテクチャ（MPLS）OAM機能を切り替え、ユーザプレーンマルチプロトコルラベルで使用される「運用及び保守（OAM）警告ラベル」にRFC 3032で定義された予約ラベル値（MPLSラベルスタック符号化）のいずれかの割り当てを記述しMPLS OAMパケットを識別するため。このメモはインターネットコミュニティのための情報を提供します。

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

インスタントメッセージングのための3428キャンベル2002年12月のセッション開始プロトコル（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.

インスタントメッセージング（IM）は、ほぼリアルタイムでユーザー間のメッセージの転送を指します。これらのメッセージは通常ですが、短いである必要はありません。インスタントメッセージが頻繁に会話モードで使用されている、それは、メッセージの転送が前後にインタラクティブな会話を維持するために、参加者のために十分な速さ、です。

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]

この文書では、インスタントメッセージの転送を可能にするMESSAGEメソッド、セッション開始プロトコル（SIP）の拡張を提案しています。 MESSAGE要求はSIPの拡張であるため、そのプロトコルのすべての要求のルーティングおよびセキュリティ機能を継承します。 MESSAGEリクエストは、MIMEボディパーツの形でコンテンツを運びます。 MESSAGEリクエスト自体はSIPダイアログを開始しません。通常の使用では、各インスタントメッセージは、多くのポケベルメッセージのように、一人で立っています。 MESSAGEリクエストは、いくつかの他のSIP要求によって開始ダイアログのコンテキストで送信することができます。 [STANDARDS TRACK]

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

セッション開始プロトコル（SIP）のための3427のマンキン2002年12月変更処理

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.

このメモは、セッション開始プロトコル（SIP）の将来の発展に建築規律を適用することを目的とプロセスを説明します。新しいSIPの提案に関してに対する懸念がありました。具体的には、新しいSIP機能の追加は、セキュリティに向かって損傷及び/又は大幅プロトコルの複雑さを増大させることができます。交通エリアの取締役は、SIPおよびグループチェアワーキングセッション開始の提案調査（SIPPING）と一緒に、SIPの変更や拡張のための提案を提供しています。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

3426 Floyd Nov 2002 General Architectural and Policy Considerations

3426フロイド2002年11月の一般建築・ポリシーの考慮事項

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.

この文書は、IETFコミュニティは新しい規格やプロトコルに作業しているときに対処しなければならないことを、一般的な建築と政策の質問を示唆しています。私たちは、この文書が従うべきガイドラインや建築の原則とは反対に、対処すべき問題が含まれていることに注意してください。このメモはインターネットコミュニティのための情報を提供します。

3425 Lawrence Nov 2002 Obsoleting IQUERY

3425ローレンス2002年11月時代遅れ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操作を非難します。このドキュメントの更新RFC 1035 [STANDARDS TRACK]

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

ネットワークアドレス変換アクロス一方的な自己アドレス固定（UNSAF）のための3424のDaigle氏2002年11月IABの考慮事項

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.

ネットワークアドレス変換（NAT）のMiddleboxesの性質の結果として、一の以上のNATにより分離されている通信エンドポイントは、その（現在および将来）のアドレス範囲で有効なアドレスピアを使用して自分自身を参照する方法がわかりません。様々な提案が「一方的な自己アドレス固定（UNSAF）」のプロセスのために作られてきました。例えば、プロトコル交換のアドレスデータを使用できるように、またはからそのパブリックアドレスをアドバタイズする - これらは、それが別のエンドポイントに認識されているアドレス（およびポート）を決定または修正するためにいくつかの発信エンドポイントの試みはれるプロセスであります接続を受信します。

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.

この文書では、これらの提案は、最高の状態で特定の問題と慎重UNSAF提案を作成する前に評価されるべき具体的な問題への短期フィックスとして考えることができるの理由を概説します。このメモはインターネットコミュニティのための情報を提供します。

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

ネットワーク要素（CRANE）のための3423張2002年11月XACCTの一般的な信頼性の高い会計プロトコル仕様バージョン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.

この文書では、このような仲介システムとビジネスサポートシステム（BSS）/業務支援システムなどの任意のシステムへのネットワーク要素から主に会計データを任意のデータの効率的かつ信頼性の高い配信を可能にするネットワークエレメント（CRANE）プロトコルのための一般的な信頼性の高い会計を（定義しますOSS）。プロトコルは、ネットワーク、ストレージ、および処理リソースの効率的な利用とNEのから会計データの高いボリュームをエクスポートするための重要なニーズに対応するために開発されています。

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.

この文書は、すべてのCRANEプロトコル実装によってサポートされなければならないプロトコルおよびメッセージ形式のアーキテクチャを指定します。このメモはインターネットコミュニティのための情報を提供します。

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

3422岡本2002年11月フォワーディングメディアアクセス制御（MAC）フレーム同期光ネットワーク/同期デジタル階層（MAPOS）の上に、複数のアクセスプロトコル経由

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.

このメモは、このようにMAPOSネットワーク環境を統一するための方法を提供し、MACベースのローカルエリアネットワーク（LAN）環境では、同期光ネットワーク/同期デジタル階層（MAPOS）の上に多重アクセスプロトコルを介してメディアアクセス制御（MAC）フレームを転送する方法を説明し。このメモはインターネットコミュニティのための情報を提供します。

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

サービスロケーションプロトコル（SLP）のための3421趙2002年11月を選択し、ソート機能拡張

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.

このドキュメントでは、サービスロケーションプロトコル（SLP）のための2つの拡張（選択して、ソート）を定義します。これらの拡張機能は、ユーザーエージェント（UA）がサービス応答（SrvRply）内のURL（Uniform Resource Locator）のエントリが指定された数に制限すること、または指定したソートキーリストに従ってソートするように要求することができます。一緒にこれらの2つの拡張を使用することで、このような最高速度または最小負荷を持っているサービスを見つけて、ベストマッチを発見容易にすることができます。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3420 Sparks Nov 2002 Internet Media Type message/sipfrag

3420スパークス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]

この文書では、メッセージ/ sipfrag MIME（Multipurpose Internet Mail Extensions）のメディアタイプを登録します。このタイプのメッセージ/ SIPに類似しているが、十分に形成されたセッション開始プロトコル（SIP）メッセージの特定のサブセットではなく、完全なSIPメッセージを必要と表現されることを可能にします。エンドツーエンドにセキュリティが使用に加えて、メッセージ/ sipfragは、参照要求のステータスに関する情報を伝達するREFERメソッドで使用されています。 [STANDARDS TRACK]

3419 Daniele Dec 2002 Textual Conventions for Transport Addresses

トランスポートアドレスのための3419のダニエル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]

この文書は、一般的に使用されるトランスポート層アドレス情報を表現するテキストの表記法を定義する管理情報ベース（MIB）モジュールを導入します。定義は、管理情報バージョン2（SMIv2）の構造によって導入TAddress /のTDomainペアの概念と互換性があり、IPv4とIPv6の上のインターネット・トランスポート・プロトコルをサポートしています。 [STANDARDS TRACK]

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

簡易ネットワーク管理プロトコル（SNMP）のための3418 Presuhn 2002年12月管理情報ベース（MIB）

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）のエンティティの振る舞いを記述する管理対象オブジェクトを定義します。この文書では、簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2は、RFC 1907、管理情報ベースを廃止します。 [STANDARDS TRACK]

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

簡易ネットワーク管理プロトコル（SNMP）のための3417のPresuhn 2002年12月交通のマッピング

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

この文書では、さまざまなプロトコル経由のSNMP（Simple Network Management Protocol）メッセージのトランスポートを定義します。この文書では、[STANDARDS TRACK] RFC 1906を廃止します

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

3416 Presuhn 2002年12月簡易ネットワーク管理プロトコルのためのプロトコル操作のバージョン2（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を処理するための構文及び手順の要素を定義します。この文書では、[STANDARDS TRACK] RFC 1905を廃止します

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

3415簡易ネットワーク管理プロトコル（SNMP）のためのWijnenの2002年12月ビューベースアクセス制御モデル（VACMに）

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. [STANDARDS TRACK]

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

簡易ネットワーク管理プロトコルのバージョン3のための3414ブルーメンソール2002年12月ユーザベースセキュリティモデル（USM）（SNMPv3の）

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）が含まれています。この文書では、[STANDARDS TRACK] RFC 2574を廃止します

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

3413レビ2002年12月SNMP（Simple Network Management Protocol）アプリケーション

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.

この文書では、STD 62で説明したようにSNMPエンジンを利用して簡易ネットワーク管理プロトコル（SNMP）5種類のアプリケーションを記述し、RFC 3411で説明アプリケーションの種類は、コマンドジェネレータ、コマンド応答者、通知のオリジネーター、通知レシーバー、およびプロキシですフォワーダ。

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. [STANDARDS TRACK]

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

3412ケース2002年12月メッセージ処理と簡単なネットワーク管理プロトコル（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（Simple Network Management Protocol）メッセージのために派遣します。これは、適切なSNMPメッセージ処理モデルにSNMPメッセージの潜在的に複数のバージョンをディスパッチするため、およびSNMPアプリケーションにPDUをディスパッチするための手順を定義します。 SNMPv3のメッセージ処理モデル - この文書は、一つのメッセージ処理モデルについて説明します。このドキュメントは廃止RFC 2572. [STANDARDS TRACK]

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

簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するための3411ハリントン2002年12月アン・アーキテクチャ

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. [STANDARDS TRACK]

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

インターネット標準の管理フレームワークのための3410ケース2002年12月の序論と適用性声明

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).

このドキュメントの目的は、インターネット標準の管理フレームワークの3番目のバージョンの概要を提供することで、SNMPバージョン3の枠組み（SNMPv3の）と呼ばれます。このフレームワークは由来し、元のインターネット標準管理フレームワーク（SNMPv1の）及び第二インターネット標準管理フレームワーク（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.

SNMPv1またはSNMPv2のの代わりに、SNMPv3を使用が強く推奨される理由を文書で説明しています。文書はまたのRFC 1157、1441、1901、1909年と1910年は歴史的な状況に移動して引退することをお勧めします。この文書では、このメモはインターネットコミュニティのための情報を提供してRFC 2570を廃止します。

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

堅牢なRTP / UDP / IPヘッダ圧縮のための3409のSvanbro 2002年12月下位層のガイドライン

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.

この文書では、ロバストヘッダ圧縮（ROHC）およびROHCは、下層の上に置い要件については、下位層のガイドラインが記載されています。そのような第三世代パートナーシッププロジェクト（3GPP）、3GPPプロジェクト2（3GPP2）、ヨーロッパの技術基準によって指定されたもののような異なるシステムに、ROHCワーキンググループに指定され、この文書の目的は、ロバストヘッダ圧縮アルゴリズムの組み込みをサポートすることです研究所（ETSI）、等。このドキュメントは[RFC3095]で指定されるようにRTP / UDP / IPおよびUDP / IPヘッダの圧縮のためだけ下層ガイドラインを覆っています。どちらも一般的なガイドラインとセルラーシステムのための具体的なガイドラインは、このドキュメントで説明されています。このメモはインターネットコミュニティのための情報を提供します。

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

拡張リンク層における双方向信頼モード（Rモード）のための3408劉2002年12月のゼロバイトのサポートは、ロバストヘッダ圧縮（ROHC）プロフィールを支援します

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]

この文書は、3242 0バイトのヘッダー圧縮は単一のを防止するために存在するRFCに定義された2つ超え、ゼロバイトのプロファイルとして知られているリンク層支援ロバストヘッダ圧縮（ROHC）プロファイルの追加のモードを定義します無線の次に高い固定パケットサイズにパケット音声ストリームをプッシュからオクテットROHCヘッダ。これは、特定の広く配備古いエアインタフェースで使用可能です。この文書では、[STANDARDS TRACK] RFC 3242でヘッダ圧縮の一方向（Uモード）と双方向楽観（Oモード）モードに指定されたものにROHC双方向信頼できるモード（Rモード）ゼロバイトの操作を追加します

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

3407アンドレア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]

この文書では、セッション記述プロトコル（SDP）のセットはそれが最小と後方互換性能力宣言機構を提供するために、SDPを可能にする属性を定義します。そのような能力の宣言は、この文書の範囲外の手段によって行われる後続のセッションネゴシエーションへの入力として使用することができます。これはまた、SDPngとして知られているSDPの次世代によって対処されている一般的な能力交渉問題に対する簡単かつ限られた解決策を提供します。 [STANDARDS TRACK]

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

3406 Daigle氏2002年10月ユニフォームリソース名（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 . 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 WGは、その解決のためにRFC 2141でのURNの構文だけでなく、いくつかの提案のメカニズムを定義し、RFC 3401でインターネットアプリケーションで使用しています。全体がURN構造内の個々の「名前空間」をコンセプトにかかっています。別に概念実証の名前空間から、URNの中の既存の識別子を使用することは、RFC 2288.この文書は、インターネットコミュニティのためのインターネットBest Current Practicesを指定するに議論し、された改良のために議論と提案が。

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

3405 Mealling 2002年10月ダイナミックな委譲発見システム（DDDS）パートファイブ：URI.ARPA割り当て手順

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.

（RFC 3401）：この文書は、完全に「包括DDDSダイナミックな委譲発見システム（DDDS）第一部」に指定されている直列に第五です。他の人を読まず、このシリーズでは、任意のドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

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

3404 Mealling 2002年10月ダイナミックな委譲発見システム（DDDS）第四部：統一資源識別子（URI）解像度アプリケーション

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.

この文書では、統一資源識別子（URI）を取り、そのURIについては、権限のあるサーバーを見つけるための仕様を説明しています。その権威サーバーを検索するために使用される方法は、ダイナミックな委譲発見システムです。

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]

（RFC 3401）：この文書では、「包括DDDSダイナミックな委譲発見システム（DDDS）第一部」に指定されているシリーズの一部です。他の人を読まず、このシリーズでは、任意のドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。 [STANDARDS TRACK]

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

3403 Mealling 2002年10月ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース

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).

この文書では、ルールの分散データベースとしてドメインネームシステム（DNS）を使用して、ダイナミックな委譲発見システム（DDDS）データベースを説明しています。キーは、ドメイン名であるとルール命名権限ポインタ（NAPTR）リソースレコード（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リソースレコードのための公式の仕様です。（RFC 3401）：それはまた、完全に「包括DDDSダイナミックな委譲発見システム（DDDS）第一部」に指定されているシリーズの一部です。他の人を読まず、このシリーズでは、任意のドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。 [STANDARDS TRACK]

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

3402 Mealling 2002年10月ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム

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）アルゴリズムを記載しています。整形式の変換ルールは、文字列に関連付けられた情報の管理の委任を反映します。（RFC 3401）：この文書はまた、完全に「包括DDDSダイナミックな委譲発見システム（DDDS）第一部」に指定されているシリーズの一部です。他の人を読まず、このシリーズでは、任意のドキュメントを読んで理解することは不可能であることに注意することが非常に重要です。 [STANDARDS TRACK]

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

3401 Mealling 2002年10月ダイナミックな委譲発見システム（DDDS）第一部：総合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 obsolete and , as well as updates RFC 2276. This memo provides information for the Internet community.

この文書では、完全な動的委任発見システム（DDDS）を構成する正確な文書を指定します。 DDDSは、アプリケーション固有の文字列を動的に検索された文字列の変換規則を適用するための抽象化アルゴリズムです。 RFC 3402、RFC 3403および時代遅れと、だけでなく、アップデートをRFC 2276と一緒にこの文書では、このメモはインターネットコミュニティのための情報を提供します。

3400 Never Issued

3400は、発行されたことはありません

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

南カリフォルニア情報科学研究所のサンディ・宜野座大学4676アドミラルティWayマリナデルレイ、CA 90292

Phone: (310) 822-1511 EMail: ginoza@isi.edu

電話：（310）822-1511 Eメール：ginoza@isi.edu

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2003）。全著作権所有。

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.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。

Acknowledgement

謝辞

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。