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

                      Request for Comments Summary
        

                         RFC Numbers 3500-3599
        

Status of This Memo

このメモのステータス

This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. 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 3599.を通じてRFC 3500から100のRFCのわずか注釈付きリストです。このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

著作権（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
---     ------          ----            -----
        

3599 Ginoza Request for Comments Summary

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

This memo.

このメモ。

3598 Murchison Sep 2003 Sieve Email Filtering -- Subaddress Extension

3598マーチソン2003年9月ふるい迷惑メールフィルタリング - サブアドレス拡張

On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. [STANDARDS TRACK]

「サブアドレス」または「アドレッシング詳細」（例えば、「ken+sieve@example.org」）を可能にする電子メールシステムでは、アドレスのこれらのサブ部分に対して比較を行うことが望ましい場合があります。この文書では、ユーザーがアドレスのユーザーと細部の部品と比較することを可能にするふるいのメールフィルタリング言語に拡張を定義します。 [STANDARDS TRACK]

3597 Gustafsson Sep 2003 Handling of Unknown DNS Resource Record (RR) Types

3597グスタフソン2003年9月取扱い不明のDNSリソースレコード（RR）の種類

Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS TRACK]

新しいリソースレコード（RR）の種類とドメインネームシステム（DNS）を拡張すると、現在のネームサーバソフトウェアを変更する必要があります。この文書は、将来のDNS実装が透過的に新しいRRタイプを処理することを可能にするために必要な変更を指定します。 [STANDARDS TRACK]

3596 Thomson Oct 2003 DNS Extensions to Support IP Version 6

IPバージョン6をサポートするために3596のトムソン2003年10月DNS拡張機能

This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS TRACK]

この文書では、IPバージョン6（IPv6）を実行しているホストをサポートするために、ドメインネームシステム（DNS）に施す必要のある変更を定義します。変更は、IPv6アドレスを格納するためのリソースレコードタイプ、IPv6アドレスに基づいて検索をサポートするために、ドメイン、および追加セクション処理の一環として、インターネットアドレスを返す既存のクエリの種類の更新された定義が含まれています。拡張子は自身の特定、DNSの実装では、既存のアプリケーションとの互換性となるように設計されています。 [STANDARDS TRACK]

3595 Wijnen Sep 2003 Textual Conventions for IPv6 Flow Label

IPv6のフローラベルのための3595のWijnenの2003年9月テキストの表記法

This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK]

このMIBモジュールは、一般的に使用されたIPv6フローラベルを表すためにテキストの表記法を定義します。意図は、これらのテキストの表記法は（TC）がインポートされ、そうでない場合は、独自の表現を定義するMIBモジュールで使用されるということです。 [STANDARDS TRACK]

3594 Duffy Sep 2003 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option

DHCP CableLabsのクライアント構成（CCC）オプションのための3594ダフィー2003年9月のPacketCableセキュリティチケット制御サブオプション

This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS TRACK]

この文書では、DHCP CableLabsのクライアント構成（CCC）オプションの新しいサブオプションを定義します。この新しいサブオプションが（すなわち、ローカルセキュリティチケットを持続）CCD不揮発性メモリに格納されたセキュリティチケットを無効にするためにCableLabsのクライアント素子（CCD）を指示するために使用されます。 [STANDARDS TRACK]

3593 Tesink, Ed. Sep 2003 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals

3593 Tesink、エド。 15分間隔に基づいて、パフォーマンス履歴を使用してMIBモジュールのための2003年9月テキストの表記法

This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals.

この文書では、15分間隔に基づいて、性能履歴データを利用するMIBモジュールのためのテキストの表記法のセットを定義します。

This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS TRACK]

このメモはRFC 2493に比べては、MIBモジュールのREVISION節に要約されているRFC 2493.変更を置き換えます。 [STANDARDS TRACK]

3592 Tesink Sep 2003 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type

同期光ネットワーク/同期デジタル階層（SONET / SDH）インターフェイスの種類のための管理オブジェクトの3592のTesink 2003の9月の定義

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 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types.

このメモは、TCP / IPベースのインターネットでネットワーク管理プロトコルと共に使用するための管理情報ベース（MIB）の一部を画定します。特に、それは、同期光ネットワーク/同期デジタル階層（SONET / SDH）インタフェースを管理するためにオブジェクトを定義します。この文書では、DS1 / E1 / DS2 / E2およびDS3 / E3インターフェイスタイプに管理対象オブジェクトを定義するドキュメントへの仲間です。

This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS TRACK]

このメモはRFC 2558に比べては、MIBモジュールのREVISION節に要約されているRFC 2558.変更を置き換えます。 [STANDARDS TRACK]

3591 Lam Sep 2003 Definitions of Managed Objects for the Optical Interface Type

光インタフェースタイプのための管理オブジェクトの3591のラム2003の9月の定義

This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872.

このメモはTCP / IPベースのインターネットでのSNMP（Simple Network Management Protocol）で使用するための管理情報ベース（MIB）の一部を定義します。特に、光インターフェース波長分割多重化システムに関連する、またはITU-T勧告G.872で定義されたOTNアーキテクチャによる光トランスポートネットワーク（OTN）によって特徴づけを管理するためにオブジェクトを定義します。

The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS TRACK]

このメモで定義されたMIBモジュールは、性能監視および/またはそのような光インターフェースのコンフィギュレーションのために使用することができます。 [STANDARDS TRACK]

3590 Haberman Sep 2003 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol

Multicast Listener Discovery（MLD）プロトコルのための3590ハーバーマン2003年9月ソースアドレス選択

It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS TRACK]

これは、ノードがステートレスアドレス自動設定を実行しているマルチキャストリスナ発見（MLD）メッセージに適したIPv6ソースアドレスの選択に問題があることが明るみに出ました。この文書は、MLDメッセージのために使用するIPv6アドレスを選択する上でのルールを明確にすることを意図しています。 [STANDARDS TRACK]

3589 Loughney Sep 2003 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5

第三世代パートナーシッププロジェクト（3GPP）リリース5のための3589のLoughney 2003年9月直径コマンドコード

This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community.

この文書では、第三世代パートナーシッププロジェクト（3GPP）この文書では、これらのコマンドコードの使用上の判断を渡すことはありません5.リリースの直径コマンドコードのブロックのIANAの割り当てについて説明します。更に、これらのコマンドコードは、将来のリリースのリリース5のために使用するためのもので、これらのコードを再利用することはできないが、直径の基本仕様に応じて割り当てられなければなりません。このメモはインターネットコミュニティのための情報を提供します。

3588 Calhoun Sep 2003 Diameter Base Protocol

3588カルフーン2003年9月直径ベースプロトコル

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS TRACK]

直径ベースプロトコルは、ネットワークアクセス又はIPモビリティなどのアプリケーションのための認証、認可およびアカウンティング（AAA）フレームワークを提供することを目的とします。直径はまた、ローカル認証、認可およびアカウンティングおよびローミング状況の両方で動作することが意図されています。この文書は、すべてのDiameterアプリケーションが使用するメッセージ・フォーマット、輸送、エラー報告、会計及びセキュリティサービスを指定します。直径ベースアプリケーションは、すべてのDiameter実装によってサポートされる必要があります。 [STANDARDS TRACK]

3587 Hinden Aug 2003 IPv6 Global Unicast Address Format

3587 Hindenと2003年8月のIPv6グローバルユニキャストアドレスフォーマット

This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.

この文書はRFC 2374、「IPv6の集約可能グローバルユニキャストアドレス形式」を廃止します。これは、トップレベルアグリゲータ（TLA）、次のレベルアグリゲータ（NLA）を備えたIPv6アドレス割当構造を定義しました。この文書は、RFC 2374およびTLA / NLA構造歴史的になります。このメモはインターネットコミュニティのための情報を提供します。

3586 Blaze Aug 2003 IP Security Policy (IPSP) Requirements

3586ブレイズ2003年8月IPセキュリティポリシー（IPSP）の要件

This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements. [STANDARDS TRACK]

この文書では、IPセキュリティポリシー（IPSP）の構成と管理のフレームワークを開発するための問題空間とソリューションの要件について説明します。 IPSPアーキテクチャは、アクセス、承認、認証、機密性、データの整合性、および他のIPセキュリティの性質を支配するホストおよびネットワークのセキュリティポリシーを、管理発見し、交渉のためのスケーラブルな、分散型のフレームワークを提供します。この文書では、このようなアーキテクチャコンポーネントを強調し、その機能要件を提示します。 [STANDARDS TRACK]

3585 Jason Aug 2003 IPsec Configuration Policy Information Model

3585ジェイソン・2003年8月のIPsecポリシーの設定情報モデル

This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model.

この文書は、IPsecポリシーの内容と意味論に関する合意を促進するように設計されたIPセキュリティ（IPSec）ポリシーのオブジェクト指向の情報モデルを提示し、そのようなストレージスキーマ、分布表現、およびポリシーなどのIPsecポリシーのタスク固有の表現の導出を可能に仕様記述言語は、IPsec対応のエンドポイントを設定するために使用します。情報モデルは、この文書モデルのIPsecによって定義された設定パラメータを記載しました。情報モデルは、インターネット鍵交換プロトコル（IKE）によって発見パラメータをカバーしています。その他の鍵交換プロトコルは、簡単な拡張により、情報モデルに追加することができます。さらなる拡張はさらにによるモデルのオブジェクト指向の性質のために容易に追加することができます。

