RFC5284 日本語訳
5284 User-Defined Errors for RSVP. G. Swallow, A. Farrel. August 2008. (Format: TXT=17452 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Swallow
Request for Comments: 5284 Cisco Systems, Inc.
Category: Standards Track A. Farrel
Old Dog Consulting
August 2008
コメントを求めるワーキンググループG.ツバメ要求をネットワークでつないでください: 5284年のシスコシステムズInc.カテゴリ: 犬のコンサルティング2008年8月に年取った標準化過程A.ファレル
User-Defined Errors for RSVP
RSVPのためのユーザによって定義された誤り
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.
Resource ReserVationプロトコル(RSVP)は、誤りを伝えるためにERROR_SPECオブジェクトを定義します。 そのオブジェクトには、256のエラーコードの定義を可能にする定義された形式があります。 RSVPが開発されて、広げられたのに従って、コンベンションは新しいエラーコードを定義するのにおいて保守的であることになっていました。 さらに、ユーザによって定義された誤りへの支給は全くRSVPに存在していません。
This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors.
このドキュメントは、誤りに関連する追加ユーザー情報を運ぶのにERROR_SPECに加えて使用されるためにUSER_ERROR_SPECを定義します。
1. Introduction
1. 序論
The Resource ReserVation Protocol (RSVP) [RFC2205] defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in communicating errors. Further, no provision for user defined errors exists in RSVP.
Resource ReserVationプロトコル(RSVP)[RFC2205]は、誤りを伝えるためにERROR_SPECオブジェクトを定義します。 そのオブジェクトには、256のエラーコードの定義を可能にする定義された形式があります。 RSVPが開発されて、広げられたのに従って、コンベンションは誤りを伝えるのにおいて保守的であることになっていました。 さらに、ユーザの定義された誤りへの支給は全くRSVPに存在していません。
When developing extensions to RSVP, it is often useful for those implementing to define error messages to aid both in the initial debugging and in testing against older versions or other implementations.
RSVPに拡大を発生するとき、初期のデバッグと旧式のバージョンか他の実装に対するテストで支援するのはしばしばエラーメッセージを定義するために実装するものの役に立ちます。
This document defines a new RSVP object to permit user-defined errors to be communicated. This will enable organizations to define errors that they can use for internal development. These error values could also be shared with the community at large to aid in promoting interoperability between diverse implementations.
このドキュメントは、ユーザによって定義された誤りが伝えられることを許可するために新しいRSVPオブジェクトを定義します。 これは、組織がそれらが内部の開発に使用できる誤りを定義するのを可能にするでしょう。 また、さまざまの実装の間の相互運用性を促進する際に支援するためにこれらの誤り値を一般社会と共有できました。
Swallow & Farrel Standards Track [Page 1] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[1ページ]RFCのユーザによって定義された誤りを追跡します。
RSVP PathErr and ResvErr messages require the presence of an ERROR_SPEC object ([RFC2205]). [RFC3473] defines the Notify message that also requires the presence of an ERROR_SPEC object. In order to not change the mandatory contents of these messages, this document defines a new error code value that indicates that the new object is present and carries a user-defined error code.
RSVP PathErrとResvErrメッセージはERROR_SPECオブジェクト([RFC2205])を存在に要求します。 [RFC3473]はまた、ERROR_SPECオブジェクトを存在に要求するNotifyメッセージを定義します。 これらのメッセージの義務的なコンテンツを変えないように、このドキュメントは、新しいオブジェクトが存在しているのを示す新しい誤りコード値を定義して、ユーザによって定義されたエラーコードを載せます。
Note that the ResvConf message defined in [RFC2205] also carries an ERROR_SPEC object. But this usage of the object does not carry meaningful Error Codes or Error Values and so the extensions defined in this document are not applicable to that message.
また、[RFC2205]で定義されたResvConfメッセージがERROR_SPECオブジェクトを運ぶことに注意してください。 しかし、オブジェクトのこの使用法が重要なError CodesかError Valuesを運ばないので、本書では定義された拡大はそのメッセージに適切ではありません。
1.1. Conventions
1.1. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. User-Defined Error
2. ユーザによって定義された誤り
A new Error Code is defined for use in an ERROR_SPEC object.
新しいError CodeはERROR_SPECオブジェクトにおける使用のために定義されます。
Error Code = 33: User Error Spec
誤りコード=33: ユーザ誤り仕様
This error code is used to signal the presence of a
USER_ERROR_SPEC. One Error Value is defined as follows.
このエラーコードは、USER_ERROR_SPECの存在に合図するのに使用されます。 1Error Valueが以下の通り定義されます。
Error Value 0 = Further details in User Error Spec
誤りValue0はUser Error Specの詳細と等しいです。
Further error values may be defined in future specifications.
さらなる誤り値は将来の仕様に基づき定義されるかもしれません。
When sending this error code, a USER_ERROR_SPEC object MUST be included in the PathErr, ResvErr, or Notify message.
このエラーコードを送るとき、PathErr、ResvErr、またはNotifyメッセージにUSER_ERROR_SPECオブジェクトを含まなければなりません。
3. USER_ERROR_SPEC Class
3. ユーザ_誤り_仕様のクラス
A new RSVP object class called USER_ERROR_SPEC is defined. To support backwards compatibility, its class number is in the range 192-247. As defined in [RFC2205], implementations that do not understand such an object will forward it unmodified.
USER_ERROR_SPECと呼ばれる新しいRSVPオブジェクトのクラスは定義されます。 後方に互換性をサポートするために、クラス番号は範囲192-247にあります。 [RFC2205]で定義されるように、そのようなオブジェクトを理解していない実装が変更されていなくそれを進めるでしょう。
USER_ERROR_SPEC object: Class = 194, C-Type = 1
USER_ERROR_SPECは反対します: クラスは194、C-タイプ=1と等しいです。
Swallow & Farrel Standards Track [Page 2] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[2ページ]RFCのユーザによって定義された誤りを追跡します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Enterprise Number |
+---------------+---------------+---------------+---------------+
| Sub Org | Err Desc Len | User Error Value |
+---------------+---------------+---------------+---------------+
| |
~ Error Description ~
| |
+---------------+---------------+---------------+---------------+
| |
~ User-Defined Subobjects ~
| |
+---------------+---------------+---------------+---------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | エンタープライズ番号| +---------------+---------------+---------------+---------------+ | 潜水艦Org| 間違え、Descレン| ユーザ誤り価値| +---------------+---------------+---------------+---------------+ | | ~ エラー記述~| | +---------------+---------------+---------------+---------------+ | | ~ ユーザによって定義されたSubobjects~| | +---------------+---------------+---------------+---------------+
Enterprise Number
エンタープライズ番号
A unique identifier of an organization encoded as a 32-bit
integer. Enterprise Numbers (sometimes known as Private
Enterprise Numbers) are assigned by IANA and managed on a first
come first served basis through the IANA registry named
"Enterprise Numbers" [RFC2578].
32ビットの整数としてコード化された組織のユニークな識別子。 エンタープライズ民数記(兵士のエンタープライズ民数記として時々知られている)は、「エンタープライズ番号」[RFC2578]というIANA登録を通してIANAによって割り当てられて、先着順で管理されます。
Sub Org
潜水艦Org
A unique identifier of an organization encoded as an 8-bit
integer. An organization MAY use this field to create
independent Error Value spaces. This is intended to facilitate
teams that are doing parallel development. If independent
spaces are not required, this field SHOULD be set to zero.
8ビットの整数としてコード化された組織のユニークな識別子。 組織は、独立しているError Value空間を作成するのにこの分野を使用するかもしれません。 これが並行開発をしているチームを容易にすることを意図します。 空間は独立者であるなら必要でなく、この分野はSHOULDです。ゼロに設定されます。
Err Desc Len
間違え、Descレン
The length of the error description in the Error Description
field in bytes excluding any padding. Zero is a valid length
if no error description is supplied.
どんな詰め物を除いたバイトで表現されるError記述分野のエラー記述の長さ。 エラー記述を全く供給しないなら、ゼロは有効な長さです。
User Error Value
ユーザ誤り価値
A 16-bit integer. The meaning is specified by the
(sub-)organization indicated by the Enterprise Number and Sub
Org fields.
16ビットの整数。 意味が指定される、(サブ、)、エンタープライズNumberとSub Org分野によって示された組織。
Swallow & Farrel Standards Track [Page 3] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[3ページ]RFCのユーザによって定義された誤りを追跡します。
Error Description
エラー記述
A string of characters padded with nulls (0x00) to a multiple
of 4 bytes. According to the guidance in [RFC2277], this
string MUST use UTF-8/Net-Unicode encoding [RFC5198].
Furthermore, it is RECOMMENDED that implementations limit the
strings that they generate to single-line printable US-ASCII
[ASCII] whenever feasible to improve the likelihood of easy use
by the recipient.
一連のキャラクタがヌル(0×00)で4バイトの倍数にそっと歩きました。 [RFC2277]での指導によると、[RFC5198]をコード化して、このストリングはネットのUTF-8/ユニコードを使用しなければなりません。 その上、受取人による簡単な使用の見込みを改良するのにおいて可能であるときはいつも、実装がそれらが生成するストリングを単線の印刷可能な米国-ASCII[ASCII]に制限するのは、RECOMMENDEDです。
If the Err Desc Len is zero, then no bytes are supplied.
Err Descレンがゼロであるなら、バイトを全く供給しません。
Note that the content of this field is implementation-specific.
It is typically printable, but might not be shown to all users
in all implementations (because of character set choice).
Therefore, the content of the field SHOULD be limited to
supplementary information and SHOULD NOT contain information
critical to operating the network. Critical information is
present in the User Error Value field.
この分野の内容が実装特有であることに注意してください。 ないかもしれないのを除いて、それは通常印刷可能です。すべてのユーザに、すべての実装(文字集合選択による)では、目立ちます。 したがって、内容、分野SHOULDでは、制限されていて、ネットワークを経営するのに重要な情報を補助情報とSHOULD NOTに含んでください。 重要情報はUser Error Value分野に存在しています。
User-Defined Subobjects
ユーザによって定義されたSubobjects
User-defined subobjects MAY be included. The generic format of
subobjects is specified in Section 3.1. The semantics of a
subobject is indicated by the Type field, but the semantics,
format, and contents of the Value field are specified by the
(sub-)organization indicated by the Enterprise Number and Sub
Org fields of this object.
ユーザによって定義された「副-オブジェクト」は含まれるかもしれません。 「副-オブジェクト」のジェネリック形式はセクション3.1で指定されます。 「副-オブジェクト」の意味論がType分野によって示されますが、Value分野の意味論、形式、およびコンテンツによって指定される、(サブ、)、このオブジェクトのエンタープライズNumberとSub Org分野によって示された組織。
3.1. Subobjects
3.1. Subobjects
Each subobject is encoded as a TLV in the following format:
各「副-オブジェクト」はTLVとして以下の形式でコード化されます:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ | タイプ| 長さ| (Subobjectコンテンツ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
Type
タイプ
An 8-bit number assigned by the (sub-)organization indicated by
the Enterprise Number and Sub Org fields of the USER_ERROR_SPEC
object.
8ビットの数が割り当てた、(サブ、)、組織は、USERのエンタープライズNumberとSub Org分野のそばで_ERROR_SPECが反対するのを示しました。
Swallow & Farrel Standards Track [Page 4] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[4ページ]RFCのユーザによって定義された誤りを追跡します。
Length
長さ
The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length MUST be at
least 4, and MUST be a multiple of 4.
LengthはTypeとLength分野を含むバイトで表現される「副-オブジェクト」の全長を含んでいます。 Lengthは少なくとも4歳でなければならなく、4の倍数であるに違いありません。
4. Procedures for Using the User Error Spec
4. ユーザ誤り仕様を使用するための手順
4.1. Procedures for Sending the User Error Spec
4.1. ユーザ誤り仕様を送るための手順
A USER_ERROR_SPEC object MAY be included in any PathErr, ResvErr, or Notify message for any defined error code. The Enterprise Number MUST be a valid value assigned by IANA from the "Enterprise Numbers" registry.
USER_ERROR_SPECオブジェクトはどんな定義されたエラーコードへのどんなPathErr、ResvErr、またはNotifyメッセージにも含まれるかもしれません。 エンタープライズNumberはIANAによって「エンタープライズ番号」登録から割り当てられた有効値であるに違いありません。
As specified in [RFC2205] and [RFC3473], an ERROR_SPEC object with a valid error code MUST be included in all PathErr, ResvErr, and Notify messages. This rule is not changed by these procedures even when a USER_ERROR_SPEC object is included. If no other error code applies, the Error Code in the ERROR_SPEC object MUST be set to "User Error Spec" as defined in Section 2 of this document. When the Error Code in the ERROR_SPEC object is set to "User Error Spec", the Error Value sub-code SHOULD be set to "Further details in User Error Spec" as defined in Section 2, but further Error Value sub-codes may be defined in future specifications.
[RFC2205]と[RFC3473]で指定されるように、_SPECがすべてのPathErr、ResvErr、およびNotifyメッセージに有効なエラーコードで含まなければならないのを反対させるERRORです。 USER_ERROR_SPECオブジェクトが含まれるときさえ、この規則はこれらの手順で変えられません。 他のエラーコードが全く適用されないなら、ERROR_SPECオブジェクトのError Codeはこのドキュメントのセクション2で定義される「ユーザ誤り仕様」へのセットであるに違いありません。 ERROR_SPECオブジェクトのError Codeが「ユーザ誤り仕様」に用意ができているとき、Error ValueサブコードSHOULDがセクション2で定義されるように「User Error Specの詳細」に用意ができていて、将来の仕様に基づきさらなるError Valueサブコードだけを定義してもよいです。
4.2. Procedures for Receiving the User Error Spec
4.2. ユーザ誤り仕様を受け取るための手順
It is RECOMMENDED that implementations that receive a PathErr, ResvErr, or Notify message carrying a USER_ERROR_SPEC object log (at a minimum) the Enterprise Number, Sub-organization, User Error Value, and Error Description. Note that the character set used for the Error Description may mean that it might not be suitable for display of logging in all systems. Implementations capable of interpreting the contents of the USER_ERROR_SPEC object SHOULD take further action based on the reported error.
USER_ERROR_SPECオブジェクトを運びながらPathErr、ResvErr、またはNotifyメッセージを受け取る実装がエンタープライズNumber、Sub-組織、User Error Value、およびError記述を登録するのは(最小限で)、RECOMMENDEDです。 Error記述に使用される文字集合が、それがすべてのシステムにログインするディスプレイに適しないかもしれないことを意味するかもしれないことに注意してください。USER_ERROR_SPECオブジェクトSHOULDのコンテンツを解釈できる実装が報告された誤りに基づくさらなる行動を取ります。
Implementations that are not UTF-8 capable and that receive a USER_ERROR_SPEC object SHOULD handle the Error Description according to the procedures set out in [RFC5137].
できるUTF-8とそれでない実装は手順に従ったError記述が[RFC5137]に設定したUSER_ERROR_SPECオブジェクトSHOULDハンドルを受けます。
If a message is received containing an ERROR_SPEC object using the "User Error Spec" error code, but not containing a USER_ERROR_SPEC object, the message MUST be treated as malformed and handled according to [RFC2205].
メッセージが「ユーザ誤り仕様」エラーコードを使用することでERROR_SPECオブジェクトを含んでいますが、USER_ERROR_SPECオブジェクトは含まないのにおいて受信されているなら、メッセージを奇形として扱われて、[RFC2205]に従って、扱わなければなりません。
Swallow & Farrel Standards Track [Page 5] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[5ページ]RFCのユーザによって定義された誤りを追跡します。
Implementations SHOULD ignore repeated occurrences of USER_ERROR_SPEC objects, and SHOULD forward them unchanged on any messages that they forward. This provides for forward compatibility.
実装SHOULDはUSER_ERROR_SPECオブジェクトの繰り返された発生を無視します、そして、SHOULDはそれらが転送するどんなメッセージでも変わりがない状態でそれらを進めます。 これは下位互換に備えます。
Implementations receiving a USER_ERROR_SPEC object on some message other than a PathErr, ResvErr, or Notify message MUST treat the error as a malformed message and process according to [RFC2205].
[RFC2205]に従って、PathErr、ResvErr、またはNotifyメッセージ以外の何らかのメッセージでUSER_ERROR_SPECオブジェクトを受ける実装は奇形のメッセージとプロセスとして誤りを扱わなければなりません。
5. IANA Considerations
5. IANA問題
5.1. RSVP Error Codes
5.1. RSVPエラーコード
This document makes the following assignments from the RSVP Error Codes and Globally-Defined Error Value Sub-Codes registry:
このドキュメントはRSVP Error CodesとGloballyによって定義されたError Value Sub-コード登録から以下の課題をします:
Error Code Meaning
エラーコード意味
33 User Error Spec
33ユーザ誤り仕様
One Error Value sub-code is defined for use with this Error Code as follows:
このError Codeは以下の通りで1つのError Valueサブコードが使用のために定義されます:
0 = Further details in User Error Spec
0はUser Error Specの詳細と等しいです。
5.2. RSVP Objects
5.2. RSVPオブジェクト
This document makes the following assignments from the RSVP Class Names, Class Numbers, and Class Types registry:
このドキュメントはRSVP Class Names、Class民数記、およびClass Types登録から以下の課題をします:
Number Space Value Name
数の宇宙値の名
Class Numbers 194 USER_ERROR_SPEC
クラス番号194ユーザ_誤り_仕様
Class Type 1 User-Defined Error
クラスは1つのユーザによって定義された誤りをタイプします。
6. Security Considerations
6. セキュリティ問題
This document makes no changes to the basic message exchanges of [RFC2205] and [RFC3473]. It will result in a small increase in the number of error messages sent in cases where messages were previously silently dropped due to the lack of an appropriate error code.
このドキュメントは[RFC2205]と[RFC3473]の基本的な交換処理への変更を全く行いません。 それはメッセージが以前に適切なエラーコードの不足のため静かに下げられた場合で送られたエラーメッセージの数の微増をもたらすでしょう。
The mechanisms defined in this document may be used by implementations to report additional error conditions and information arising from security issues and attacks on the RSVP network.
本書では定義されたメカニズムは実装によって使用されて、RSVPネットワークに対する安全保障問題と攻撃から起こる追加エラー条件と情報を報告するかもしれません。
Swallow & Farrel Standards Track [Page 6] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[6ページ]RFCのユーザによって定義された誤りを追跡します。
Note that the use of a character string that will be displayed or logged opens the potential for certain security attacks through the use of overruns or embedded control characters. Implementations SHOULD take precautions against overruns, and (especially where the full character set of [RFC5198] is not supported, SHOULD use the procedures set out in [RFC5137] to handle unexpected or unknown control characters.
表示するか、または登録する文字列の使用が超過か埋め込まれた制御文字の使用で、あるセキュリティー攻撃の可能性を開くことに注意してください。 そして、実装SHOULDが超過に対して予防策を講する、(特に[RFC5198]の完全な文字集合がサポートされないところでは、SHOULDは、予期していなかったか未知の制御文字を扱うのに[RFC5137]を始められた手順を用います。
7. Acknowledgments
7. 承認
The authors would like to thank Elisheva Halevy for motivating this document. Thanks to Tom Nadeau, Magnus Westerlund, Hannes Tschofenig, Bruce Davie, Jukka Manner, Francois Le Faucheur, Lars Eggert, and Tom Petch for their review and comments.
作者は、このドキュメントを動機づけて頂いて、Elishevaアレビに感謝したがっています。 彼らのレビューとコメントをトム・ナドー、マグヌスWesterlund、ハンネスTschofenig、ブルース・デイビー、ユッカManner、フランソアLe Faucheur、ラース・エッゲルト、およびトムPetchをありがとうございます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.(エド)、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3473] エドバーガー、L.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
[RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", BCP
137, RFC 5137, February 2008.
[RFC5137] Klensin、J.、「ユニコードキャラクターから逃げるASCII」、BCP137、RFC5137、2008年2月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5198] KlensinとJ.とM.Padlipsky、「ネットワーク置き換えのためのユニコード形式」、RFC5198、2008年3月。
[ASCII] American National Standards Institute, "USA Code for
Information Interchange", ANSI X3.4, 1968.
[ASCII]American National Standards Institut、「米国情報交換用符号」、ANSI X3.4、1968。
8.2. Informative References
8.2. 有益な参照
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
Swallow & Farrel Standards Track [Page 7] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[7ページ]RFCのユーザによって定義された誤りを追跡します。
Authors' Addresses
作者のアドレス
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
ジョージツバメシスコシステムズInc.メール: swallow@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンのファレルの古い犬のコンサルティングメール: adrian@olddog.co.uk
Swallow & Farrel Standards Track [Page 8] RFC 5284 User-Defined Errors for RSVP August 2008
飲み込んでください。そうすれば、ファレルStandardsは2008年8月にRSVPのために5284の[8ページ]RFCのユーザによって定義された誤りを追跡します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Swallow & Farrel Standards Track [Page 9]
ツバメとファレル標準化過程[9ページ]
一覧
スポンサーリンク
