RFC3499 日本語訳
3499 Request for Comments Summary RFC Numbers 3400-3499. S. Ginoza. December 2003. (Format: TXT=88033 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Ginoza Request for Comments: 3499 ISI Category: Informational December 2003
コメントを求めるワーキンググループS.宜野座の要求をネットワークでつないでください: 3499年のISIカテゴリ: 情報の2003年12月
Request for Comments Summary
コメントには、概要を要求してください。
RFC Numbers 3400-3499
RFC No.3400-3499
Status of This Memo
このメモの状態
This RFC is a slightly annotated list of the 100 RFCs from RFC 3400 through RFC 3499. This is a status report on these RFCs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このRFCはRFC3400からRFC3499の100RFCsのわずかに注釈されたリストです。 これはこれらのRFCsに関する現状報告です。 このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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].
すべてではなく、多くのRFCsがProposed Standards、Draft Standards、またはStandardsです。 これらのRFCsの状態が規格処理の間、変化するかもしれないので、私たちは、ここで標準化過程の上にそれらがあるだけであることに注意します。 これらのRFCsの現状と状態に「インターネット公式プロトコル標準」の最新版を見てください。 以下では、標準化過程の上のRFCsは[STANDARDS TRACK]であるとマークされます。
RFC Author Date Title --- ------ ---- -----
RFC作者日付のタイトル--- ------ ---- -----
3499 Ginoza Request for Comments Summary
3499年のコメント概要に関する宜野座の要求
This memo.
このメモ。
Ginoza Informational [Page 1] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[1ページ]のRFC3499概要
3498 Kuhfeld Mar 2003 Definitions of Managed Objects
for Synchronous Optical
Network (SONET) Linear
Automatic Protection Switching
(APS) Architectures
3498 同期式光通信網(Sonet)の直線的な自動保護の切り換え(APS)アーキテクチャのための管理オブジェクトのKuhfeld2003年3月定義
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS TRACK]
このメモは使用のために、ネットワーク管理プロトコルでTCP/IPに基づいているインターネットでManagement Information基地の一部(MIB)を定義します。 特に、それは、同期式光通信網(Sonet)の直線的なAutomatic Protection Switching(APS)アーキテクチャを使用することでネットワークを経営するためにオブジェクトを定義します。 [標準化過程]
3497 Gharai Mar 2003 RTP Payload Format for
Society of Motion Picture and
Television Engineers (SMPTE)
292M Video
3497 映画テレビ技術者協会(SMPTE)の292MのビデオのためのGharai2003年3月のRTP有効搭載量形式
This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS TRACK]
このメモは映画テレビ技術者協会(SMPTE)規格、SMPTEによって292M定義されるように解凍されたHigh Definition Television(HDTV)をカプセル化するのにRTPペイロード形式を指定します。 SMPTEは動きイメージ産業でボディーを標準化するメインです、そして、SMPTEの292Mの規格は局部HDTV輸送のために少し連続のデジタルインタフェースを定義します。 [標準化過程]
3496 Malis Mar 2003 Protocol Extension for Support
of Asynchronous Transfer Mode
(ATM) Service Class-aware
Multiprotocol Label Switching
(MPLS) Traffic Engineering
3496 非同期通信モードの(気圧)サービスのクラス意識しているMultiprotocolラベルの切り換え(MPLS)交通工学のサポートのためのMalis2003年3月のプロトコル拡張子
This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.
このドキュメントは、Asynchronous Transfer Mode(ATM)のサービスのClass意識しているMultiprotocol Label Switching(MPLS)トラフィックEngineeringのサポートのための拡大に合図しながら、Resource ReSerVationプロトコルトラフィックEngineering(RSVP-TE)を指定します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 2] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[2ページ]のRFC3499概要
3495 Beser Mar 2003 Dynamic Host Configuration
Protocol (DHCP) Option
for CableLabs Client
Configuration
CableLabsクライアント構成のための3495年のBeser2003年3月のDynamic Host Configuration Protocol(DHCP)オプション
This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS TRACK]
このドキュメントはCableLabsアーキテクチャの中で配布された様々なデバイスを構成するのに使用されるDynamic Host Configuration Protocol(DHCP)オプションを定義します。 明確に、ドキュメントは1つのクラスのCableLabsクライアントデバイスを構成するのに使用されるDHCPオプション内容について説明します: PacketCableメディアティーエー(MTA)。 将来のCableLabsクライアントデバイスが開発されているのに従って、このドキュメントの中に定義されたオプション内容は広げられるでしょう。 [標準化過程]
3494 Zeilenga Mar 2003 Lightweight Directory Access
Protocol version 2 (LDAPv2)
to Historic Status
Zeilenga3494年2003年3月のライトウェイト・ディレクトリ・アクセス・プロトコルバージョン2(LDAPv2) Historic Statusに
This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community.
このドキュメントは、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAPv2)と他の依存する仕様のバージョン2の引退を推薦して、そうする理由について議論します。 このドキュメントは、RFC1777、1778、1779、1781、および2559(それらが取って代わったドキュメントと同様に)がHistoric状態に動かされることを勧めます。 このメモはインターネットコミュニティのための情報を提供します。
3493 Gilligan Mar 2003 Basic Socket Interface
Extensions for IPv6
3493 ギリガン2003年3月IPv6に、基本的なソケットインタフェース拡大
The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.
TCP/IPアプリケーションのためのデファクトスタンダードApplication Program Interface(API)は「ソケット」インタフェースです。 このAPIは1980年代前半のUnixのために開発されましたが、また、それはさまざまな非unixシステムの上で実装されました。ソケットAPIを使用することで書かれたTCP/IPアプリケーションは過去に高度合いの移植性を楽しみました、そして、私たちはIPv6アプリケーションがある同じ移植性が欲しいと思います。 しかし、変化はソケットAPIにIPv6をサポートしなければなりません、そして、このメモはこれらの変化について説明します。 これらは、IPv6アドレス、新しいアドレス変換機能、およびいくつかの新しいソケットオプションを運ぶために新しいソケットアドレス構造を含んでいます。 これらの拡大はTCPとUDPアプリケーションで必要である基本のIPv6の特徴へのアクセスを提供するように設計されています、マルチキャスティングを含んでいて最小変化をシステムに取り入れて、既存のIPv4アプリケーションに完全な両立性を提供していて。 高度なIPv6の特徴(生のソケットとIPv6拡張ヘッダーへのアクセス)のための追加拡大は別のドキュメントで定義されます。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 3] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[3ページ]のRFC3499概要
3492 Costello Mar 2003 Punycode: A Bootstring
encoding of Unicode for
Internationalized Domain Names
in Applications (IDNA)
3492 コステロ2003年3月のPunycode: ApplicationsのInternationalized Domain Namesのためにユニコードをコード化するBootstring(IDNA)
Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS TRACK]
Punycodeは使用のためにApplications(IDNA)のInternationalized Domain Namesと共に設計された構文をコード化する簡単で効率的な転送です。 それは唯一、reversiblyにユニコードストリングをASCIIストリングに変えます。 ユニコードストリングのASCII文字は文字通り代理をされます、そして、非ASCII文字はホスト名ラベル(手紙、ケタ、およびハイフン)に許容されているASCII文字によって代理をされます。 このドキュメントは一連の基本コードポイントにより大きいセットから得られたコード・ポイントのどんなストリングも唯一表させるBootstringと呼ばれる一般的なアルゴリズムを定義します。 PunycodeはIDNAに、適切なこのドキュメントによって指定された特定のパラメタ値を使用するBootstringのインスタンスです。 [標準化過程]
3491 Hoffman Mar 2003 Nameprep: A Stringprep Profile
for Internationalized Domain
Names (IDN)
3491 ホフマン2003年3月のNameprep: 国際化ドメイン名のためのStringprepプロフィール(IDN)
This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS TRACK]
このドキュメントは名前入力と名前比較が世界中の典型的なユーザのために理解できる方法で働いている可能性を広げるために国際化ドメイン名(IDN)ラベルを準備する方法を説明します。 stringprepプロトコルのこのプロフィールは、ドメインネームシステム(DNS)を国際的にするのにワイヤの上のひとそろいのプロトコルの一部として使用されます。 [標準化過程]
3490 Faltstrom Mar 2003 Internationalizing Domain
Names in Applications (IDNA)
3490 アプリケーションにおけるドメイン名を国際的にするFaltstrom2003年3月(IDNA)
Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS TRACK]
現在まで、ドメイン名がASCIIレパートリーの外にキャラクタを使用する標準方法が全くありませんでした。 このドキュメントは、一般的なファッションで彼らを扱うためにApplications(IDNA)で国際化ドメイン名(IDNs)とInternationalizing Domain Namesと呼ばれるメカニズムを定義します。 IDNsは大きいレパートリー(ユニコード)から得られたキャラクタを使用しますが、IDNAは、非ASCII文字が代理をされるのを今日いわゆるホスト名で既に許容されたASCII文字だけを使用することで許容します。 この後方コンパチブル表現がDNSのような既存のプロトコルで必要です、既存のインフラストラクチャへの変化なしでIDNsを導入できるように。 IDNAは無料のテキストではなく、処理ドメイン名のために意味されるだけです。 [標準化過程]
Ginoza Informational [Page 4] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[4ページ]のRFC3499概要
3489 Rosenberg Mar 2003 STUN - Simple Traversal of
User Datagram Protocol (UDP)
Through Network Address
Translators (NATs)
ローゼンバーグ2003年3月が気絶させる3489--ネットワークアドレス変換機構を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断(NATs)
Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS TRACK]
Network Address Translators(NATs)(STUN)を通したユーザー・データグラム・プロトコル(UDP)の簡単なTraversalはアプリケーションがそれらの間のNATsとファイアウォールの存在とタイプを発見できる軽量のプロトコルと公共のインターネットです。 また、それはアプリケーションがNATによってそれらに割り当てられた公共のインターネットプロトコル(IP)アドレスを決定する能力を提供します。 STUNは多くの既存のNATsと共に働いて、彼らから少しの特別な振舞いも必要としません。 その結果、それで、さまざまなアプリケーションが既存のNATインフラストラクチャを終えることができます。 [標準化過程]
3488 Wu Feb 2003 Cisco Systems Router-port
Group Management Protocol
(RGMP)
3488 ウー2003年2月のシスコシステムズルータポートグループ管理プロトコル(RGMP)
This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.
このドキュメントはRouter-ポートGroup Managementプロトコル(RGMP)について説明します。 このプロトコルは、シスコシステムズによって開発されて、それらのルータへのパケットが必要であるかもしれないスイッチでマルチキャストパケット推進を制限するのにマルチキャストルータとスイッチの間で使用されます。
RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community.
RGMPは複数の、そして、高い速度ルータがインタコネクトされるバックボーン交換網のために設計されています。 このメモはインターネットコミュニティのための情報を提供します。
3487 Schulzrinne Feb 2003 Requirements for Resource
Priority Mechanisms for the
Session Initiation Protocol
(SIP)
3487 Schulzrinne2003年2月に、セッション開始のためのリソース優先権メカニズムのための要件は議定書を作ります。(一口)
This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community.
このドキュメントはSession Initiationプロトコル(SIP)を使用することで非常時の気構えコミュニケーションのための回路交換ネットワーク、エンドシステム、およびプロキシリソースへのアクセスを最優先させるための要件をまとめます。 このメモはインターネットコミュニティのための情報を提供します。
3486 Camarillo Feb 2003 Compressing the Session
Initiation Protocol (SIP)
3486 セッション開始プロトコルを圧縮するキャマリロ2003年2月(一口)
This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS TRACK]
このドキュメントは、圧縮が1つ以上のSession Initiationプロトコル(SIP)メッセージのために望まれていると合図するためにメカニズムについて説明します。 また、それは、圧縮されたSIPメッセージをSIP実体に送るのがいつ適切であるかを述べます。 [標準化過程]
Ginoza Informational [Page 5] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[5ページ]のRFC3499概要
3485 Garcia-Martin Feb 2003 The Session Initiation
Protocol (SIP) and Session
Description Protocol
(SDP) Static Dictionary for
Signaling Compression
(SigComp)
3485 シグナリング圧縮のためのガルシア-マーチン2003年2月のセッション開始プロトコル(一口)とセッションの記述のプロトコルの(SDP)静的な辞書(SigComp)
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS TRACK]
Session Initiationプロトコル(SIP)は、コミュニケーションセッションを開始して、管理するためのテキストベースのプロトコルです。 Signaling Compression(SigComp)を使用することによって、プロトコルを圧縮できます。 同様に、Session記述プロトコル(SDP)はセッション発表(セッション招待、および他の形式のマルチメディアセッション開始)の目的のためのマルチメディアセッションについて説明するために意図するテキストベースのプロトコルです。 このメモはSigCompが、より高い効率を達成するのに使用するかもしれないSIP/SDP特有の静的な辞書を定義します。 辞書は圧縮アルゴリズム独立者です。 [標準化過程]
3484 Draves Feb 2003 Default Address Selection for
Internet Protocol version 6
(IPv6)
3484 インターネットプロトコルバージョン6のためのDraves2003年2月のDefault Address Selection(IPv6)
This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.
このドキュメントはソースアドレス選択と目的地アドレス選択のための2つのアルゴリズムを説明します。 アルゴリズムはすべてのインターネットプロトコルバージョン6(IPv6)実装のためのデフォルトの振舞いを指定します。 彼らはアプリケーションでされた選択か上側の層のプロトコルをくつがえしません、そして、アドレス選択のために、より高度なメカニズムの開発を排除しません。 2つのアルゴリズムが一般的な文脈を共有します、管理者がデフォルトの振舞いをくつがえすことができる方針を提供するのを許容するための任意のメカニズムを含んでいて。 デュアルスタック実装では、目的地アドレス選択アルゴリズムはIPv4とIPv6アドレスの両方を考えることができます--利用可能なソースアドレスによって、アルゴリズムはIPv4アドレスよりIPv6アドレスを好むかもしれませんか、逆もまた同様です。
All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS TRACK]
ホストとルータの両方を含むすべてのIPv6ノードが、この仕様に基づき定義されるようにデフォルトがアドレス選択であると実装しなければなりません。 [標準化過程]
Ginoza Informational [Page 6] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[6ページ]のRFC3499概要
3483 Rawlins Mar 2003 Framework for Policy Usage
Feedback for Common Open
Policy Service with Policy
Provisioning (COPS-PR)
3483 方針の食糧を供給するとの一般的なオープンポリシーサービスのための方針用法フィードバックのためのローリンズ2003年3月のフレームワーク(PRを獲得します)です。
Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community.
一般的なオープンPolicy Services(COPS)はPolicy Decision Point(PDP)と(RFC2748)について議定書の中で述べて、情報を報告する能力を定義します。 レポート情報のタイプは、インストールされた状態の成功と、失敗と会計です。 このドキュメントはインストールされた状態への用法フィードバックのモニターと報告のためにAccountingのCOPS Report Typeと必要なフレームワークに焦点を合わせます。 このメモはインターネットコミュニティのための情報を提供します。
3482 Foster Feb 2003 Number Portability in the
Global Switched Telephone
Network (GSTN): An Overview
3482はグローバルな切り換えられた電話網(GSTN)の2003年2月のナンバーポータビリティを伸ばしています: 概要
This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN).
このドキュメントはE.164電話番号の移植性(NP)の概要をGlobal Switched Telephone Network(GSTN)に供給します。
NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community.
NPは地方の電話サービス競争を自由化しようとする規定の命令です、サービスプロバイダーを変えている間、エンドユーザが電話番号を保有するのを可能にすることによって。 NPはダイヤルされたE.164番号の基本的な本質を階層的な物理的なルーティングアドレスから仮想アドレスに変えます、その結果、前者への後のわかりやすい翻訳を必要とします。 さらに、それの大部分がネットワーク技術特有でないNP実装のための関連パラメタを確立する様々な規定の規制があります。 その結果、適切な規定の規制と一致したNPの振舞いの実装(存在があるinteroperationの必要性と同様にGSTN NP実装)はIETFがあるIP電話技術執筆中の作品の多数の領域への関連した話題です。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 7] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[7ページ]のRFC3499概要
3481 Inamura, Ed. Feb 2003 TCP over Second (2.5G)
and Third (3G) Generation
Wireless Networks
エド3481Inamura、2番目の(2.5G)と第3(3G)世代ワイヤレス・ネットワークの上の2003年2月のTCP
This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
このドキュメントが適合するようにTCPを最適化するためのプロフィールについて説明するので、それは2番目の(2.5G)と3(3G)番目の世代ワイヤレス・ネットワークを含む経路を扱います。 それは2.5Gと3Gネットワークの関連特性、およびそのようなネットワークの例の展開の特定の特徴について説明します。 次に、それはそのような経路で出発するか終わるのが知られているノードのためのアルゴリズム選択をTCPに推薦します、そして、また、未解決の問題について議論します。 このドキュメントのお勧めの設定オプションは、近代的なTCPスタックで一般的に見つけられて、共同体が一般的なインターネットにおける使用に安全であると考える広く利用可能な標準化過程メカニズムです。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3480 Kompella Feb 2003 Signalling Unnumbered Links in
CR-LDP (Constraint-Routing
Label Distribution Protocol)
3480 CR-自由民主党で無数のリンクに合図するKompella2003年2月(規制ルート設定ラベル分配プロトコル)
Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS TRACK]
Multi-プロトコルLabel Switching Traffic Engineering(MPLS TE)によって使用された現在の合図は無数のリンクのサポートを提供しません。 このドキュメントはConstraint-ルート設定Label Distributionプロトコル(CR-自由民主党)(無数のリンクを支えるのに必要であるMPLS TE合図プロトコルの1つ)と手順と拡大を定義します。 [標準化過程]
3479 Farrel, Ed. Feb 2003 Fault Tolerance for the Label
Distribution Protocol (LDP)
3479 エドファレル、ラベル分配プロトコルのための2003年2月の耐障害性(自由民主党)
Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks.
Multiprotocol Label Switching(MPLS)システムはシステム休止時間を絶対最小値まで保たなければならないコアネットワークに使用されるでしょう。 したがって、多くのMPLS Label Switching Routers(LSRs)が、コアネットワークの高い有用性を提供するのにFault Tolerant(FT)ハードウェアかソフトウェアを利用するかもしれません。
The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations.
FTがLabel Distributionプロトコル(自由民主党)、切り換えハードウェア、およびTCPを含むFT LSRの様々な部品のためにどう達成されるかに関する詳細は実装特有です。 このドキュメントは、RFC3036の自由民主党仕様、現在の自由民主党プロトコルを使用することでFT LSRを実装するのを難しくする「自由民主党仕様」で問題を特定して、そのようなFT LSR実装を緩和するために自由民主党仕様と増進を定義します。
Ginoza Informational [Page 8] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[8ページ]のRFC3499概要
The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS TRACK]
「規制ベースのLSPセットアップは自由民主党を使用し」て(CR-自由民主党)、ここで説明された問題と拡大は等しくRFC3212に適切です。 [標準化過程]
3478 Leelanivas Feb 2003 Graceful Restart Mechanism for
Label Distribution Protocol
3478 ラベル分配プロトコルのためのLeelanivasの2003年2月の優雅な再開メカニズム
This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart.
このドキュメントはLabel Switching Routerの(LSR)のコントロール飛行機再開で引き起こされたMPLSトラフィックへのマイナスの効果を最小にするのを助けるメカニズムについて説明します、特にLabel Distributionプロトコル(自由民主党)コンポーネントの再開で、再開の向こう側にMPLS推進の部品を保存できるLSRsで。
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.
本書では説明されたメカニズムはすべてのLSRs(能力(後者は、本書では説明されたメカニズムの部分集合だけを実装する必要がありますが)がある自由民主党の再開とそれらの間の推進状態を保持する両方のそれら)に適切です。 サポートする、(部分集合、)、ここで再開の向こう側に彼らのMPLS推進状態を保持できないLSRsによって説明されたメカニズムが彼らのコントロール飛行機再開で引き起こされたMPLSトラフィックへの負の衝撃を減少させないでしょうが、それは、彼らの隣人ができるなら彼らの制御飛行機の再開の向こう側に推進状態を保持するのについて影響を最小にして、ここで説明されたメカニズムを実装するでしょう。
The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart.
メカニズムは再開の向こう側に保存されなければならないことに関するminimalistic仮定をします--メカニズムは、実際のMPLS推進状態だけが保持されなければならないと仮定します。 メカニズムは、自由民主党関連の州のどれかが再開の向こう側に保存されるのを必要としません。
The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS TRACK]
本書では説明された手順は川下の求められていないラベル分配に適用されます。 さらなる研究には川下のオンデマンドのラベル分配にこれらの手順を広げるのがあります。 [標準化過程]
3477 Kompella Jan 2003 Signalling Unnumbered Links in
Resource ReSerVation Protocol -
Traffic Engineering (RSVP-TE)
2003年1月が議定書を作ると資源予約に基づく無数のリンクに合図する3477Kompella--交通工学(RSVP-Te)
Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS TRACK]
Multi-プロトコルLabel Switching Traffic Engineering(MPLS TE)によって使用された現在の合図は無数のリンクのサポートを提供しません。 このドキュメントはLabel Switched Path(LSP)Tunnels(RSVP-TE)、無数のリンクを支えるのに必要であるプロトコルに合図するMPLS TEの1つのためにResource ReSerVationプロトコル(RSVP)と手順と拡大を定義します。 [標準化過程]
Ginoza Informational [Page 9] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[9ページ]のRFC3499概要
3476 Rajagopalan Mar 2003 Documentation of IANA
Assignments for Label
Distribution Protocol
(LDP), Resource ReSerVation
Protocol (RSVP), and Resource
ReSerVation Protocol-Traffic
Engineering (RSVP-TE)
Extensions for Optical UNI
Signaling
3476 ラベル分配プロトコルのためのIANA課題(自由民主党)、資源予約プロトコル(RSVP)、および光学UNIシグナリングのための資源予約プロトコル交通工学(RSVP-Te)拡大のRajagopalan2003年3月のドキュメンテーション
The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community.
Optical Interworking Forum(OIF)は光学User Network Interface(UNI)シグナリングのためにLabel Distributionプロトコル(自由民主党)とResource ReSerVationプロトコル(RSVP)と拡大を定義しました。 これらの拡大は1セットの新しいデータ・オブジェクトとエラーコードから成ります。 このドキュメントはこれらの拡大について説明します。 このメモはインターネットコミュニティのための情報を提供します。
3475 Aboul-Magd Mar 2003 Documentation of IANA
assignments for
Constraint-Based LSP setup
using LDP (CR-LDP) Extensions
for Automatic Switched Optical
Network (ASON)
3475 Automatic Switched Optical Networkに自由民主党(CR-自由民主党)拡張子を使用するベースのConstraint LSPセットアップのためのIANA課題のAboul-Magd2003年3月のDocumentation(ASON)
Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community.
自動Switched Optical Network(ASON)は光学ネットワークのための制御飛行機の導入のためのITU-T Study Group15によって指定されたアーキテクチャです。 ASONアーキテクチャはASONの建築実体の間の関係を定義する1セットの基準点を指定します。 それらの基準点で定義されたインタフェースの上で合図するのはGeneralized Multi-プロトコルLabel Switching(GMPLS)仕事の文脈でIETFによって定義されるプロトコルを利用できます。 このドキュメントは、ASON基準点で定義されたインタフェースの上で合図するのに自由民主党(CR-自由民主党)拡張子を使用することでベースのConstraint LSPセットアップについて説明します。 ドキュメントの目的はIANAがCR-自由民主党の拡大に必要なコード・ポイントを割り当てるよう要求することです。 CR-自由民主党拡張子の使用のためのプロトコル仕様はITU-Tドキュメントで見つけられます。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 10] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[10ページ]のRFC3499概要
3474 Lin Mar 2003 Documentation of IANA
assignments for Generalized
MultiProtocol Label Switching
(GMPLS) Resource Reservation
Protocol - Traffic Engineering
(RSVP-TE) Usage and Extensions
for Automatically Switched
Optical Network (ASON)
Generalized MultiProtocol Label Switching(GMPLS)リソース予約プロトコルのためのIANA課題の3474年のリン2003年3月のDocumentation--Automatically Switched Optical NetworkのためのトラフィックEngineering(RSVP-TE)用法とExtensions(ASON)
The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs).
プロトコル仕様のGeneralized MultiProtocol Label Switching(GMPLS)スイートは、異なったアプリケーションと同様に異なった技術のサポートを提供するために定義されました。 これらはOptical Transport Networks(OTNs)と同様にSynchronous Optical NETwork/同期デジタルハイアラーキ(Sonet/SDH)に基づくTDM接続を要求するサポートを含んでいます。
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.
このドキュメントはプロトコルのGMPLSスイートのシグナリング局面に集中します、明確にGMPLSがResource予約プロトコルを使用することで合図して--トラフィックEngineering(RSVP-TE)。 それは、ASONネットワークの能力をサポートするためにこれらのシグナリングプロトコルに追加拡大を提案します。
This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.
このドキュメントはITUのASON標準化取り組みを支持してITU-T Study Group15によって特定されて、伝えられた追加要件の解決に向かって適切な拡大を提案します。 このメモはインターネットコミュニティのための情報を提供します。
3473 Berger Jan 2003 Generalized Multi-Protocol
Label Switching (GMPLS)
Signaling Resource ReserVation
Protocol-Traffic Engineering
(RSVP-TE) Extensions
バーガー3473年1月の2003年の一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大
This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS TRACK]
このドキュメントはMulti-プロトコルLabel Switching(MPLS)リソースReserVationプロトコルに拡大について説明します--トラフィックEngineering(RSVP-TE)シグナリングがGeneralized MPLSをサポートするのが必要です。 一般化されたMPLSは、時間分割(例えば、同期式光通信網と同期デジタルハイアラーキ、Sonet/SDH)、波長(光学λ)、および空間的な切り換え(例えば、出発しているポートかファイバーへの入って来るポートかファイバー)を取り囲むためにMPLS制御飛行機を広げています。 このドキュメントは拡大のRSVP-TEの明確な記述を提示します。 別々のドキュメントでジェネリックの機能的な記述を見つけることができます。 [標準化過程]
Ginoza Informational [Page 11] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[11ページ]のRFC3499概要
3472 Ashwood-Smith Jan 2003 Generalized Multi-Protocol
Label Switching (GMPLS)
Signaling Constraint-based
Routed Label Distribution
Protocol (CR-LDP) Extensions
3472のAshwood-スミス1月の2003年の一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの規制ベースの発送されたラベル分配プロトコル(CR-自由民主党)延期
This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS TRACK]
このドキュメントはシグナリングがGeneralized MPLSをサポートするのを必要としたMulti-プロトコルLabel Switching(MPLS)の規制ベースのRouted Label Distributionプロトコル(CR-自由民主党)に拡大について説明します。 一般化されたMPLSは、時間分割(例えば、同期式光通信網と同期デジタルハイアラーキ、Sonet/SDH)、波長(光学λ)、および空間的な切り換え(例えば、出発しているポートかファイバーへの入って来るポートかファイバー)を取り囲むためにMPLS制御飛行機を広げています。 このドキュメントは拡大のCR-自由民主党の明確な記述を提示します。 別々のドキュメントでジェネリックの機能的な記述を見つけることができます。 [標準化過程]
3471 Berger Jan 2003 Generalized Multi-Protocol
Label Switching (GMPLS)
Signaling Functional
Description
3471 バーガー2003年1月は、機能的な記述に合図しながら、マルチプロトコルラベルスイッチング(GMPLS)を一般化しました。
This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS TRACK]
このドキュメントはLabel Switching(MPLS)シグナリングがGeneralized MPLSをサポートするのを必要としたMulti-プロトコルに拡大について説明します。 一般化されたMPLSは、時間分割(例えば、同期式光通信網と同期デジタルハイアラーキ、Sonet/SDH)、波長(光学λ)、および空間的な切り換え(例えば、出発しているポートかファイバーへの入って来るポートかファイバー)を取り囲むためにMPLS制御飛行機を広げています。 このドキュメントは拡大の機能的な記述を提示します。 特定の形式とメカニズムについて議定書の中で述べてください。そうすれば、技術の特定の詳細は別々のドキュメントで指定されます。 [標準化過程]
3470 Hollenbeck Jan 2003 Guidelines for the Use
of Extensible Markup
Language (XML)
within IETF Protocols
3470 IETFプロトコルの中の拡張マークアップ言語(XML)の使用のためのHollenbeck2003年1月ガイドライン
The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.
拡張マークアップ言語(XML)は、データを構造化するためのフレームワークです。 Standard Generalized Markup Language(SGML)から発展しましたが(マークアップ言語は、ドキュメントを構造化するのは主として焦点を合わせました)、XMLは、構造化されたデータを表すための広く使用されたメカニズムになるように発展しました。
Ginoza Informational [Page 12] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[12ページ]のRFC3499概要
There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
開発されていて、さまざまなインターネットプロトコルがあります。 多くで、構造化されたデータの表現の必要性は彼らのアプリケーションに関連するようになります。 表現メソッドとしてXMLの使用における大きな関心がありました。 このドキュメントは、基本のXML概念について説明して、XMLの使用で様々な代替手段を分析して、IETF標準化過程プロトコルの中でXMLの使用のためのガイドラインを提供します。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3469 Sharma, Ed. Feb 2003 Framework for Multi-Protocol
Label Switching (MPLS)-based
Recovery
3469 エドシャルマ、マルチプロトコルラベルスイッチングの(MPLS)ベースの回復のための2003年2月のフレームワーク
Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community.
マルチプロトコルラベルスイッチング(MPLS)はラベルスワッピング推進パラダイムをネットワーク層ルーティングと統合します。 信頼できるサービスを提供するなら、MPLSは、異なった経路で運ばれたトラフィックの保護を提供するためにセットに手順を要求します。 これは、ラベル切り換えルータ(LSRs)が欠点検出、欠点通知、および欠点回収機構をサポートして、MPLSシグナリングが回復の構成をサポートするのを必要とします。 これらの目的が念頭にある状態で、このドキュメントはMPLSのベースの回復にフレームワークを指定します。 再開問題はこのフレームワークに含まれていません。 このメモはインターネットコミュニティのための情報を提供します。
3468 Andersson Feb 2003 The Multiprotocol Label
Switching (MPLS) Working Group
decision on MPLS signaling
protocols
3468年のアンデション2003年2月MPLSシグナリングプロトコルのMultiprotocol Label Switching(MPLS)作業部会の決定
This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community.
このドキュメントは主力を注ぐIETFの中のMultiprotocol Label Switching(MPLS)作業部会によって達せられたコンセンサスを記録します。「資源予約は(RSVP)Teについて議定書の中で述べます」。 交通工学アプリケーション、「ラベル分配プロトコル(自由民主党)を使用する規制ベースのLSPセットアップ」(RFC3212)に関連するどんな新しい取り組みも引き受けないようにプロトコルに合図するMPLSとして「LabelのためのRSVPへの拡大はPaths(LSP)Tunnelsを切り換えた」(RFC3209)。 セクション6の推薦はIESGによって受け入れられました。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 13] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[13ページ]のRFC3499概要
3467 Klensin Feb 2003 Role of the Domain Name System
(DNS)
3467 ドメインネームシステムのKlensin2003年2月の役割(DNS)
This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.
このドキュメントはドメイン名システム(DNS)の元の機能と目的について調査します。 それはそれに置かれるか、またはそれのために示されるDNSが最近適用された目的のいくつかと、より新しい要求のいくつかに対して、その歴史を対照します。 そして、これらの追加圧力をDNSに置くことへの代替手段のためのフレームワークは概説されています。 このドキュメントとそのフレームワークは提案されたソリューション(時間が私たちが行きあたっている問題について、より露骨に考えて、それらを解決することへの可能なアプローチを始めるようになったという強い提案だけ)ではありません。 このメモはインターネットコミュニティのための情報を提供します。
3466 Day Feb 2003 A Model for Content
Internetworking (CDI)
満足しているインターネットワーキングのための1モデルあたりの3466年の日の2003年2月(CDI)
Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community.
満足している(分配)インターネットワーキング(CDI)は、ネットワーク、以前に時々呼ばれた「満足しているじっと見る」または「CDNのじっと見る」という内容とインタコネクトするための技術です。 一般的なボキャブラリーはそのようなインタコネクトとinteroperationについて議論するプロセスを助けます。 このドキュメントは、満足しているネットワークと満足しているインターネットワーキングを紹介して、そのような一般的なボキャブラリーのために要素を定義します。 このメモはインターネットコミュニティのための情報を提供します。
3465 Allman Feb 2003 TCP Congestion Control with
Appropriate Byte Counting
(ABC)
3465 適切なバイトが重要であることのオールマン2003年2月のTCP輻輳制御(ABC)
This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community.
このドキュメントはTCPが混雑ウィンドウを増強する方法への小さい変更を提案します。 それぞれ到着している承認のために混雑ウィンドウを一定の量で増強する伝統的方法よりむしろ、ドキュメントは、増加を各ACKがカバーする以前に不承認のバイトの数に基礎づけるのを示します。 この変化は、あまりに急速に送付レートを増強するのに送付者を引き起こすためにTCPの性能を向上させて、TCP受信機が使用できるセキュリティーホールを閉じます。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
Ginoza Informational [Page 14] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[14ページ]のRFC3499概要
3464 Moore Jan 2003 An Extensible Message Format
for Delivery Status
Notifications
3464 配送状態通知のための広げることができるメッセージ・フォーマットあたりのムーア2003年1月
This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail.
このメモはメッセージ転送エージェント(MTA)か電子メールゲートウェイによって使用される、1人以上の受取人に伝言をもたらす試みの結果を報告するかもしれないマルチパーパスインターネットメールエクステンション(MIME)content typeを定義します。 このcontent typeは現在インターネット電子メールで使用されている様々なタイプに関する配送状態通知とのマシン-「プロセス-可能」交換として意図します。
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS TRACK]
インターネットと他のメッセージシステム(X.400かいわゆる「ローカル・エリア・ネットワーク(LAN)ベース」のシステムなどの)の間に多くのメッセージを送るので、Delivery Status Notification(DSN)プロトコルは環境を通信させながらマルチプロトコルで役に立つように設計されています。 このために、このメモで説明されたプロトコルは「外国」のアドレスとエラーコードのキャリッジに備えます、通常、インターネット・メールで使用されるものに加えて。 また、追加属性は、インターネット・メールによる外国通知の「トンネリング」をサポートするために定義されるかもしれません。 [標準化過程]
3463 Vaudreuil Jan 2003 Enhanced Mail System Status
Codes
ボードルイ2003年1月が高めた3463はシステムステータスコードを郵送します。
This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS TRACK]
このドキュメントは配送現状報告(追跡していて、改良された病気の特徴)のメールシステムの中の使用のために1セットの拡張ステータスコードを定義します。 Delivery Status Notification(DSN)配送レポートに提供された他の情報と組み合わせて、これらのコードはメッセージ配送状態のメディアと言語から独立しているレンダリングを容易にします。 [標準化過程]
3462 Vaudreuil Jan 2003 The Multipart/Report Content
Type for the Reporting of
Mail System Administrative
Messages
3462 メールのシステムの管理メッセージの報告のためのボードルイ2003年1月複合/レポートcontent type
The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports.
Multipart/レポートマルチパーパスインターネットメールエクステンション(MIME)content typeは、どんな種類の電子メールレポートのための一般的な「ファミリー」か「コンテナ」タイプです。 このメモはMultipart/の使用だけを定義しますが、すべての種類のレポートにおいて、配送現状報告に関するcontent type、ただ一つのcontent typeがためになるなら処理プログラムがためになるメールが使用されていると報告してください。
Ginoza Informational [Page 15] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[15ページ]のRFC3499概要
This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS TRACK]
このドキュメントは配送現状報告サービスについて説明する1人の4文献集合の一部です。 この収集は、配送現状報告、配送レポートの報告のためのMIME内容、拡張ステータスコードの列挙、および失敗の配送レポート、オリジナルのメッセージ、および人間に優しい概要のための複合コンテナを要求するためにシンプルメールトランスファプロトコル(SMTP)拡大を含んでいます。 [標準化過程]
3461 Moore Jan 2003 Simple Mail Transfer Protocol
(SMTP) Service Extension
for Delivery Status
Notifications (DSNs)
配送状態通知のための3461年のムーア2003年1月のシンプルメールトランスファプロトコル(SMTP)サービス拡大(DSNs)
This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS TRACK]
このメモはシンプルメールトランスファプロトコル(SMTP)サービスへの送付者がDSNが発行された受取人とオリジナルのメッセージが送られたトランザクションの両方を特定できる拡大を定義します。((b) そのような通知がDSNと共に返すためにメッセージ、および(c)のコンテンツに追加情報を返すべきであるか否かに関係なく、SMTPクライアントはサービスで(a) Delivery Status Notifications(DSNs)が一定の条件の下で生成されるべきであると指定できます)。 [標準化過程]
3460 Moore Jan 2003 Policy Core Information Model
(PCIM) Extensions
3460のムーア2003年1月の方針コア情報モデル(PCIM)拡大
This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS TRACK]
このドキュメントはPolicy Core情報Model(PCIM、RFC3060)への多くの変化を指定します。 2つのタイプの変化は含まれています。 まず最初に、ヘッダーのための例えばクラスがフィルターにかけられて、それが以前にカバーしなかった領域にPCIMを広げる数個の完全に新しい要素が紹介されます。2番目に、ケースがPCIM(例えば、政策ルールプライオリティ)の要素が推奨しなく、交換要素が定義される(この場合、プライオリティは政策ルールを示す協会につながりました)ところにあります。 両方のタイプの変化は可能な範囲内でオリジナルのPCIMモデルの実装がある相互運用性が保存されるような方法で完了しています。 このドキュメントはRFC3060をアップデートします。 [標準化過程]
3459 Burger Jan 2003 Critical Content Multi-purpose
Internet Mail Extensions
(MIME) Parameter
バーガー3459年1月の2003の重要な満足している多目的のインターネットメール拡大(MIME)パラメタ
This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.
このドキュメントはメカニズムの送付者が複合インターネットメール・メッセージで重要であると考える身体の部分を特定する使用について説明します。 RFC3204によって説明されるように説明されたメカニズムはContent-気質へのパラメタです。
Ginoza Informational [Page 16] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[16ページ]のRFC3499概要
By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS TRACK]
より少ない能力のシステムにゲートウェイサービスを供給するとき、送付者が、重要であるとメッセージのどんな部分が考えるかを知っていることによって、満足しているゲートウェイは知的に複合メッセージを扱うことができます。 重要な内容は、満足しているゲートウェイが、どんな部品を進めたらよいかを決めるのを助けることができます。 それは、どれくらい固いゲートウェイが身体の部分を提供しようとするはずであるかを示すことができます。 より少ない能力のシステムがメッセージを受け取るとき静かに削除するために安全な身体の部分を選ぶと、ゲートウェイを助けることができます。 追加、重要な満足している缶の支援におけるゲートウェイは受電方式のための通知戦略を選びました。 同様に、送付者が、目的地が身体の部分における何らかの処理をすると予想するなら、重要な内容で、送付者は受信機が加工処理しなければならない身体の部分を示すことができます。 [標準化過程]
3458 Burger Jan 2003 Message Context for Internet
Mail
3458 インターネットメールのためのバーガー2003年1月のメッセージの文脈
This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message.
このメモは新しいRFC2822メッセージヘッダー、「メッセージの文脈」について説明します。 このヘッダーはメッセージの文脈とプレゼンテーションの特性の情報を提供します。
A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS TRACK]
受信ユーザエージェント(UA)は、メッセージを最適に提示するのにヒントとしてこの情報を使用するかもしれません。 [標準化過程]
3457 Kelly Jan 2003 Requirements for IPsec Remote
Access Scenarios
3457 IPsecの遠隔アクセスのシナリオのためのケリー2003年1月要件
IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community.
IPsecは安全なリモートアクセス機構として多くの約束を提供します。 しかしながら、多くの異なった遠隔アクセスのシナリオ、いくつかをそれぞれ共有させて、およびいくつかのユニークな要件があります。 これらの要件の徹底的な理解が、事実上、どんな特定の遠隔アクセスのシナリオのためにも特定のセットのメカニズムの適合を評価するのに必要です。 このドキュメントは多くの一般的な遠隔アクセスのシナリオのための要件を列挙します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 17] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[17ページ]のRFC3499概要
3456 Patel Jan 2003 Dynamic Host Configuration
Protocol (DHCPv4)
Configuration of IPsec Tunnel
Mode
3456年のIPsecトンネル・モードのパテル2003年1月のDynamic Host Configuration Protocol(DHCPv4)構成
This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS TRACK]
このメモは、IPsecトンネルモードによるホスト構成のための要件について調査して、Dynamic Host Configuration Protocol(DHCPv4)が構成のためにどう利用されるかもしれないかを説明します。 多くの遠隔アクセスのシナリオでは、リモートホストが、ローカルの企業ネットワークに存在しているように見えさせるためのメカニズムはかなり役に立ちます。 これは、「仮想」のアドレスを企業ネットワークからホストに割り当てて、次に、ホストのISP割り当てられたアドレスから企業の機密保持ゲートウェイまでのIPsecを通してトラフィックにトンネルを堀ることによって、達成されるかもしれません。 IPv4では、DHCPはそのようなリモートホスト構成に備えます。 [標準化過程]
3455 Garcia-Martin Jan 2003 Private Header (P-Header)
Extensions to the Session
Initiation Protocol (SIP) for
the 3rd-Generation Partnership
Project (3GPP)
第3世代パートナーシッププロジェクトのためのセッション開始プロトコル(一口)への3455のガルシア-マーチンの2003年1月の個人的なヘッダー(P-ヘッダー)拡大(3GPP)
This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.
このドキュメントは第3世代Partnership Project(3GPP)によって使用された1セットの個人的なSession Initiationプロトコル(SIP)ヘッダー(P-ヘッダー)について説明します、彼らの適用性と共に。(それは、特定の環境に制限されます)。 パートナーが使用するネットワークの中にP-ヘッダーはさまざまな目的のためにあります、呼び出しが横断するネットワークの充電と情報を含んでいて。 このメモはインターネットコミュニティのための情報を提供します。
3454 Hoffman Dec 2002 Preparation of
Internationalized Strings
("stringprep")
3454 国際化しているストリングのホフマン2002年12月の準備("stringprep")
This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings.
このドキュメントは、世界中の典型的なユーザのために理解できる方法でそのストリング入力とストリング比較仕事をテキストが可能性を広げるために結ぶユニコードに準備するためにフレームワークについて説明します。 stringprepプロトコルはプロトコル識別子値、会社、個人名、国際化ドメイン名、および他のテキスト文字列の役に立ちます。
This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS TRACK]
このドキュメントはプロトコルがどうテキスト文字列を準備するべきであるかを指定しません。 プロトコルは、処理オプションを完全に指定するためにstringprepのプロフィールを作成しなければなりません。 [標準化過程]
Ginoza Informational [Page 18] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[18ページ]のRFC3499概要
3453 Luby Dec 2002 The Use of Forward Error
Correction (FEC) in Reliable
Multicast
信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の3453Luby2002年12月の使用
This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community.
このメモは、IPマルチキャストを使用することで多くへの1のための信頼性の確実な資料輸送を効率的に提供する、そして/または、増大させるためにForward Error Correction(FEC)コードの使用について説明します。 FECコードの基本性質の1つはこのような関係においては同時に複数の受信機で異なったパケット損失パターンを修理するのにFECデータを含む同じパケットを使用する能力です。 異なったクラスのFECコードと彼らのいくつかの基礎特性が説明されます、そして、信頼できるマルチキャストプロトコルでFECを実装すると関連している用語は紹介されます。 パケットのための可能な抽象的な形式がFECを運ぶのについて例を提供します。 このメモはインターネットコミュニティのための情報を提供します。
3452 Luby Dec 2002 Forward Error Correction (FEC)
Building Block
3452年のLuby2002年12月の前進型誤信号訂正(FEC)ブロック
This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community.
一般に、このドキュメントはデータ伝送のために信頼性を効率的に提供する、そして/または、増大させるのにForward Error Correction(FEC)コードを使用する方法を説明します。 このドキュメントの焦点はIPマルチキャストを使用する多くへの1つの信頼できるデータ伝送へのFECコードの適用です。 このドキュメントは、どんな情報が特定のFECコードを特定するのに必要であるか、そして、どんな情報が、FECコードを使用するためにバンドの外でコミュニケートする必要があるか、そして、どんな情報がそれらが運ぶコード化シンボルを特定するのにデータ・パケットで必要であるかを説明します。 また、インターネットAssigned民数記Authority(IANA)にFECコードを指定して、それらを登録するための手順は説明されます。 このドキュメントは題をつけられた仲間ドキュメント、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」について読んで、用語を使用することであるべきです。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
3451 Luby Dec 2002 Layered Coding Transport (LCT)
Building Block
3451 Luby2002年12月の層にされたコード化輸送(LCT)ブロック
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community.
(LCT)が提供する層にされたCoding Transportは信頼できる内容物配送とストリーム配送プロトコルの平らなサポートを輸送します。 LCTはIPマルチキャストを使用することでプロトコルをサポートするように明確に設計されていますが、ユニキャストを使用するプロトコルにサポートをまた提供します。 LCTも複数のレート配送を受信機に供給する輻輳制御と互換性があって、また、内容の信頼できる配信を提供するコーディング技法と互換性があります。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
Ginoza Informational [Page 19] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[19ページ]のRFC3499概要
3450 Luby Dec 2002 Asynchronous Layered Coding
(ALC) Protocol Instantiation
3450 Luby2002年12月の非同期な層にされたコード化(ALC)プロトコル具体化
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community.
このドキュメントはAsynchronous Layered Coding(ALC)プロトコル、膨大にスケーラブルな信頼できる内容物配送プロトコルについて説明します。 混雑を供給するLayered Coding Transport(LCT)ブロック、倍数が混雑制御建家とForward Error Correction(FEC)ブロックを評定する非同期なLayered Codingコンバインは独身の送付者から無制限な数の同時発生の受信機に内容の信頼できる非同期な配送を制御しました。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
3449 Balakrishnan Dec 2002 TCP Performance Implications
of Network Path Asymmetry
3449 ネットワーク経路非対称のBalakrishnan2002年12月TCPパフォーマンス含意
This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.
このドキュメントは非対称の効果で起こるTCP性能問題について説明します。 これらの問題は帯域幅非対称のネットワークと異なった基本的な理由によるパケットラジオサブネットワークを含むいくつかのアクセスネットワークで起こります。 しかしながら、TCP性能の結末はどちらの場合も、同じです: 性能は不完全と可変性のためにACKフィードバックでしばしば受信機から送付者までかなり下がります。
The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
ドキュメントはいくつかの緩和をこれらの効果に詳しく述べます。(文学で提案されるか、評価される、または効果は現在、ネットワークで配布されました)。 以下から成って、これらのソリューションはローカルのリンク層のテクニック、サブネットワーク、および終わりから終わりへのメカニズムの組み合わせを使用します。 (i) 上流のボトルネックに使用されるチャンネルを管理するテクニックはACKsを運びながら、リンクされます、ヘッダー圧縮を通常使用するか、またはTCP ACKs(反対の方向へのデータとACKパケットが両面交通があるとき性能を向上させる計画をするようにTCP送付者の承認で引き起こされた自己時計と(iii)のテクニックを保有するためにこの減少しているACK頻度に扱う(ii)のテクニック)の頻度を減少させて 各テクニックは知られている問題、および使用のための推薦と共に説明されます。 ドキュメントの端で推薦の概要を提供します。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
Ginoza Informational [Page 20] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[20ページ]のRFC3499概要
3448 Handley Jan 2003 TCP Friendly Rate Control
(TFRC): Protocol Specification
ハンドレー3448年2003年1月のTCPの好意的な速度制御(TFRC): プロトコル仕様
This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS TRACK]
このドキュメントはTCP好意的なRate Control(TFRC)を指定します。 TFRCは最も良い取り組みインターネット環境で作動するユニキャスト流れのための混雑制御機構です。 それで、TCP流れで帯域幅を競争するとき、合理的に公正ですが、時間がたつにつれてスループットのはるかに低い変化をTCPと比較します、それを比較的滑らかな送付レートが重要である電話などのアプリケーションに適したかストリーミングのメディアにして。 [標準化過程]
3447 Jonsson Feb 2003 Public-Key Cryptography
Standards (PKCS) #1: RSA
Cryptography Specifications
Version 2.1
3447 イェンソン2003年2月公開鍵暗号化標準(PKCS)#1: RSA暗号仕様バージョン、2.1
This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.
このメモはRSA研究所の公開鍵暗号化標準(PKCS)シリーズからPKCS#1v2.1の再刊を表します、そして、変化コントロールはPKCSプロセスの中で保有されます。 このドキュメントのボディーは直接PKCS#1v2.1ドキュメントから抜粋されます、公表プロセスの間、ある修正をしていて。 このメモはインターネットコミュニティのための情報を提供します。
3446 Kim Jan 2003 Anycast Rendevous Point (RP)
mechanism using Protocol
Independent Multicast (PIM)
and Multicast Source Discovery
Protocol (MSDP)
プロトコル無党派Multicast(PIM)とMulticast Sourceディスカバリープロトコルを使用する3446年のキムジャン2003Anycast Rendevous Point(RP)メカニズム(MSDP)
This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.
このドキュメントは、ただ一つの共有された木のプロトコル無党派のMulticastまばらなMode(PIM-SM)ドメインで1グループあたりのRendevous Points(RPs)の特殊活字の数字を考慮するためにメカニズムについて説明します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 21] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[21ページ]のRFC3499概要
3445 Massey Dec 2002 Limiting the Scope of the KEY
Resource Record (RR)
3445 主要なリソース記録の範囲を制限するマッシー2002年12月(RR)
This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS TRACK]
このドキュメントはドメインネームシステム(DNS)KEY Resource Record(RR)をドメインネームシステムSecurity Extensions(DNSSEC)によって使用されたキーだけに制限します。 オリジナルのKEY RRは、DNSSECキーと任意のアプリケーションキーの両方を保存するのにサブタイプを使用しました。 同じレコード種類でDNSSECとアプリケーションキーの両方を保存するのは、誤りです。 このドキュメントは、KEY RR DataでKEY記録からプロトコルOctet分野を再定義することによって、アプリケーションキーを取り除きます。 アプリケーションキーを取り除くことの結果、KEY記録の旗の1つ以外のすべてが、不要になって、再定義されます。 3つの既存のアプリケーションキーサブタイプに予約されていた状態で変えますが、KEY記録の形式は変えません。 このドキュメントはRFC2535をアップデートします。 [標準化過程]
3444 Pras Jan 2003 On the Difference between
Information Models and Data
Models
3444 情報モデルとデータモデルの違いのPras2003年1月
There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models.
ネットワークマネージメントで管理オブジェクトを定義するための情報ModelsとData Modelsの違いに関して進行中の混乱がありました。 このドキュメントで、既存のネットワーク管理モデル仕様(国際電気通信連合(ITU)かDistributed Management Task Force(DMTF)などのIETFと他のボディーからの)がどう情報ModelsとData Modelsの宇宙に収まるかを分析することによって、これらの用語の違いがわかります。
This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.
このメモはテキサス大学オースティン校によって接待されたインターネットResearch Task Force(IRTF)のNetwork Management Research Group(NMRG)の8番目のワークショップの主な結果を記録します。 このメモはインターネットコミュニティのための情報を提供します。
3443 Agarwal Jan 2003 Time To Live (TTL) Processing
in Multi-Protocol Label
Switching (MPLS) Networks
3443生きるマルチプロトコルラベルスイッチング(MPLS)ネットワークで処理されるAgarwal2003年1月の時間(TTL)
This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS TRACK]
このドキュメントは、階層的なMulti-プロトコルLabel Switching(MPLS)ネットワークでTime To Live(TTL)処理について説明して、MPLSのための操作のTTL-透過モードのラベルで切り換えられた経路を正式にする必要性によって動機づけられています。 それはRFC3032、「MPLSラベルスタックコード化」をアップデートします。 PipeとUniform Modelの両方で階層的なトンネルを処理するTTLが両方のための「プッシュ」という例で指定されて、ケースを「飛び出させます」。 ドキュメントは、また、RFC3270、「差別化されたサービスのMPLSサポート」の補足となって、そのドキュメントでTTL処理で階層的なMPLSネットワークで紹介された用語を結びつけます。 [標準化過程]
Ginoza Informational [Page 22] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[22ページ]のRFC3499概要
3442 Lemon Dec 2002 The Classless Static Route
Option for Dynamic Host
Configuration Protocol (DHCP)
version 4
3442 Dynamic Host Configuration Protocol(DHCP)バージョン4のためのレモン2002年12月のClassless Static Route Option
This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS TRACK]
このドキュメントはクライアントでスタティックルートのリストを構成するためにDHCP ServerからDHCP Clientまで合格される新しいDynamic Host Configuration Protocol(DHCP)オプションを定義します。 これらのルートによるネットワークの目的地は階級がありません--それぞれの経路指定テーブルエントリーはサブネットマスクを含んでいます。 [標準化過程]
3441 Kumar Jan 03 Asynchronous Transfer Mode
(ATM) Package for the Media
Gateway Control Protocol
(MGCP)
メディアゲートウェイ制御プロトコルのための3441年のクマー1月03日の非同期通信モード(気圧)パッケージ(MGCP)
This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community.
このドキュメントはメディアゲートウェイControlプロトコル(MGCP)のためのAsynchronous Transfer Mode(ATM)パッケージについて説明します。 このパッケージは新しいLocal Connection Options、ATM特有のイベント、信号、およびATM接続パラメタを含んでいます。 また、含まれているのは、コーデックとプロフィール交渉の記述です。 それは現在多くの製品の中に配布されているMGCPを広げています。 ImplementersはIETF Megaco作業部会とITU SG16で開発を意識しているべきです。(ITU SG16は現在、このプロトコルの潜在的後継者に働いています)。 このメモはインターネットコミュニティのための情報を提供します。
3440 Ly Dec 2002 Definitions of Extension
Managed Objects for Asymmetric
Digital Subscriber Lines
3440 非対称デジタル加入者線伝送方式のための拡大管理オブジェクトのLy2002年12月定義
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS TRACK]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはADSL線MIB(RFC2662)でカバーされなかった非対称デジタル加入者線伝送方式(ADSL)インタフェースを管理するのに使用される追加管理オブジェクトについて説明します。 [標準化過程]
Ginoza Informational [Page 23] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[23ページ]のRFC3499概要
3439 Bush Dec 2002 Some Internet Architectural
Guidelines and Philosophy
3439年のブッシュ2002年12月何らかのインターネットの建築ガイドラインと哲学
This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community.
このドキュメントは、インターネットの基幹ネットワークの建築家とデザイナーが固守するべきである哲学的なガイドラインのいくつかについて概説することによって、RFC1958を広げています。 私たちは、複雑さが効率的なスケーリングを妨害する一次機構であると述べるSimplicity Principleについて説明して、アーキテクチャで含意について議論します、とデザインと工学問題によって、大規模インターネットの基幹でわかりました。 このメモはインターネットコミュニティのための情報を提供します。
3438 Townsley Dec 2002 Layer Two Tunneling Protocol
(L2TP) Internet Assigned
Numbers Authority (IANA)
Considerations Update
Townsley3438年2002年12月の層Twoのトンネリングプロトコル(L2TP)インターネット規定番号権威(IANA)問題アップデート
This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
このドキュメントはLayer Two Tunnelingプロトコル(L2TP)のためにインターネットAssigned民数記Authority(IANA)問題にアップデートについて説明します。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3437 Palter Dec 2002 Layer-Two Tunneling Protocol
Extensions for PPP Link
Control Protocol Negotiation
pppリンク制御議定書交渉のためのプロトコル拡大にトンネルを堀って、3437は2002年12月の層-Twoをあしらいます。
This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS TRACK]
このドキュメントはPointプロトコル(PPP)オプションへのリンク特有のPointの高められたサポートのためにLayer Two Tunnelingプロトコル(L2TP)と拡大を定義します。 PPP終点は、通常、それらを接続する一般的な物理的なメディアにダイレクトに近づく手段を持って、その結果、メディアに関する使用中の知識を詳しく述べました。 L2TPが使用されているとき、2人のPPP同輩はもう直接同じ物理的なメディアの上に接続されません。 代わりに、L2TPはIPなどのパケット交換網の上でトンネリングPPPフレームのそばでPPP接続のいくつかかすべて上に仮想接続を挿入します。 いくつかの条件のもとでは、L2TP終点は、LCP交渉への適切な参加のためにメディア必要情報のすべてに近づく手段を持っていないかもしれない位置でPPP Link Controlプロトコル(LCP)オプションを交渉する必要があるかもしれません。 このドキュメントはPPP LCP交渉の前にL2TP終点の間でL2TPトンネルの遠端で必要なLCPオプションを伝えるのにメカニズムを提供します、交渉されたLCPオプションに伝え返すためのネイティブのPPPリンクが住んでいるメカニズムと同様に。 [標準化過程]
Ginoza Informational [Page 24] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[24ページ]のRFC3499概要
3436 Jungmaier Dec 2002 Transport Layer Security over
Stream Control Transmission
Protocol
3436 Jungmaier2002年12月に、ストリーム制御伝動の上のトランスポート層セキュリティは議定書を作ります。
This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.
このドキュメントはTransport Layer Security(TLS)プロトコルの用法を説明します、RFC2246で定義されるように、Stream Control Transmissionプロトコル(SCTP)の上で、RFC2960とRFC3309で定義されるように。
The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance.
TLSのユーザはSCTPによって提供された特徴を利用できます、すなわち、系列ブロッキングのヘッドを避ける複数のストリームのサポートと提供するマルチホーミングのサポートは平らな耐障害性をネットワークでつなぎます。
Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS TRACK]
また、特にIPアドレスのダイナミックな再構成のサポートを意味して、さらに、SCTPの拡大の議論はサポートされます。 [標準化過程]
3435 Andreasen Jan 03 Media Gateway Control Protocol
(MGCP) Version 1.0
3435年のAndreasen1月03日のメディアゲートウェイ制御プロトコル(MGCP)バージョン1.0
This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP.
このドキュメントはアプリケーションプログラミングインターフェースと分解しているマルチメディアゲートウェイの要素の間で使用される対応するプロトコル(MGCP)について説明します。 分解しているマルチメディアゲートウェイはCallエージェントとメディア機能(例えば、TDM声からボイス・オーバー IPまでの変換)を含むメディアゲートウェイから成ります。(そのエージェントは、呼び出しコントロール「知性」を含みます)。
Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints.
メディアゲートウェイはCallエージェントが他のマルチメディア終点とのメディアセッションを確立して、制御するために接続を創造して、変更して、削除できる終点を含んでいます。 また、Callエージェントはあるイベントを検出して、信号を生成するよう終点に命令できます。 終点は自動的にサービス状態の変化をCallエージェントに伝えます。 その上、Callエージェントは終点における接続と同様に終点を監査できます。
The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. This memo provides information for the Internet community.
基本的で一般的なMGCPプロトコルは本書では定義されます、メディアゲートウェイが、特定のタイプのメディアゲートウェイによる使用に適したプロトコルと拡大を定義する1個以上のMGCPパッケージを実装する最も必要があっても。 そのようなパッケージは別々のドキュメントで定義されます。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 25] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[25ページ]のRFC3499概要
3434 Bierman Dec 2002 Remote Monitoring MIB
Extensions for High Capacity
Alarms
3434 高容量アラームのためのBierman2002年12月リモートモニターしているMIB拡張子
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS TRACK]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは、Counter64データ型に基づくオブジェクトの同様の敷居モニターを提供するためにRemote Monitoring(RMON)MIB(RFC2819)で見つけられたアラームthresholding能力を広げるために管理オブジェクトについて説明します。 [標準化過程]
3433 Bierman Dec 2002 Entity Sensor Management
Information Base
3433 Bierman2002年12月の実体センサ管理情報ベース
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS TRACK]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは、ネットワーク設備(筐体温度、ファンRPM、電源電圧などの)でしばしば見つけられる物理的なセンサに関連する一般化された情報入手を提供するために、Entity MIB(RFC2737)を広げるために管理オブジェクトについて説明します。 [標準化過程]
3432 Raisanen Nov 2002 Network performance
measurement with periodic
streams
3432は周期的なストリームで2002年11月のNetwork性能測定をRaisanenします。
This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS TRACK]
このメモは、IPネットワークの性能を評価するために周期的な標本抽出メソッドと関連測定基準について説明します。 まず最初に、メモは、RFC2330で説明されたポアソン標本抽出に代わる手段として周期的な標本抽出を動機づけて、価値の問題を扱います。 利益は分析を簡素化できるアクティブで受け身の測定値、(マルチメディア通信、またはほとんどCBRの典型と、声のアクティビティ検出について備え付け)の固定ビットレート(CBR)トラフィックのシミュレーション、およびいくつかのインスタンスへの適用性を含んでいます。 標本抽出メソッドは、ランダム・スタート時間と有限長さ試験を強制することによって、予見性を避けます。 標本抽出メソッドとサンプルのメートル法のパラメタ、測定メソッド、および誤りの後述について議論します。 最終的に、私たちはセキュリティ問題を含む周期的な測定値に関する追加情報を与えます。 [標準化過程]
Ginoza Informational [Page 26] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[26ページ]のRFC3499概要
3431 Segmuller Dec 2002 Sieve Extension: Relational
Tests
3431 Segmuller2002年12月のふるいの拡張子: 関係テスト
This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS TRACK]
このドキュメントはRFC3028で定義された言語をフィルターにかけるSieveメールにRELATIONAL拡張子について説明します。 この拡大は、関係演算子を許容するためにSieveでの既存の条件付きのテストを広げています。 また、それらの内容をテストすることに加えて、それは、ヘッダーと封筒分野の実体の数をテストすると考慮します。 [標準化過程]
3430 Schoenwaelder Dec 2002 Simple Network Management
Protocol (SNMP) over
Transmission Control Protocol
(TCP) Transport Mapping
通信制御プロトコル(TCP)輸送マッピングの上のSchoenwaelderの3430年2002年12月の簡単なネットワーク管理プロトコル(SNMP)
This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community.
このメモはSimple Network Managementを使用するために、TCPの上でプロトコル(SNMP)を写像する輸送を定義します。 SNMPのどんなバージョンと共にも輸送マッピングを使用できます。 このドキュメントはSTD62、RFC3417で定義された輸送マッピングを広げています。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
3429 Ohta Nov 2002 Assignment of the 'OAM Alert
Label' forMultiprotocol Label
Switching Architecture (MPLS)
Operation and Maintenance
(OAM) Functions
3429 'OAMの警告ラベル'forMultiprotocolラベル切り換えアーキテクチャ(MPLS)維持管理(OAM)機能の太田2002年11月の課題
This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community.
このドキュメントはRFC3032(MPLSラベルスタックコード化)でMPLS OAMパケットの識別にユーザ飛行機Multiprotocol Label Switching Architecture(MPLS)OAM機能によって使用される'操作とMaintenance(OAM)の警告Label'と定義された予約されたラベル値の1つの課題について説明します。 このメモはインターネットコミュニティのための情報を提供します。
3428 Campbell Dec 2002 Session Initiation Protocol
(SIP) Extension for Instant
Messaging
インスタントメッセージングのための3428年のキャンベル2002年12月のセッション開始プロトコル(一口)拡大
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.
近いリアルタイムで即時のMessaging(IM)はユーザの間のメッセージの転送について言及します。 通常、急にあるのが必要でないのを除いて、これらのメッセージはそうです。 IMsは会話形モードでしばしば使用されます、すなわち、メッセージの転送。前後に、関係者がインタラクティブの会話を維持できるくらい速くあります。
Ginoza Informational [Page 27] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[27ページ]のRFC3499概要
This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS TRACK]
このドキュメントはMESSAGEメソッド(Instant Messagesの転送を許容するSession Initiationプロトコル(SIP)への拡大)を提案します。 MESSAGE要求がSIPへの拡大であるので、それはそのプロトコルのすべての要求ルーティングとセキュリティ機能を引き継ぎます。 MESSAGE要求はMIME身体の部分の形で内容を運びます。 自分たちではなく、要求がするMESSAGEがSIP対話を開始します。 正常な用法の下では、各Instant Messageはポケットベルのメッセージのように単独で立ちます。 ある他のSIP要求で開始された対話の文脈でMESSAGE要求を送るかもしれません。 [標準化過程]
3427 Mankin Dec 2002 Change Process for the Session
Initiation Protocol (SIP)
3427 セッション開始プロトコルのためのマンキン2002年12月の変化プロセス(一口)
This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
このメモはSession Initiationプロトコル(SIP)の今後の開発に建築規律を適用することを意図するプロセスを記録します。 新しいSIP提案への尊敬がある関心がありました。 明確に、新しいSIPの特徴の追加がセキュリティに向かって大いにダメージが大きい場合があるのがプロトコルの複雑さを増強します。 Transport AreaディレクターはSIPとSession Initiation Proposal Investigation(SIPPING)ワーキンググループいすをもってSIP変更と拡大のための提案を提供しました。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3426 Floyd Nov 2002 General Architectural and
Policy Considerations
3426 フロイド2002年11月建築するのと方針の一般問題
This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community.
このドキュメントは新しい規格とプロトコルに取り組むときIETF共同体が扱わなければならない建築するのと方針の一般的な質問を示します。 私たちは、ガイドラインか建築原則と対照的に続かれるように扱われるためにこのドキュメントが質問を含むことに注意します。 このメモはインターネットコミュニティのための情報を提供します。
3425 Lawrence Nov 2002 Obsoleting IQUERY
3425 IQUERYを時代遅れにするローレンス2002年11月
The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS TRACK]
逆さのDNSルックアップを実行するRFC1035で指定されたIQUERYメソッドは、一般に、実装されていなくて、通常、それが実装されたところで操作上無効にされました。 両方が概念が賢明でなく、指針(PTR)質問と逆マッピング記録を使用する広く使用された代替のアプローチが望ましいという共同体の一般的な意見を反映します。 その結果、それが完全に時代遅れであると宣言して、このドキュメントはIQUERY操作を非難します。 このドキュメントはRFC1035をアップデートします。 [標準化過程]
Ginoza Informational [Page 28] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[28ページ]のRFC3499概要
3424 Daigle Nov 2002 IAB Considerations for
UNilateral Self-Address Fixing
(UNSAF) Across Network Address
Translation
3424 ネットワークアドレス変換の向こう側に(UNSAF)を修理する一方的な自己アドレスのためのDaigle2002年11月IAB問題
As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
Network Address Translation(NAT)Middleboxesの自然の結果、1NATsによって切り離される交信終点は彼らの(現在で将来)の同輩のアドレシング分野で有効なアドレスを使用することで自分たちについて言及する方法を知りません。 「一方的な自己アドレス固定(UNSAF)」プロセスのために様々な提案をしました。 これらはいくつかの起因する終点がそれは別の終点に知られています--プロトコル交換にアドレスデータを使用するか、または例えばそれが接続を受ける場内放送の広告を出すことができるようにアドレス(そして、ポート)を決定するか、または修理するのを試みるプロセスです。
This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.
このドキュメントは、UNSAF提案を作成する前に慎重に評価されるために、短期間フィックスであるとこれらの提案をせいぜいみなすことができる理由について特定の問題と特定の問題に概説します。 このメモはインターネットコミュニティのための情報を提供します。
3423 Zhang Nov 2002 XACCT's Common Reliable
Accounting for Network Element
(CRANE) Protocol Specification
Version 1.0
3423 ネットワーク要素(クレーン)プロトコル仕様バージョン1.0のためのチャン2002年11月のXACCTの一般的な信頼できる会計
This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.
このドキュメントはどんなデータの効率的で信頼できる配送も可能にするNetwork Element(CRANE)プロトコルのためにCommon Reliable Accountingを定義します、データを主にNetwork Elementsからどんなシステムまでも説明して、仲介システムやBusiness Support Systems(BSS)/操作Support Systems(OSS)のように。 プロトコルは、ネットワーク、ストレージ、および処理リソースの効率的な使用でNEのものからの会計データの高いボリュームをエクスポートすることに関する決定的な必要性を扱うために開発されます。
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community.
このドキュメントはプロトコルのアーキテクチャとメッセージ・フォーマットを指定します。(すべてのCRANEプロトコル実装でそれをサポートしなければなりません)。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 29] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[29ページ]のRFC3499概要
3422 Okamoto Nov 2002 Forwarding Media Access
Control (MAC) Frames over
Multiple Access Protocol over
Synchronous Optical
Network/Synchronous Digital
Hierarchy (MAPOS)
同期式光通信網/同期デジタルハイアラーキの上の複数のアクセス・プロトコルの上の3422個の岡本2002年11月の推進メディアアクセス制御(MAC)フレーム(MAPOS)
This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community.
このメモは同期式光通信網/同期デジタルハイアラーキ(MAPOS)の上でMultiple Accessプロトコルの上で推進メディアアクセス制御(MAC)フレームにメソッドを説明します、その結果、MAPOSネットワーク環境とMACベースのローカル・エリア・ネットワーク(LAN)環境を統一する方法を提供します。 このメモはインターネットコミュニティのための情報を提供します。
3421 Zhao Nov 2002 Select and Sort Extensions for
the Service Location Protocol
(SLP)
3421 チャオ2002年11月は、サービス位置のプロトコルのための拡大を選択して、分類します。(SLP)
This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community.
そして、このドキュメントが2つの拡大を定義する、(選ぶ、Sort) Service Locationプロトコル(SLP)のために。 これらの拡大で、Userエージェント(UA)は、Service Reply(SrvRply)のUniform Resource Locator(URL)エントリーが指定された数に制限されるか、または指定された分類用キーリストによると、分類されるよう要求できます。 これらの2つの拡張子を一緒に使用するのは、最も良いマッチを発見するのを容易にすることができます、最高回転数か最小負荷を持っているサービスを見つけるのなどように。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
3420 Sparks Nov 2002 Internet Media Type
message/sipfrag
3420 スパークス2002年11月のインターネットメディアTypeメッセージ/sipfrag
This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS TRACK]
このドキュメントはメッセージ/sipfragマルチパーパスインターネットメールエクステンション(MIME)メディアタイプを示します。 このタイプは、メッセージ/一口と同様ですが、完全なSIPメッセージを必要とすることの代わりに表されるべき整形式のSession Initiationプロトコル(SIP)メッセージのある部分集合を許容します。 終わりから終わりへのセキュリティ用途に加えて、メッセージ/sipfragは参照をつけられた要求の状態の周りで情報を伝達するREFERメソッドで使用されます。 [標準化過程]
Ginoza Informational [Page 30] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[30ページ]のRFC3499概要
3419 Daniele Dec 2002 Textual Conventions for
Transport Addresses
3419 輸送アドレスのためのダニエル2002年12月原文のコンベンション
This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS TRACK]
このドキュメントは一般的に使用されたトランスポート層アドレス指定情報を表すために原文のコンベンションを定義するManagement Information基地(MIB)のモジュールを導入します。 定義は、Management情報バージョン2(SMIv2)のStructureによって紹介されるTAddress/TDomain組の概念と互換性があって、IPv4とIPv6の上でインターネットがトランスポート・プロトコルであるとサポートします。 [標準化過程]
3418 Presuhn Dec 2002 Management Information Base
(MIB) for the Simple Network
Management Protocol (SNMP)
簡単なネットワーク管理プロトコルのためのPresuhn3418年2002年12月の管理情報ベース(MIB)(SNMP)
This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS TRACK]
このドキュメントはSimple Network Managementプロトコル(SNMP)実体の振舞いについて説明する管理オブジェクトを定義します。 このドキュメントはSimple Network Managementプロトコル(SNMPv2)のバージョン2のためにRFC1907、Management Information基地を時代遅れにします。 [標準化過程]
3417 Presuhn Dec 2002 Transport Mappings for
the Simple Network Management
Protocol (SNMP)
3417 Presuhn2002年12月に、簡単なネットワークマネージメントのための輸送マッピングは議定書を作ります。(SNMP)
This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS TRACK]
このドキュメントは様々なプロトコルの上でSimple Network Managementプロトコル(SNMP)メッセージの輸送を定義します。 このドキュメントはRFC1906を時代遅れにします。 [標準化過程]
3416 Presuhn Dec 2002 Version 2 of the Protocol
Operations for the Simple
Network Management Protocol
(SNMP)
簡単なネットワーク管理プロトコルのためのプロトコル操作のPresuhn3416年2002年12月のバージョン2(SNMP)
This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS TRACK]
このドキュメントはSimple Network Managementプロトコル(SNMP)のためのプロトコル操作のバージョン2を定義します。 それは送付、受信、および処理SNMP PDUsのための手順の構文と要素を定義します。 このドキュメントはRFC1905を時代遅れにします。 [標準化過程]
Ginoza Informational [Page 31] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[31ページ]のRFC3499概要
3415 Wijnen Dec 2002 View-based Access Control
Model (VACM) for the
Simple Network Management
Protocol (SNMP)
簡単なネットワーク管理プロトコルのためのWijnenの3415年2002年12月の視点ベースのアクセス制御モデル(VACM)(SNMP)
This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS TRACK]
このドキュメントはSimple Network Managementプロトコル(SNMP)アーキテクチャにおける使用のために、ViewベースのAccess Control Model(VACM)について説明します。 それは、経営情報へのアクセスを制御するためにProcedureのElementsを定義します。 また、このドキュメントはViewのベースのAccess Control Modelのための設定パラメータを離れて管理するためのManagement Information基地(MIB)を含んでいます。 このドキュメントはRFC2575を時代遅れにします。 [標準化過程]
3414 Blumenthal Dec 2002 User-based Security Model
(USM) for version 3 of the
Simple Network Management
Protocol (SNMPv3)
Simple Network Managementプロトコルのバージョン3のためのブルーメンソル3414年2002年12月のUserベースのSecurity Model(USM)(SNMPv3)
This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS TRACK]
このドキュメントはSNMPアーキテクチャにおける使用のためのSimple Network Managementプロトコル(SNMP)バージョン3のために、UserベースのSecurity Model(USM)について説明します。 それは、メッセージレベルセキュリティをSNMPに供給するためにProcedureのElementsを定義します。 また、このドキュメントはこのSecurity Modelのための設定パラメータを離れてモニターするか、または管理するためのManagement Information基地(MIB)を含んでいます。 このドキュメントはRFC2574を時代遅れにします。 [標準化過程]
3413 Levi Dec 2002 Simple Network Management
Protocol (SNMP) Applications
3413のレビ2002年12月の簡単なネットワーク管理プロトコル(SNMP)アプリケーション
This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.
このドキュメントはSTD62(RFC3411)で説明されるようにSNMPエンジンを利用する5つのタイプのSimple Network Managementプロトコル(SNMP)アプリケーションについて説明します。 説明されたアプリケーションのタイプは、Command Generatorsと、Command Respondersと、Notification Originatorsと、Notification Receiversと、Proxy Forwardersです。
This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS TRACK]
また、このドキュメントは管理操作の目標を指定するためのManagement Information基地(MIB)のモジュールを定義します、推進をフィルターにかけてプロキシ推進のための通知のために。 このドキュメントはRFC2573を時代遅れにします。 [標準化過程]
Ginoza Informational [Page 32] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[32ページ]のRFC3499概要
3412 Case Dec 2002 Message Processing and
Dispatching for the Simple
Network Management Protocol
(SNMP)
3412は簡単なネットワーク管理プロトコルのための2002年12月のメッセージ処理と急ぎをケースに入れます。(SNMP)
This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS TRACK]
このドキュメントはSimple Network Managementプロトコル(SNMP)メッセージのためにSNMPアーキテクチャの中でMessage ProcessingとDispatchingについて説明します。 それはSNMPメッセージの潜在的に複数のバージョンを適切なSNMP Message Processing Modelsに派遣して、SNMPアプリケーションにPDUsを派遣するための手順を定義します。 また、このドキュメントは1Message Processing Modelについて説明します--SNMPv3 Message Processing Model。 このドキュメントはRFC2572を時代遅れにします。 [標準化過程]
3411 Harrington Dec 2002 An Architecture for Describing
Simple Network Management
Protocol (SNMP) Management
Frameworks
3411 簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するための1アーキテクチャあたりのハリントン2002年12月
This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS TRACK]
このドキュメントは、Simple Network Managementプロトコル(SNMP)管理Frameworksについて説明するためにアーキテクチャについて説明します。 アーキテクチャは、時間がたつにつれてSNMPプロトコル標準の発展を許容するためにはモジュールであるために設計されています。 アーキテクチャの主要部は、Message Processing Subsystem、Security Subsystem、およびAccess Control Subsystemを含むSNMPエンジンと、管理データの特定の機能的な処理を提供することによると複数のSNMPアプリケーションです。 このドキュメントはRFC2571を時代遅れにします。 [標準化過程]
3410 Case Dec 2002 Introduction and Applicability
Statements for Internet
Standard Management Framework
インターネットの標準の管理フレームワークのための3410のケース2002年12月の序論と適用性証明
The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).
SNMPバージョン3Framework(SNMPv3)は、このドキュメントの目的がインターネット標準のManagement Frameworkの第3バージョンの概要を提供することであると呼びました。 このFrameworkはオリジナルのインターネット標準のManagement Framework(SNMPv1)と第2インターネット標準のManagement Framework(SNMPv2)の両方を引き出されて、当てにします。
The architecture is designed to be modular to allow the evolution of the Framework over time.
アーキテクチャは、時間がたつにつれてFrameworkの発展を許容するためにはモジュールであるために設計されています。
The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.
ドキュメントで、SNMPv1かSNMPv2の代わりにSNMPv3を使用するのがなぜ強く推薦されるかがわかります。 また、ドキュメントは、RFCs1157、1441、1901、1909、および1910が彼らをHistoric状態に動かすことによって回収されることを勧めます。 このドキュメントはRFC2570を時代遅れにします。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 33] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[33ページ]のRFC3499概要
3409 Svanbro Dec 2002 Lower Layer Guidelines for
Robust RTP/UDP/IP Header
Compression
3409 強健なRTP/UDP/IPヘッダー圧縮のためのSvanbro2002年12月下層ガイドライン
This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community.
このドキュメントは体力を要しているヘッダー圧縮(ROHC)のための下層ガイドラインとROHCが下層に置く要件について説明します。 このドキュメントの目的は強健なヘッダー圧縮アルゴリズムの編入をサポートすることです、ROHCワーキンググループで指定されるように、Third Generation Partnership Projectによって指定されたもの(3GPP)、3GPP Project2(3GPP2)、ヨーロッパのTechnical Standards Institute(ETSI)などの異系統に このドキュメントは[RFC3095]の指定されるとしてのRTP/UDP/IPとUDP/IPヘッダーの圧縮のための下層ガイドラインだけをカバーしています。 本書では一般的ガイドラインとセルラ方式に、特定のガイドラインの両方について議論します。 このメモはインターネットコミュニティのための情報を提供します。
3408 Liu Dec 2002 Zero-byte Support for
Bidirectional Reliable Mode
(R-mode) in Extended
Link-Layer Assisted RObust
Header Compression (ROHC)
Profile
3408 拡張リンクレイヤの双方向の信頼できるモード(R-モード)のリュウ2002年12月の無バイトサポートは(ROHC)が輪郭を描く体力を要しているヘッダー圧縮を促進しました。
This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS TRACK]
このドキュメントは2を超えてRFC3242で定義されていた状態でまた、無バイトプロフィールとして知られているリンクレイヤ補助RObust Header Compression(ROHC)プロフィールの追加モードを定義します。 無バイトヘッダー圧縮は、ただ一つの八重奏ROHCヘッダーがラジオのために次の、より高い固定パケットサイズにパケット声のストリームを押し込むのを防ぐために存在しています。 それは広く配布しているあるより古い空気インタフェースで使用可能です。 このドキュメントはRFC3242のヘッダー圧縮のUnidirectional(U-モード)とBidirectional Optimistic(O-モード)モードに指定されたものにROHC Bidirectional Reliableモード(R-モード)のための無バイト操作を加えます。 [標準化過程]
3407 Andreasen Oct 2002 Session Description Protocol
(SDP) Simple Capability
Declaration
3407年のAndreasen2002年10月のセッション記述プロトコル(SDP)の簡単な能力宣言
This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS TRACK]
このドキュメントはSDPが最小量の、そして、遅れているコンパチブル能力宣言メカニズムを提供するのを可能にする1セットのSession記述プロトコル(SDP)属性を定義します。 その後のセッション交渉(このドキュメントの範囲の外の手段で行われる)に入力されるようにそのような能力宣言を使用できます。 これはSDPの次の世代によって扱われて、また、SDPngとして知られていることにおける一般的な能力交渉問題に簡単で限られた解決法を提供します。 [標準化過程]
Ginoza Informational [Page 34] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[34ページ]のRFC3499概要
3406 Daigle Oct 2002 Uniform Resource Names (URN)
Namespace Definition
Mechanisms
3406 Daigleの2002年10月の一定のリソースは(つぼ)名前空間定義をメカニズムと命名します。
This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
このドキュメントはUniform Resource Namesを設立するための一般的な定義とメカニズム(URN)「名前空間」を広げます。 URN WGは構文がRFC2141のURNsのために定義されて、RFC3401とRFC3405のインターネットアプリケーションにおける彼らの解決と使用のためにいくつかの提案されたメカニズムを定義されました。 全体がURN構造の中で個々の「名前空間」の概念にかかっています。 概念の証拠名前空間は別として、RFC2288でURNsにおける既存の識別子の使用について議論しました。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3405 Mealling Oct 2002 Dynamic Delegation Discovery
System (DDDS) Part Five:
URI.ARPA Assignment Procedures
3405年の食事している2002年10月のダイナミックな委譲発見システム(DDDS)パートFive: URI.ARPA課題手順
This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
このドキュメントはそれが完全に指定されるシリーズでは、5番目に、「ダイナミックな委譲発見システム(DDDS)は1つを分ける」ということです。 「包括的なDDDS。」(RFC3401) 他のものを読まないでこのシリーズでどんなドキュメントも読んで、理解しているのが不可能であることに注意するのは非常に重要です。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3404 Mealling Oct 2002 Dynamic Delegation Discovery
System (DDDS) Part Four: The
Uniform Resource Identifiers
(URI) Resolution Application
3404年の食事している2002年10月のダイナミックな委譲発見システム(DDDS)パートFour: Uniform Resource Identifier(URI)解決アプリケーション
This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System.
このドキュメントはそのURIの情報のためにUniform Resource Identifier(URI)を取って、正式のサーバの場所を見つけるための仕様を説明します。 その正式のサーバの場所を見つけるのに使用されるメソッドはDynamic DelegationディスカバリーSystemです。
This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK]
このドキュメントはシリーズの一部です、すなわち、指定されて、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS。」(RFC3401) 他のものを読まないでこのシリーズでどんなドキュメントも読んで、理解しているのが不可能であることに注意するのは非常に重要です。 [標準化過程]
Ginoza Informational [Page 35] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[35ページ]のRFC3499概要
3403 Mealling Oct 2002 Dynamic Delegation Discovery
System (DDDS) Part Three: The
Domain Name System (DNS)
Database
3403年の食事している2002年10月のダイナミックな委譲発見システム(DDDS)パートThree: ドメインネームシステム(DNS)データベース
This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).
このドキュメントは、Rulesの分散データベースとしてドメインネームシステム(DNS)を使用することでDynamic DelegationディスカバリーSystem(DDDS)データベースについて説明します。 キーズはドメイン名です、そして、Rulesは、Naming Authority Pointer(NAPTR)リソースRecord(RR)を使用することでコード化されます。
Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK]
このドキュメントがRFC2915を時代遅れにするので、それはNAPTR DNS Resource Recordのための公式の仕様書です。 また、それはシリーズの一部です、すなわち、完全に指定されて、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS。」(RFC3401) 他のものを読まないでこのシリーズでどんなドキュメントも読んで、理解しているのが不可能であることに注意するのは非常に重要です。 [標準化過程]
3402 Mealling Oct 2002 Dynamic Delegation Discovery
System (DDDS) Part Two: The
Algorithm
3402年の食事している2002年10月のダイナミックな委譲発見システム(DDDS)パートTwo: アルゴリズム
This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS TRACK]
このドキュメントはダイナミックに検索されたストリング変換規則をアプリケーションユニークなストリングに適用するためのDynamic DelegationディスカバリーSystem(DDDS)アルゴリズムを説明します。 整形式の変換規則はストリングに関連している情報管理の委譲を反映するでしょう。 また、このドキュメントはシリーズの一部です、すなわち、完全に指定されて、「ダイナミックな委譲発見システム(DDDS)は1つを分けます」。 「包括的なDDDS。」(RFC3401) 他のものを読まないでこのシリーズでどんなドキュメントも読んで、理解しているのが不可能であることに注意するのは非常に重要です。 [標準化過程]
3401 Mealling Oct 2002 Dynamic Delegation Discovery
System (DDDS) Part One: The
Comprehensive DDDS
3401年の食事している2002年10月のダイナミックな委譲発見システム(DDDS)パート1: 包括的なDDDS
This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.
このドキュメントは完全なDynamic DelegationディスカバリーSystem(DDDS)を作る正確なドキュメントを指定します。 DDDSは、ダイナミックに検索されたストリング変換規則をアプリケーションユニークなストリングに適用するための抽象的なアルゴリズムです。 RFC3402に伴うこのドキュメント、RFC3403、およびRFC3404はRFC2168とRFC2915を時代遅れにします、アップデートRFC2276と同様に。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 36] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[36ページ]のRFC3499概要
3400 Never Issued
3400 決して発行されませんでした。
RFC 3400 was never issued.
RFC3400は決して発行されませんでした。
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
南カリフォルニア情報Sciences Institute4676海軍本部Wayマリナデルレイの砂地の宜野座大学、カリフォルニア 90292
Phone: (310) 822-1511 EMail: ginoza@isi.edu
以下に電話をしてください。 (310) 822-1511 メールしてください: ginoza@isi.edu
Ginoza Informational [Page 37] RFC 3499 Summary of 3400-3499 December 2003
3400-3499 2003年12月の宜野座の情報[37ページ]のRFC3499概要
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Ginoza Informational [Page 38]
宜野座情報です。[38ページ]
一覧
スポンサーリンク