This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS TRACK]

この情報モデルは方針コア情報モデル（PCIM）にし、政策コア情報モデルの拡張（PCIMe）で定義されているコアポリシークラスに基づいています。 [STANDARDS TRACK]

3584 Frye Aug 2003 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

3584フライ2003年8月の共存バージョン1、バージョン2、およびインターネット標準ネットワーク管理フレームワークのバージョン3の間

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

この文書の目的は、インターネット標準ネットワーク管理フレームワーク（SNMPv3の）、インターネット標準ネットワーク管理フレームワーク（SNMPv2の）、元インターネット標準ネットワーク管理フレームワーク（SNMPv1のバージョン2のバージョン3との間の共存を説明することです）。この資料はまたSMIv2の形式にでSMIv1形式からMIBモジュールを変換する方法について説明します。この文書は、RFC 2576このドキュメントは、インターネットコミュニティのためのインターネットBest Current Practicesを指定廃止、および改良のために議論と提案が。

3583 Chaskar, Ed. Sep 2003 Requirements of a Quality of Service (QoS) Solution for Mobile IP

3583 Chaskar、エド。 9月のサービス品質の2003の要件（QoS）のモバイルIPのためのソリューション

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. This memo provides information for the Internet community.

モバイルノードは、インターネットへの接続点を変更するようにモバイルIPは、モバイルノードへのパケットの正しいルーティングを確実にします。しかし、またのQoSに敏感なIPサービスは、モバイルIPを介してサポートすることができるように、ネットワーク内の中間ノードに移動ノードのパケットストリームへのサービス（QoS）の転送処理の適切な品質を提供するために必要とされます。この文書では、モバイルIPとの満足な動作のためのIP QoSメカニズムのための要件について説明します。このメモはインターネットコミュニティのための情報を提供します。

3582 Abley Aug 2003 Goals for IPv6 Site-Multihoming Architectures

3582 Abley 8月のIPv6サイトマルチホーミングアーキテクチャのための2003年目標

This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community.

この文書は、提案された新しいIPv6サイトマルチホーミングアーキテクチャの目標のセットを概説します。目標のこのセットは、野心的であることが認識されていると、いくつかの目標が他の人と競合する可能性があること。採用されたソリューションやソリューションは、ここでしか提示目標のいくつかを満たすことができるかもしれません。このメモはインターネットコミュニティのための情報を提供します。

3581 Rosenberg Aug 2003 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

対称応答ルーティングのためのセッション開始プロトコル（SIP）に3581ローゼンバーグ2003年8月アン延長

The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS TRACK]

セッション開始プロトコル（SIP）は、とりわけ、UDPおよびTCP上で動作します。 UDPで使用する場合、要求への応答が送信元アドレスに返される要求がから、要求の最上位Viaヘッダーフィールド値に書き込まれたポートに来ました。クライアントがネットワークアドレス変換（NAT）の背後にあるとき、この動作は、最も顕著なのは、多くの場合、望ましいことではありません。この拡張は、クライアントがサーバが要求の発信元のソースIPアドレスとポートに応答を送信することを要求することを可能にする「RPORT」と呼ばれるViaヘッダーフィールド、のための新しいパラメータを定義します。 [STANDARDS TRACK]

3580 Congdon Sep 2003 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines

ユーザーサービス3580コングドン2003年9月IEEE 802.1Xのリモート認証ダイヤル（RADIUS）使用上のガイドライン

This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

このドキュメントでは、IEEE 802.1Xオーセンティケータにより、ユーザーサービス（RADIUS）の使用法ではリモート認証ダイヤルの提案を提供します。この文書に記載されている材料はまた、IEEE 802.1X規格内の非規範付録の中に含まれており、情報提供の目的のためにIETF RFCとして提示されています。このメモはインターネットコミュニティのための情報を提供します。

3579 Aboba Sep 2003 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)

3579拡張認証プロトコル（EAP）についてはAboba 2003年9月RADIUS（ユーザサービスにおけるリモート認証ダイヤル）サポート

This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community.

このドキュメントでは、ユーザーサービス（RADIUS）拡張認証プロトコル（EAP）、複数の認証メカニズムをサポートしている認証フレームワークのサポートでリモート認証ダイヤルを定義します。提案方式では、ネットワークアクセスサーバー（NAS）がEAP-メッセージ属性内にカプセル化、およびRADIUSサーバからEAPパケットを転送します。これは、NASは、RADIUSサーバ上に存在するメソッド固有のコードを必要とせずに、任意のEAP認証方式をサポートするために可能にするという利点を有します。 EAPは、もともとPPPで使用するために開発されたが、それはまた、このメモはインターネットコミュニティのための情報を提供し、IEEE 802で現在使用中です。

3578 Camarillo Aug 2003 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)

セッション開始プロトコル（SIP）にシグナリングオーバーラップ統合サービスデジタル網の3578カマリロ2003年8月のマッピング（ISDN）ユーザ部（ISUP）

This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS TRACK]

この文書では、セッション開始プロトコル（SIP）へのシグナリング重複総合デジタル通信サービス網ユーザ部（ISUP）をマップする方法を説明します。公衆交換電話網（PSTN）との通話の一部は、インターワーキングを必要とする環境にSIPを使用する場合は、このメカニズムが実装されることがあります。 [STANDARDS TRACK]

3577 Waldbusser Aug 2003 Introduction to the Remote Monitoring (RMON) Family of MIB Modules

MIBモジュールのリモートモニタリング（RMON）ファミリーに3577 Waldbusser 2003年8月はじめに

The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. This memo provides information for the Internet community.

リモートモニタリング（RMON）フレームワークは、相互に関連ドキュメントの数で構成されています。このメモは、これらの文書を説明し、彼らが互いにどのように関連しますか。このメモはインターネットコミュニティのための情報を提供します。

3576 Chiba Jul 2003 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)

ユーザーサービス（RADIUS）でリモート認証ダイヤルに3576の千葉2003年7月のダイナミックな承認拡張

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

この文書では、ネットワークアクセスサーバ製品によって実装され、ユーザーセッションの動的な変更を許可するユーザーサービス（RADIUS）プロトコルでは、リモート認証ダイヤルに現在配備の拡張について説明します。これは、ユーザーを切断し、ユーザセッションに適用される権限を変更するためのサポートが含まれています。このメモはインターネットコミュニティのための情報を提供します。

3575 Aboba Jul 2003 IANA Considerations for RADIUS (Remote Authentication Dial In User Service)

RADIUSのための3575のAboba 2003年7月IANAの考慮事項（ユーザサービスにおけるリモート認証ダイヤル）

This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS TRACK]

このドキュメントでは、ユーザーサービス（RADIUS）でリモート認証ダイヤルインのためにIANAの考慮事項について説明します。 [STANDARDS TRACK]

3574 Soininen, Ed. Aug 2003 Transition Scenarios for 3GPP Networks

3574 Soininen、エド。 3GPPネットワークのため2003年8月の移行シナリオ

This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community.

この文書では、第三世代パートナーシッププロジェクト（3GPP）IPバージョン6とIPバージョン4遷移を必要とする定義されたパケットネットワーク、すなわち、汎用パケット無線サービス（GPRS）の異なるシナリオを説明しています。この文書の焦点は、ユーザ機器（UE）は、インターネットで、例えば、他のネットワーク内のノードに接続するシナリオです。ネットワーク内の異なるGPRS要素間のGPRSネットワーク内部移行シナリオ、すなわち、範囲外です。ドキュメントの目的は、さらなる議論や研究のためのシナリオをリストアップすることです。このメモはインターネットコミュニティのための情報を提供します。

3573 Goyret Jul 2003 Signaling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)

レイヤでのモデム・オン・ホールド状態の3573 Goyret 2003年7月シグナリング2トンネリングプロトコル（L2TP）

The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network.

レイヤ2トンネリングプロトコル（L2TP）がトンネリングポイントツーポイントプロトコル（PPP）セッションのためのメカニズムを定義します。これらのPPPセッションは、公衆交換電話網を介して接続されたモデムを使用して確立されることが一般的です。

One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls.

モデムの操作を管理する基準の一つは、保留に電話を入れて、後で、最小限の遅延でリダイヤルすることなく、モデムリンクを再確立するためのクライアントモデムを有効にする手順を定義します。モデムコールが保留されますが、クライアント電話回線は、他の電話をかけるまたは受信するために使用することができます。

The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled.

L2TPベースのプロトコルは、モデムがPPPセッションが処理されるL2TPネットワークサーバー（LNS）に、物理的に接続されているL2TPアクセスコントローラ（LAC）からこれらのイベントを通知するための任意の手段を提供しません。

This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS TRACK]

この文書では、LNSは、LACに接続されたクライアントモデムが保留に電話を置いたときに知らせる方法を説明しています。 [STANDARDS TRACK]

3572 Ogura Jul 2003 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH)

MAPOS以上3572小倉2003年7月インターネットプロトコルバージョン6（SONET / SDHを介して複数のアクセスプロトコル）

Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH).

