RFC4250 日本語訳
4250 The Secure Shell (SSH) Protocol Assigned Numbers. S. Lehtinen, C.Lonvick, Ed.. January 2006. (Format: TXT=44010 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Lehtinen
Request for Comments: 4250 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
コメントを求めるワーキンググループS.レーティネン要求をネットワークでつないでください: 4250年のセキュアシェル (SSH)通信秘密保全Corpカテゴリ: エド標準化過程C.Lonvick、シスコシステムズInc.2006年1月
The Secure Shell (SSH) Protocol Assigned Numbers
セキュア・シェル(セキュアシェル (SSH))プロトコル規定番号
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents.
このドキュメントはIANAとSecureシェル(SSH)プロトコルのIANA規定番号の初期状態と指示を定義します。 それはSSHドキュメントのセットで参照をつけられるIANA登録の初期化のためだけに意図します。
Table of Contents
目次
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
3.1. RFC 2119 Keywords ..........................................3
3.2. RFC 2434 Keywords ..........................................3
3.3. Protocol Fields and Values .................................4
4. IANA Considerations .............................................5
4.1. Message Numbers ............................................5
4.1.1. Conventions .........................................5
4.1.2. Initial Assignments .................................6
4.1.3. Future Assignments ..................................6
4.2. Disconnection Messages Reason Codes and Descriptions .......7
4.2.1. Conventions .........................................7
4.2.2. Initial Assignments .................................7
4.2.3. Future Assignments ..................................8
4.3. Channel Connection Failure Reason Codes and Descriptions ...8
4.3.1. Conventions .........................................8
4.3.2. Initial Assignments .................................8
1. 序論…2 2. 貢献者…3 3. このドキュメントで中古のコンベンション…3 3.1. RFC2119キーワード…3 3.2. RFC2434キーワード…3 3.3. 分野と値について議定書の中で述べてください…4 4. IANA問題…5 4.1. メッセージ番号…5 4.1.1. コンベンション…5 4.1.2. 課題に頭文字をつけてください…6 4.1.3. 将来の課題…6 4.2. 断線メッセージはコードと記述を推論します…7 4.2.1. コンベンション…7 4.2.2. 課題に頭文字をつけてください…7 4.2.3. 将来の課題…8 4.3. チャンネル接続失敗理由コードと記述…8 4.3.1. コンベンション…8 4.3.2. 課題に頭文字をつけてください…8
Lehtinen & Lonvick Standards Track [Page 1] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[1ページ]RFC4250セキュアシェル (SSH)プロトコル
4.3.3. Future Assignments ..................................8
4.3.4. Notes about the PRIVATE USE Range ...................9
4.4. Extended Channel Data Transfer data_type_code and Data .....9
4.4.1. Conventions .........................................9
4.4.2. Initial Assignments ................................10
4.4.3. Future Assignments .................................10
4.5. Pseudo-Terminal Encoded Terminal Modes ....................10
4.5.1. Conventions ........................................10
4.5.2. Initial Assignments ................................10
4.5.3. Future Assignments .................................12
4.6. Names .....................................................12
4.6.1. Conventions for Names ..............................13
4.6.2. Future Assignments of Names ........................13
4.7. Service Names .............................................13
4.8. Authentication Method Names ...............................14
4.9. Connection Protocol Assigned Names ........................14
4.9.1. Connection Protocol Channel Types ..................14
4.9.2. Connection Protocol Global Request Names ...........14
4.9.3. Connection Protocol Channel Request Names ..........15
4.9.4. Initial Assignment of Signal Names .................15
4.9.5. Connection Protocol Subsystem Names ................15
4.10. Key Exchange Method Names ................................16
4.11. Assigned Algorithm Names .................................16
4.11.1. Encryption Algorithm Names ........................16
4.11.2. MAC Algorithm Names ...............................17
4.11.3. Public Key Algorithm Names ........................17
4.11.4. Compression Algorithm Names .......................17
5. Security Considerations ........................................17
6. References .....................................................18
6.1. Normative References ......................................18
6.2. Informative References ....................................18
Authors' Addresses ................................................19
Trademark Notice ..................................................19
4.3.3. 将来の課題…8 4.3.4. 私用に関する注は及びます…9 4.4. 拡張Channel Data Transferデータ_は_コードとDataをタイプします…9 4.4.1. コンベンション…9 4.4.2. 課題に頭文字をつけてください…10 4.4.3. 将来の課題…10 4.5. 疑似端末はターミナルモードをコード化しました…10 4.5.1. コンベンション…10 4.5.2. 課題に頭文字をつけてください…10 4.5.3. 将来の課題…12 4.6. 名前…12 4.6.1. 名前のためのコンベンション…13 4.6.2. 名前の将来の課題…13 4.7. 名前を修理してください…13 4.8. 認証方法名…14 4.9. 接続プロトコルは名前を割り当てました…14 4.9.1. 接続プロトコルチャンネルはタイプします…14 4.9.2. 接続プロトコルのグローバルな要求名…14 4.9.3. 接続プロトコルチャンネル要求名…15 4.9.4. 信号名の課題に頭文字をつけてください…15 4.9.5. 接続プロトコルサブシステム名…15 4.10. 主要な交換メソッド名…16 4.11. アルゴリズム名を割り当てます…16 4.11.1. 暗号化アルゴリズム名…16 4.11.2. MACアルゴリズム名…17 4.11.3. 公開鍵アルゴリズム名…17 4.11.4. 圧縮アルゴリズム名…17 5. セキュリティ問題…17 6. 参照…18 6.1. 標準の参照…18 6.2. 有益な参照…18人の作者のアドレス…19 通知を商標登録してください…19
1. Introduction
1. 序論
This document does not define any new protocols. It is intended only to create the initial state of the IANA databases for the SSH protocol and also contains instructions for future assignments. Except for one HISTORIC algorithm generally regarded as obsolete, this document does not define any new protocols or number ranges not already defined in: [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT].
このドキュメントはどんな新しいプロトコルも定義しません。 それは、単にSSHプロトコルのためのIANAデータベースの初期状態を創設することを意図して、また、将来の課題のための指示を含んでいます。 時代遅れです、このドキュメントがどんな新しいプロトコルも定義しないか、または数が以下で既に定義されていなく及ぶので一般に、見なされた1つのHISTORICアルゴリズムを除いて [セキュアシェル (SSH)アーチ]、[セキュアシェル (SSH)、-、移-、]、[セキュアシェル (SSH)-USERAUTH]と、[セキュアシェル (SSH)で接続しています。]です。
Lehtinen & Lonvick Standards Track [Page 2] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[2ページ]RFC4250セキュアシェル (SSH)プロトコル
2. Contributors
2. 貢献者
The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions.
このセットのドキュメントの一流の元の貢献者は以下の通りです。 Tatu Ylonen、Tero Kivinen、ティモ・J.リンネ、サミ・レーティネン(セキュアシェル (SSH)通信秘密保全Corpのすべて)、およびマルック-Juhani O.サーリネン(ユベスキュレ大学)。 ダーレン・モファットは、このセットのドキュメントの元のエディタであり、また、非常にかなりの貢献をしました。
Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it.
多くの人々が数年間このドキュメントの開発に貢献しました。 承認されるべきである人々はマッツ・アンデション、ベン・ハリス、ビル・ゾンマーフェルト、ブレント・マクルーア、ニールズ・モーラー、ダミアン・ミラー、デリックFawcus、フランク・キューザック、Heikki Nousiainen、ジェイコブSchlyter、ジェフ・ヴァンダイク、ジェフリー・アルトマン、ジェフリーHutzelman、ジョンBright、ジョゼフ・ガルブレイス、ケン・ホーンスタイン、マーカス・フリードル、マーチンForssen、ニコラス・ウィリアムズ、ニールズProvos、ペリーメッツガー、ピーター・ガットマン、サイモンJosefsson、サイモンTatham、ウェイDai、デニスBider、der Mouse、および河野忠義を入れます。 ここにそれらの名前を記載するのは、彼らがこのドキュメントに裏書きしますが、それに貢献したことを意味しません。
3. Conventions Used in This Document
3. 本書では使用されるコンベンション
3.1. RFC 2119 Keywords
3.1. RFC2119キーワード
All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119].
SSHプロトコルに関連するすべてのドキュメントが“MUST"、「必須NOT」が「必要である」というキーワードを使用するものとします、“SHALL"、「」、“SHOULD"、「「推薦され」て、要件について説明するために「5月」の、そして、「任意」のNOTはそうするべきです。 これらのキーワードは[RFC2119]で説明されるように解釈されることです。
3.2. RFC 2434 Keywords
3.2. RFC2434キーワード
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434]. These designations are repeated in this document for clarity.
名前空間配分について説明するのに本書では使用されると現れる「私用」、「階層的な配分」、「先着順」、「専門のレビュー」、「仕様が必要である」、「IESG承認」、「IETFコンセンサス」、および「規格動作」というキーワードは[RFC2434]で説明されるように解釈されることです。 これらの名称は本書では明快なように繰り返されます。
PRIVATE USE - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments and assignments are not generally useful for interoperability.
PRIVATE USE--タイプと目的がローカル・サイトによって定義されている個人的であるか地方の使用だけのために。 複数のサイトが異なって(非互換)の方法で同じ値を使用するのを防ぐのを試みを全くしません。 IANAがそのような課題を見直す必要は全くありません、そして、一般に、課題は相互運用性の役に立ちません。
Lehtinen & Lonvick Standards Track [Page 3] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[3ページ]RFC4250セキュアシェル (SSH)プロトコル
HIERARCHICAL ALLOCATION - Delegated managers can assign values provided they have been given control over that part of the name space. IANA controls the higher levels of the namespace according to one of the other policies.
HIERARCHICAL ALLOCATION--スペースという名前のその部分の支配力をそれらに与えたなら、代表として派遣されたマネージャは値を割り当てることができます。 他の方針の1つに従って、IANAは名前空間の、より高いレベルを制御します。
FIRST COME FIRST SERVED - Anyone can obtain an assigned number, so long as they provide a point of contact and a brief description of what the value would be used for. For numbers, the exact value is generally assigned by the IANA; with names, specific names are usually requested.
FIRST COME FIRST SERVED--だれでも規定番号を得ることができます、彼らが値が何に使用されるだろうかに関する連絡先と簡単な説明を提供する限り。 数において、一般に、正確な値はIANAによって割り当てられます。 名前で、通常、種名は要求されています。
EXPERT REVIEW - approval by a Designated Expert is required.
EXPERT REVIEW--Designated Expertによる承認が必要です。
SPECIFICATION REQUIRED - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
SPECIFICATION REQUIRED--RFCか他の永久的で容易に利用可能な参照に値とそれらの意味を記録しなければなりません、詳細に十分な独立している実装の間の相互運用性は可能です。
IESG APPROVAL - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis).
IESG APPROVAL--IESGは新しい課題を承認しなければなりませんが、要求がRFCに記録されるという要件が全くありません(IESGは何らかのケースバイケースで材料を支える要求ドキュメントに分別がありますが)。
IETF CONSENSUS - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).
IETF CONSENSUS--新しい値はIETFコンセンサスを得るためのプロセスで割り当てられます。 明確に、IESGによって承認されたRFCsを通して新しい課題をします。 通常、IESGは適切な人々から将来の課題に関する入力を求めるでしょう(例えば関連作業部会は1であるなら存在します)。
STANDARDS ACTION - Values are assigned only for Standards Track RFCs approved by the IESG.
STANDARDS ACTION--値はIESGによって承認されたStandards Track RFCsのためだけに割り当てられます。
3.3. Protocol Fields and Values
3.3. プロトコル分野と値
Protocol fields and possible values to fill them are defined in this set of documents. Protocol fields will be defined in the message definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as follows.
それらをいっぱいにするプロトコル分野と可能な値はこのセットのドキュメントで定義されます。 プロトコル分野はメッセージ定義で定義されるでしょう。 例と、SSH_エムエスジー_CHANNEL_DATAは以下の通り定義されます。
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
バイトSSH_エムエスジー_CHANNEL_DATA uint32受取人チャンネル列データ
Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill those fields are referenced, they will appear within double quotes. Using the above example, possible values for 'data' are "foo" and "bar".
分野が参照をつけられるとき、これらのドキュメント中では、それらはシングル・クォーテション・マークの中に現れるでしょう。 それらの分野をいっぱいにする値が参照をつけられるとき、それらは二重引用符の中に現れるでしょう。 上記の例を使用して、'データ'のための可能な値は、"foo"と「バー」です。
Lehtinen & Lonvick Standards Track [Page 4] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[4ページ]RFC4250セキュアシェル (SSH)プロトコル
4. IANA Considerations
4. IANA問題
This entire document is the IANA considerations for the SSH protocol, as defined in [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH], [SSH-CONNECT]. This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments.
[SSH-CONNECT]、この全体のドキュメントは[SSH-ARCH]、[SSH-TRANS][SSH-USERAUTH]で定義されるようにSSHプロトコルのためのIANA問題です。 このセクションは名前空間を命名する際に使用されるコンベンション、登録の初期状態、および将来の課題のための指示を含みます。
4.1. Message Numbers
4.1. メッセージ番号
The Message Number is a byte value that describes the payload of a packet.
Message Numberはパケットのペイロードについて説明するバイト値です。
4.1.1. Conventions
4.1.1. コンベンション
Protocol packets have message numbers in the range 1 to 255. These numbers are allocated as follows:
プロトコルパケットは範囲に1〜255にメッセージ番号を持っています。 以下の通りこれらの数を割り当てます:
Transport layer protocol:
層のプロトコルを輸送してください:
1 to 19 Transport layer generic (e.g., disconnect, ignore,
debug, etc.)
20 to 29 Algorithm negotiation
30 to 49 Key exchange method specific (numbers can be reused
for different authentication methods)
1〜19Transport層のジェネリック、(例えば、切断してください、無視、デバッグなど) 20〜29Algorithm交渉30〜49Key交換メソッド特有です。(異なった認証方法のために数を再利用できます)
User authentication protocol:
ユーザー認証プロトコル:
50 to 59 User authentication generic
60 to 79 User authentication method specific (numbers can be
reused for different authentication methods)
50〜59User認証ジェネリック60〜79User認証方法特有です。(異なった認証方法のために数を再利用できます)
Connection protocol:
接続プロトコル:
80 to 89 Connection protocol generic
90 to 127 Channel related messages
80〜89Connectionプロトコルジェネリック90〜127Channelはメッセージについて話しました。
Reserved for client protocols:
クライアントプロトコルのために、予約されます:
128 to 191 Reserved
予約された128〜191
Local extensions:
地方の拡大:
192 to 255 Local extensions
192〜255のLocal拡張子
Lehtinen & Lonvick Standards Track [Page 5] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[5ページ]RFC4250セキュアシェル (SSH)プロトコル
4.1.2. Initial Assignments
4.1.2. 初期の課題
The following table identifies the initial assignments of the Message ID values.
以下のテーブルはMessage ID値の初期の課題を特定します。
Message ID Value Reference
----------- ----- ---------
SSH_MSG_DISCONNECT 1 [SSH-TRANS]
SSH_MSG_IGNORE 2 [SSH-TRANS]
SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS]
SSH_MSG_DEBUG 4 [SSH-TRANS]
SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS]
SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS]
SSH_MSG_KEXINIT 20 [SSH-TRANS]
SSH_MSG_NEWKEYS 21 [SSH-TRANS]
SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH]
SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH]
SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH]
SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH]
SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT]
SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT]
SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT]
SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT]
SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT]
SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT]
SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT]
SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT]
SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT]
SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT]
SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT]
SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT]
メッセージID値の参照----------- ----- --------- SSH_MSG_DISCONNECT 1 [SSH-TRANS] SSH_MSG_IGNORE 2 [SSH-TRANS] SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS] SSH_MSG_DEBUG 4 [SSH-TRANS] SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS] SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS] SSH_MSG_KEXINIT 20 [SSH-TRANS] SSH_MSG_NEWKEYS 21 [SSH-TRANS] SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH] SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH] SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH] SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH] SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT] SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT] SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT] SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT] SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT] SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT] SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT] SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT] SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT] SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT] SSH_MSG_CHANNEL_FAILURE 100 [セキュアシェル (SSH)で接続します]
4.1.3. Future Assignments
4.1.3. 将来の課題
Requests for assignments of new message numbers in the range of 1 to 29, 50 to 59, and 80 to 127 MUST be done through the STANDARDS ACTION method, as described in [RFC2434].
STANDARDS ACTIONメソッドで1〜29の範囲の新しいメッセージ番号の課題を求める要求、50〜59、および80〜127をしなければなりません、[RFC2434]で説明されるように。
The meanings of message numbers in the range of 30 to 49 are specific to the key exchange method in use, and their meaning will be specified by the definition of that method.
30〜49の範囲のメッセージ番号の意味は使用中の主要な交換メソッドに特定です、そして、それらの意味はそのメソッドの定義で指定されるでしょう。
Lehtinen & Lonvick Standards Track [Page 6] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[6ページ]RFC4250セキュアシェル (SSH)プロトコル
The meanings of message numbers in the range of 60 to 79 are specific to the user authentication method in use, and their meaning will be specified by the definition of that method.
60〜79の範囲のメッセージ番号の意味は使用中のユーザー認証メソッドに特定です、そして、それらの意味はそのメソッドの定義で指定されるでしょう。
Requests for assignments of new message numbers in the range of 128 to 191 MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
128〜191の範囲の新しいメッセージ番号の課題を求めてIETF CONSENSUSメソッドで要求しなければなりません、[RFC2434]で説明されるように。
The IANA will not control the message numbers in the range of 192 through 255. This range will be left for PRIVATE USE.
IANAは192〜255の範囲でメッセージ番号を制御しないでしょう。 この範囲はPRIVATE USEに出られるでしょう。
4.2. Disconnection Messages Reason Codes and Descriptions
4.2. 断線メッセージはコードと記述を推論します。
The Disconnection Message 'reason code' is a uint32 value. The associated Disconnection Message 'description' is a human-readable message that describes the disconnect reason.
Disconnection Message'理由コード'はuint32値です。 関連Disconnection Message'記述'は分離理由について説明する人間読み込み可能なメッセージです。
4.2.1. Conventions
4.2.1. コンベンション
Protocol packets containing the SSH_MSG_DISCONNECT message MUST have Disconnection Message 'reason code' values in the range of 0x00000001 to 0xFFFFFFFF. These are described in [SSH-TRANS].
SSH_エムエスジー_DISCONNECTメッセージを含むプロトコルパケットは0×00000001の範囲にDisconnection Message'理由コード'値を0xFFFFFFFFに持たなければなりません。 これらは[SSH-TRANS]で説明されます。
4.2.2. Initial Assignments
4.2.2. 初期の課題
The following table identifies the initial assignments of the SSH_MSG_DISCONNECT 'description' and 'reason code' values.
以下のテーブルはSSH_エムエスジー_DISCONNECT'記述'と'理由コード'値の初期の課題を特定します。
Symbolic Name reason code
------------- -----------
SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
SSH_DISCONNECT_PROTOCOL_ERROR 2
SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
SSH_DISCONNECT_RESERVED 4
SSH_DISCONNECT_MAC_ERROR 5
SSH_DISCONNECT_COMPRESSION_ERROR 6
SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
SSH_DISCONNECT_CONNECTION_LOST 10
SSH_DISCONNECT_BY_APPLICATION 11
SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
SSH_DISCONNECT_ILLEGAL_USER_NAME 15
シンボリックなName理由コード------------- ----------- _が_に許容された_ではなく、セキュアシェル (SSH)_分離_ホスト_が__どんな_もサポートしなかった利用可能な7セキュアシェル (SSH)_分離_プロトコル_バージョン_ではなく、主要な失敗した1つのセキュアシェル (SSH)_分離_プロトコル_誤り2のセキュアシェル (SSH)_分離_予約された4セキュアシェル (SSH)_分離_Mac_誤り5セキュアシェル (SSH)_分離_セキュアシェル (SSH)_分離__交換_3圧縮_誤り6セキュアシェル (SSH)_分離サービス_を接続します; 8 _無くなっている10セキュアシェル (SSH)_が_また、アプリケーション11セキュアシェル (SSH)_が__コネクションズ12セキュアシェル (SSH)_が_AUTH_から切断する多くから切断する_で_から切断する証明可能な9セキュアシェル (SSH)_分離_接続_ではなく、_の主要なセキュアシェル (SSH)_分離_ホスト_が_より多くの_AUTH_メソッド_利用可能なユーザの_分離_不法な_13セキュアシェル (SSH)_分離_いいえ、_14セキュアシェル (SSH)ユーザ_名15の_を取り消しました。
Lehtinen & Lonvick Standards Track [Page 7] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[7ページ]RFC4250セキュアシェル (SSH)プロトコル
4.2.3. Future Assignments
4.2.3. 将来の課題
Disconnection Message 'reason code' values MUST be assigned sequentially. Requests for assignments of new Disconnection Message 'reason code' values, and their associated Disconnection Message 'description' text, in the range of 0x00000010 through 0xFDFFFFFF, MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Disconnection Message 'reason code' values in the range of 0xFE000000 through 0xFFFFFFFF. Disconnection Message 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
断線Message'理由コード'値を連続して割り当てなければなりません。 IETF CONSENSUSメソッドで新しいDisconnection Message'理由コード'値の課題を求める要求、および0xFDFFFFFFを通した0×00000010の範囲のそれらの関連Disconnection Message'記述'テキストをしなければなりません、[RFC2434]で説明されるように。 IANAは0xFFFFFFFFを通して0xFE000000の範囲でDisconnection Message'理由コード'に値を割り当てないでしょう。 その範囲の断線Message'理由コード'値は[RFC2434]で説明されるようにPRIVATE USEに残されます。
4.3. Channel Connection Failure Reason Codes and Descriptions
4.3. チャンネル接続失敗理由コードと記述
The Channel Connection Failure 'reason code' is a uint32 value. The associated Channel Connection Failure 'description' text is a human- readable message that describes the channel connection failure reason. This is described in [SSH-CONNECT].
英仏海峡Connection Failure'理由コード'はuint32値です。 関連Channel Connection Failure'記述'テキストはチャンネル接続失敗理由について説明する人間の読み込み可能なメッセージです。 これは[SSH-CONNECT]で説明されます。
4.3.1. Conventions
4.3.1. コンベンション
Protocol packets containing the SSH_MSG_CHANNEL_OPEN_FAILURE message MUST have Channel Connection Failure 'reason code' values in the range of 0x00000001 to 0xFFFFFFFF.
SSH_エムエスジー_CHANNEL_オープン_FAILUREメッセージを含むプロトコルパケットは0×00000001の範囲にChannel Connection Failure'理由コード'値を0xFFFFFFFFに持たなければなりません。
4.3.2. Initial Assignments
4.3.2. 初期の課題
The initial assignments for the 'reason code' values and 'description' values are given in the table below. Note that the values for the 'reason code' are given in decimal format for readability, but they are actually uint32 values.
テーブルで'理由コード'値と'記述'値のための初期の課題を以下に与えます。 読み易さのための10進形式で'理由コード'のための値を与えますが、それらが実際にuint32値であることに注意してください。
Symbolic Name reason code
------------- -----------
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4
シンボリックなName理由コード------------- ----------- _の行政上禁止された_の1つのセキュアシェル (SSH)の_開いているセキュアシェル (SSH)_戸外の_は_失敗した2のオープンな_未知の_セキュアシェル (SSH)_チャンネル_タイプ3のセキュアシェル (SSH)の_の開いている_リソース_不足4を接続します。
4.3.3. Future Assignments
4.3.3. 将来の課題
Channel Connection Failure 'reason code' values MUST be assigned sequentially. Requests for assignments of new Channel Connection Failure 'reason code' values, and their associated Channel Connection Failure 'description string', in the range of 0x00000005 to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Channel Connection
チャンネルConnection Failure'理由コード'値を連続して割り当てなければなりません。 IETF CONSENSUSメソッドで新しいChannel Connection Failure'理由コード'値の課題を求める要求、および0xFDFFFFFFへの0×00000005の範囲のそれらの関連Channel Connection Failure'記述ストリング'をしなければなりません、[RFC2434]で説明されるように。 IANAはChannel Connectionを割り当てないでしょう。
Lehtinen & Lonvick Standards Track [Page 8] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[8ページ]RFC4250セキュアシェル (SSH)プロトコル
Failure 'reason code' values in the range of 0xFE000000 to 0xFFFFFFFF. Channel Connection Failure 'reason code' values in that range are left for PRIVATE USE, as described in [RFC2434].
0xFFFFFFFFへの0xFE000000の範囲の失敗'理由コード'値。 その範囲のチャンネルConnection Failure'理由コード'値は[RFC2434]で説明されるようにPRIVATE USEに残されます。
4.3.4. Notes about the PRIVATE USE Range
4.3.4. 私用範囲に関する注
While it is understood that the IANA will have no control over the range of 0xFE000000 to 0xFFFFFFFF, this range will be split in two parts and administered by the following conventions.
IANAが0xFE000000の範囲を0xFFFFFFFFに管理しないのが理解されている間、この範囲は、2つの部品で分けられて、以下のコンベンションによって管理されるでしょう。
o The range of 0xFE000000 to 0xFEFFFFFF is to be used in conjunction
with locally assigned channels. For example, if a channel is
proposed with a 'channel type' of "example_session@example.com"
but fails, then the server will respond with either a 'reason
code' assigned by the IANA (as listed above and in the range of
0x00000001 to 0xFDFFFFFF), or with a locally assigned value in the
range of 0xFE000000 to 0xFEFFFFFF. Naturally, if the server does
not understand the proposed 'channel type', even if it is a
locally defined 'channel type', then the 'reason code' MUST be
0x00000003, as described above. If the server does understand the
'channel type', but the channel still fails to open, then the
server SHOULD respond with a locally assigned 'reason code' value
that is consistent with the proposed local 'channel type'. It is
assumed that practitioners will first attempt to use the IANA-
assigned 'reason code' values and then document their locally
assigned 'reason code' values.
o 0xFEFFFFFFへの0xFE000000の範囲は局所的に割り当てられたチャンネルに関連して使用されることです。 例えば、チャンネルが" example_session@example.com "の'チャンネルタイプ'で提案されますが、失敗すると、IANA(範囲の上と、そして、0xFDFFFFFFへの0×00000001の範囲に記載されているように)で'理由コード'がどちらかを割り当てていたか、または0xFEFFFFFFへの0xFE000000の範囲の値が局所的に割り当てられていた状態で、サーバは反応するでしょう。 当然、サーバがそれが局所的に定義された'チャンネルタイプ'であっても提案された'チャンネルタイプ'を理解していないなら、'理由コード'は0×00000003であるに違いありません、上で説明されるように。 サーバが'チャンネルタイプ'を理解していますが、チャンネルがまだ開いていないなら、サーバSHOULDは提案された地方の'チャンネルタイプ'と一致した局所的に割り当てられた'理由コード'値で応じます。 開業医が最初にIANA割り当てられた'理由コード'値を使用して、次に、それらの局所的に割り当てられた'理由コード'値を記録するのを試みると思われます。
o There are no restrictions or suggestions for the range starting
with 0xFF. No interoperability is expected for anything used in
this range. Essentially, it is for experimentation.
o 0xFFから始まる範囲のためのどんな制限も提案もありません。 相互運用性は全くこの範囲で使用される何のためにも予想されません。 本質的には、それは実験のためのものです。
4.4. Extended Channel Data Transfer data_type_code and Data
4.4. 拡張Channel Data Transferデータ_は_コードとDataをタイプします。
The Extended Channel Data Transfer 'data_type_code' is a uint32 value. The associated Extended Channel Data Transfer 'data' is a human-readable message that describes the type of data allowed to be transferred in the channel.
Extended Channel Data Transfer'データ_タイプ_コード'はuint32値です。 関連Extended Channel Data Transfer'データ'はチャンネルで移すことができるだろうデータのタイプについて説明する人間読み込み可能なメッセージです。
4.4.1. Conventions
4.4.1. コンベンション
Protocol packets containing the SSH_MSG_CHANNEL_EXTENDED_DATA message MUST have Extended Channel Data Transfer 'data_type_code' values in the range of 0x00000001 to 0xFFFFFFFF. This is described in [SSH-CONNECT].
SSH_エムエスジー_CHANNEL_EXTENDED_DATAメッセージを含むプロトコルパケットは0×00000001の範囲にExtended Channel Data Transfer'データ_タイプ_コード'値を0xFFFFFFFFに持たなければなりません。 これは[SSH-CONNECT]で説明されます。
Lehtinen & Lonvick Standards Track [Page 9] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[9ページ]RFC4250セキュアシェル (SSH)プロトコル
4.4.2. Initial Assignments
4.4.2. 初期の課題
The initial assignments for the 'data_type_code' values and 'data' values are given in the table below. Note that the value for the 'data_type_code' is given in decimal format for readability, but the values are actually uint32 values.
テーブルで'データ_タイプ_コード'値と'データ'値のための初期の課題を以下に与えます。 読み易さのための10進形式で'データ_タイプ_コード'のための値を与えますが、値が実際にuint32値であることに注意してください。
Symbolic name data_type_code
------------- --------------
SSH_EXTENDED_DATA_STDERR 1
英字名データ_は_コードをタイプします。------------- -------------- セキュアシェル (SSH)_は_データ_STDERR1を広げました。
4.4.3. Future Assignments
4.4.3. 将来の課題
Extended Channel Data Transfer 'data_type_code' values MUST be assigned sequentially. Requests for assignments of new Extended Channel Data Transfer 'data_type_code' values, and their associated Extended Channel Data Transfer 'data' strings, in the range of 0x00000002 to 0xFDFFFFFF, MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. The IANA will not assign Extended Channel Data Transfer 'data_type_code' values in the range of 0xFE000000 to 0xFFFFFFFF. Extended Channel Data Transfer 'data_type_code' values in that range are left for PRIVATE USE, as described in [RFC2434].
拡張Channel Data Transfer'データ_タイプ_コード'値を連続して割り当てなければなりません。 IETF CONSENSUSメソッドで新しいExtended Channel Data Transfer'データ_タイプ_コード'値の課題を求める要求、および0xFDFFFFFFへの0×00000002の範囲のそれらの関連Extended Channel Data Transfer'データ'ストリングをしなければなりません、[RFC2434]で説明されるように。 IANAは0xFFFFFFFFへの0xFE000000の範囲でExtended Channel Data Transfer'データ_タイプ_コード'に値を割り当てないでしょう。 その範囲の拡張Channel Data Transfer'データ_タイプ_コード'値は[RFC2434]で説明されるようにPRIVATE USEに残されます。
4.5. Pseudo-Terminal Encoded Terminal Modes
4.5. 疑似端末のコード化されたターミナルモード
SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain 'encoded terminal modes'. The 'encoded terminal modes' value is a byte stream of opcode-argument pairs.
"pty-req"ストリングがあるCHANNEL_REQUESTメッセージが含まなければならないSSH_エムエスジー_は'ターミナルモードをコード化しました'。 'コード化されたターミナルモード'値はopcode-議論組のバイト・ストリームです。
4.5.1. Conventions
4.5.1. コンベンション
Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with a "pty-req" string MUST contain an 'encoded terminal modes' value. The opcode values consist of a single byte and are in the range of 1 to 255. Opcodes 1 to 159 have a uint32 argument. Opcodes 160 to 255 are not yet defined.
"pty-req"ストリングがあるSSH_エムエスジー_CHANNEL_REQUESTメッセージを含むプロトコルパケットは'コード化されたターミナルモード'値を含まなければなりません。 opcode値は、1バイトから成って、1〜255の範囲にあります。 Opcodes1〜159には、uint32議論があります。 Opcodes160〜255はまだ定義されていません。
4.5.2. Initial Assignments
4.5.2. 初期の課題
The following table identifies the initial assignments of the opcode values that are used in the 'encoded terminal modes' value.
以下のテーブルは'コード化されたターミナルモード'値に使用されるopcode値の初期の課題を特定します。
Lehtinen & Lonvick Standards Track [Page 10] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[10ページ]RFC4250セキュアシェル (SSH)プロトコル
opcode mnemonic description
------ -------- -----------
0 TTY_OP_END Indicates end of options.
1 VINTR Interrupt character; 255 if none. Similarly
for the other characters. Not all of these
characters are supported on all systems.
2 VQUIT The quit character (sends SIGQUIT signal on
POSIX systems).
3 VERASE Erase the character to left of the cursor.
4 VKILL Kill the current input line.
5 VEOF End-of-file character (sends EOF from the
terminal).
6 VEOL End-of-line character in addition to
carriage return and/or linefeed.
7 VEOL2 Additional end-of-line character.
8 VSTART Continues paused output (normally
control-Q).
9 VSTOP Pauses output (normally control-S).
10 VSUSP Suspends the current program.
11 VDSUSP Another suspend character.
12 VREPRINT Reprints the current input line.
13 VWERASE Erases a word left of cursor.
14 VLNEXT Enter the next character typed literally,
even if it is a special character
15 VFLUSH Character to flush output.
16 VSWTCH Switch to a different shell layer.
17 VSTATUS Prints system status line (load, command,
pid, etc).
18 VDISCARD Toggles the flushing of terminal output.
30 IGNPAR The ignore parity flag. The parameter
SHOULD be 0 if this flag is FALSE,
and 1 if it is TRUE.
31 PARMRK Mark parity and framing errors.
32 INPCK Enable checking of parity errors.
33 ISTRIP Strip 8th bit off characters.
34 INLCR Map NL into CR on input.
35 IGNCR Ignore CR on input.
36 ICRNL Map CR to NL on input.
37 IUCLC Translate uppercase characters to
lowercase.
38 IXON Enable output flow control.
39 IXANY Any char will restart after stop.
40 IXOFF Enable input flow control.
41 IMAXBEL Ring bell on input queue full.
50 ISIG Enable signals INTR, QUIT, [D]SUSP.
51 ICANON Canonicalize input lines.
opcodeの簡略記憶記述------ -------- ----------- オプションの0TTY_OP_END Indicatesエンド。 1 VINTR Interruptキャラクタ。 255 なにもであるなら。 同様である、他のキャラクタのために。 これらのキャラクタのすべてがシステム2VQUITでサポートされるというわけではない、キャラクタ(SIGQUIT信号をPOSIXシステムに送る)をやめてください。 3 カーソルの左へのキャラクタのVERASE Erase。 4VKILL Kill、電流は系列を入力しました。 5 ファイルのVEOF Endキャラクタ(端末からEOFを送ります)。 6 復帰、そして/または、ラインフィードに加えた系列のVEOL Endキャラクタ。 7 VEOL2 Additional行末文字。 8VSTART Continuesが出力(通常コントロールQ)をポーズしました。 9VSTOP Pauses出力(通常コントロールS)。 電流がプログラムする10VSUSP Suspends。 11 VDSUSP Anotherはキャラクタを停学処分にします。 電流が入力した12VREPRINT Reprintsが立ち並んでいます。 単語が残したカーソルの13VWERASE Erases。 14 次のキャラクタのVLNEXT Enterはそれが特殊文字15VFLUSHキャラクターであっても文字通り豊富な出力にタイプしました。 16 異なったシェルへのVSWTCH Switchは層にします。 17VSTATUS Printsシステム状況表示行(負荷、コマンド、pidなど)。 端末を洗い流すのが出力した18VDISCARD Toggles。 30IGNPAR、パリティ・フラグを無視してください。 パラメタSHOULD、この旗がFALSEであり、それであるなら1がTRUEであるなら、0になってください。 31 PARMRKマークの同等と縁どり誤り。 パリティエラーの32INPCK Enableの照合。 33 ISTRIP Stripは8番目にキャラクタを食いちぎりました。 34 入力でのCRへのINLCR Map NL。 35 入力でのIGNCR Ignore CR。 36 入力でのNLへのICRNL Map CR。 37 IUCLC Translateは、小文字で印刷するためにキャラクタを大文字します。 38 IXON Enableはフロー制御を出力しました。 39 IXANY Any炭は停止の後に再開するでしょう。 40 IXOFF Enableはフロー制御を入力しました。 41 IMAXBEL Ringは入力キューで満に鈴をつけます。 50 ISIG EnableはINTR、QUIT、[D]SUSPに合図します。 51 ICANON Canonicalizeは系列を入力しました。
Lehtinen & Lonvick Standards Track [Page 11] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[11ページ]RFC4250セキュアシェル (SSH)プロトコル
52 XCASE Enable input and output of uppercase
characters by preceding their lowercase
equivalents with "\".
53 ECHO Enable echoing.
54 ECHOE Visually erase chars.
55 ECHOK Kill character discards current line.
56 ECHONL Echo NL even if ECHO is off.
57 NOFLSH Don't flush after interrupt.
58 TOSTOP Stop background jobs from output.
59 IEXTEN Enable extensions.
60 ECHOCTL Echo control characters as ^(Char).
61 ECHOKE Visual erase for line kill.
62 PENDIN Retype pending input.
70 OPOST Enable output processing.
71 OLCUC Convert lowercase to uppercase.
72 ONLCR Map NL to CR-NL.
73 OCRNL Translate carriage return to newline
(output).
74 ONOCR Translate newline to carriage
return-newline (output).
75 ONLRET Newline performs a carriage return
(output).
90 CS7 7 bit mode.
91 CS8 8 bit mode.
92 PARENB Parity enable.
93 PARODD Odd parity, else even.
52 「\」がある彼らの小文字の同等物に先行するのによる大文字しているキャラクタのXCASE Enable入出力。 53 ECHO Enable反響。 54 ECHOE Visually抹消は焦げます。 55 ECHOK Killキャラクタは現在行を捨てます。 56ECHONL Echo NL、ECHOがオフであっても。 57 中断の平らに後でないことのNOFLSHドン。 58 出力からのTOSTOP Stopバックグラウンドジョブ。 59 IEXTEN Enable拡張子。 60 ^(炭)としてのECHOCTL Echo制御文字。 ECHOKE Visualが系列のために消す61人は殺されます。 62 入力までPENDIN Retype。 70OPOST Enable出力処理。 71 OLCUC Convertは、大文字するために小文字で印刷します。 72 ONLCRはNLをCR-NLに写像します。 73 ニューライン(出力)へのOCRNL Translate復帰。 復帰ニューライン(出力)への74ONOCR Translateニューライン。 75 ONLRET Newlineは復帰(出力)を実行します。 90 CS7 7はモードに噛み付きました。 91 CS8 8はモードに噛み付きました。 PARENB Parityが可能にする92。 ほかに93PARODD Oddの同等である、同等です。
128 TTY_OP_ISPEED Specifies the input baud rate in
bits per second.
129 TTY_OP_OSPEED Specifies the output baud rate in
bits per second.
128TTY_OP_ISPEED Specifies、bpsにおける入力ボーレート。 129TTY_OP_OSPEED Specifies、bpsにおける出力ボーレート。
4.5.3. Future Assignments
4.5.3. 将来の課題
Requests for assignments of new opcodes and their associated arguments MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
新しいopcodesと彼らの関連議論の課題を求めてIETF CONSENSUSメソッドで要求しなければなりません、[RFC2434]で説明されるように。
4.6. Names
4.6. 名前
In the following sections, the values for the name spaces are textual. The conventions and instructions to the IANA for future assignments are given in this section. The initial assignments are given in their respective sections.
以下のセクションでは、空間という名前のための値は原文です。 このセクションで将来の課題のためのIANAへのコンベンションと指示を与えます。 それらのそれぞれのセクションで初期の課題を与えます。
Lehtinen & Lonvick Standards Track [Page 12] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[12ページ]RFC4250セキュアシェル (SSH)プロトコル
4.6.1. Conventions for Names
4.6.1. 名前のためのコンベンション
All names registered by the IANA in the following sections MUST be
printable US-ASCII strings, and MUST NOT contain the characters at-
sign ("@"), comma (","), whitespace, control characters (ASCII codes
32 or less), or the ASCII code 127 (DEL). Names are case-sensitive,
and MUST NOT be longer than 64 characters.
以下のセクションにIANAによって登録されたすべての名前が印刷可能な米国-ASCIIストリングでなければならなく、キャラクタを含んではいけない、-、("@")に署名してください、コンマ、(「」、)、空白、制御文字(ASCIIよりコード32)、またはASCIIが127(デル)をコード化します。 名前は、大文字と小文字を区別していて、64のキャラクタより長いはずがありません。
A provision is made here for locally extensible names. The IANA will not register, and will not control, names with the at-sign in them.
ここに局所的に広げることができる名前に備えます。 IANAは登録しないで、また制御しないで、サインインにおける名前はそれらです。
Names with the at-sign in them will have the format of
"name@domainname" (without the double quotes) where the part
preceding the at-sign is the name. The format of the part preceding
the at-sign is not specified; however, these names MUST be printable
US-ASCII strings, and MUST NOT contain the comma character (","),
whitespace, control characters (ASCII codes 32 or less), or the ASCII
code 127 (DEL). They MUST have only a single at-sign in them. The
part following the at-sign MUST be a valid, fully qualified internet
domain name [RFC1034] controlled by the person or organization
defining the name. Names are case-sensitive, and MUST NOT be longer
than 64 characters. It is up to each domain how it manages its local
namespace. It has been noted that these names resemble STD 11
[RFC0822] email addresses. This is purely coincidental and has
nothing to do with STD 11 [RFC0822]. An example of a locally defined
name is "ourcipher-cbc@example.com" (without the double quotes).
サインインのそれらの名前はサインに先行する部分が名前であるところに" name@domainname "の形式を持つでしょう(二重引用符なしで)。 サインに先行する部分の形式は指定されません。 しかしながら、これらの名前が印刷可能な米国-ASCIIストリングでなければならなく、コンマキャラクタを含んではいけない、(「」、)、空白、制御文字(ASCIIよりコード32)、またはASCIIが127(デル)をコード化します。 彼らは単一のサインインのそれらしか持ってはいけません。 サインに従う部分は名前を定義する人か組織によって制御された有効で、完全に適切なインターネットドメイン名であるに違いありません[RFC1034]。 名前は、大文字と小文字を区別していて、64のキャラクタより長いはずがありません。 それは地方の名前空間を管理する各ドメインまで達しています。 これらの名前がSTD11[RFC0822]Eメールアドレスに類似していることに注意されました。 これは、純粋に暗合的であり、STD11[RFC0822]と関係ありません。 局所的に定義された名前に関する例は" ourcipher-cbc@example.com "(二重引用符のない)です。
4.6.2. Future Assignments of Names
4.6.2. 名前の将来の課題
Requests for assignments of new names MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
新しい名前の課題を求めて[RFC2434]で説明されるようにIETF CONSENSUSメソッドで要求しなければなりません。
4.7. Service Names
4.7. サービス名
The 'service name' is used to describe a protocol layer. The following table lists the initial assignments of the 'service name' values.
'サービス名'は、プロトコル層について説明するのに使用されます。 以下のテーブルは値という'サービス名'の初期の課題を記載します。
Service Name Reference
------------- ---------
ssh-userauth [SSH-USERAUTH]
ssh-connection [SSH-CONNECT]
サービス名参照------------- --------- セキュアシェル (SSH)-userauth[SSH-USERAUTH]セキュアシェル (SSH)接続[セキュアシェル (SSH)で接続します]
Lehtinen & Lonvick Standards Track [Page 13] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[13ページ]RFC4250セキュアシェル (SSH)プロトコル
4.8. Authentication Method Names
4.8. 認証方法名
The Authentication Method Name is used to describe an authentication method for the "ssh-userauth" service [SSH-USERAUTH]. The following table identifies the initial assignments of the Authentication Method Names.
Authentication Method Nameは、「セキュアシェル (SSH)-userauth」サービス[SSH-USERAUTH]のために認証方法を説明するのに使用されます。 以下のテーブルはAuthentication Method Namesの初期の課題を特定します。
Method Name Reference
------------ ---------
publickey [SSH-USERAUTH, Section 7]
password [SSH-USERAUTH, Section 8]
hostbased [SSH-USERAUTH, Section 9]
none [SSH-USERAUTH, Section 5.2]
メソッド名前参照------------ --------- パブリックキー、[SSH-USERAUTH、セクション7] パスワード、[SSH-USERAUTH、8が]hostbasedしたセクション、[SSH-USERAUTH、セクション9] なし[セキュアシェル (SSH)-USERAUTH、セクション5.2]
4.9. Connection Protocol Assigned Names
4.9. 名前が割り当てられた接続プロトコル
The following table lists the initial assignments to the Connection Protocol Type and Request names.
以下のテーブルはConnectionプロトコルTypeとRequest名に初期の課題を記載します。
4.9.1. Connection Protocol Channel Types
4.9.1. 接続プロトコルチャンネル種別
The following table lists the initial assignments of the Connection Protocol Channel Types.
以下のテーブルはConnectionプロトコルChannel Typesの初期の課題を記載します。
Channel type Reference
------------ ---------
session [SSH-CONNECT, Section 6.1]
x11 [SSH-CONNECT, Section 6.3.2]
forwarded-tcpip [SSH-CONNECT, Section 7.2]
direct-tcpip [SSH-CONNECT, Section 7.2]
チャンネルタイプReference------------ --------- セッション[SSH-CONNECT、セクション6.1]x11[SSH-CONNECT、セクション6.3.2]の進められたtcpip[SSH-CONNECT、セクション7.2]のダイレクトtcpip[セキュアシェル (SSH)で接続してください、そして、7.2を区分してください]
4.9.2. Connection Protocol Global Request Names
4.9.2. 接続プロトコルのグローバルな要求名
The following table lists the initial assignments of the Connection Protocol Global Request Names.
以下のテーブルはConnectionプロトコルGlobal Request Namesの初期の課題を記載します。
Request type Reference
------------ ---------
tcpip-forward [SSH-CONNECT, Section 7.1]
cancel-tcpip-forward [SSH-CONNECT, Section 7.1]
タイプReferenceを要求してください。------------ --------- tcpip前進[SSH-CONNECT、セクション7.1]のキャンセルtcpipフォワード[セキュアシェル (SSH)で接続してください、そして、7.1を区分してください]
Lehtinen & Lonvick Standards Track [Page 14] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[14ページ]RFC4250セキュアシェル (SSH)プロトコル
4.9.3. Connection Protocol Channel Request Names
4.9.3. 接続プロトコルチャンネル要求名
The following table lists the initial assignments of the Connection Protocol Channel Request Names.
以下のテーブルはConnectionプロトコルChannel Request Namesの初期の課題を記載します。
Request type Reference
------------ ---------
pty-req [SSH-CONNECT, Section 6.2]
x11-req [SSH-CONNECT, Section 6.3.1]
env [SSH-CONNECT, Section 6.4]
shell [SSH-CONNECT, Section 6.5]
exec [SSH-CONNECT, Section 6.5]
subsystem [SSH-CONNECT, Section 6.5]
window-change [SSH-CONNECT, Section 6.7]
xon-xoff [SSH-CONNECT, Section 6.8]
signal [SSH-CONNECT, Section 6.9]
exit-status [SSH-CONNECT, Section 6.10]
exit-signal [SSH-CONNECT, Section 6.10]
タイプReferenceを要求してください。------------ --------- pty-req、[SSH-CONNECT、セクション6.2] x11-req、[SSH-CONNECT、.1が]envするセクション6.3、[SSH-CONNECT、セクション6.4] シェル、[SSH-CONNECT、セクション6.5] 幹部、[SSH-CONNECT、セクション6.5] サブシステム、[SSH-CONNECT、セクション6.5] ウィンドウ変化、[SSH-CONNECT、セクション6.7] xon-xoff、[SSH-CONNECT、セクション6.8] 信号、[SSH-CONNECT、セクション6.9] イグジットステータス[SSH-CONNECT、セクション6.10]出口信号[セキュアシェル (SSH)で接続してください、そして、6.10を区分してください]
4.9.4. Initial Assignment of Signal Names
4.9.4. 信号名の初期の課題
The following table lists the initial assignments of the Signal Names.
以下のテーブルはSignal Namesの初期の課題を記載します。
Signal Reference
------ ---------
ABRT [SSH-CONNECT]
ALRM [SSH-CONNECT]
FPE [SSH-CONNECT]
HUP [SSH-CONNECT]
ILL [SSH-CONNECT]
INT [SSH-CONNECT]
KILL [SSH-CONNECT]
PIPE [SSH-CONNECT]
QUIT [SSH-CONNECT]
SEGV [SSH-CONNECT]
TERM [SSH-CONNECT]
USR1 [SSH-CONNECT]
USR2 [SSH-CONNECT]
信号参照------ --------- ABRT[セキュアシェル (SSH)で接続する]ALRM[セキュアシェル (SSH)で接続する]FPE[セキュアシェル (SSH)で接続する]HUP[セキュアシェル (SSH)で接続する]病気[セキュアシェル (SSH)で接続する]INT[セキュアシェル (SSH)で接続する]獲物[セキュアシェル (SSH)で接続する]パイプ[セキュアシェル (SSH)で接続する]はSEGV[セキュアシェル (SSH)で接続する]用語[セキュアシェル (SSH)で接続する]USR1[セキュアシェル (SSH)で接続する]USR2をやめます[セキュアシェル (SSH)で接続します]。[セキュアシェル (SSH)で接続します]
4.9.5. Connection Protocol Subsystem Names
4.9.5. 接続プロトコルサブシステム名
There are no initial assignments of the Connection Protocol Subsystem Names.
ConnectionプロトコルSubsystem Namesのどんな初期の課題もありません。
Lehtinen & Lonvick Standards Track [Page 15] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[15ページ]RFC4250セキュアシェル (SSH)プロトコル
4.10. Key Exchange Method Names
4.10. 主要な交換メソッド名
The name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group, as defined in [RFC2409]. SSH maintains its own group identifier space, which is logically distinct from Oakley [RFC2412] and IKE; however, for one additional group, the Working Group adopted the number assigned by [RFC3526], using "diffie-hellman-group14-sha1" for the name of the second defined group. Implementations should treat these names as opaque identifiers and should not assume any relationship between the groups used by SSH and the groups defined for IKE.
「diffie-hellman-group1-sha1"は主要な交換メソッドに[RFC2409]で定義されるようにオークリーグループを使用することで使用される」と命名します。 SSHはそれ自身のグループ識別子スペースを維持します。(それは、オークリー[RFC2412]とIKEと論理的に異なっています)。 しかしながら、1つの追加グループのために、作業部会は[RFC3526]によって割り当てられた数を採用しました、「2番目の定義されたグループの名前のためのdiffie-hellman-group14-sha1"」を使用して。 実装は、不明瞭な識別子としてこれらの名前を扱うべきであり、SSHによって使用されたグループとIKEのために定義されたグループとの少しの関係も仮定するべきではありません。
The following table identifies the initial assignments of the key exchange methods.
以下のテーブルは主要な交換メソッドの初期の課題を特定します。
Method name Reference
------------ ---------
diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1]
diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2]
メソッド名前Reference------------ --------- diffie-hellman-group1-sha1[SSH-TRANS、セクション8.1]diffie-hellman-group14-sha1[セキュアシェル (SSH)、-、移-、セクション8.2]
4.11. Assigned Algorithm Names
4.11. 割り当てられたアルゴリズム名
4.11.1. Encryption Algorithm Names
4.11.1. 暗号化アルゴリズム名
The following table identifies the initial assignment of the Encryption Algorithm Names.
以下のテーブルはEncryption Algorithm Namesの初期の課題を特定します。
Encryption Algorithm Name Reference
------------------------- ---------
3des-cbc [SSH-TRANS, Section 6.3]
blowfish-cbc [SSH-TRANS, Section 6.3]
twofish256-cbc [SSH-TRANS, Section 6.3]
twofish-cbc [SSH-TRANS, Section 6.3]
twofish192-cbc [SSH-TRANS, Section 6.3]
twofish128-cbc [SSH-TRANS, Section 6.3]
aes256-cbc [SSH-TRANS, Section 6.3]
aes192-cbc [SSH-TRANS, Section 6.3]
aes128-cbc [SSH-TRANS, Section 6.3]
serpent256-cbc [SSH-TRANS, Section 6.3]
serpent192-cbc [SSH-TRANS, Section 6.3]
serpent128-cbc [SSH-TRANS, Section 6.3]
arcfour [SSH-TRANS, Section 6.3]
idea-cbc [SSH-TRANS, Section 6.3]
cast128-cbc [SSH-TRANS, Section 6.3]
none [SSH-TRANS, Section 6.3]
des-cbc [FIPS-46-3] HISTORIC; See
page 4 of [FIPS-46-3]
暗号化アルゴリズム名前参照------------------------- --------- セクション6.3 3des-cbc SSH-TRANS、セクション6.3フグ-cbc SSH-TRANS、セクション6.3 twofish256-cbc SSH-TRANS、セクション6.3 twofish-cbc SSH-TRANS、セクション6.3 twofish192-cbc SSH-TRANS、セクション6.3 twofish128-cbc SSH-TRANS、セクション6.3 aes256-cbc SSH-TRANS、aes192-cbc SSH-TRANS(セクション6); セクション6.3 3aes128-cbc SSH-TRANS、セクション6.3 serpent256-cbc SSH-TRANS、セクション6.3 serpent192-cbc SSH-TRANS、セクション6.3 serpent128-cbc SSH-TRANS、セクション6.3 arcfour SSH-TRANS、セクション6.3考え-cbc SSH-TRANS、セクション6.3 cast128-cbc SSH-TRANS、SSH-TRANSのいずれ、もセクション6.3des-cbc FIPS-46-3 HISTORIC;でない 4ページを参照します。[FIPS-46-3]
Lehtinen & Lonvick Standards Track [Page 16] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[16ページ]RFC4250セキュアシェル (SSH)プロトコル
4.11.2. MAC Algorithm Names
4.11.2. MACアルゴリズム名
The following table identifies the initial assignments of the MAC Algorithm Names.
以下のテーブルはMAC Algorithm Namesの初期の課題を特定します。
MAC Algorithm Name Reference
------------------ ---------
hmac-sha1 [SSH-TRANS, Section 6.4]
hmac-sha1-96 [SSH-TRANS, Section 6.4]
hmac-md5 [SSH-TRANS, Section 6.4]
hmac-md5-96 [SSH-TRANS, Section 6.4]
none [SSH-TRANS, Section 6.4]
MACアルゴリズム名前参照------------------ --------- hmac-sha1、[SSH-TRANS、セクション6.4] hmac-sha1-96、[SSH-TRANS、セクション6.4] hmac-md5、[SSH-TRANS、セクション6.4] hmac-md5-96、[SSH-TRANS、セクション6.4] なし[セキュアシェル (SSH)、-、移-、セクション6.4]
4.11.3. Public Key Algorithm Names
4.11.3. 公開鍵アルゴリズム名
The following table identifies the initial assignments of the Public Key Algorithm names.
以下のテーブルはPublic Key Algorithm名の初期の課題を特定します。
Public Key Algorithm Name Reference
------------------------- ---------
ssh-dss [SSH-TRANS, Section 6.6]
ssh-rsa [SSH-TRANS, Section 6.6]
pgp-sign-rsa [SSH-TRANS, Section 6.6]
pgp-sign-dss [SSH-TRANS, Section 6.6]
公開鍵アルゴリズム名前参照------------------------- --------- セキュアシェル (SSH)-dss[SSH-TRANS、セクション6.6]セキュアシェル (SSH)-rsa[SSH-TRANS、セクション6.6]pgpサインrsa[SSH-TRANS、セクション6.6]pgpサインdss[セキュアシェル (SSH)、-、移-、セクション6.6]
4.11.4. Compression Algorithm Names
4.11.4. 圧縮アルゴリズム名
The following table identifies the initial assignments of the Compression Algorithm names.
以下のテーブルはCompression Algorithm名の初期の課題を特定します。
Compression Algorithm Name Reference
-------------------------- ---------
none [SSH-TRANS, Section 6.2]
zlib [SSH-TRANS, Section 6.2]
圧縮アルゴリズム名前参照-------------------------- --------- なにも[SSH-TRANS、セクション6.2]zlibされません。[セキュアシェル (SSH)、-、移-、セクション6.2]
5. Security Considerations
5. セキュリティ問題
This protocol provides a secure encrypted channel over an insecure network.
このプロトコルは安全な暗号化されたチャンネルを不安定なネットワークの上に提供します。
Full security considerations for this protocol are provided in [SSH-ARCH].
このプロトコルのための完全なセキュリティ問題を[SSH-ARCH]に提供します。
Lehtinen & Lonvick Standards Track [Page 17] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[17ページ]RFC4250セキュアシェル (SSH)プロトコル
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Protocol Architecture", RFC 4251, January 2006.
[セキュアシェル (SSH)アーチ] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、1月2006日
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Transport Layer Protocol", RFC 4253, January
2006.
[セキュアシェル (SSH)、-、移-、]、YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))トランスポート層プロトコル」、RFC4253、1月2006日
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[セキュアシェル (SSH)-USERAUTH] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))認証プロトコル」、RFC4252、1月2006日
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Connection Protocol", RFC 4254, January 2006.
[セキュアシェル (SSH)で接続します] YlonenとT.とC.Lonvick、エド、「セキュア・シェル(セキュアシェル (SSH))接続プロトコル」、RFC4254、1月2006日
[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月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T.、およびM.Kojo、「より多くのModular Exponential(MODP)ディフィー-ヘルマンはインターネット・キー・エクスチェンジ(IKE)のために分類します」、RFC3526、2003年5月。
6.2. Informative References
6.2. 有益な参照
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC0822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC2412] Orman、H.、「オークリーの主要な決断プロトコル」、RFC2412、1998年11月。
[FIPS-46-3] US National Institute of Standards and Technology,
"Data Encryption Standard (DES)", Federal Information
Processing Standards Publication 46-3, October 1999.
[FIPS-46-3]米国米国商務省標準技術局、「データ暗号化規格(DES)」、連邦政府の情報処理規格公表46-3、1999年10月。
Lehtinen & Lonvick Standards Track [Page 18] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[18ページ]RFC4250セキュアシェル (SSH)プロトコル
Authors' Addresses
作者のアドレス
Sami Lehtinen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
サミレーティネンセキュアシェル (SSH)通信秘密保全Corp Valimotie17 00380ヘルシンキフィンランド
EMail: sjl@ssh.com
メール: sjl@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
クリスLonvick(エディタ)シスコシステムズInc.12515研究Blvd. オースチン78759米国
EMail: clonvick@cisco.com
メール: clonvick@cisco.com
Trademark Notice
商標表示
"ssh" is a registered trademark in the United States and/or other countries.
「セキュアシェル (SSH)」は合衆国、そして/または、他国で登録商標です。
Lehtinen & Lonvick Standards Track [Page 19] RFC 4250 SSH Protocol Assigned Numbers January 2006
数の2006年1月に割り当てられたレーティネンとLonvick標準化過程[19ページ]RFC4250セキュアシェル (SSH)プロトコル
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Lehtinen & Lonvick Standards Track [Page 20]
レーティネンとLonvick標準化過程[20ページ]
一覧
スポンサーリンク
