RFC1639 日本語訳
1639 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. June 1994. (Format: TXT=10055 bytes) (Obsoletes RFC1545) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Piscitello Request for Comments: 1639 Core Competence, Inc. Obsoletes: 1545 June 1994 Category: Experimental
Piscitelloがコメントのために要求するワーキンググループD.をネットワークでつないでください: 能力Inc.が時代遅れにする1639年のコア: 1545 1994年6月のカテゴリ: 実験的
FTP Operation Over Big Address Records (FOOBAR)
大きいアドレス記録の上のFTP操作(FOOBAR)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This paper describes a convention for specifying address families other than the default Internet address family in FTP commands and replies.
この論文は、FTPコマンドと回答におけるデフォルトインターネット・アドレスファミリー以外のアドレスファミリーを指定するためにコンベンションについて説明します。
Introduction
序論
In the File Transfer Protocol (STD 9, RFC 959), the PORT command argument <host-port> specifies the data port to be used to establish a data connection for FTP (STD 9, RFC 959). This argument is also used in the PASV reply to request the server-DTP to listen on a data port other than its default data port. This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a <long- host-port>, which allows for additional address families, variable length network addresses and variable length port numbers.
File Transferプロトコル(STD9、RFC959)では、PORTコマンド議論<ホストポート>は、FTP(STD9、RFC959)のためのデータ接続を証明するのに使用されるためにデータポートを指定します。 また、この議論は、デフォルトデータポート以外のデータポートの上で聴くようサーバ-DTPに要求するのにPASV回答に使用されます。 このRFCは「長いPort(LPRT)」コマンドと「長い受動態(LPSV)」回答の仕様でデータポートへの32ビットのIPv4アドレス以外のアドレスを割り当てるためのメソッドを指定します、議論としてそれぞれ、<の長いホストのポートの>(追加アドレスファミリー、可変長ネットワーク・アドレス、および可変長ポートナンバーを考慮する)を持っていて。
This is a general solution, applicable for all "next generation" IP alternatives, as well as for other network protocols than IP. This revision also extends FTP to allow for its operation over transport interfaces other than TCP.
これは一般解です、すべての「次世代」IP選択肢に適切です、よくIP以外のネットワーク・プロトコルのように。 また、この改正は、TCP以外の輸送インタフェースの上の操作を考慮するためにFTPを広げています。
Acknowledgments
承認
Many thanks to all the folks in the IETF who casually mentioned how to do this, but who left it to me to write this RFC. Special thanks to Rich Colella, Bob Ullmann, Steve Lunt, Jay Israel, Jon Postel, Shawn Ostermann, and Tae Kyong Song, who contributed to this work.
何気なくどうこれをするかに言及しましたが、このRFCに書くように私に任せたIETFのすべての人々をありがとうございます。 この仕事に貢献したリッシュColella、ボブ・ウルマン、スティーブ・ラント、ジェイ・イスラエル、ジョン・ポステル、ショーン・オステルマン、および多英Kyong Songへの特別な感謝。
Piscitello [Page 1] RFC 1639 FTP Over Big Address June 1994
大きいアドレス1994年6月にわたるPiscitello[1ページ]RFC1639FTP
1. Background
1. バックグラウンド
The PORT command of File Transfer Protocol allows users to specify an address other than the default data port for the transport connection over which data are transferred. The PORT command syntax is:
File TransferプロトコルのPORTコマンドで、ユーザはデータがデータがわたっている輸送接続のために移植するデフォルト以外のアドレスを指定できます。 PORTコマンド構文は以下の通りです。
PORT <SP> <host-port> <CRLF>
ポート<SP><ホストポート><CRLF>。
The <host-port> argument is the concatenation of a 32-bit internet <host-address> and a 16-bit TCP <port-address>. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A PORT command is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where h1 is the high order 8 bits of the internet host address.
ポートを接待している<>議論は32ビットのインターネット<ホスト・アドレス>と16ビットのTCP<ポートアドレス>の連結です。 8ビットの野原はこのアドレス情報に細かく分けられます、そして、それぞれの分野の値は10進数(ぴったりしたストリング表現)として送られます。 野原はコンマによって分離されます。 PORTコマンドはそうです、その結果、司令官では、「PORT h1、h2、h3、h4、p1、p2"」を形成してください。(そこでは、h1がインターネットホストの8ビットが扱う高位です)。
The <host-port> argument is also used by the PASV reply, and in certain negative completion replies.
また、ポートを接待している<>議論はPASV回答、およびある否定的完成回答に使用されます。
To accommodate larger network addresses anticipated for all IP "next generation" alternatives, and to accommodate FTP operation over network and transport protocols other than IP, new commands and reply codes are needed for FTP.
すべてのIP「次世代」選択肢のために予期されたより大きいネットワーク・アドレスに対応して、IPを除いて、ネットワークとトランスポート・プロトコルの上にFTP操作を収容するために、新しいコマンドと回答コードがFTPに必要です。
2. The LPRT Command
2. LPRTコマンド
The LPRT command allows users to specify a "long" address for the transport connection over which data are transferred. The LPRT command syntax is:
LPRTコマンドで、ユーザは「長い」アドレスをデータがわたっている輸送接続に指定できます。 LPRTコマンド構文は以下の通りです。
LPRT <SP> <long-host-port> <CRLF>
LPRTの<のSPの>の<の長いホストポート><CRLF>。
The <long-host-port> argument is the concatenation of the following fields;
<の長いホストのポートの>議論は以下の分野の連結です。
o an 8-bit <address-family> argument (af)
o ファミリー>を扱っている8ビットの<議論(af)
o an 8-bit <host-address-length> argument (hal)
o 8ビットの<ホスト長さを扱っている>議論(hal)
o a <host-address> of <host-address-length> (h1, h2, ...)
o <ホストアドレス長さの>の<ホスト・アドレス>。(h1、h2)
o an 8-bit <port-address-length> (pal)
o アドレス長さを移植している8ビットの<>。(仲間)
o a <port-address> of <port-address-length> (p1, p2, ...)
o <ポートアドレス長さの>の<ポートアドレス>。(p1、p2)
The initial values assigned to the <address-family> argument take the value of the version number of IP (see Assigned Numbers, STD 2, RFC 1340); values in the range of 0-15 decimal are thus reserved for IP
ファミリー>を扱っている<議論に割り当てられた初期の値はIPのバージョン番号の値を取ります(Assigned民数記を見てください、STD2、RFC1340)。 0-15 小数の範囲の値はIPのためにこのようにして予約されます。
Piscitello [Page 2] RFC 1639 FTP Over Big Address June 1994
大きいアドレス1994年6月にわたるPiscitello[2ページ]RFC1639FTP
and assigned by IANA. Values in the range 16-255 are available for the IANA to assign to all other network layer protocols over which FTP may be operated.
そして、IANAによって割り当てられます。 IANAがFTPが操作されるかもしれない他のすべてのネットワーク層プロトコルに割り当てるように、範囲16-255の値は利用可能です。
Relevant assigned <address-family> numbers for FOOBAR are:
FOOBARのファミリー>を扱っている関連割り当てられた<番号は以下の通りです。
Decimal Keyword ------ ------- 0 reserved 1-3 unassigned 4 Internet Protocol (IP) 5 ST Datagram Mode 6 SIP 7 TP/IX 8 PIP 9 TUBA 10-14 unassigned 15 reserved 16 Novell IPX
10進キーワード------ ------- 0 予約された標準時5データグラムMode6SIP7TP/IX8PIP9TUBA10-14が15を割り当てなかった4インターネットプロトコル(IP)が割り当てられなかった1-3は16ノベルIPXを予約しました。
The value of each field is broken into 8-bit fields and the value of each field is transmitted as an unsigned decimal number (in character string representation, note that negative numbers are explicitly not permitted). The fields are separated by commas.
8ビットの野原はそれぞれの分野の値に細かく分けられます、そして、それぞれの分野の値は未署名の10進数として送られます(文字列表現で、負数が明らかに受入れられないことに注意してください)。 野原はコンマによって分離されます。
A LPRT command is thus of the general form
LPRTコマンドはそうです、その結果、司令官では、形成してください。
LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...
LPRT af、hal、h1、h2、h3、h4…仲間、p1、p2…
where h1 is the high order 8 bits of the internet host address, and p1 is the high order 8 bits of the port number (transport address).
h1がインターネットホストの8ビットが扱う高位であり、p1がポートナンバー(輸送アドレス)の高位8ビットであるところ。
3. The LPSV Command
3. LPSVコマンド
The L(ONG) PASSIVE command requests the server-DTP to listen on a data port other than its default data port and to wait for a connection rather than initiate one upon receipt of a transfer command. The response to this command includes the address family, host address length indicator, host address, port address length, and port address of the listener process at the server. The reply code and text for entering the passive mode using a long address is 228 (Interpretation according to FTP is: positive completion reply 2yz, connections x2z, passive mode entered using long address xy8).
L(オング)PASSIVEコマンドはデフォルトデータポート以外のデータポートの上で聴いて、転送命令を受け取り次第開始1よりむしろ接続を待つようサーバ-DTPに要求します。 このコマンドへの応答はサーバでリスナープロセスのアドレスファミリー、ホスト・アドレス長さのインディケータ、ホスト・アドレス、ポートアドレスの長さ、およびポートアドレスを含んでいます。長いアドレスを使用することで受け身の形態を入れるための回答コードとテキストは228(積極的な完成回答2yz、接続x2z、FTPに従った解釈は以下の通りであり、長いアドレスxy8を使用することで受け身の形態に入った)です。
The suggested text message to accompany this reply code is:
この回答コードに伴う提案されたテキストメッセージは以下の通りです。
228 Entering Long Passive Mode (af, hal, h1, h2, h3,..., pal, p1, p2...)
228 長い受け身の形態を入れること。(af、hal、h1、h2、h3、…、仲間、p1、p2)
Piscitello [Page 3] RFC 1639 FTP Over Big Address June 1994
大きいアドレス1994年6月にわたるPiscitello[3ページ]RFC1639FTP
4. Permanent Negative Completion Reply Codes
4. 永久的な否定的完成回答コード
The negative completion reply codes that are associated with syntax errors in the PORT and PASV commands are appropriate for the LPRT and LPSV commands (500, 501). An additional negative completion reply code is needed to distinguish the case where a host supports the LPRT or LPSV command, but does not support the address family specified.
LPRTとLPSVコマンド(500、501)に、PORTとPASVコマンドにおける構文エラーに関連している否定的完成回答コードは適切です。 追加否定的完成回答コードが、ホストがLPRTかLPSVがコマンドであるとサポートしますが、指定されたアドレスファミリーを養わないケースを区別するのに必要です。
Of the FTP function groupings defined for reply codes (syntax, information, connections, authentication and accounting, and file system), "connections" seems the most logical choice; thus, an additional negative command completion reply code, 521 is added, with the following suggested textual message:
回答コード(構文、情報、接続、認証、会計学、およびファイルシステム)のために定義されたFTP機能組分けでは、「接続」は最も論理的な選択に見えます。 したがって、追加否定的コマンド完成回答コード、521は加えられて、以下で、原文のメッセージは示されていました:
521 Supported address families are (af1, af2, ..., afn)
521 サポートしているアドレスファミリーはそうです。(af1、af2、…、afn)
Where (af1, af2, ..., afn) are the values of the version numbers of the "next generation" or other protocol families supported. (Note: it has been suggested that the families could also be represented by ASCII strings.)
(af1、af2、…、afn)が「次の世代」か他のプロトコルファミリーの数がサポートしたバージョンの値であるところ。 (注意: また、ASCIIストリングでファミリーの代理をされることができたことが提案されました。)
5. Rationale
5. 原理
An explicit address family argument in the LPRT command and LPSV reply allows the Internet community to experiment with a variety of "next generation IP" and other network layer protocol alternatives within a common FTP implementation framework. (It also allows the use of a different address family on the command and data connections.) An explicit length indicator for the host address is necessary because some of the IPNG alternatives make use of variable length addresses. An explicit host address is necessary because FTP says it's necessary.
LPRTコマンドとLPSV回答における明白なアドレスファミリー議論で、インターネットコミュニティは一般的なFTP実装フレームワークの中でさまざまな「次の世代IP」と他のネットワーク層プロトコル代替手段を実験できます。 (また、それはコマンドとデータにおける異なったアドレスファミリーの使用に接続を許します。) IPNG代替手段のいくつかが可変長アドレスを利用するので、ホスト・アドレスのための明白な長さのインディケータが必要です。 FTPが、それが必要であると言うので、明白なホスト・アドレスが必要です。
The decision to provide a length indicator for the port number is not as obvious, and certainly goes beyond the necessary condition of having to support TCP port numbers.
長さのインディケータをポートナンバーに提供するという決定は、明白でなく、確かに、TCPにポートナンバーをサポートしなければならないという必要条件を越えます。
Currently, at least one IPng alternative (TP/IX) supports longer port addresses. And given the increasingly "multi-protocol" nature of the Internet, it seems reasonable that someone, somewhere, might wish to operate FTP operate over Appletalk, IPX, and OSI networks as well as TCP/IP networks. (In theory, FTP should operate over *any* transport protocol that offers the same service as TCP.) Since some of these transport protocols may offer transport selectors or port numbers that exceed 16 bits, a length indicator may be desirable. If FTP must indeed be changed to accommodate larger network addresses, it may be prudent to determine at this time whether the same flexibility is useful or necessary with respect to transport addresses.
現在、少なくとも1つのIPng選択肢(TP/IX)が、より長いポートアドレスをサポートします。 そして、ますます「マルチプロトコル」インターネットの性質を考えて、だれかが、どこかでFTPを操作するために、TCP/IPネットワークと同様にAppletalk、IPX、およびOSIネットワークの上で作動するように願っているかもしれないのは妥当に思えます。 (理論上、FTPは*の上でTCPと同じサービスを提供するどんな*トランスポート・プロトコルも操作するべきです。) これらのトランスポート・プロトコルのいくつかが16ビットを超えている輸送セレクタかポートナンバーを提供するかもしれないので、長さのインディケータは望ましいかもしれません。 より大きいネットワーク・アドレスに対応するために本当にFTPを変えなければならないなら、このとき同じ柔軟性が輸送アドレスに関して役に立つか、または必要であるかを決定するのは慎重であるかもしれません。
Piscitello [Page 4] RFC 1639 FTP Over Big Address June 1994
大きいアドレス1994年6月にわたるPiscitello[4ページ]RFC1639FTP
6. Conclusions
6. 結論
The mechanism defined here is simple, extensible, and meets both IPNG and multi-protocol internet needs.
ここで定義されたメカニズムは、簡単であって、広げることができて、IPNGとマルチプロトコルインターネットの必要性の両方を満たします。
7. References
7. 参照
STD 9, RFC 959 Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
STD9、ポステル、J.、およびJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、USC/情報科学が1985年10月に設けるRFC959。
STD 2, RFC 1340 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. (Does not include recently assigned IPv7 numbers).
STD2、レイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340、USC/情報科学が1992年7月に設けるRFC1340。 (最近割り当てられたIPv7番号を含んでいません。)
STD 3, RFC 1123 Braden, R., Editor, "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.
STD3、1123年のRFCブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123(科学が1989年10月に設けるUSC/情報)
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9. Author's Address
9. 作者のアドレス
David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025
デヴィッドM.PiscitelloコアコンピタンスInc.1620Tuckerstown道路Dresher、PA 19025
EMail: dave@corecom.com
メール: dave@corecom.com
Piscitello [Page 5]
Piscitello[5ページ]
一覧
スポンサーリンク