SONET / SDH（MAPOS）の上に複数のアクセスプロトコルは、同期光ネットワーク/同期デジタル階層（SONET / SDH）を介して複数のアクセス機能を提供する高速リンク層プロトコルです。

This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. This memo provides information for the Internet community.

この文書はMAPOSフレームでIPv6データグラムをカプセル化するためのフレームフォーマットを指定します。また、IPv6インタフェース識別子を形成する方法、重複アドレスを検出する方法、およびIPv6近隣探索メッセージで使用されるソース/ターゲットリンク層アドレスオプションフィールドの形式を指定します。このメモはインターネットコミュニティのための情報を提供します。

3571 Rawlins Aug 2003 Framework Policy Information Base for Usage Feedback

使用フィードバックのための3571ローリンズ2003年8月枠組みの方針情報ベース

This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device.

このドキュメントは、デバイスにポリシーの使用状況の収集と報告を制御するポリシー情報ベース（PIB）の一部を説明しています。

The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported.

ここで指定されたプロビジョニング・クラスは、ポリシーオブジェクトが使用情報を収集するかを選択するためのポリシー決定ポイント（PDP）は、どのような情報を収集する必要があり、それを報告しなければならないときが可能。

This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community.

このPIBは、使用情報が収集されたポリシー・オブジェクトを提供する他のPIB（他の場所で定義される）の存在を必要とします。このメモはインターネットコミュニティのための情報を提供します。

3570 Rzewski Jul 2003 Content Internetworking (CDI) Scenarios

3570 Rzewski 2003年7月のコンテンツのインターネットワーキング（CDI）のシナリオ

In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. This memo provides information for the Internet community.

生産ネットワークで使用するための標的技術などのコンテンツインターネットワーキングの説明においては、2つのコンテンツネットワークが相互接続することを決定するときに発生する可能性のあるイベントのシーケンスの例を提供することが有用です。ここで紹介するシナリオは、コンテンツのインターネットワーキングが何であるかのいくつかの具体的な例を提供するために、また、コンテンツのインターネットワーキング提案を評価するための基礎を提供することを求めます。このメモはインターネットコミュニティのための情報を提供します。

3569 Bhattacharyya Jul 2003 An Overview of Source-Specific Multicast (SSM)

ソース固有マルチキャストの3569バッタチャリヤ2003年7月概況（SSM）

The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community.

このドキュメントの目的は、ソース固有のマルチキャスト（SSM）とその展開に関連する問題の概要を提供することです。これは、SSMサービスモデルは、ドメイン間のマルチキャストの展開に直面している課題、現在のマルチキャストサービスモデルとSSMおよび相互運用性の問題を展開するルーティングプロトコルおよびアプリケーションに必要な変更を対処方法について説明します。このメモはインターネットコミュニティのための情報を提供します。

3568 Barbir Jul 2003 Known Content Network (CN) Request-Routing Mechanisms

3568 Barbir 2003年7月既知のコンテンツネットワーク（CN）のRequest-ルーティングメカニズム

This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community.

この文書では、さまざまなポリシーやメトリクスの可能なセットに基づいて、サロゲートへの直接のクライアントの要求に使用されているリクエスト・ルーティング技術の概要を示します。文書は、一般的にこのメモでは2000年12月日以前に業界で使用された技術をカバーし、用語のRequest-ルーティングは、一般的にコンテンツルーティング、またはコンテンツのリダイレクトと呼ばれる技術を表しています。 DNSリクエスト・ルーティング、トランスポート・レイヤ・リクエスト・ルーティング、およびアプリケーション層の要求-ルーティング：原則として、リクエスト・ルーティング技術は、下に分類することができます。このメモはインターネットコミュニティのための情報を提供します。

3567 Li Jul 2003 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication

3567李2003年7月中間システム（IS-IS）暗号認証への中間システム

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords.

RFC 2104で-ISがISに指定されて見られるようなメッセージダイジェスト5（HMAC-MD5）アルゴリズム - このドキュメントは、中間システム（IS-IS）プロトコルデータユニット（PDU）ハッシュメッセージ認証コードを使用する中間システムの認証について説明しますインターネットプロトコルバージョン4（IPv4）をサポートするための拡張と国際標準化機構（ISO）10589、基本仕様は、複数の認証アルゴリズムを可能にする認証機構を含むRFC 1195に記載。基本仕様は、平文パスワードのアルゴリズムを指定します。

This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community.

この文書では、既存の認証メカニズムと組み合わせて使用​​するHMAC-MD5認証アルゴリズムを使用することができ、その仕様の拡張を提案します。このメモはインターネットコミュニティのための情報を提供します。

3566 Frankel Sep 2003 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec

3566フランケル2003年9月AES-XCBC-MAC-96アルゴリズムとIPsecでの使用

A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. [STANDARDS TRACK]

メッセージ認証コード（MAC）キー依存一方向ハッシュ関数です。 MACアルゴリズムを構築するための1つの一般的な方法は、操作の暗号ブロック連鎖（CBC）モードと一緒にブロック暗号を使用することです。古典CBC-MACアルゴリズムは、事前に選択された固定長のメッセージのための安全ながら、そのような一般的なIPデータグラムに見られるタイプのように種々の長さのメッセージを横切って安全でないことが示されています。このメモは、この制限を克服するための拡張セットでCBCモードのAESを使用することを指定します。この新しいアルゴリズムはAES-XCBC-MAC-96と命名されます。 [STANDARDS TRACK]

3565 Schaad Jul 2003 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)

3565 Schaad 7月暗号メッセージ構文内のAdvanced Encryption Standard（AES）暗号化アルゴリズムの2003を使用（CMS）

This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS TRACK]

この文書は、暗号メッセージ構文（CMS）での暗号化のためのAdvanced Encryption Standard（AES）アルゴリズムを使用するための規則を指定します。 [STANDARDS TRACK]

3564 Le Faucheur Jul 2003 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering

3564ルFaucheur 07月差別化サービスを意識したMPLSトラフィックエンジニアリングのサポートのために2003の要件

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-TE).

この文書では、差別化サービス（差分-SERV）をサポートするためのサービスプロバイダの要件-aware MPLSトラフィックエンジニアリング（DS-TE）を提示しています。

Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document.

その目的は、これらの要件に対処する技術的なソリューションの定義、選択、仕様のガイダンスを提供することです。このソリューション自体の仕様は、このドキュメントの範囲外です。

A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. This memo provides information for the Internet community.

問題文が最初に提供されます。その後、文書は既存のMPLSトラフィックエンジニアリング機構は及ばないとのDiff-Servの対応のトラフィックエンジニアリングは、ニーズに対応できるサービスプロバイダによって識別されるサンプルアプリケーションのシナリオについて説明します。技術的な解決策で対処する必要が詳細な要件も検討されています。最後に、文書には、技術的な解決策の選択と定義を考慮すべきである評価基準を識別します。このメモはインターネットコミュニティのための情報を提供します。

3563 Zinin Jul 2003 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development

IS-ISルーティングプロトコルの開発に関するISOC / IETFおよびISO / IEC合同技術委員会1 /小委員会6（JTC1 / SC6）との間で3563ジニン2003年7月協力協定

This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community.

この文書では、IS-ISルーティングプロトコルの共同開発に関するISOC / IETFおよびISO / IEC JTC1 / SC6の間で締結された契約のテキストが含まれています。契約は2つの団体、IANAによってIS-ISレジストリの作成とメンテナンスのための要求だけでなく、コラボレーションのガイドラインについては、関連する作業のスコープの定義が含まれています。このメモはインターネットコミュニティのための情報を提供します。

3562 Leech Jul 2003 Key Management Considerations for the TCP MD5 Signature Option

TCP MD5署名オプションのための3562のリーチ2003年7月キー管理上の考慮事項

The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community.

BGPによって主に使用されるTCP MD5署名オプション（RFC 2385）は、インターネットインフラストラクチャの重要な領域における重要な展開を見ています。このオプションのセキュリティは、MD5署名を計算するために使用される鍵素材の品質に大きく依存しています。この文書では、キーイング材料のセキュリティ要件に対応しています。このメモはインターネットコミュニティのための情報を提供します。

3561 Perkins Jul 2003 Ad hoc On-Demand Distance Vector (AODV) Routing

3561パーキンス2003年7月アドホックオンデマンド距離ベクトル（AODV）ルーティング

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community.

アドホックオンデマンド距離ベクトル（AODV）ルーティングプロトコルは、アドホックネットワーク内のモバイルノードによる使用のために意図されています。これは、ダイナミックリンク条件、低処理およびメモリのオーバーヘッド、低ネットワーク使用率への迅速な適応を提供し、アドホックネットワーク内の宛先へのユニキャストルートを決定します。これは、古典的な距離ベクトルプロトコルに関連付けられている（例えば、「無限にカウント」のような）問題を回避すること、（たとえ制御メッセージをルーティングする異常送達の面で）常にループの自由度を確保するために、宛先シーケンス番号を使用します。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3560 Housley Jul 2003 Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS)

暗号メッセージ構文におけるRSAES-OAEPキー交通アルゴリズム（CMS）の3560 Housleyの2003年7月の使用

This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS TRACK]

