RFC3299 日本語訳
3299 Request for Comments Summary RFC Numbers 3200-3299. S. Ginoza. December 2003. (Format: TXT=63813 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Ginoza Request for Comments: 3299 ISI Category: Informational December 2003
コメントを求めるワーキンググループS.宜野座の要求をネットワークでつないでください: 3299年のISIカテゴリ: 情報の2003年12月
Request for Comments Summary
コメントには、概要を要求してください。
RFC Numbers 3200-3299
RFC No.3200-3299
Status of This Memo
このメモの状態
This RFC is a slightly annotated list of the 100 RFCs from RFC 3200 through RFC 3299. 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はRFC3200からRFC3299の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作者日付のタイトル--- ------ ---- -----
3299 Ginoza Dec 2003 Request for Comments Summary
宜野座2003年12月がコメント概要のために要求する3299
This memo.
このメモ。
Ginoza Informational [Page 1] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[1ページ]のRFC3299概要
3298 Faynberg Aug 2002 Service in the Public Switched
Telephone Network/Intelligent
Network (PSTN/IN) Requesting
InTernet Service (SPIRITS)
Protocol Requirements
3298 インターネットサービス(スピリッツ)プロトコル要件を要求する公衆電話交換網/インテリジェントネットワーク(中にPSTN/がある状態で)におけるFaynberg2002年8月のサービス
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
このドキュメントはRFC3136に提示されたアーキテクチャに基づいてSPIRITSプロトコル要件について説明します。 (SPIRITSは「インターネットサービスを要求することにおけるPSTN/でのサービス」を表します。) プロトコルの目的はPublic Switched Telephone Network(PSTN)で起こって、PSTNとインターネットとの相互作用を必要とするサービスをサポートすることです。 同様に、そのようなサービスはSPIRITSサービスと呼ばれます。 (インターネット発信番号表示のインターネットCall Waiting、Delivery、およびインターネットCall Forwardingは聖霊サービスの例ですが、プロトコルは他の多くのサービスを組み込むことができるブロックを定義することです。) PSTN側では、SPIRITSサービスがIntelligent Network(IN)実体から開始されます。 PSTN/インターネットInterworking(PINT)への以前のIETF作業はインターネットからPSTNまで逆に開始されたサービスを支持してプロトコル(RFC2848)をもたらしました。
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community.
このために、このドキュメントはWireless IN(IN)、およびPINTブロックに適切なそれらと同様にSPIRITSプロトコルのための一般的な要件をリストアップします。 また、ドキュメントはSPIRITSシグナリングプロトコルの選択に関するSPIRITS WGコンセンサスを提示します。 このメモはインターネットコミュニティのための情報を提供します。
3297 Klyne Jul 2002 Content Negotiation for
Messaging Services based on
Email
メッセージサービスのためのKlyne2002年7月のContent Negotiationがメールに基礎づけた3297
This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS TRACK]
このメモはファクシミリ、声、およびインターネットメールを使用する他のメッセージングサービスのために満足している交渉メカニズムについて説明します。 [標準化過程]
3296 Zeilenga Jul 2002 Named Subordinate References
in Lightweight Directory
Access Protocol (LDAP)
Directories
Zeilenga2002年7月が命名した3296はライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)ディレクトリにおける参照を下位に置かせます。
This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS TRACK]
表すのと管理のためのこのドキュメント詳細図式とプロトコル要素はライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)における下位参照をディレクトリと命名しました。 [標準化過程]
Ginoza Informational [Page 2] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[2ページ]のRFC3299概要
3295 Sjostrand Jun 2002 Definitions of Managed Objects
for the General Switch
Management Protocol (GSMP)
3295 シェストランド2002年6月に、一般スイッチ管理のための管理オブジェクトの定義は議定書を作ります。(GSMP)
This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS TRACK]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは一般Switch Managementプロトコル(GSMP)のために管理オブジェクトについて説明します。 [標準化過程]
3294 Doria Jun 2002 General Switch Management
Protocol (GSMP) Applicability
ドーリアの3294年2002年6月の一般スイッチ管理プロトコル(GSMP)の適用性
This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community.
このメモは、GSMP(一般Switch Managementプロトコル)の概要を提供して、IPネットワークで展開にMPLS環境で関連する情報を含んでいます。 それはATM(非同期なTransfer Mode)ネットワークか生のイーサネット構成で展開について議論しません。 このメモはインターネットコミュニティのための情報を提供します。
3293 Doria Jun 2002 General Switch Management
Protocol (GSMP) Packet
Encapsulations for
Asynchronous Transfer Mode
(ATM), Ethernet and
Transmission Control Protocol
(TCP)
非同期通信モード(気圧)のためのドーリアの3293年2002年6月の一般スイッチ管理プロトコル(GSMP)パケットカプセル化、イーサネット、および通信制御プロトコル(TCP)
This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS TRACK]
このメモはATM(非同期なTransfer Mode)、イーサネット、およびTCP(通信制御プロトコル)でGSMP(一般Switch Managementプロトコル)パケットのカプセル化を指定します。 [標準化過程]
3292 Doria Jun 2002 General Switch Management
Protocol (GSMP) V3
3292ドーリアの2002年6月の一般スイッチ管理プロトコル(GSMP)V3
This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS TRACK]
このドキュメントは一般Switch Managementプロトコルバージョン3(GSMPv3)について説明します。 GSMPv3はラベルスイッチの状態を設置して、維持するコントローラ、ATM、フレームリレーまたはMPLSスイッチを1個以上の外部のスイッチに許容する非対称のプロトコルです。 GSMPv3はユニキャストとマルチキャストスイッチ接続状態とスイッチ系リソースとQoSの特徴のコントロールの両方のコントロールを許します。 [標準化過程]
Ginoza Informational [Page 3] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[3ページ]のRFC3299概要
3291 Daniele May 2002 Textual Conventions for
Internet Network Addresses
3291 ダニエル2002年5月に、インターネットへの原文のコンベンションはアドレスをネットワークでつなぎます。
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK]
このMIBモジュールは、一般的に使用されたインターネット網層のアドレス指定情報を表すために原文のコンベンションを定義します。 意図はこれらの原文のコンベンション(TCs)がそうでなければそれら自身の表現を定義するMIBモジュールでインポートされて、使用されるということです。 [標準化過程]
3290 Bernet May 2002 An Informal Management Model
for Diffserv Routers
3290 Bernet2002年5月に、非公式の管理はDiffservルータのためにモデル化されます。
This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.
このドキュメントはそれらの管理と構成における使用のためにDifferentiated Services(Diffserv)ルータの非公式のマネジメント・モデルを提案します。 このモデルは機能的なdatapath要素(メーター、動作、マークしていて、絶対の低下が数えられて、例えば、クラシファイアが多重送信して)、アルゴリズムの点滴器、待ち行列、およびスケジューラを定義します。 それはこれらの要素とそれらがトラフィック調節の範囲がわかるためにどうインタコネクトされることができるように可能な設定パラメータとDiffserv Architectureで説明された1ホップあたりの振舞い(PHB)の機能性について説明するか。 このメモはインターネットコミュニティのための情報を提供します。
3289 Baker May 2002 Management Information Base
for the Differentiated
Services Architecture
3289 差別化されたサービスアーキテクチャのためのベイカー2002年5月の管理情報ベース
This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS TRACK]
このメモはDifferentiated Services Architectureを実装するデバイスのためにSMIv2(Management情報バージョン2の構造)MIBについて説明します。 それはDifferentiated Servicesの機能性ができるルータかスイッチのモニターと構成に使用されるかもしれません。 [標準化過程]
3288 O'Tuathail Jun 2002 Using the Simple Object Access
Protocol (SOAP) in Blocks
Extensible Exchange Protocol
(BEEP)
3288 広げることができる交換が議定書の中で述べるブロックでSimple Object Access Protocol(SOAP)を使用するO'Tuathail2002年6月(ビープ音)
This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS TRACK]
このメモは、Blocks Extensible Exchangeプロトコルコア(BEEP)まで付きながら、Simple Object Access Protocol(SOAP)を指定します。 SOAP結合はSOAPメッセージがネットワークでどう送られるかを説明します。 [標準化過程]
Ginoza Informational [Page 4] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[4ページ]のRFC3299概要
3287 Bierman Jul 2002 Remote Monitoring MIB
Extensions for
Differentiated Services
3287 差別化されたサービスのためのBierman2002年7月リモートモニターしているMIB拡張子
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS TRACK]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、DS分野を含むパケットでDifferentiated Services(DS)Codepoint用法をモニターするのに使用される管理オブジェクトについて説明します、RMON-2(リモートNetwork Monitoring Managementバージョン2)MIBで定義されたモニターしているフレームワークを利用して。 [標準化過程]
3286 Ong May 2002 An Introduction to the Stream
Control Transmission Protocol
(SCTP)
3286 ストリーム制御伝動プロトコルへの1序論あたりのオング2002年5月(SCTP)
This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community.
このドキュメントはStream Control Transmissionプロトコル(SCTP)によってサポートされた能力に高い平らな序論を提供します。 それは汎用のトランスポート・プロトコルとしてのSCTPの潜在的ユーザのためのガイドとして意図します。 このメモはインターネットコミュニティのための情報を提供します。
3285 Gahrns May 2002 Using Microsoft Word to create
Internet Drafts and RFCs
3285 インターネットDraftsとRFCsを作成するGahrns2002年5月のUsingマイクロソフト・ワード
This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community.
このドキュメントは、インターネットDraftとRFC形式で書類を提示するためにマイクロソフト・ワードアプリケーションを構成するためにステップについて説明します。 このメモはインターネットコミュニティのための情報を提供します。
3284 Korn Jun 2002 The VCDIFF Generic
Differencing and Compression
Data Format
3284 コルン2002年6月のVCDIFFジェネリックDifferencingと圧縮データの形式
This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS TRACK]
このメモはVCDIFF(コンピュータの中で容易にそれらを輸送できるように圧縮される、そして/または、データをdifferencingするコード化に適当な一般的で、効率的で携帯用のデータの形式)について説明します。 [標準化過程]
Ginoza Informational [Page 5] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[5ページ]のRFC3299概要
3283 Mahoney Jun 2002 Guide to Internet Calendaring
3283 インターネットCalendaringへのマホニー2002年6月のガイド
This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.
このドキュメントは様々なインターネットcalendaringとスケジューリング規格、執筆中の作品、およびそれらの間の関係について説明します。 意図は、これらのドキュメントのための文脈を提供して、彼らの理解を助けて、規格ベースのcalendaringとスケジューリングシステムの設計で潜在的に支援することです。扱われた規格は、RFC2445(iCalendar)と、RFC2446(iTIP)と、RFC2447です(iMIP)。 扱われた処理中の作業は「カレンダーアクセス・プロトコル」(CAP)です。 また、このドキュメントはこれらのプロトコルによって解決されていなくて、今後の活動のための目標であるかもしれない問題と問題について説明します。 このメモはインターネットコミュニティのための情報を提供します。
3282 Alvestrand May 2002 Content Language Headers
3282 Alvestrand2002年5月満足している言語ヘッダー
This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS TRACK]
このドキュメントがaを定義する、「満足している言語:」 そして、ヘッダー、それには、1つが何かの言語を示すことを望んでいる場合における使用のために、RFCの822のようなヘッダーがあります、MIME身体の部分やウェブドキュメントのように「言語を受け入れます:、」 1つが言語に関して人の好みを示したがっている場合における使用のためのヘッダー。 [標準化過程]
3281 Farrell Apr 2002 An Internet Attribute
Certificate Profile for
Authorization
3281 承認のためのインターネット属性証明書プロフィールあたりのファレル2002年4月
This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS TRACK]
この仕様はインターネットプロトコルにおけるX.509 Attribute Certificatesの使用のためのプロフィールを定義します。 属性証明書は相互運用性目標の広いスペクトルと操作上と保証要件の、より広いスペクトルを含んでいるさまざまなアプリケーションと環境で使用されるかもしれません。 このドキュメントの目標は限られた専用要件と同様に広い相互運用性を必要とする一般的適用のために一般的な基線を確立することです。 プロフィールはインターネット電子メール、IPSec、およびWWWセキュリティアプリケーションの属性証明書サポートを強調します。 [標準化過程]
3280 Housley Apr 2002 Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List
(CRL) Profile
3280年のHousley2002年4月のインターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィール
This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS TRACK]
このメモはインターネットでの使用のために、X.509 v3証明書とX.509 v2 Certificate Revocation List(CRL)の輪郭を描きます。 [標準化過程]
Ginoza Informational [Page 6] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[6ページ]のRFC3299概要
3279 Polk Apr 2002 Algorithms and Identifiers for
the Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List
(CRL) Profile
インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィールのための3279のポーク2002年4月アルゴリズムと識別子
This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS TRACK]
このドキュメントはインターネットX.509公開鍵暗号基盤(PKI)に使用されるデジタル署名と対象の公開鍵にアルゴリズム識別子とASN.1コード化形式を指定します。 デジタル署名は、証明書と証明書取消しがリスト(CRLs)であると署名するのに使用されます。 証明書は命名された対象の公開鍵を含んでいます。 [標準化過程]
3278 Blake-Wilson Apr 2002 Use of Elliptic Curve
Cryptography (ECC) Algorithms
in Cryptographic Message
Syntax (CMS)
3278 暗号のメッセージ構文における楕円曲線暗号(ECC)アルゴリズムのブレーク-ウィルソンの2002年4月の使用(cm)
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community.
このドキュメントはCryptographic Message Syntax(CMS)のElliptic Curve Cryptography(ECC)公開鍵アルゴリズムを使用する方法を説明します。 ECCアルゴリズムは、内容を暗号化するか、または認証するためにデジタル署名の作成とキーの交換をサポートします。 アルゴリズム処理の定義はANSI X9F1ワーキンググループ、1363年のIEEE規格、およびSEC1規格によって開発されたANSI X9.62規格に基づいています。 このメモはインターネットコミュニティのための情報を提供します。
3277 McPherson Apr 2002 Intermediate System to
Intermediate System (IS-IS)
Transient Blackhole Avoidance
中間システムへのマクファーソン3277年2002年4月の中間システム、(-、)、一時的なBlackhole回避
This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community.
このドキュメントがIntermediate SystemでIntermediate Systemに使うことができる簡単で、共同利用できるメカニズムについて説明する、(-、)、一時的なネットワーク状態の間、パケットの決定論的なblackholingに関連しているデータの損失を減少させるために、ネットワークでつなぎます。 ここで提案されたメカニズムが、いいえが必要である、-、プロトコルが変えて、完全に共同利用できる、存在、-、仕様 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 7] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[7ページ]のRFC3299概要
3276 Ray May 2002 Definitions of Managed Objects
for High Bit-Rate DSL - 2nd
generation (HDSL2) and
Single-Pair High-Speed Digital
Subscriber Line (SHDSL) Lines
高いビット伝送速度DSLのための管理オブジェクトの3276のレイの2002年5月の定義--第2世代(HDSL2)と単独の組の高速デジタル加入者線(SHDSL)線
This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS TRACK]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このドキュメントは使用のためのManagement Information基地(MIB)のモジュールの部分を定義します。 特に、High Bit-レートDSLを管理するのに使用されるオブジェクトについて説明します--第2世代(HDSL2)とSingle-組High-速度Digital Subscriber線(SHDSL)のインタフェース。 [標準化過程]
3275 Eastlake 3rd Mar 2002 (Extensible Markup Language)
XML-Signature Syntax and
Processing
3275年のイーストレーク2002年3月3日(拡張マークアップ言語)のXML-署名構文と処理
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS TRACK]
このドキュメントはXML(拡張マークアップ言語)デジタル署名処理規則と構文を指定します。 [標準化過程]
3274 Gutmann Jun 2002 Compressed Data Content Type
for Cryptographic Message
Syntax (CMS)
3274 暗号のメッセージ構文のためのガットマン2002年6月の圧縮されたデータcontent type(cm)
This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS TRACK]
このドキュメントは、Cryptographic Message Syntax(CMS)content typeとして圧縮されたデータを使用するために書式を定義します。 トランスミッションの前にデータを圧縮すると、多くの利点が提供されます、攻撃者を助けることができたデータの冗長性の除去を含んでいて、後のステップ(署名か暗号化などの)で処理されるためにデータ量を減少させて、総合的なメッセージサイズを減少させることによって処理を早くして。 他のレベル(例えば、MIMEかSSLレベルにおける)で圧縮を加えるための提案がありましたが、外部の手段(例えば、MIMEとCMSを混ぜるのによる)で圧縮が供給されない場合、これらはCMS内容の要約のその問題を訴えません。 [標準化過程]
Ginoza Informational [Page 8] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[8ページ]のRFC3299概要
3273 Waldbusser Jul 2002 Remote Network Monitoring
Management Information Base
for High Capacity Networks
3273 Waldbusserの2002年7月の高容量ネットワークに、リモートなネットワーク監視管理情報ベース
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 remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]
このメモは使用のために、ネットワーク管理プロトコルでTCP/IPベースのインターネットでManagement Information基地の一部(MIB)を定義します。 特に、それは、高速ネットワークにおける使用のためのリモートネットワーク監視(RMON)デバイスを管理するためにオブジェクトを定義します。 このドキュメントはRFC2819のRMON-MIBとRFC2021のRMON2-MIBからこれらの新しいオブジェクトを定義して、またいくつかのアップデートされたオブジェクトの定義を含むMIB Moduleを含んでいます。 [提案された標準]
3272 Awduche May 2002 Overview and Principles of
Internet Traffic Engineering
3272年のAwduche2002年5月の概要とインターネットプリンシプルズ交通工学
This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community.
このメモはインターネットでTraffic Engineering(TE)の本質について説明します。 ドキュメントは、IPネットワークで交通工学を囲む問題の、より良い理解を促進して、交通工学能力の開発の共有基準をインターネットに提供することを意図します。 このドキュメント中で操作上のIPネットワークの業績評価とパフォーマンスの最適化のための原則、アーキテクチャ、および方法論について議論します。 このメモはインターネットコミュニティのための情報を提供します。
3271 Cerf Apr 2002 The Internet is for Everyone
3271 サーフ2002年4月に、インターネットはEveryoneのためのものです。
This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community.
このドキュメントはインターネットが本当に皆のためのものであるインターネット協会のイデオロギーを言い表します。 しかしながら、したがって、私たちがそれを作る場合にだけ、それはそのようなものになるでしょう。 このメモはインターネットコミュニティのための情報を提供します。
3270 Le Faucheur May 2002 Multi-Protocol Label Switching
(MPLS) Support of
Differentiated Services
3270年の差別化されたサービスのLe Faucheur2002年5月のマルチプロトコルラベルスイッチング(MPLS)サポート
This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS TRACK]
このドキュメントはMulti-プロトコルの上のDifferentiated Services(デフ-Serv)Label Switching(MPLS)ネットワークのサポートのためにフレキシブルなソリューションを定義します。 [標準化過程]
Ginoza Informational [Page 9] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[9ページ]のRFC3299概要
3269 Kermode Apr 2002 Author Guidelines for Reliable
Multicast Transport (RMT)
Building Blocks and Protocol
Instantiation documents
3269 Reliable Multicast Transport(RMT)のためのドキュメントをBlocksとプロトコルInstantiationに造るカーモード2002年4月のAuthor Guidelines
This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.
このドキュメントは、Reliable Multicast Transport(RMT)ブロックとプロトコル具体化定義の作者を補助するために一般的ガイドラインを提供します。 これらのガイドラインの目的は彼らの操作と使用について完全に説明するために定義が作成したどんなブロックとプロトコル具体化も十分な情報を含むのを保証することです。 さらに、これらのガイドラインは、モジュールの、そして、明確に定義されたRMTブロックとどんな既存のプロトコルも設計されなかった新しいシナリオにおける使用のために安全に新しいプロトコルを作成するために精製して、増大させることができるプロトコル具体化を指定するために方向を提供します。 このメモはインターネットコミュニティのための情報を提供します。
3268 Chown Jun 2002 Advanced Encryption Standard
(AES) Ciphersuites for
Transport Layer Security (TLS)
トランスポート層セキュリティのための3268Chownの2002年6月の高度な暗号化規格(AES)Ciphersuites(TLS)
This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS TRACK]
このドキュメントは数個の新しいciphersuitesを提案します。 現在のところ、Transport Layer Security(TLS)によってサポートされた左右対称の暗号は、RC2と、RC4と、国際Data Encryption Algorithm(IDEA)と、データ暗号化規格(DES)と、三重のDESです。 プロトコルはエー・イー・エス(AES)ciphersuitesの追加によって高められるでしょう。 [標準化過程]
3267 Sjoberg Jun 2002 Real-Time Transport Protocol
(RTP) Payload Format and File
Storage Format for the
Adaptive Multi-Rate (AMR) and
Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs
適応型のマルチレート(AMR)の、そして、適応型のマルチレート広帯域(AMR-WB)オーディオコーデックのための3267年のシェーベリ2002年6月のリアルタイムのトランスポート・プロトコル(RTP)有効搭載量形式とファイル記憶装置形式
This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS TRACK]
このドキュメントはAdaptive Multi-レート(AMR)に使用されるためにリアルタイムのトランスポート・プロトコル(RTP)ペイロード形式を指定します、そして、Adaptive Multi-レートWideband(AMR-WB)はスピーチ信号をコード化しました。 ペイロード形式は、AMRとAMR-WB輸送が非IPネットワークでフォーマットする存在で共同利用できるように設計されています。 さらに、ファイル形式はメールなどのストレージモードアプリケーションにおけるAMRとAMR-WBスピーチデータの輸送に指定されます。 2は含まれていたMIMEの種類登録証明書、AMRのためのもの、およびAMR-WBのための1つを切り離します、RTPペイロード形式とストレージ形式の両方の使用を指定して。 [標準化過程]
Ginoza Informational [Page 10] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[10ページ]のRFC3299概要
3266 Olson Jun 2002 Support for IPv6 in Session
Description Protocol (SDP)
3266 セッション記述プロトコルのIPv6のオルソン2002年6月のサポート(SDP)
This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS TRACK]
このドキュメントはSession記述プロトコル(SDP)に関連してインターネットプロトコルバージョン6(IPv6)アドレスの使用について説明します。 明確に、このドキュメントはIPv6アドレスの構文へのSDPのあいさつがある既存のテキストをはっきりさせます。 [標準化過程]
3265 Roach Jun 2002 Session Initiation Protocol
(SIP)-Specific Event
Notification
3265 ローチ2002年6月のセッション開始プロトコル(一口)特定のイベント通知
This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS TRACK]
このドキュメントはSession Initiationプロトコル(SIP)に拡大について説明します。 この拡大の目的はSIPノードが、あるイベントが起こったのを示す遠隔ノードから通知を要求できる広げることができるフレームワークを提供することです。 [標準化過程]
3264 Rosenberg Jun 2002 An Offer/Answer Model with the
Session Description Protocol
(SDP)
3264 セッション記述プロトコルがある申し出/答えモデルあたりのローゼンバーグ2002年6月(SDP)
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS TRACK]
このドキュメントは2つの実体がそれらの間のマルチメディアセッションの共通認識に到着するのに、Session記述プロトコル(SDP)を利用できるメカニズムを定義します。 モデルでは、1人の関係者が必要なセッションと共に必要なセッションの記述をそれらの見解、および他の関与している答えからそれらの見解からもう片方に提供します。 この申し出/答えモデルはユニキャストセッションのときに両方の関係者からの情報がセッションの完全な視点に必要であるところで最も役に立ちます。 申し出/答えモデルはSession Initiationプロトコル(SIP)のようなプロトコルによって使用されます。 [標準化過程]
3263 Rosenberg Jun 2002 Session Initiation Protocol
(SIP): Locating SIP Servers
ローゼンバーグ3263年2002年6月のセッション開始プロトコル(一口): 一口サーバの場所を見つけます。
The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS TRACK]
Session Initiationプロトコル(SIP)は、クライアントが連絡する次のホップのIPアドレス、ポート、およびトランスポート・プロトコルにSIP Uniform Resource Identifier(URI)に変えるのを許容するのにDNS手順を用います。 また、プライマリクライアントが失敗したなら、それは、サーバがバックアップクライアントに応答を送るのを許容するのにDNSを使用します。 このドキュメントは詳細にそれらのDNS手順について説明します。 [標準化過程]
Ginoza Informational [Page 11] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[11ページ]のRFC3299概要
3262 Rosenberg Jun 2002 Reliability of Provisional
Responses in the Session
Initiation Protocol (SIP)
3262 セッション開始プロトコルの暫定的な応答のローゼンバーグ2002年6月の信頼性(一口)
This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS TRACK]
このドキュメントは、信頼できる暫定的な応答メッセージを提供しながら、Session Initiationプロトコル(SIP)に拡大を指定します。 この拡大は、オプションタグ100relを使用して、Provisional Response ACKnowledgement(PRACK)メソッドを定義します。 [標準化過程]
3261 Rosenberg Jun 2002 SIP: Session Initiation
Protocol
3261 ローゼンバーグ2002年6月に、ちびちび飲んでください: セッション開始プロトコル
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK]
このドキュメントは1人以上の関係者との作成、変更、および終わりセッションのためにSession Initiationプロトコル(SIP)、応用層規制(シグナリング)プロトコルについて説明します。 これらのセッションはインターネット通話、マルチメディア分配、およびマルチメディア会議を含んでいます。 [標準化過程]
3260 Grossman Apr 2002 New Terminology and
Clarifications for Diffserv
Diffservのための3260のグロースマン2002年4月の新しい用語と明確化
This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.
このメモは、新しくて改良された用語に関してワーキンググループ協定をDiffservとして得て、小さい方の技術的な明確化を供給します。 RFC2474、RFC2475、およびRFC2597をアップデートするのは意図しています。 RFCs2474と2597が標準化過程の上を進んで、RFC2475をアップデートするとき、このメモにおける改正が法人組織になって、このメモが新しいRFCsによって時代遅れにされることを意図します。 このメモはインターネットコミュニティのための情報を提供します。
3259 Ott Apr 2002 A Message Bus for Local
Coordination
3259 地元調整のためのメッセージバスあたりのオット2002年4月
The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community.
地方のMessage Bus(Mbus)はアプリケーション構成要素のグループコミュニケーションのための軽量のメッセージ指向のコーディネートプロトコルです。 Mbusはコミュニケーション同輩、対象のベースのアドレシング、信頼できるメッセージ転送、および異なったタイプのコミュニケーション体系の自動位置を提供します。 プロトコルは、IPマルチキャストの上で層にされて、IPv4とIPv6に指定されます。 IPマルチキャスト範囲はリンク地方のマルチキャストに制限されます。 このドキュメントはMbusプロトコルを指定します、すなわち、メッセージ構文、アドレシング、および移送機構このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 12] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[12ページ]のRFC3299概要
3258 Hardie Apr 2002 Distributing Authoritative
Name Servers via Shared
Unicast Addresses
3258 Shared Unicast Addressesを通したハーディー2002年4月のDistributing Authoritative Name Servers
This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community.
このメモは正式のネームサーバオペレータが複数の所在地のただ一つの命名されたサーバへのアクセスを提供するのを可能にすることを意図する1セットの習慣について説明します。 これらの習慣の開発と展開に関するプライマリ動機は、ドメインネームシステム(DNS)サーバの分配をネットワーク形態の以前に下の誘致圏域に増強して、それらの領域でのDNS質問応答のためにレイテンシを減少させることです。 このメモはインターネットコミュニティのための情報を提供します。
3257 Coene Apr 2002 Stream Control Transmission
Protocol Applicability
Statement
3257 Coene2002年4月のストリーム制御伝動プロトコル適用性証明
This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community.
このドキュメントはStream Control Transmissionプロトコル(SCTP)の適用性について説明します。 それは、また、2つの優位なトランスポート・プロトコル、ユーザー・データグラム・プロトコル(UDP)、および通信制御プロトコル(TCP)に対してSCTPを対照して、SCTPを使用するのがいつ最も良いか、そして、SCTPを使用するのがいつ最も役に立たないか間、いくつかのガイドラインを与えます。 このメモはインターネットコミュニティのための情報を提供します。
3256 Jones Apr 2002 The DOCSIS (Data-Over-Cable
Service Interface
Specifications) Device Class
DHCP (Dynamic Host
Configuration Protocol) Relay
Agent Information Sub-option
3256 ジョーンズ2002年4月に、DOCSIS(データ過剰ケーブルサービスインターフェース仕様)装置クラスDHCP(Dynamic Host Configuration Protocol)はエージェント情報サブオプションをリレーします。
This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS TRACK]
このドキュメントはDHCP(Dynamic Host Configuration Protocol)リレーエージェント情報Optionに新しいサブオプションを提案します。 [標準化過程]
Ginoza Informational [Page 13] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[13ページ]のRFC3299概要
3255 Jones Apr 2002 Extending Point-to-Point
Protocol (PPP) over
Synchronous Optical
NETwork/Synchronous Digital
Hierarchy (SONET/SDH) with
virtual concatenation, high
order and low order payloads
仮想の連結、高位、および下位のペイロードがあるSynchronous Optical NETwork/同期デジタルハイアラーキ(Sonet/SDH)の上の2002年のExtending Pointからジョーンズの4月の3255年のポイントのプロトコル(PPP)
This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS TRACK]
このドキュメントは、Sonet/SDH SPE/VCの仮想の連結の使用と高位と下位のペイロードの両方の使用を含むようにPointからポイントへのSynchronous Optical NETwork/同期デジタルハイアラーキ(Sonet/SDH)へのプロトコル(PPP)に関するマッピングに拡大について説明します。 [標準化過程]
3254 Alvestrand Apr 2002 Definitions for talking about
directories
3254 ディレクトリに関して話すためのAlvestrand2002年4月のDefinitions
When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community.
情報をインターネットを通して標準化された方法でアクセスしやすくするシステムについて議論するとき、それについて議論している人々がそれらが使用する用語の一般的な理解を持っているなら、役に立つかもしれません。 例えば、このドキュメントの参照は、周辺保全と共にDNS(ドメインネームシステム)がグローバルなルックアップ倉庫であるのに同意する権限を1つに与えて、ほどけるでしょう、一貫性を一点に集めて。 他方では、LDAP(ライトウェイト・ディレクトリ・アクセス・プロトコル)ディレクトリサーバはルックアップと検索能力の両方がある地方の、そして、集結された倉庫です。 このドキュメントは諸条件で知られている、そのようなシステムの1つのグループ、「ディレクトリ」について議論します。 このメモはインターネットコミュニティのための情報を提供します。
3253 Clemm Mar 2002 Versioning Extensions to
WebDAV (Web Distributed
Authoring and Versioning)
3253 WebDAVへのクレム2002年3月Versioning拡張子(ウェブの分配されたオーサリングとVersioning)
This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS TRACK]
このドキュメントはHTTP/1.1プロトコルに拡大をversioningしながらWebDAV(ウェブDistributed AuthoringとVersioning)を定義する1セットのメソッド、ヘッダー、およびリソースタイプを指定します。 [標準化過程]
3252 Kennedy 1 April 2002 Binary Lexical Octet Ad-hoc
Transport
3252年のケネディ2002年4月1日のバイナリー語彙の八重奏臨時の輸送
This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.
このドキュメントはIPと2つのトランスポート層プロトコル(TCPとUDP)の再定式化をXMLアプリケーションと定義します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 14] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[14ページ]のRFC3299概要
3251 Rajagopalan 1 April 2002 Electricity over IP
3251 IPの上のRajagopalan2002年4月1日の電気
Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This memo provides information for the Internet community.
ほとんどPointless Lamp Switching(MPLampS)は、IP(MPLS制御飛行機がある)の上まで電気を運ぶためのアーキテクチャです。 私たちの営業部によると、MPLampSには、劇的に値段を下げて、分配と用法を緩和して、電気を提供する管理可能性を改良する可能性があります。 このドキュメントはSonet/SDHのような仕事でIP/MPLS(作者を無断借用させてもらって)の上に動機づけられています。 前の仕事の読者は頭をかいて、「次は何?」とささやいているのが観察されました。 このドキュメントはその質問に答えます。 このメモはインターネットコミュニティのための情報を提供します。
3250 McIntyre Sep 2002 Tag Image File Format Fax
eXtended (TIFF-FX) -
image/tiff-fx MIME Sub-type
Registration
マッキンタイヤ3250年2002年9月のTag Image File FormatファックスeXtended(TIFF-FX)--いさかいイメージ/fx MIME Sub-タイプRegistration
This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS TRACK]
このドキュメントはMIMEサブタイプいさかいイメージ/fxの登録について説明します。 encodingsはインターネットファックスとその拡大のためにFile Formatによって定義されます。 [標準化過程]
3249 Cancio Sep 2002 Implementers Guide for
Facsimile Using Internet Mail
Cancio2002年9月のImplementersがインターネットメールを使用するファクシミリのために誘導する3249
This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community.
このドキュメントはRFC2305と2532を使用することでファクシミリに発信するのにメールを使用するソフトウェアのimplementersのために意図します。 これは情報のドキュメントです、そして、ガイドラインは参照をつけられたドキュメントに取って代わりません。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 15] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[15ページ]のRFC3299概要
3248 Armitage Mar 2002 A Delay Bound alternative
revision of RFC 2598
3248 RFC2598のアーミテージ2002年3月のA Delay Boundの代替の改正
For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community.
歴史的な関心のために、このドキュメントはRFC2598の原作者によって好まれますが、2000年12月にワーキンググループによって採用されなかったEF Design Teamの提案されたソリューションを得ます。 EFのオリジナルの定義は降ろされたネットワークにおける推進の比較に基づきました。 他のトラフィックのため、この実験的なDelay Bound(dB)PHBはパケットの遅れでネットワークでバウンドを必要とします。 2000年8月のピッツバーグIETFミーティングでは、Differentiated ServicesワーキンググループはRFC2598に関する重大問題に直面していました--グループのHop Behavior(PHB)あたりのExpedited Forwarding(EF)の標準化過程定義。 'EF Design Team'は、RFC2598の再式を開発するのを買って出ました、DiffServグループで提起された問題を覚えておいて。 2000年12月のサンディエゴIETFミーティングでは、DiffServワーキンググループは、EF PHBの代替の再式を追求すると決めました。 このメモはインターネットコミュニティのための情報を提供します。
3247 Charny Mar 2002 Supplemental Information for
the New Definition of the EF
PHB (Expedited Forwarding
Per-Hop Behavior)
3247 EF PHBの新しい定義のためのシャルニー2002年3月の補足的情報(1ホップあたりの完全優先転送の振舞い)
This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community.
このドキュメントはRFC2598の明確化のプロセス「完全優先転送PHB」の間、「完全優先転送PHB」というEFに関する訂正明細書の公表にそんなに導かれた状態で書かれました。 プライマリ動機は改訂されたEF定義とその特性に追加説明を供給しています。 ドキュメントは、いくつかのよく知られているスケジューラとルータアーキテクチャのための新しい定義の数字のパラメタの計算のためにまた、追加実装の例を提供して、何らかの指導を与えます。 このメモはインターネットコミュニティのための情報を提供します。
3246 Davie Mar 2002 An Expedited Forwarding PHB
(Per-Hop Behavior)
3246 完全優先転送PHBあたりのデイビー2002年3月(1ホップあたりの振舞い)
This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS TRACK]
このドキュメントはExpedited Forwarding(EF)と呼ばれるPHB(1ホップあたりの振舞い)を定義します。 PHBはDifferentiated Servicesアーキテクチャの基本的なブロックです。 EF集合が、ある構成されたレートで役立たれているのを確実にすることによってEFが低い遅れ、低いジター、および低い損失サービスにブロックを提供することを意図します。 このドキュメントはRFC2598を時代遅れにします。 [標準化過程]
Ginoza Informational [Page 16] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[16ページ]のRFC3299概要
3245 Klensin, Ed. Mar 2002 The History and Context of
Telephone Number Mapping
(ENUM) Operational Decisions:
Informational Documents
Contributed to ITU-T Study
Group 2 (SG2)
エド電話番号のマッピングの(ENUM)操作上の決定の2002年3月の3245Klensin、歴史、および文脈: ITU-T研究グループ2に寄付された情報のドキュメント(SG2)
RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.
RFC2916はTelephone Number Mapping(ENUM)の多くの管理の、そして、操作上の細部への責任をIABに割り当てました。 また、それは、ITUがトップレベルENUMドメインに関する「国名略号」レベルサブドメインの委譲のために応募者の合法性と適切さを決定することへの責任を取ると予期しました。 最近、3つのメモがITU-T Study Group2(SG2)が関連決定のためにバックグラウンドについて説明して、推論するように準備されました。 また、IABはそれらのモデルの部分の実装のために1セットの手続き上の指示をRIPE NCCに供給しました。 本書ではIETF共同体の情報に3つのメモの中身を提供します。
3244 Swift Feb 2002 Microsoft Windows 2000
Kerberos Change Password and
Set Password Protocols
3244の迅速な2002年2月のマイクロソフトWindows2000ケルベロス変化パスワードとセットパスワードプロトコル
This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. This memo provides information for the Internet community.
このメモはマイクロソフトのWindows2000ケルベロス変化パスワードとセットパスワードプロトコルを指定します。 Windows2000ケルベロス変化パスワードプロトコルはオリジナルのケルベロス変化パスワードプロトコルで共同利用します。 変化パスワードはユーザへの新しいパスワードを含むKRB_PRIVメッセージを含んでいる要求回答プロトコルです。 このメモはインターネットコミュニティのための情報を提供します。
3243 Jonsson Apr 2002 RObust Header Compression
(ROHC): Requirements and
Assumptions for 0-byte
IP/UDP/RTP Compression
3243 イェンソン2002年4月の体力を要しているヘッダー圧縮(ROHC): 0バイトのIP/UDP/RTP圧縮のための要件と仮定
This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.
このドキュメントは0バイトのIP/UDP/RTP(インターネットのリアルプロトコル/ユーザー・データグラム・プロトコル/タイムのTransportプロトコル)ヘッダー圧縮技術がRobust Header Compression(ROHC)作業部会によって開発されるという要件を含んでいます。 また、それは0バイトの圧縮が実装されるかもしれない典型的なリンクレイヤのための基本仮定、および一般に、用法に関する仮定を含んでいます。
Ginoza Informational [Page 17] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[17ページ]のRFC3299概要
3242 Jonsson Apr 2002 RObust Header Compression
(ROHC): A Link-Layer Assisted
Profile for IP/UDP/RTP
3242 イェンソン2002年4月の体力を要しているヘッダー圧縮(ROHC): リンクレイヤはIP/UDP/RTPのためにプロフィールを補助しました。
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS TRACK]
このドキュメントはIP/UDP/RTP(インターネットのリアルプロトコル/ユーザー・データグラム・プロトコル/タイムのTransportプロトコル)パケットの圧縮のためのROHC(強健なHeader Compression)プロフィールを定義します、下層によって提供された、ほとんどのパケットのために最適の操作の間、ヘッダーを完全に排除することによって圧縮効率を増強した機能性を利用して。 プロフィールは拡大としてROHC RTPプロフィールに造られます。 それは、ROHCで必要である追加メカニズムを定義して、透明を保証するという補助層に関する要件を述べて、この無ヘッダーのパケットを利用する圧縮と減圧に一般的な論理を指定します。 [標準化過程]
3241 Bormann Apr 2002 Robust Header Compression
(ROHC) over PPP
3241 pppの上のボルマン2002年4月の体力を要しているヘッダー圧縮(ROHC)
This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS TRACK]
このドキュメントはポイントへのPointプロトコル(PPP)の上に送られたIPデータグラムにおける体力を要しているヘッダー圧縮(ROHC)の使用を交渉するためのオプションについて説明します。 それはIPv4とIPv6のためにPPP Controlプロトコルと拡大を定義します。 [標準化過程]
3240 Clunie Feb 2002 Digital Imaging and
Communications in Medicine
(DICOM) - Application/dicom
MIME Sub-type Registration
薬(DICOM)の3240のClunie2002年2月のディジタル画像とコミュニケーション--アプリケーション/dicom MIMEサブタイプ登録
This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in "Digital Imaging and Communications in Medicine". This memo provides information for the Internet community.
このドキュメントはMIMEサブタイプアプリケーション/dicom(MedicineのデジタルImagingとCommunications)の登録について説明します。 基線コード化は「薬のディジタル画像とコミュニケーション」でDICOM Standards Committeeによって定義されます。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 18] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[18ページ]のRFC3299概要
3239 Kugler Feb 2002 Internet Printing Protocol
(IPP): Requirements for Job,
Printer, and Device
Administrative Operations
クーグラー3239年2002年2月のインターネット印刷プロトコル(IPP): 仕事のための要件、プリンタ、およびDevice行政課
This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community.
このドキュメントは、使用のためのいくつかの任意の管理操作にインターネットPrintingプロトコル(IPP)バージョン1.0とバージョン1.1で要件を指定して、ケースを使用します。 これらの管理操作のいくつかがIPP JobとPrinterオブジェクトを作動させます。 残っている操作は、より密接に単一の出力装置をモデル化する新しいDeviceオブジェクトを作動させます。 このメモはインターネットコミュニティのための情報を提供します。
3238 IAB Jan 2002 IAB Architectural and Policy
Considerations for Open
Pluggable Edge Services
開いているPluggable縁のサービスのためのIABジャン2002IAB建築するのと方針3238の問題
This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community.
このドキュメントは建築していた状態でいくつかのIABによるコメントと推薦を含んでいます、そして、政策問題はIETFのオープンPluggable Edge Services(作品)の特許に関連しました。 作品は例えばアプリケーションレベル仲介者で発生源サーバとクライアントの間のウェブプロキシキャッシュでネットワークで配布されるサービスです。 これらの仲介者は、コンテンツプロバイダーかエンドユーザのどちらかの明白な同意で内容を変えるか、またはフィルターにかけるでしょう。 このメモはインターネットコミュニティのための情報を提供します。
3237 Tuexen Jan 2002 Requirements for Reliable
Server Pooling
3237は信頼できるサーバプーリングのための2002年1月要件をTuexenします。
This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community.
このドキュメントは信頼できるサーバプーリングのための基本的なセットの要件を定義します。 このメモはインターネットコミュニティのための情報を提供します。
3236 Baker Feb 2002 The 'application/xhtml+xml'
Media Type
ベイカー2002年2月の'アプリケーション/xhtml+xml'メディアがタイプする3236
This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.
このドキュメントはXHTMLのベースのマークアップ言語のために'アプリケーション/xhtml+xml'MIMEメディアタイプを定義します。 それが'テキスト/html'を登録する特定のRFC2854のどんな前のIETFドキュメントも時代遅れにすることを意図しません。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 19] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[19ページ]のRFC3299概要
3235 Senie Jan 2002 Network Address Translator
(NAT)-Friendly Application
Design Guidelines
Senie2002年1月がネットワークでつなぐ3235は、翻訳者の(NAT)に優しいアプリケーション設計がガイドラインであると扱います。
This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community.
このドキュメントは新しいプロトコルを設計するときアプリケーション設計者が考えたがっているかもしれないそれらのものについて議論します。 これらのデバイスに交差するとき、多くの一般的なインターネットアプリケーションがNetwork Address Translatorsの面前で清潔に作動する間、他のものはさまざまな問題に悩みます。 ガイドラインは、新しいプロトコルとアプリケーションは可能な範囲内でNAT(ネットワークAddress Translation)と互換性があるのを確実にするのを助けるためにここに提示されます。 このメモはインターネットコミュニティのための情報を提供します。
3234 Carpenter Feb 2002 Middleboxes: Taxonomy and
Issues
3234は2002年2月にMiddleboxesの大工仕事をします: 分類学と問題
This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.
このドキュメントは"middleboxes"についてのIETF議論の一部として意図します--IPルータの正常で、標準の機能は別として、送信元ホストとあて先ホストの間のデータ経路でどんな仲介者箱の実行機能とも定義されます。 このドキュメントは、middleboxesのカタログか分類学を確立して、middleboxesに関して前の、そして、現在のIETF仕事を引用して、いくつかの予備の結論を特定するのを試みます。 しかしながら、それは、決定的であると主張しません。 このメモはインターネットコミュニティのための情報を提供します。
3233 Hoffman Feb 2002 Defining the IETF
3233 IETFを定義するホフマン2002年2月
This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
このドキュメントは今日理解していたように「IETF」の、より具体的な定義を与えます。 多くのRFCsが「IETF」について言及します。 多くの重要なIETFドキュメントがまるでそれが既に定義された実体であるかのようにIETFについて話します。 しかしながら、どんなIETFドキュメントも、IETFが何であるかを正しく定義しません。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3232 Reynolds Jan 2002 Assigned Numbers: RFC 1700 is
Replaced by an On-line Database
3232 レイノルズ2002年1月は数を割り当てました: RFC1700はOn-系列DatabaseによるReplacedです。
This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.
このメモはRFC1700(STD2)「規定番号」を時代遅れにします。(それは、割り当てられたインターネットプロトコルパラメタの1994年10月のスナップを含みました)。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 20] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[20ページ]のRFC3299概要
3231 Levi Jan 2002 Definitions of Managed Objects
for Scheduling Management
Operations
3231 スケジューリング管理操作のための管理オブジェクトのレビ2002年1月定義
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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS TRACK]
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは定期的か指定された期日と時に管理操作の計画をするのに使用される1セットの管理オブジェクトについて説明します。 [標準化過程]
3230 Mogul Jan 2002 Instance Digests in HTTP
3230 要人2002年1月のインスタンスはHTTPで読みこなされます。
HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS TRACK]
HTTP/1.1はサーバに応答本体のダイジェストを含ませるContent-MD5ヘッダーを定義します。 しかしながら、これは、完全なファイルのコンテンツではなく、実際のメッセージのボディー(応答がContent-範囲である、またはデルタコード化を使用するなら、全く異なっているかもしれない)をカバーするために明確に定義されます。 また、Content-MD5は1つの特定のダイジェストアルゴリズムに制限されます。 いくつかの事情では、SHA-1などの他のアルゴリズム(安全なHash Standard)は、より適切であるかもしれません。 最終的に、HTTP/1.1はクライアントがダイジェストを要求するかもしれないどんな明白なメカニズムも提供しません。 このドキュメントはこれらの問題を解決するHTTP拡大を提案します。[標準化過程]
3229 Mogul Jan 2002 Delta encoding in HTTP
3229 HTTPにおける要人2002年1月のデルタのコード化
This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS TRACK]
このドキュメントはHTTP/1.1へのコンパチブル拡大としてどうデルタコード化をサポートすることができるかを記述します。 [標準化過程]
3228 Fenner Feb 2002 IANA Considerations for IPv4
Internet Group Management
Protocol (IGMP)
3228 フェナー2002年2月に、IPv4インターネット集団経営のためのIANA問題は議定書を作ります。(IGMP)
This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
このメモは、IANAがIGMP(インターネットGroup Managementプロトコル)プロトコルヘッダーの分野への登録を作成するよう要求して、IANAがそれらの分野にパラメタを割り当てる際に使用する指導を前提とします。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
Ginoza Informational [Page 21] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[21ページ]のRFC3299概要
3227 Brezinski Feb 2002 Guidelines for Evidence
Collection and Archiving
3227 証拠収集と格納のためのBrezinski2002年2月ガイドライン
A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
「インターネットセキュリティ用語集」で定義される「セキュリティインシデント」(RFC2828)はシステムの安全保障政策が背かれるか、または別の方法で破られるセキュリティ関連しているシステムイベントです。 このドキュメントの目的はそのようなセキュリティインシデントに関連している証拠の収集と格納に関するガイドラインをSystem Administratorsに提供することです。 このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
3226 Gudmundsson Dec 2001 DNSSEC and IPv6 A6 aware
server/resolver message size
requirements
3226のグドムンソン2001年12月のDNSSECとIPv6 A6の意識しているサーバ/レゾルバメッセージサイズ要件
This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS TRACK]
命令がEDNS0(DNSのための拡大Mechanisms)のためにDNS Security ExtensionsかA6のどちらかが記録であるとサポートすると主張するDNS実体で支えるこのドキュメント。 これらの新機能がDNSメッセージのサイズを増強するので、この要件が必要です。 EDNS0がサポートされないと、TCPへの落下は起こるでしょう、質問潜在とDNSサーバに関する有害な影響をロードさせて。 このドキュメントは、新しい要件を加えることによって、RFC2535とRFC2874をアップデートします。 [標準化過程]
3225 Conrad Dec 2001 Indicating Resolver Support of
DNSSEC
3225 DNSSECのレゾルバサポートを示すコンラッド2001年12月
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS TRACK]
レゾルバがそれらのRRsを理解できるという明白な指示があるときだけ、DNSSEC(ドメインネームシステムSecurity Extensions)を操作上配布するために、DNSSECの意識しているサーバはDNSSEC RRsの自動包含を実行するべきです。 このドキュメントは、その明白な指示を提供するEDNS0ヘッダーで使用を少し提案して、その通知を実装するために必要なプロトコル変化について説明します。 [標準化過程]
Ginoza Informational [Page 22] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[22ページ]のRFC3299概要
3224 Guttman Jan 2002 Vendor Extensions for Service
Location Protocol, Version 2
3224 サービス位置のプロトコル、バージョン2のためのGuttman2002年1月ベンダー拡大
This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol." [STANDARDS TRACK]
このドキュメントは、Service Locationプロトコルの特徴でありバージョン2がどのように安全にベンダー伸展性を考慮するかを指定します、衝突の可能性なしで。 仕様は新しいSLPv2拡張子を紹介します: ベンダーの不透明な拡大。 固有のプロトコル拡大はIETF規格によって奨励されませんが、引き受けられる場合対応する実装の相互運用性を妨げないのは、重要です。 このドキュメントudpates RFC2608、「サービス位置のプロトコル。」 [標準化過程]
3223 Never Issued
3223 決して発行されませんでした。
RFC 3223 was never issued.
RFC3223は決して発行されませんでした。
3222 Trotter Dec 2001 Terminology for Forwarding
Information Base (FIB) based
Router Performance
Forwarding Information基地(FIB)への3222年の速足の馬2001年12月のTerminologyはRouterパフォーマンスを基礎づけました。
This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community.
このドキュメントは、ルータの中でインストールされた推進情報ベースの関数としてIPルータのIPパケット推進性能を決定する方法論に使用されるために用語について説明します。 IPルータの推進性能は、依存しているかもしれないか、またはルータの中でインストールされた推進情報ベースの構成とサイズにリンクされるかもしれません。 このメモはインターネットコミュニティのための情報を提供します。
3221 Huston Dec 2001 Commentary on Inter-Domain
Routing in the Internet
3221 インターネットの相互ドメインルート設定のヒューストン2001年12月の論評
This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community.
このドキュメントは、インターネットのBGPテーブルの特性の中で目に見える様々なより長い用語傾向を調べて、これらの傾向に貢献する多くの操作上の習慣とプロトコル要素を特定します。 相互ドメインルーティングスペースのスケーリング特性のこれらの習慣とプロトコルの特性の可能性のある衝撃は調べられます。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 23] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[23ページ]のRFC3299概要
3220 Perkins Jan 2002 IP Mobility Support for IPv4
3220 IPv4のパーキンス2002年1月のIP移動性サポート
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS TRACK]
このドキュメントはIPデータグラムの見え透いたルーティングをインターネットのモバイルノードに許すプロトコル増進を指定します。 それぞれのモバイルノードはインターネットへの現在の接着点にかかわらずいつもホームアドレスによって特定されます。 また、ホームから遠くに位置している間、モバイルノードと交際する、注意、-、アドレス、現在の接着点の情報をインターネットに提供する。 プロトコルが登録に備える、注意、-、ホームのエージェントとのアドレス。 ホームのエージェントがモバイルノードのためにトンネルを通って運命づけられたデータグラムを送る、注意、-、アドレス そして、トンネルの到着した後端では、各データグラムはモバイルノードに提供されます。 [標準化過程]
3219 Rosenberg Jan 2002 Telephony Routing over IP
(TRIP)
3219 IPの上のローゼンバーグの2002年1月の電話ルート設定(旅行)
This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS TRACK]
このドキュメントはIP(TRIP)の上のTelephonyルート設定を提示します。 TRIPは位置のサーバの間に電話の目的地の可到達性の広告を出す、およびそれらの目的地へのルートの広告属性のための方針駆動の相互管理のドメインプロトコルです。 TRIPの操作がどんなシグナリングプロトコルからも独立している、したがって、TRIPはどんなシグナリングプロトコルのための電話ルーティング・プロトコルとしても機能できます。 [標準化過程]
3218 Rescorla Jan 2002 Preventing the Million Message
Attack on Cryptographic
Message Syntax
3218 暗号のメッセージ構文に対する100万メッセージ攻撃を防ぐレスコラ2002年1月
This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community.
このメモはMillion Message Attackに抵抗するための戦略を説明します。 このメモはインターネットコミュニティのための情報を提供します。
3217 Housley Dec 2001 Triple-DES and RC2 Key
Wrapping
3217の三重のHousley2001年12月DESとRC2の主要なラッピング
This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.
このドキュメントは別のTriple-DESキーによって主要な1Triple-DESを包装するためのアルゴリズムと別のRC2キーによって主要な1RC2を包装するためのアルゴリズムを指定します。 このメモはインターネットコミュニティのための情報を提供します。
Ginoza Informational [Page 24] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[24ページ]のRFC3299概要
3216 Elliott Dec 2001 SMIng Objectives
3216 エリオット2001年12月SMIng目的
This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community.
このドキュメントは直接SNMPに写像できる新しいネットワークマネージメント構造物のモデルに適したデータ定義言語とCOPS-PRプロトコル操作のために目的について説明します。 このメモはインターネットコミュニティのための情報を提供します。
3215 Boscher Jan 2002 LDP State Machine
3215 Boscher2002年1月の自由民主党州のマシン
This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community.
このドキュメントはATM(非同期なTransfer Mode)スイッチLSRsに州の工作台を供給します。 現在の自由民主党仕様には、処理自由民主党メッセージに指定された州のマシンが全くありません。 私たちは、異なった自由民主党とCR-自由民主党実装の間の相互運用性に、一般的な州のマシンを定義するのが非常に重要であると思います。 このメモはインターネットコミュニティのための情報を提供します。
3214 Ash Jan 2002 LSP Modification Using CR-LDP
3214 CR-自由民主党を使用する灰の2002年1月のLSP変更
This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS TRACK]
このドキュメントは、停電なしでCR-自由民主党(規制ベースのRouted Label Distributionプロトコル)を使用することで確立したCR-LSP(規制ベースのRouted Label Switched Paths)の帯域幅とことによると他のパラメタを変更するためにアプローチを提示します。 [標準化過程]
3213 Ash Jan 2002 Applicability Statement for
CR-LDP
3213 CR-自由民主党のための灰の2002年1月の適用性証明
This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community.
このドキュメントは、自由民主党を使用することでベースのConstraint LSP Setupの適用性について議論します。 それは可能なネットワーク応用((自由民主党)が規制ベースのルーティング、プロトコルの展開と知られている制限のためのガイドラインを実装するのを必要としたLabel Distributionプロトコルへの拡大)について議論します。 このドキュメントは標準化過程の上でCR-自由民主党を進めることへの前提条件です。 このメモはインターネットコミュニティのための情報を提供します。
3212 Jamoussi Jan 2002 Constraint-Based LSP Setup
using LDP
3212 自由民主党を使用するJamoussiの2002年1月の規制ベースのLSPセットアップ
This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS TRACK]
このドキュメントは、自由民主党(ラベルDistributionプロトコル)を使用することでメカニズムとTLVs(タイプ/長さ/値)をCR-LSPs(規制ベースの発送されたLabel Switched Path)のサポートに指定します。 [標準化過程]
Ginoza Informational [Page 25] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[25ページ]のRFC3299概要
3211 Gutmann Dec 2001 Password-based Encryption for
CMS
3211 cmのためのガットマン2001年12月のパスワードベースの暗号化
This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS TRACK]
このドキュメントは必ずアルゴリズム特有の固定フォーマットキーであるというわけではないユーザによって与えられたパスワードを使用することでデータを暗号化するメソッドと拡大によるどんな形式の可変長の合わせることの材料も供給します。 Cryptographic Message Syntaxデータの形式は現在、パスワードベースのデータ暗号化のためのどんな条項も含みません。 [標準化過程]
3210 Awduche Dec 2001 Applicability Statement for
Extensions to RSVP for
LSP-Tunnels
3210 LSP-TunnelsのためのRSVPへの拡大のためのAwduche2001年12月の適用性証明
This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. This memo provides information for the Internet community.
このメモは「LSP TunnelsのためのRSVP(資源予約プロトコル)への拡大」の適用性について議論します。 それは、プロトコルの操作の原則を強調して、設計されたネットワーク文脈について説明します。 展開のためのガイドラインを提供します、そして、知られているプロトコル制限を示します。 このドキュメントが「LSP TunnelsのためのRSVPへの拡大」のインターネット標準化過程への服従に伴うことを意図します。 このメモはインターネットコミュニティのための情報を提供します。
3209 Awduche Dec 2001 RSVP-TE: Extensions to RSVP
for LSP Tunnels
3209 Awduche2001年12月のRSVP-Te: LSP TunnelsのためのRSVPへの拡大
This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS TRACK]
このドキュメントはRSVP(リソース予約プロトコル)の使用について説明します、ラベルで切り換えられた経路(LSPs)をMPLS(マルチプロトコルLabel Switching)に証明するためにすべての必要な拡大を含んでいて。 LSPに沿った流れが経路のイングレスノードで適用されたラベルによって完全に特定されるので、これらの経路はトンネルとして扱われるかもしれません。 LSPトンネルの主要なアプリケーションは指定されるとしてのMPLSがRFC2702にある交通工学です。 [標準化過程]
Ginoza Informational [Page 26] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[26ページ]のRFC3299概要
3208 Speakman Dec 2001 PGM Reliable Transport
Protocol Specification
3208 Speakmanの2001年12月のPGMの信頼できる輸送プロトコル仕様
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community.
実践的な司令官のMulticast(PGM)は命令されるか順不同の、写しの有でない複数のソースから複数の受信機までのマルチキャストデータ配送を必要とするアプリケーションのための信頼できるマルチキャストトランスポート・プロトコルです。 PGMは、グループにおける受信機がトランスミッションと修理からすべてのデータ・パケットを受けるか、または復しないデータパケット損失を検出できるのを保証します。 PGMは基本の信頼度要求事項があるマルチキャストアプリケーションのための実行し得る解決法として明確に意図します。 主要なデザイン目標は当然払うべき敬意を払ってスケーラビリティとネットワーク効率のための操作の簡単さです。 このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。
3207 Hoffman Feb 2002 SMTP Service Extension for
Secure SMTP over Transport
Layer Security
3207 トランスポート層セキュリティの安全なSMTPのためのホフマン2002年2月のSMTPサービス拡張子
This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS TRACK]
このドキュメントはSMTPサーバーとクライアントが個人的に提供するのに、TLS(輸送Layer Security)を使用できるSMTP(シンプルメールトランスファプロトコル)サービスに拡大について説明します、認証されたインターネット通信。 これは立ち聞きする者と攻撃者から彼らのコミュニケーションのいくつかかすべてを保護する能力をSMTPエージェントに与えます。 [標準化過程]
3206 Gellens Feb 2002 The SYS and AUTH POP Response
Codes
3206 Gellens2002年2月に、SYSとAUTHは応答コードを飛び出させます。
This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS TRACK]
このメモは2つの応答コードを提案します: SYSとAUTH。(そのAUTHは、クライアントが明白に認証失敗への最適の応答を決定するのを可能にします)。 さらに、新しい能力(AUTH-RESP-CODE)は定義されます。 [標準化過程]
3205 Moore Feb 2002 On the use of HTTP as a
Substrate
3205年のムーア2002年2月のOn SubstrateとしてのHTTPの使用
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
最近、他のアプリケーションレベルプロトコルに、基板としてハイパーテキストTransferプロトコル(HTTP)を使用することへの広範囲の関心がありました。 このドキュメントはそのような使用の技術的な子細を推薦します、デフォルトポート、URL体系、およびHTTPセキュリティー対策の使用を含んでいて。このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。
Ginoza Informational [Page 27] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[27ページ]のRFC3299概要
3204 Zimmerer Dec 2001 MIME media types for ISUP and
QSIG Objects
3204 Zimmerer12月のISUPのための2001のMIMEメディアタイプとQSIG Objects
This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS TRACK]
このドキュメントはSIPアプリケーションにおける使用のためのアプリケーション/ISUPとアプリケーション/QSIGオブジェクトのためにMIMEの種類について説明します、RFC2048で定義された規則に従って。 INVITEかINFOなどのSIPメッセージの中でISUPとQSIGオブジェクトを特定するのにこれらのタイプを使用できます、呼び出しの一部がPSTNに織り込むことを伴う環境でSIPを使用するとき、実装されるかもしれないように。 [標準化過程]
3203 T'Joens Dec 2001 DHCP reconfigure extension
3203年のT'Joens2001年12月に、DHCPは拡大を再構成します。
This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS TRACK]
このドキュメントは、DHCPサーバ(例えば、新しいIPアドレス、そして/または、ローカルの設定パラメータ)によって引き起こされた独身のホストのダイナミックな再構成を許すためにDHCP(Dynamic Host Configuration Protocol)と拡大を定義します。 [標準化過程]
3202 Steinberger Jan 2002 Definitions of Managed Objects
for Frame Relay Service Level
Definitions
3202 シュタインバーガー2002年1月に、フレームリレーサービスのための管理オブジェクトの定義は定義を平らにします。
This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS TRACK]
このメモはネットワーク管理プロトコルでTCP/IPベースのインターネットで使用のためのManagement Information基地(MIB)の拡大を定義します。 特に、それは、Frame Relay Service Level Definitionsを管理するためにオブジェクトを定義します。 [標準化過程]
3201 Steinberger Jan 2002 Definitions of Managed Objects
for Circuit to Interface
Translation
3201 回路が翻訳を連結する管理オブジェクトのシュタインバーガー2002年1月定義
This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS TRACK]
このメモはネットワーク管理プロトコルでTCP/IPベースのインターネットで使用のためのManagement Information基地(MIB)の拡大を定義します。 特に、それは、おもしろいCircuit Interfacesの挿入をifTableに管理するためにオブジェクトを定義します。 ifEntryを必要とする他のMIBモジュールの中で使用しなければならない回路に、これは重要です。 MIBモジュールを先在させて、それは使用が非変更した回路へのルーティングと同様に回路の統合モニターを考慮します。 [標準化過程]
3200 Never Issued
3200 決して発行されませんでした。
RFC 3200 was never issued.
RFC3200は決して発行されませんでした。
Ginoza Informational [Page 28] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[28ページ]のRFC3299概要
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 29] RFC 3299 Summary of 3200-3299 December 2003
3200-3299 2003年12月の宜野座の情報[29ページ]のRFC3299概要
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 30]
宜野座情報です。[30ページ]
一覧
スポンサーリンク
