RFC 4248 - The telnet URI Scheme 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4248
タイトル : RFC 4248 - Telnet URIスキーム
翻訳編集 : 自動生成

[要約] RFC 4248は、Telnet URIスキームの仕様を定義しており、Telnetセッションの開始と制御を目的としています。

Network Working Group                                         P. Hoffman
Request for Comments: 4248                                VPN Consortium
Obsoletes: 1738                                             October 2005
Category: Standards Track

The telnet URI Scheme

Telnet URIスキーム

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.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.

このドキュメントは、元々RFC 1738で指定されていたTelnetユニフォームリソース識別子（URI）スキームを指定しています。このドキュメントの目的は、標準トラック上のスキームに関する情報を維持しながら、RFC 1738を廃止することです。

1. Introduction

1. はじめに

URIs were previously defined in [RFC2396], which was updated by [RFC3986]. Those documents also specify how to define schemes for URIs.

URIは以前[RFC2396]で定義されており、[RFC3986]によって更新されました。これらのドキュメントは、URIのスキームを定義する方法も指定しています。

The first definition for many URI schemes appeared in [RFC1738]. Because that document has been made obsolete, this document copies the telnet URI scheme from it to allow that material to remain on standards track.

多くのURIスキームの最初の定義は[RFC1738]に登場しました。その文書は時代遅れになったため、このドキュメントは、その素材が標準の追跡に留まることを可能にするために、そこからTelnet URIスキームをコピーします。

2. Scheme Definition

2. スキーム定義

The Telnet URL scheme is used to designate interactive services that may be accessed by the Telnet protocol [STD8].

Telnet URLスキームは、Telnetプロトコル[STD8]でアクセスできるインタラクティブサービスを指定するために使用されます。

A telnet URL takes the form:

Telnet URLが形式を取得します。

telnet://<user>:<password>@<host>:<port>/ The final "/" character may be omitted. If :<port> is omitted, the port defaults to 23. The :<password> can be omitted, as well as the whole <user>:<password> part. Few implementations handle the user name and password very well, if at all.

telnet：// <user>：<absfarment>@<host>：<port>/the final "/"文字は省略できます。<port>が省略されている場合、ポートはデフォルトで23になります。：<sassword>は省略できます。ユーザー名とパスワードを非常にうまく処理する実装はほとんどありません。

This URL does not designate a data object, but rather an interactive service. Remote interactive services vary widely in the means by which they allow remote logins; in practice, the <user> and <password> supplied are advisory only: clients accessing a telnet URL merely advise the user of the suggested username and password.

このURLは、データオブジェクトを指定するのではなく、インタラクティブなサービスを指定します。リモートインタラクティブサービスは、リモートログインを許可する手段が大きく異なります。実際には、提供された<ユーザー>および<パスワード>はアドバイザリーのみです。TelnetURLにアクセスするクライアントは、推奨されるユーザー名とパスワードについてユーザーにアドバイスするだけです。

Many RFCs have added various services to the Telnet protocol for better authentication, encryption of traffic, or both. Those RFCs have not specified new URI schemes for Telnet to invoke those services (along the lines of "https" being a different URI scheme from "http"). Some modern telnet clients attempt to invoke those more-secure versions of Telnet when resolving a "telnet" URL.

多くのRFCは、より良い認証、トラフィックの暗号化、またはその両方のために、Telnetプロトコルにさまざまなサービスを追加しています。これらのRFCは、Telnetがこれらのサービスを呼び出すための新しいURIスキームを指定していません（「HTTPS」のラインに沿って、「HTTP」とは異なるURIスキームです）。一部の最新のTelnetクライアントは、「Telnet」URLを解決する際に、これらのより安全なバージョンのTelnetを呼び出そうとします。

3. Security Considerations

3. セキュリティに関する考慮事項

There are many security considerations for URI schemes discussed in [RFC3986].

[RFC3986]で議論されているURIスキームには多くのセキュリティ上の考慮事項があります。

The Telnet protocol normally uses passwords in the clear for authentication, and normally offers no privacy. In normal telnet, both the user's identity and their password are exposed without any protection; after that, the contents of the entire Telnet session is exposed without any protection.

Telnetプロトコルは通常、認証のためにクリアでパスワードを使用し、通常はプライバシーを提供しません。通常のTelnetでは、ユーザーのIDとパスワードの両方が保護せずに公開されます。その後、Telnetセッション全体の内容は保護せずに公開されます。

Many extensions have been made to Telnet to make it more secure in different ways. In particular, [RFC2941] gives a framework based on a telnet option that many other security extensions have leveraged off of. These extensions are certainly worthwhile methods for reducing the obvious problems with exposing the user's name, password, and plaintext of the session in the clear.

さまざまな方法でより安全にするために、Telnetに多くの拡張機能が作成されています。特に、[RFC2941]は、他の多くのセキュリティ拡張機能が活用しているTelnetオプションに基づくフレームワークを提供します。これらの拡張機能は、ユーザーの名前、パスワード、およびセッションのプレーンテキストをクリアで公開する際の明らかな問題を減らすための価値のある方法です。

Although some modern telnet clients attempt to invoke those more-secure versions of Telnet when resolving a "telnet" URL, other telnet clients do not, so a user cannot rely on this type of security unless it is explicitly enabled and the results of the security negotiation are checked.

一部の最新のTelnetクライアントは、「Telnet」URLを解決する際にこれらのより安全なバージョンのTelnetを呼び出そうとしますが、他のTelnetクライアントはそうではないため、ユーザーは明示的に有効になり、セキュリティ交渉の結果がチェックされない限り、このタイプのセキュリティに依存することはできません。

4. Normative References

4. 引用文献

[STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.

[STD8] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。

5. Informative References

5. 参考引用

[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[RFC1738] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。

[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[RFC2396] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、RFC 2396、1998年8月。

[RFC2941] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.

[RFC2941] Ts'o、T。およびJ. Altman、「Telnet認証オプション」、RFC 2941、2000年9月。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。

Author's Address

著者の連絡先

Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 US

ポールホフマンVPNコンソーシアム127セグレプレイスサンタクルス、カリフォルニア州95060米国

   EMail: paul.hoffman@vpnc.org

Full Copyright Statement

完全な著作権声明

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.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

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.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。

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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスが利用可能になる可能性がある範囲に関連する可能性があると主張される可能性のある他の権利の範囲に関してはありません。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.ietf.org/IPRでIETFオンラインIPRリポジトリから取得できます。

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 currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。