この文書は、暗号メッセージ構文（CMS）とRSAES-OAEPキートランスポート・アルゴリズムを使用するための規則について説明します。 CMSは、1人または複数の受信者用の暗号化コンテンツと暗号化されたコンテンツ暗号化キーで構成され、エンベロープ・データのコンテンツタイプを指定します。 RSAES-OAEPキートランスポート・アルゴリズムは、目的の受信者のためのコンテンツ暗号化キーを暗号化するために使用することができます。 [STANDARDS TRACK]

3559 Thaler Jun 2003 Multicast Address Allocation MIB

3559ターラー2003年6月のマルチキャストアドレス割り当て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 used for managing multicast address allocation. [STANDARDS TRACK]

このメモは、インターネットコミュニティでのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、マルチキャストアドレスの割り当てを管理するために使用される管理オブジェクトについて説明します。 [STANDARDS TRACK]

3558 Li Jul 2003 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)

強化された可変レートコーデック（EVRC）および選択可能なモードボコーダのための3558のLi 2003年7月RTPペイロードフォーマット（SMV）

This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS TRACK]

この文書では、強化された可変レートコーデック（EVRC）音声および選択可能なモードボコーダ（SMV）スピーチのためのRTPペイロード形式について説明します。二つのサブフォーマットが異なるアプリケーション・シナリオに指定されています。バンドル/インターリーブフォーマットは、音声品質に対するパケット損失の影響を低減し、複数の音声フレームの上にRTPヘッダのオーバーヘッドを償却するために含まれています。非バンドル形式は、会話のアプリケーションでサポートされています。 [STANDARDS TRACK]

3557 Xie, Ed. Jul 2003 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding

3557謝、エド。 2003年7月、欧州電気通信標準化機構（ETSI）のためのRTPペイロードフォーマット欧州規格ES 201 108分散型音声認識エンコーディング

This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS TRACK]

この文書は、欧州電気通信標準化機構（ETSI）欧州規格（ES）は、分散音声認識のための201 108フロントエンド信号処理機能ストリーム（DSR）システムをカプセル化するためのRTPペイロードフォーマットを指定します。 [STANDARDS TRACK]

3556 Casner Jul 2003 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

3556 Casner 2003年7月セッション記述プロトコル（SDP）RTP制御プロトコルのための帯域幅修飾子（RTCP）帯域幅

This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS TRACK]

この文書では、帯域幅属性のための2つの追加の修飾子を指定するためのセッション記述プロトコル（SDP）への拡張を定義します。これらの修飾子は、リアルタイムトランスポートプロトコル（RTP）セッションでのRTP制御プロトコル（RTCP）パケットに許可される帯域幅を指定するために使用することができます。 [STANDARDS TRACK]

3555 Casner Jul 2003 MIME Type Registration of RTP Payload Formats

RTPペイロードフォーマットの3555 Casner 2003年7月MIMEタイプ登録

This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. [STANDARDS TRACK]

この文書では、オーディオ、ビデオまたは他のMIMEサブタイプ名としてRTPペイロードフォーマットを登録するための手順を定義します。これは、RTP伝送のタイプを識別するためのテキストベースのフォーマットまたは制御プロトコルに有用です。また、このドキュメントでは、MIMEサブタイプとしてオーディオとビデオ会議用RTPプロファイルで定義されているすべてのRTPペイロードフォーマットを登録します。これらのいくつかは、RTP以外の転送モードのために使用することができます。 [STANDARDS TRACK]

3554 Bellovin Jul 2003 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec

IPsecの持つストリーム制御伝送プロトコル（SCTP）の利用について3554 Bellovin氏2003年7月

This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS TRACK]

この文書では、SCTP（RFC 2960）のトラフィックを確保する上での使用を容易にするためにIPsec（RFC 2401）およびインターネット鍵交換（IKE）（RFC 2409）のための機能要件について説明します。 [STANDARDS TRACK]

3553 Mealling Jun 2003 An IETF URN Sub-namespace for Registered Protocol Parameters

登録プロトコル・パラメータのための3553 Mealling 2003年6月アンIETF URNサブ名前空間

This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF-defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

このドキュメントは、登録されたプロトコル項目の「IETFのURN名前空間のための新しいサブ委任を説明しています。 「IETFのURN名前空間は、IETF定義のリソースを参照してください永続的なURIのルートとして、RFC 2648で定義されています。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

3552 Rescorla Jul 2003 Guidelines for Writing RFC Text on Security Considerations

セキュリティの考慮事項の書き方RFC Textの3552のレスコラ2003年7月のガイドライン

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

すべてのRFCは、Security Considerations部を有することが要求されています。歴史的に、そのようなセクションが比較的弱いとなっています。この文書では、良いSecurity Considerations部を書き込む方法についてのRFCの作者にガイドラインを提供します。このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。

3551 Schulzrinne Jul 2003 RTP Profile for Audio and Video Conferences with Minimal Control

最小量のコントロールがあるオーディオとビデオ会議のための3551 Schulzrinneと2003年7月RTPプロフィール

This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.

この文書は、最小限のコントロールとオーディオおよびビデオmultiparticipant会議内のリアルタイム転送プロトコル（RTP）、バージョン2、及び関連する制御プロトコルRTCPの使用のための「RTP / AVP」と呼ばれるプロファイルを記述する。これは、オーディオおよびビデオ会議に適したRTP仕様内の汎用フィールドの解釈を提供します。特に、この文書は、ペイロードタイプ番号からエンコーディングへのデフォルトマッピングのセットを定義します。

This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.

この文書では、オーディオおよびビデオデータをRTP内で搬送することができる方法を説明します。 RTP内で使用されるときには、標準のエンコーディングとその名前のセットを定義します。説明は、実装と詳細な基準を参照するためのポインタを提供します。この文書は、オーディオ、ビデオ、およびその他のリアルタイムマルチメディアアプリケーションの実装のための補助として意味しています。

This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS TRACK]

このメモは、二つの相互運用可能な実装が見つからなかったので、それが除去機能を除いて大部分が後方互換であるRFC 1890を時代遅れ。 RFC 1890への追加は、このプロファイルの下のペイロードフォーマットの使用中の既存の慣行を成文化し、RFC 1890が発行されましたので、定義された新しいペイロードフォーマットが含まれます。 [STANDARDS TRACK]

3550 Schulzrinne Jul 2003 RTP: A Transport Protocol for Real-Time Applications

3550 Schulzrinneと2003年7月RTP：リアルタイムアプリケーションのためのトランスポートプロトコル

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.

このメモはRTP、リアルタイムトランスポートプロトコルを記述します。 RTPは、マルチキャストまたはユニキャストネットワークサービス上、そのようなオーディオ、ビデオ又はシミュレーションデータなどのリアルタイムデータを送信するアプリケーションに適したエンドツーエンドのネットワークトランスポート機能を提供します。 RTPは、リソース予約には対応していませんし、サービス品質のリアルタイムサービスのためを保証するものではありません。データ転送は、大規模なマルチキャストネットワークに対してスケーラブルな様式でデータ配信の監視を可能にするために、最小限の制御および識別機能を提供する制御プロトコル（RTCP）によって増強されます。 RTPとRTCPは、基盤となるトランスポート層およびネットワーク層から独立して設計されています。プロトコルは、RTPレベルの翻訳者とミキサーの使用をサポートしています。

Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS TRACK]

この覚書のテキストのほとんどは、それが廃止RFC 1889と同じです。ワイヤ上のパケットフォーマットに変化、プロトコルが使用されている方法に関する規則及びアルゴリズムへの唯一の変更はありません。最大の変化は、多くの参加者が同時にセッションに参加するときに意図率を超える伝送を最小限にするために、RTCPパケットを送信する際に計算するためのスケーラブルなタイマーアルゴリズムの拡張機能です。 [STANDARDS TRACK]

3549 Salim Jul 2003 Linux Netlink as an IP Services Protocol

IPサービスプロトコルとして3549サリム2003年7月のLinuxするNetlink

This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.).

この文書では、イントラカーネルメッセージングシステムとしてだけでなく、カーネルとユーザー空間の間の両方のLinuxで使用されているLinuxのするNetlinkを、説明しています。この文書の焦点は、転送エンジン部品（FEC）とコントロールプレーンコンポーネント（CPC）、IPサービスを定義する2つの構成要素間のプロトコルとしてするNetlinkの機能を記述することです。この焦点の結果として、この文書は、プロセス間通信方式（IPC）として、または他の非ネットワークまたは非ための構成ツールとして、イントラカーネルメッセージングシステムとしての使用を含めするNetlinkの他の用途を無視しますIPネットワークサービス（など、DECnetなど）。

This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.

この文書は、IETFワーキンググループのForCESのための先行技術の文脈での情報提供を目的としています。このメモはインターネットコミュニティのための情報を提供します。

3548 Josefsson Jul 2003 The Base16, Base32, and Base64 Data Encodings

3548 Josefsson氏2003年7月ザ・Base16、Base32、およびBase64でデータエンコーディング

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community.

この文書は、一般的に使用されるベース64、ベース32、ベース16符号化方式を記載しています。また、符号化データ、符号化データにパディングを使用する、符号化データ中の非アルファベット文字の使用、および異なる符号化アルファベットの使用でラインフィードの使用を論じています。このメモはインターネットコミュニティのための情報を提供します。

3547 Baugher Jul 2003 The Group Domain of Interpretation

3547 Baugher 2003年7月解釈のグループドメイン

This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS TRACK]

この文書では、安全なグループ通信をサポートするために、グループ鍵管理のための解釈のISAMKPドメイン（DOI）を提示しています。 GDOIはIPSECとIPまたはアプリケーション層で動作し、潜在的に他のデータセキュリティプロトコルによって使用されるグループセキュリティアソシエーションを管理します。これらのセキュリティアソシエーションは、一つ以上のキー暗号化キー、トラフィック暗号化キー、またはグループのメンバーによって共有されるデータを保護します。 [STANDARDS TRACK]

3546 Blake-Wilson Jun 2003 Transport Layer Security (TLS) Extensions

3546ブレイク・ウィルソン2003年6月のTransport Layer Security（TLS）拡張機能

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.

この文書では、トランスポート層セキュリティ（TLS）に機能を追加するために使用することができる拡張機能について説明します。これは、TLSハンドシェイククライアントとサーバのhello、およびこれらの一般的なメカニズムを使用して、特定の拡張子の両方の一般的な拡張メカニズムを提供します。

The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS TRACK]

エクステンションは、TLSクライアントとサーバが使用することができます。拡張子は後方互換性があります - 通信は拡張およびTLS 1.0の拡張機能をサポートしていないサーバー、およびその逆をサポートするTLS 1.0クライアントの間で可能です。 [STANDARDS TRACK]

3545 Koren Jul 2003 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering

3545コレン2003年7月には、高遅延、パケット損失や並べ替えでのリンクのための圧縮RTP（CRTP）を強化しました

This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS TRACK]

この文書では、パケット損失と長い遅延とのリンクをポイント・ツー・ポイントのためのヘッダ圧縮スキームを説明します。これは、圧縮されたリアルタイムトランスポートプロトコル（CRTP）に基づいており、RFC 2508に記述されたIP / UDP / RTPヘッダー圧縮はCRTPはそのようなリンクでうまく行っていない：コンテキストの破損や長時間の遅延が原因でパケットロスの結果、多くのコンテキストが修復される前に、より多くのパケットが破棄されます。このようなリンクの上にCRTPの動作を修正するには、プロトコルにいくつかの拡張は、ここで指定されています。拡張子は、コンプレッサーがデコンプレッサでコンテキストを更新する方法を変更することにより、コンテキストの破損を軽減することを目指して：アップデートを繰り返し、フルと差分コンテキストパラメータへの更新が含まれています。これらの拡張機能を使用すると、CRTPはパケットロス、パケットの並べ替えと長い遅延とのリンクの上にうまく機能します。 [STANDARDS TRACK]

3544 Koren Jul 2003 IP Header Compression over PPP

PPPを超える3544コレン2003年7月IPヘッダー圧縮

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS TRACK]

この文書では、ポイントツーポイントプロトコル（RFC 1661）を介して送信されたIPデータグラムにヘッダ圧縮の使用を交渉するためのオプションが記載されています。これは、IPv4とIPv6のPPP制御プロトコル（RFC 1332、RFC 2472）への拡張を定義します。 RFC 2507で指定されたヘッダ圧縮は、TCP、UDP及びRTPトランスポートプロトコルとの組み合わせで、IPv4とIPv6データグラムに適用されてもよい、RFC 2508及びRFC 3545. [STANDARDS TRACK]

3543 Glass Aug 2003 Registration Revocation in Mobile IPv4

モバイルIPv4における3543グラス2003年8月登録の失効

This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS TRACK]

この文書では、モバイルノードにモバイルIPサービスを提供する際に関与するモビリティエージェントは、この登録の終了の同じモバイルノードにモバイルIPサービスを提供する他のモビリティエージェントに通知することができるモバイルIPv4登録失効メカニズムを定義します。機構は、そのも同様結合の終了の同一位置の移動ノードに通知するために、ホームエージェントによって使用可能です。また、機構が認められるには、この通知を提供します。既にモバイルIPv4プロトコルによって定義されたシグナリングメカニズムは、その結合の取消しのモバイルノードに通知する手段として活用されます。 [STANDARDS TRACK]

3542 Stevens May 2003 Advanced Sockets Application Program Interface (API) for IPv6

IPv6のための3542スティーブンス2003年5月拡張ソケットアプリケーション・プログラム・インターフェース（API）

This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community.

この文書は、RFC 3493.期待アプリケーションは通常、アクセスにrawソケットを使用してpingを実行し、トレースルート、ルーティングデーモンなどを含むアプリケーション・プログラム・インターフェース（API）は、別仕様の補足として、「先進」のIPv6アプリケーションをサポートするためのソケットを提供しますIPv6のまたはICMPv6のヘッダフィールド。この文書は、IPv6の下でrawソケットを使用するアプリケーションのためのいくつかのポータブルインタフェースを提案しています。インタフェース識別（発信インターフェイスを指定して、着信インターフェイスを決定する）、IPv6拡張ヘッダ、及びパス最大伝送単位（MTU）情報：いくつかのアプリケーションがアクセスする必要があることのIPv6の他の特徴があります。この文書では、あまりにも、これらの機能へのAPIアクセスを提供します。また、「R」コマンドのライブラリにいくつかの拡張インタフェースが定義されています。拡張子は、IPv6に対応していない既存の実装に優れた後方互換性を提供します。このメモはインターネットコミュニティのための情報を提供します。

3541 Walsh May 2003 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D)

3541ウォルシュ2003年5月のWeb3Dコンソーシアムのための統一リソース名（URN）名前空間（のWeb3D）

This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. This memo provides information for the Internet community.

この文書では、このような技術文書や仕様などの永続的なリソースを命名するためのWeb3Dコンソーシアム（のWeb3D）のための統一リソース名（URN）名前空間、バーチャルリアリティモデリング言語（VRML）および拡張3D（X3D）ファイルとリソース、拡張マークアップ言語を（説明しますXML）文書型定義（DTDの）、XMLスキーマ、名前空間、スタイルシート、メディア資産、およびその他のリソースは、生産やのWeb3Dによって管理されます。このメモはインターネットコミュニティのための情報を提供します。

3540 Spring Jun 2003 Robust Explicit Congestion Notification (ECN) Signaling with Nonces

ナンスとシグナリング3540春2003年6月堅牢明示的輻輳通知（ECN）

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community.

このノートでは、明示的輻輳通知（ECN）-nonce、TCPの送信者からマークされたパケットの偶発的または悪質な隠蔽から保護ECNへのオプションの追加について説明します。これは、ネットワーク帯域幅の不当なシェアを獲得するためにECNを利用するから、受信機を防止することにより、輻輳制御のロバスト性を向上させることができます。 ECN-ノンスは、IPヘッダのECNフィールド二つECN-可能なトランスポート（ECT）コードポイントを使用し、TCPヘッダ内のフラグを必要とします。これは、ルータとホストの両方のための計算上効率的です。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3539 Aboba Jun 2003 Authentication, Authorization and Accounting (AAA) Transport Profile

3539 Aboba 2003年6月認証、認可およびアカウンティング（AAA）のトランスポート・プロファイル

This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS TRACK]

この文書は、認証、認可及びアカウンティング（AAA）のためのプロトコル内で発生輸送の問題を論じています。また、AAAプロトコルによる輸送の使用に関する推奨事項を提供します。これは、標準化過程のRFCの利用だけでなく、実験的な提案を含んでいます。 [STANDARDS TRACK]

3538 Kawatsura Jun 2003 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)

v1.0のインターネットオープン取引プロトコル（IOTP）のための3538 Kawatsura 2003年6月セキュア電子取引（SET）サプリメント

This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. This memo provides information for the Internet community.

この文書は、インターネットオープン取引プロトコル（IOTP）支払アプリケーションプログラミングインターフェイス（API）の詳細な入力/出力パラメータについて説明します。また、IOTPのバージョン1.0以内の支払プロトコルとして（セキュアな電子トランザクションをSET）SETを使用するための支払いの橋の手順を説明します。このメモはインターネットコミュニティのための情報を提供します。

3537 Schaad May 2003 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key

トリプルデータ暗号化規格（DES）キーまたはのAdvanced Encryption Standard（AES）キー付きハッシュメッセージ認証コード（HMAC）鍵をラッピング3537 Schaad 2003年5月

This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD]

この文書では、HMAC（ハッシュメッセージ認証コード）キーを包装するための2つの方法を定義しています。定義された第一の方法は、HMACキーを暗号化するためのトリプルDES（データ暗号化規格）キーを使用します。定義された第二の方法は、HMACキーを暗号化するAES（高度暗号化規格）キーを使用します。このようなアルゴリズムが使用されている場所の一つは、CMSで認証されたデータの種類（暗号メッセージ構文）のためです。 [提案された標準]

3536 Hoffman May 2003 Terminology Used in Internationalization in the IETF

IETFでの国際化に使用される3536ホフマン2003年5月の用語

This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community.

この文書では、国際化を議論する際にIETFで使用している用語を解説します。目的は、IETFの様々な分野における国際化のフレーム議論を助け、IETFの参加者に主要な概念を紹介する手助けをすることです。このメモはインターネットコミュニティのための情報を提供します。

3535 Schoenwaelder May 2003 Overview of the 2002 IAB Network Management Workshop

2002 IABネットワーク管理ワークショップの3535 Schoenwaelder 2003年5月概要

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community.

この文書では、ネットワーク管理上のインターネットアーキテクチャ委員会（IAB）で開催されたワークショップの概要を説明します。ワークショップは、ネットワークオペレータとプロトコルの開発者の間で開始し、IETFsはに関する今後の作業に焦点を当てる導くためにワークショップの目的は、重要な対話を継続することだった6月6日、2002年を通して6月4日レストン、VA、USAにCNRIが主催しました。ネットワーク管理。このレポートでは、議論をまとめ、IETF（Internet Engineering Task Force）のコミュニティに結論と提言を示しています。このメモはインターネットコミュニティのための情報を提供します。

3534 Walleij May 2003 The application/ogg Media Type

3534 Walleij 2003年5月アプリケーション/ oggのメディアタイプ

The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS TRACK]

Oggビットストリームフォーマットは、コンピューティング・プラットフォームとネットワークを介してマルチメディアコンテンツを転送するための一般的な、自由に利用可能な標準になることを目指しています。このドキュメントの意図は、インターネットを横切って輸送時にこの種のコンテンツを参照するためにMIMEメディアタイプapplication / oggのを定義することです。それは、知的財産の懸念なしに使用可能であることはOggビットストリームフォーマットの開発者の意図です。 [STANDARDS TRACK]

3533 Pfeiffer May 2003 The Ogg Encapsulation Format Version 0 This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community.

3533ファイファー2003年5月のOggカプセル化形式のバージョン0このドキュメントでは、メディアストリームのための一般的な、自由に利用可能なカプセル化形式でのOggビットストリームフォーマットバージョン0を、説明しています。単一のビットストリームに任意の種類のビデオおよびオーディオ符号化フォーマットの数だけでなく、他のデータストリームをカプセル化することができます。このメモはインターネットコミュニティのための情報を提供します。このメモはインターネットコミュニティのための情報を提供します。

3532 Anderson May 2003 Requirements for the Dynamic Partitioning of Switching Elements

スイッチング素子の動的パーティショニングのための3532のアンダーソン2003の5月要件

This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. This memo provides information for the Internet community.

この文書は、動的に、そのパーティションにスイッチング素子（例えば、ATMスイッチ）のリソースを再割り当てするために使用されるメカニズムのための要件のセットを識別する。これらの要件は、オペレータスイッチのパーティションを作成し、第三者にそのパーティションの制御をリースの場合に特に重要です。このメモはインターネットコミュニティのための情報を提供します。

3531 Blanchet Apr 2003 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block

IPv6アドレスブロックのビットの割り当てを管理するための3531ブランシェ2003年4月A柔軟な方法

This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. This memo provides information for the Internet community.

この文書は、IPv6アドレスブロックまたは範囲のビットの割り当てを管理するための方法を提案します。組織は、そのサブネットまたはISPが顧客のためのアドレス計画を作成する必要がある場合、このメソッドは、彼らが持っているアドレス空間に分割するビット数の最終決定を延期する組織を可能にするためのアドレス計画を作成する必要がある場合。これは、可能な限り自由であるために、パーティションの境界の周りにビットを保つことによってそれをしません。この方式は、空間内のパーティションを持つビットを使用してアドレス指定方式を任意のビットに適用されるが、その最初の意図された使用は、IPv6のためです。これは、RFC 1219の一般化したものであるとIPv6の割り当てのために使用することができます。このメモはインターネットコミュニティのための情報を提供します。

3530 Shepler Apr 2003 Network File System (NFS) version 4 Protocol

3530 Shepler 2003年4月ネットワークファイルシステム（NFS）バージョン4プロトコル

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

ネットワークファイルシステム（NFS）バージョン4分散ファイルシステムNFSプロトコルバージョン2に遺産を負っているプロトコル、RFC 1094、およびバージョン3、以前のバージョンとは異なり、RFC 1813でのサポートを統合しながら、NFSバージョン4プロトコルは、従来のファイルアクセスをサポートファイルのロックとマウントプロトコル。また、強力なセキュリティ（およびその交渉）、化合物の操作、クライアントのキャッシュ、および国際化のためのサポートが追加されました。もちろん、注意はNFSバージョン4は、インターネット環境でも動作させるに適用されています。

This document replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS TRACK]

この文書では、NFSバージョン4プロトコルの定義としてRFC 3010に置き換えられます。 [STANDARDS TRACK]

3529 Harold Apr 2003 XML-RPC is an Extensible

3529ハロルド・2003年4月XML-RPCは、拡張可能です

Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures.

インターネット上で動作するマークアップ言語、リモートプロシージャ呼び出しプロトコル。これは、HTTPを使用して、クライアントとサーバー間で転送されるメッセージのXMLフォーマットを定義します。 XML-RPCメッセージは、プロシージャ呼び出しで使用するパラメータとともに、サーバによって呼び出される、または呼び出しの結果のいずれかをコードします。プロシージャパラメータと結果はスカラー、数字、文字列、日付、などすることができ;彼らはまた、複雑な記録とリスト構造することができます。

This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community.

このドキュメントでは、クライアントとサーバの間でXML-RPC形式でエンコードされたメッセージを転送するブロック拡張可能交換プロトコル（BEEP）を使用する方法を指定します。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3528 Zhao Apr 2003 Mesh-enhanced Service Location Protocol (mSLP)

3528趙2003年4月サービスロケーションプロトコル（MSLP）メッシュ強化

This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. This memo defines an Experimental Protocol for the Internet community.

この文書では、メッシュが強化されたサービスロケーションプロトコル（MSLP）について説明します。 MSLPはスコープベースのフルメッシュピアリングディレクトリエージェント（DA）アーキテクチャとサービスロケーションプロトコル（SLP）を強化します。ピアダスは、抗エントロピーとの直接転送を介して共有スコープの新サービス登録を交換します。 MSLPは、SLP DAサービスの信頼性と一貫性を向上させ、複数のDAを持つシステムでサービスエージェント（SA）の登録を簡素化します。 MSLPはSLPv2のと下位互換性があり、漸進的に展開することができます。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3527 Kinnear Apr 2003 Link Selection sub-option for the Relay Agent Information Option for DHCPv4

DHCPv4のリレーエージェント情報オプションのための3527キニア2003年4月リンク選択サブオプション

This document describes the link selection sub-option of the relay-agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS TRACK]

この文書では、動的ホスト構成プロトコル（DHCPv4の）のためのリレーエージェント情報オプションのリンク選択サブオプションについて説明します。 GIADDRは、サブネット、およびそれによってリンクDHCP（Dynamic Host Configuration Protocol）クライアントが置かれているだけでなく、リレーエージェントとの通信に使用できるIPアドレスの両方を決定し、IPアドレスを指定します。サブネット選択オプションは、一つのエンティティがDHCPプロキシとして実行している場合、それはIPアドレスと異なるIPアドレスを割り当てるためのサブネット/リンクを指定できるようにGIADDRの機能を分割することを可能にするとそれは、DHCPサーバと通信することを望みます。リレーエージェントは、リレーエージェントと通信するために使用できるIPアドレスと異なっている、DHCPクライアントが存在するサブネット/リンクを指定する必要がある場合、類似の状況が存在します。 [STANDARDS TRACK]

3526 Kivinen May 2003 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)

インターネット鍵交換のための3526 Kivinen 2003年5月よりモジュラー指数（MODP）のDiffie-Hellmanグループ（IKE）

This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS TRACK]

この文書は、インターネット鍵交換（IKE）プロトコルのための新しいモジュラー指数（MODP）グループを定義します。これはよく知られており、1536ビットグループ5を使用したドキュメント、また新しい2048、3072、4096、6144を定義し、8192ビットのDiffie-Hellmanグループは、14から始まる番号を付け論文グループの素数の選択は、リチャードによって確立された基準に従いますSchroeppel。 [STANDARDS TRACK]

3525 Groves Jun 2003 Gateway Control Protocol Version 1

3525グローブス2003年6月ゲートウェイコントロールプロトコルバージョン1

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.

この文書は、物理的に分解し、マルチメディア・ゲートウェイ、すなわち、メディアゲートウェイとメディアゲートウェイコントローラの構成要素間で使用されるプロトコルを定義します。 RFC 2805に示されたように、本書で提示プロトコルは、メディアゲートウェイ制御プロトコルのための要件を満たしています。

This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of , modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1.

この文書では、それはMegacoのEメールリストに議論され、中に組み込まれ訂正と明確化によって変更IETF Megacoの作業部会とITU-T研究グループ16.それは、元のテキストを組み込んだ、との継続的な協力の結果であるRFC 3015置き換え勧告H.248のための研究会16開発者のためのガイド。このドキュメントの現在のバージョンがあるため、ITU-TのリナンバリングのITU-T勧告H.248に改正1とラストコールを受け、それが勧告H.248.1（03/2002）、ゲートウェイ制御プロトコルのバージョンとして、ITU-Tによって公開されました1。

Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS TRACK]

この仕様のユーザーは、追加の訂正と明確化のためhttp://www.itu.int/itudoc/itu-t/com16/implgdでH.248サブシリーズの実装者のガイドを参照してくださいすることをお勧めします。 [STANDARDS TRACK]

3524 Camarillo Apr 2003 Mapping of Media Streams to Resource Reservation Flows

予約フローをリソースへのメディアストリームの3524カマリロ2003年4月のマッピング

This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). [STANDARDS TRACK]

この文書では、セッション記述プロトコル（SDP）グループ化フレームワークの拡張を定義します。これは、メディアストリームのグループは、単一のリソース予約フローにマッピングすることを要求することができます。必要な構文が定義されているSDP、ならびに単一予約の流れ（SRF）と呼ばれる新しい「意味論」属性。 [STANDARDS TRACK]

3523 Polk Apr 2003 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology

3523ポーク2003年4月、インターネット防災（IEPREP）テレフォニートポロジーの用語

This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This memo provides information for the Internet community.

このドキュメントはインターネット防災（IEPREP）電話に関連して使用される命名規則トポロジを定義します。これらの命名規則は、議論と要件、ギャップ分析や他のソリューションの文書を書く時にIEPREPワーキンググループの焦点を合わせるために使用されるべきです。このメモはインターネットコミュニティのための情報を提供します。

3522 Ludwig Apr 2003 The Eifel Detection Algorithm for TCP

TCPのための3522ルートヴィヒ2003年4月アイフェル検出アルゴリズム

The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.

アイフェル検出アルゴリズムは、TCPの送信者は、それが不必要に損失回復に入ったかどうかを事後に検出することができます。これは、RFC 1323で定義されたTCPタイムスタンプオプションは、接続のために有効にする必要があります。アイフェル検出アルゴリズムは、TCPタイムスタンプオプションがTCPで再送あいまいさを排除しているという事実を利用しています。損失回復の間に到着した最初の許容できるACKのタイムスタンプに基づいて、損失回復が不必要に入力されたかどうかを決定します。アイフェル検出アルゴリズムは、将来のTCP機能強化のための基礎を提供します。これは、TCPの送信側の輻輳制御状態を復元することによって損失回復のバックアウトする応答アルゴリズムを含んでいます。このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。

3521 Hamer Apr 2003 Framework for Session Set-up with Media Authorization

メディア認証とセッションのセットアップのための3521ハマー2003年4月の枠組み

Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host.

マルチメディアストリームを確立することは、エンドツーエンドのQoS、使用するリソースのネットワークリソースの使用量と正確な会計処理の許可のためのアカウント要件を考慮する必要があります。セットアップセッション中に、ポリシーがメディアストリームを要求しているホストのために確立されたサービスプロファイルの範囲内で嘘を要求されていることを確認するために実施することができます。同様に、ホスト要求リソースがパケットフローに関する特定のQoSを提供する場合、ポリシーは必要なリソースを要求しているホストのために確立されたリソースプロファイルの範囲内にあることを確実にするために実施されてもよいです。

To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session. This memo provides information for the Internet community.

不正行為を防止し、正確な課金を確実にするために、この文書は、セッションのために要求されたQoSを提供するために使用されるリソースは、インライン要求（および承認）メディアストリームとであることを確認するために必要な結合を提供する様々なシナリオおよびメカニズムを説明しています。このメモはインターネットコミュニティのための情報を提供します。

3520 Hamer Apr 2003 Session Authorization Policy Element

3520ハマー2003年4月のセッション認可ポリシーの要素

This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios. [STANDARDS TRACK]

この文書では、ポリシーベースのセッションごとの認証および許可制御をサポートするためのセッション認可ポリシー要素の表現について説明します。セッション認証の目標は、サービスのためのリソースの使用を承認するとシグナリングと輸送面の間のアクション・コーディネイトするために、ネットワーク要素間の情報交換を可能にすることです。この文書では、システム上のプロセスがホストによってリソースの予約を許可して、リソース予約プロトコル（例えば、リソース予約プロトコル（RSVP）PATHメッセージ）に挿入できるセッション認可ポリシー要素と、そのホストをどのように提供するかについて説明しネットワーク内でそれらの資源の適正かつ確実な予約を容易にします。我々は、ポリシー・データ・オブジェクト（RFC 2750）のフォーマットに準拠したポリシー要素としてセッション許可情報の符号化を説明し、操作、処理ルールとエラーシナリオに関する詳細を提供します。 [STANDARDS TRACK]

3519 Levkowetz May 2003 Mobile IP Traversal of Network Address Translation (NAT) Devices

ネットワークアドレス変換（NAT）デバイスの3519 Levkowetz 2003年5月モバイルIPトラバーサル

Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS TRACK]

モバイルIPデータグラムのトンネリングは、ネットワークアドレス変換（NAT）と互換性がありません。この文書では、モバイルIPプロトコルやNATデバイスによって公共のインターネットから分離されているプラ​​イベートアドレスネットワークで動作するように、モバイルIPを用いた移動ノードを許可するトンネリング方式への拡張を提供します。 NATトラバーサルは、カプセル化されたデータトラフィックのためのモバイルIPホームエージェントUDPポートを使用することに基づいています。 [STANDARDS TRACK]

3518 Higashiyama Apr 2003 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)

3518東山2003年4月のPoint-to-Pointプロトコル（PPP）ブリッジング制御プロトコル（BCP）

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols.

ポイントツーポイントプロトコル（PPP）は、ポイントツーポイントリンク上でマルチプロトコルデータグラムを輸送するための標準的な方法を提供します。 PPPは、拡張リンク制御プロトコル（LCP）を定義し、確立し、異なるネットワーク層プロトコルを設定するためのネットワーク制御プロトコル（NCP）のファミリーを提案しています。

This document defines the NCP for establishing and configuring Remote Bridging for PPP links.

このドキュメントは、PPPリンク用のリモートブリッジングを確立し、構成するためにNCPを定義します。

This document obsoletes RFC 2878, which was based on the IEEE 802.1D-1993 MAC Bridge. This document extends that specification by improving support for bridge control packets. [STANDARDS TRACK]

このドキュメントでは、IEEE 802.1D-1993 MACブリッジに基づいていたRFC 2878を廃止します。この文書では、ブリッジ制御パケットのサポートを改善することにより、その仕様を拡張します。 [STANDARDS TRACK]

3517 Blanton Apr 2003 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP

3517ブラントン2003年4月A保守的な選択的確認応答（SACK）は、TCPのために損失回復アルゴリズムをベース

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS TRACK]

この文書は、選択的確認応答（SACK）TCPオプションの使用に基づいているTCPのための保守的な損失回復アルゴリズムを提案します。この文書で提示するアルゴリズムは、現在の輻輳制御仕様（RFC 2581）の精神に準拠するが、複数のセグメントがデータの単一フライトから失われている場合に、TCP送信者がより効果的に回復することを可能にします。 [STANDARDS TRACK]

3516 Nerenberg Apr 2003 IMAP4 Binary Content Extension

3516 Nerenberg 2003年4月IMAP4バイナリコンテンツ拡張

This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer-encoding. [STANDARDS TRACK]

このメモは、インターネットメッセージアクセスプロトコル（IMAP4）にバイナリ拡張子を定義します。これは、IMAP4クライアントとサーバMIMEコンテンツ転送エンコードを使用せずに、メッセージボディデータを交換するためのメカニズムを提供します。 [STANDARDS TRACK]

3515 Sparks Apr 2003 The Session Initiation Protocol (SIP) Refer Method

3515スパークス2003年4月セッション開始プロトコル（SIP）メソッドを参照してください。

This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer.

この文書は、REFERメソッドを定義します。受信者がリクエストで提供されるリソースを参照して、このセッション開始プロトコル（SIP）の拡張を要求。それは、参照要求の結果が通知されるようにREFER送信パーティを許可するメカニズムを提供します。これは、コール転送など、多くのアプリケーションを、有効にするために使用することができます。

In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS TRACK]

REFERメソッドに加えて、この文書は参照イベントパッケージと参照の-する要求ヘッダを定義しています。 [STANDARDS TRACK]

3514 Bellovin 1 Apr 2003 The Security Flag in the IPv4 Header

3514 Bellovin氏2003年4月1日のIPv4ヘッダのセキュリティ・フラグ

Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.

ファイアウォール、パケットフィルタ、侵入検知システムなどがしばしば困難悪意を持っているパケットと単に珍しいものを区別しています。我々は2つのケースを区別する手段として、IPv4ヘッダ内のセキュリティフラグを定義します。このメモはインターネットコミュニティのための情報を提供します。

3513 Hinden Apr 2003 Internet Protocol Version 6 (IPv6) Addressing Architecture

3513 Hindenと2003年4月インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS TRACK]

この仕様は、IPバージョン6（IPv6）のプロトコルのアドレス体系を定義します。文書は、IPv6アドレッシングモデル、IPv6アドレスのテキスト表現、IPv6ユニキャストアドレスの定義、エニーキャストアドレス、マルチキャストアドレス、およびIPv6ノードの必要なアドレスを含んでいます。 [STANDARDS TRACK]

3512 MacFaden Apr 2003 Configuring Networks and Devices with Simple Network Management Protocol (SNMP)

3512のMacFaden 2003年4月ネットワークの設定と簡易ネットワーク管理プロトコル（SNMP）を持つデバイス

This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This memo provides information for the Internet community.

このドキュメントはインターネット標準管理フレームワークとそのプロトコル、簡易ネットワーク管理プロトコル（SNMP）に関心のある読者のために書かれています。特に、それは、構成管理のためのSNMPの有効利用のガイダンスを提供しています。この情報は、ネットワーク要素、管理アプリケーションの開発者、および取得し、自社のネットワークでこの技術を展開しているものを構築ベンダーに関連しています。このメモはインターネットコミュニティのための情報を提供します。

3511 Hickman Apr 2003 Benchmarking Methodology for Firewall Performance

ファイアウォールのパフォーマンスのための3511ヒックマン2003年4月のベンチマーキング方法論

This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.

この文書は、ファイアウォールの性能特性を記述するために使用することができる試験の数を説明し、定義します。テストの定義に加えて、この文書はまた、テストの結果を報告するための特定のフォーマットを説明しています。

This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）のベンチマーク手法ワーキンググループ（BMWG）の製品です。このメモはインターネットコミュニティのための情報を提供します。

3510 Herriot Apr 2003 Internet Printing Protocol/1.1: IPP URL Scheme

3510ヘリオット2003年4月インターネット印刷プロトコル/ 1.1：IPP URLスキーム

This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS TRACK]

このメモは、「IPP」URL（ユニフォームリソースロケータ）方式を定義します。このメモはIPP / 1.1を更新：RFC 2910アン「IPP」URLのセクション5、「IPP URLスキーム」を拡充し、明確化することにより符号化及びトランスポート（RFC 2910）は、サポートするプリントサービスのネットワークの場所を指定するために使用されますそのような印刷サービスによって管理されるIPPプロトコル（RFC 2910）、またはネットワークリソースの（例えば、印刷ジョブ）。 [STANDARDS TRACK]

3509 Zinin Apr 2003 Alternative Implementations of OSPF Area Border Routers

OSPFエリア境界ルータの3509のジニン2003年4月の代替実装

Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. This memo provides information for the Internet community.

オープンショーテストパスファースト（OSPF）IPネットワークにおけるルーティングのために使用されるリンクステートドメイン内ルーティングプロトコルです。 OSPF仕様のエリア境界ルータ（ABR）の定義は、バックボーン接続を持つように、複数の接続されたエリアでルータを必要としませんが、エリア間および外部の宛先に成功したルーティングを提供するために、実際には必要です。この要件が満たされていない場合は、そのようなABRまたはOSPFドメインの外に接続されていない領域宛てのすべてのトラフィックは、廃棄されます。このドキュメントでは、CiscoとIBMルータに実装され、代替ABRの動作を説明します。このメモはインターネットコミュニティのための情報を提供します。

3508 Levin Apr 2003 H.323 Uniform Resource Locator (URL) Scheme Registration

3508レビン2003年4月H.323ユニフォームリソースロケータ（URL）スキームの登録

ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

ITU-T勧告H.323バージョン4は、H.323固有のURL（Uniform Resource Locator）を導入しました。この文書では、H.323で見つかったH323-URL定義を再生し、IANA（Internet Assigned Numbers Authority）にしてアクセスし、登録を容易にするためにRFCとして公開されています。このメモはインターネットコミュニティのための情報を提供します。

3507 Elson Apr 2003 Internet Content Adaptation Protocol (ICAP)

3507エルソン2003年4月インターネットコンテンツアダプテーションプロトコル（ICAP）

ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. This memo provides information for the Internet community.

ICAP、インターネットコンテンツへの適応性プロトコルは、HTTPサービスのための単純なオブジェクトベースのコンテンツベクタリングを提供することを目的としたプロトコルです。 ICAPは、本質的には、HTTPメッセージの「リモートプロシージャコール」を実行するための軽量プロトコルです。これは、ICAPクライアントは、変換または他の処理（「適応」）のいくつかの並べ替えのためにICAPサーバにHTTPメッセージを渡すことができます。サーバーは、メッセージに対して変換サービスを実行し、通常は修正メッセージで、クライアントに応答を送り返します。一般的に、適応したメッセージは、HTTP要求またはHTTP応答のいずれかです。このメモはインターネットコミュニティのための情報を提供します。

3506 Fujimura Mar 2003 Requirements and Design for Voucher Trading System (VTS)

3506の藤村2003の3月要件とクーポン取引システムの設計（VTS）

Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described. This memo provides information for the Internet community.

ロイヤリティポイントをクレジットし、デジタルクーポンやギフト券を収集することは、購買や取引の取引に共通の機能です。これらの活動は、商品やサービスを請求する権利のデジタル表現である、「バウチャー」の概念を用いて一般化することができます。この文書では、しっかりバウチャーとその用語を循環させるクーポン取引システム（VTS）を提示します。それは、バウチャーの多様な種類が記述可能な設計原理とVTSとジェネリッククーポン言語（GVL）の要件を、一覧表示されます。このメモはインターネットコミュニティのための情報を提供します。

3505 Eastlake Mar 2003 Electronic Commerce Modeling Language (ECML): Version 2 Requirements

3505イーストレイク2003年3月電子商取引モデリング言語（ECML）：バージョン2つの要件

This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing. This memo provides information for the Internet community.

この文書は、設計原則、範囲、および電子商取引モデリング言語（ECML）バージョン2仕様の要件を示しています。彼らは拡張マークアップ言語（XML）シンタックス、データモデル、フォーマット、および支払い処理に関連するように、それは要件が含まれています。このメモはインターネットコミュニティのための情報を提供します。

3504 Eastlake Mar 2003 Internet Open Trading Protocol (IOTP) Version 1, Errata

3504イーストレイク2003年3月、インターネットのオープン・トレーディング・プロトコル（IOTP）バージョン1、エラッタ

Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted. This informational document lists these errors and provides corrections for them. This memo provides information for the Internet community.

インターネットオープン取引プロトコル（IOTP）のバージョン1.0を指定するRFCの出版以来、いくつかのエラーが指摘されています。この情報資料は、これらのエラーを一覧表示し、それらの修正を行っています。このメモはインターネットコミュニティのための情報を提供します。

3503 Melnikov Mar 2003 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)

インターネットメッセージアクセスプロトコル（IMAP）のための3503メルニコフ2003年3月のメッセージディスポジション通知（MDN）のプロフィール

The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment.

RFC 2298で定義されたメッセージ気質通知（MDN）ファシリティメッセージが肯定応答並びに肯定応答に使用されるフォーマットされた受信者によってそのメッセージの処理を要求することができる手段を提供します。しかし、それはメールユーザエージェント（MUA）は、インターネットメッセージアクセスプロトコル（IMAP4）環境で開封通知の世代をどのように処理するかを複数記述していません。

This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS TRACK]

この文書では、このような環境の中で開封通知を処理する方法について説明し、自社製品にMDNのサポートを追加したいIMAP4の実装のためのガイドラインを提供します。 [STANDARDS TRACK]

3502 Crispin Mar 2003 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension

3502クリスピン2003年3月インターネットメッセージアクセスプロトコル（IMAP） - MULTIAPPEND拡張

This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server.

このドキュメントは、インターネットメッセージアクセスプロトコル（IMAP）（RFC 3501）にmultiappending拡張を説明しています。この拡張機能は、サーバー上のメールボックスに一度に複数のメッセージをアップロードするIMAPクライアントの大幅な性能向上を提供します。

A server which supports this extension indicates this with a capability name of "MULTIAPPEND". [STANDARDS TRACK]

この拡張機能をサポートするサーバーは、「MULTIAPPEND」の機能名でこれを示します。 [STANDARDS TRACK]

3501 Crispin Mar 2003 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

3501クリスピン2003年3月インターネットメッセージアクセスプロトコル - VERSION 4rev1

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.

インターネットメッセージアクセスプロトコル、Version 4rev1（IMAP4rev1の）は、クライアントがサーバ上の電子メールメッセージにアクセスして操作することができます。 IMAP4rev1のは、ローカルフォルダと機能的に同等であるようにメールボックス（リモートメッセージフォルダ）の操作を可能にします。 IMAP4rev1のは、オフラインクライアントがサーバーと再同期するための機能を提供します。

IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.

IMAP4rev1のは、作成、削除、メールボックスの名前を変更し、新たなメッセージをチェック、メッセージを完全に除去し、設定し、そのフラグ、RFC 2822及びRFC 2045の解析、検索、およびメッセージの選択的な取り込み属性、テキスト、および部分をクリアするための動作を含みます。 IMAP4rev1の中のメッセージは番号の使用によってアクセスされています。これらの数値は、いずれかのメッセージのシーケンス番号または一意の識別子です。

IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.

IMAP4rev1のは、単一のサーバをサポートしています。複数のIMAP4rev1サーバをサポートするために、構成情報にアクセスするためのメカニズムは、RFC 2244で説明されています。

IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS TRACK]

IMAP4rev1のメールを掲示する手段を指定しません。この機能は、RFC 2821のようなメール転送プロトコル[STANDARDS TRACK]によって処理され

3500 Never Issued

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

RFC 3500 was never issued.

RFC 3500が発行されていませんでした。

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

完全な著作権声明

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

著作権（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機能のための基金は現在、インターネット協会によって提供されます。