RFC3659 日本語訳
3659 Extensions to FTP. P. Hethmon. March 2007. (Format: TXT=137962 bytes) (Updates RFC0959) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Hethmon Request for Comments: 3659 Hethmon Software Updates: 959 March 2007 Category: Standards Track
コメントを求めるワーキンググループP.ヘスマンの要求をネットワークでつないでください: 3659のヘスマンのソフトウェアアップデート: 959 2007年3月のカテゴリ: 標準化過程
Extensions to FTP
FTPへの拡大
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 IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure.
このドキュメントは定義された形式でリモートディレクトリのリストを入手する新しいFTPコマンドを指定します、そして、可能にするのはSTREAMモードによる中断しているデータ転送を再開します。 それは、米国-ASCIIを除いた文字の組を許容して、また、任意の仮想のファイル格納構造を定義します。
Hethmon Standards Track [Page 1] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Pathnames. . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Times. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Server Replies . . . . . . . . . . . . . . . . . . . . . 7
2.5. Interpreting Examples. . . . . . . . . . . . . . . . . . 8
3. File Modification Time (MDTM). . . . . . . . . . . . . . . . . 8
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 9
3.3. FEAT Response for MDTM . . . . . . . . . . . . . . . . . 10
3.4. MDTM Examples. . . . . . . . . . . . . . . . . . . . . . 10
4. File SIZE. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Error Responses. . . . . . . . . . . . . . . . . . . . . 12
4.3. FEAT Response for SIZE . . . . . . . . . . . . . . . . . 12
4.4. Size Examples. . . . . . . . . . . . . . . . . . . . . . 12
5. Restart of Interrupted Transfer (REST) . . . . . . . . . . . . 13
5.1. Restarting in STREAM Mode. . . . . . . . . . . . . . . . 14
5.2. Error Recovery and Restart . . . . . . . . . . . . . . . 14
5.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. FEAT Response for REST . . . . . . . . . . . . . . . . . 16
5.5. REST Example . . . . . . . . . . . . . . . . . . . . . . 17
6. A Trivial Virtual File Store (TVFS). . . . . . . . . . . . . . 17
6.1. TVFS File Names. . . . . . . . . . . . . . . . . . . . . 18
6.2. TVFS Pathnames . . . . . . . . . . . . . . . . . . . . . 18
6.3. FEAT Response for TVFS . . . . . . . . . . . . . . . . . 20
6.4. OPTS for TVFS. . . . . . . . . . . . . . . . . . . . . . 21
6.5. TVFS Examples. . . . . . . . . . . . . . . . . . . . . . 21
7. Listings for Machine Processing (MLST and MLSD). . . . . . . . 23
7.1. Format of MLSx Requests. . . . . . . . . . . . . . . . . 23
7.2. Format of MLSx Response. . . . . . . . . . . . . . . . . 24
7.3. File Name Encoding . . . . . . . . . . . . . . . . . . . 26
7.4. Format of Facts. . . . . . . . . . . . . . . . . . . . . 28
7.5. Standard Facts . . . . . . . . . . . . . . . . . . . . . 28
7.6. System Dependent and Local Facts . . . . . . . . . . . . 36
7.7. MLSx Examples. . . . . . . . . . . . . . . . . . . . . . 37
7.8. FEAT Response for MLSx . . . . . . . . . . . . . . . . . 49
7.9. OPTS Parameters for MLST . . . . . . . . . . . . . . . . 51
8. Impact on Other FTP Commands . . . . . . . . . . . . . . . . . 54
9. Character Sets and Internationalization. . . . . . . . . . . . 55
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 55
10.1. The OS Specific Fact Registry. . . . . . . . . . . . . . 56
10.2. The OS Specific Filetype Registry. . . . . . . . . . . . 56
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . 3 2.1を記録してください。 基本的な象徴. . . . . . . . . . . . . . . . . . . . . . 4 2.2。 パス名。 . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. 回。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. サーバ回答. . . . . . . . . . . . . . . . . . . . . 7 2.5。 例を解釈します。 . . . . . . . . . . . . . . . . . 8 3. 変更時間(MDTM)をファイルしてください。 . . . . . . . . . . . . . . . . 8 3.1. 構文. . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2。 誤り応答。 . . . . . . . . . . . . . . . . . . . . 9 3.3. MDTM. . . . . . . . . . . . . . . . . 10 3.4のための功績応答。 MDTMの例。 . . . . . . . . . . . . . . . . . . . . . 10 4. サイズをファイルしてください。 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. 構文. . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2。 誤り応答。 . . . . . . . . . . . . . . . . . . . . 12 4.3. サイズ. . . . . . . . . . . . . . . . . 12 4.4のための功績応答。 サイズの例。 . . . . . . . . . . . . . . . . . . . . . 12 5. 中断している転送(休息). . . . . . . . . . . . 13 5.1の再開。 流れのモードで、再開します。 . . . . . . . . . . . . . . . 14 5.2. エラー回復と再開. . . . . . . . . . . . . . . 14 5.3。 構文. . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4。 休息. . . . . . . . . . . . . . . . . 16 5.5のための功績応答。 例. . . . . . . . . . . . . . . . . . . . . . 17 6を休ませてください。 些細な仮想のファイルストア(TVFS)。 . . . . . . . . . . . . . 17 6.1. TVFSは名前をファイルします。 . . . . . . . . . . . . . . . . . . . . 18 6.2. TVFSパス名. . . . . . . . . . . . . . . . . . . . . 18 6.3。 TVFS. . . . . . . . . . . . . . . . . 20 6.4のための功績応答。 TVFSを選びます。 . . . . . . . . . . . . . . . . . . . . . 21 6.5. TVFSの例。 . . . . . . . . . . . . . . . . . . . . . 21 7. マシン処理(MLSTとMLSD)のためのリスト。 . . . . . . . 23 7.1. MLSx要求の形式。 . . . . . . . . . . . . . . . . 23 7.2. MLSx応答の形式。 . . . . . . . . . . . . . . . . 24 7.3. 名前コード化. . . . . . . . . . . . . . . . . . . 26 7.4をファイルしてください。 事実の形式。 . . . . . . . . . . . . . . . . . . . . 28 7.5. 標準の事実. . . . . . . . . . . . . . . . . . . . . 28 7.6。 システムに依存してローカルの事実. . . . . . . . . . . . 36 7.7。 MLSxの例。 . . . . . . . . . . . . . . . . . . . . . 37 7.8. MLSx. . . . . . . . . . . . . . . . . 49 7.9のための功績応答。 MLST. . . . . . . . . . . . . . . . 51 8のためのパラメタを選びます。 他のFTPコマンド. . . . . . . . . . . . . . . . . 54 9のときに、影響を与えてください。 文字コードと国際化。 . . . . . . . . . . . 55 10. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 55 10.1. OSの特定の事実登録。 . . . . . . . . . . . . . 56 10.2. OSの特定のFiletype登録。 . . . . . . . . . . . 56
Hethmon Standards Track [Page 2] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[2ページ]。
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 57 12. Normative References . . . . . . . . . . . . . . . . . . . . . 58 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 59
11. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 57 12. 標準の参照. . . . . . . . . . . . . . . . . . . . . 58承認。 . . . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction
1. 序論
This document updates the File Transfer Protocol (FTP) [3]. Four new commands are added: "SIZE", "MDTM", "MLST", and "MLSD". The existing command "REST" is modified. Of those, the "SIZE" and "MDTM" commands, and the modifications to "REST" have been in wide use for many years. The others are new.
このドキュメントはFile Transferプロトコル(FTP)[3]をアップデートします。 4つの新しいコマンドが加えられます: 「サイズ」、"MDTM"、"MLST"、および"MLSD"。 既存のコマンド「休息」は変更されています。 それらでは、「サイズ」と"MDTM"は命令します、そして、「休ませる」変更が何年も広い使用でありました。 他のものは新しいです。
These commands allow a client to restart an interrupted transfer in transfer modes not previously supported in any documented way, and to obtain a directory listing in a machine friendly, predictable, format.
クライアントは、これらのコマンドで、以前にどんな記録された方法でも支持されなかった転送モードにおける中断している転送を再開して、好意的で、予測できるマシンにリストアップされているディレクトリを入手します、形式。
An optional structure for the server's file store (NVFS) is also defined, allowing servers that support such a structure to convey that information to clients in a standard way, thus allowing clients more certainty in constructing and interpreting pathnames.
また、サーバのファイル店(NVFS)のための任意の構造は定義されます、そのような構造を支えるサーバが標準の方法でその情報をクライアントに伝えるのを許容して、その結果、パス名を構成して、解釈する際に、より多くの確実性をクライアントに許容します。
2. Document Conventions
2. ドキュメントコンベンション
This document makes use of the document conventions defined in BCP 14, RFC 2119 [4]. That provides the interpretation of capitalized imperative words like MUST, SHOULD, etc.
このドキュメントはBCP14、RFC2119[4]で定義されたドキュメントコンベンションを利用します。 それは同類がそうしなければならない大文字で書かれた必須の単語、SHOULDなどの解釈を提供します。
This document also uses notation defined in STD 9, RFC 959 [3]. In particular, the terms "reply", "user", "NVFS" (Network Virtual File System), "file", "pathname", "FTP commands", "DTP" (data transfer process), "user-FTP process", "user-PI" (user protocol interpreter), "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "NVT" (Network Virtual Terminal), "control connection", "data connection", and "ASCII", are all used here as defined there.
また、このドキュメントはSTD9、RFC959[3]で定義された記法を使用します。 特に、用語が、「ユーザ」、「NVFS」(ネットワークの仮想のファイルシステム)と「返答する」という「ファイル」、「パス名」、「FTPコマンド」、"DTP"(データ転送の過程)、「ユーザFTPの過程」、「ユーザパイ」(ユーザプロトコルインタプリタ)、「ユーザ-DTP」、「サーバFTPの過程」、「サーバパイ」、「サーバ-DTP」、「モード」、「タイプ」、"NVT"(ネットワーク仮想端末)、「コントロール接続」、「データ接続」、および「ASCII」はそこで定義されるようにここですべて使用されます。
Syntax required is defined using the Augmented BNF defined in [5]. Some general ABNF definitions that are required throughout the document will be defined later in this section. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section.
必要である構文は、[5]で定義されたAugmented BNFを使用することで定義されます。 ドキュメント中で必要であるいくつかの一般的なABNF定義が後でこのセクションで定義されるでしょう。 初めに読んで、これらの定義がここに存在したと単に思い出して、次のセクションまでスキップするのは賢明であるかもしれません。
Hethmon Standards Track [Page 3] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[3ページ]。
2.1. Basic Tokens
2.1. 基本的な象徴
This document imports the core ABNF definitions given in Appendix A of [5]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. The following terms are added for use in this document.
このドキュメントは[5]のAppendix Aで与えられたコアABNF定義を意味します。 そこでは、定義がアルファー、DIGIT、SPなどのような基本的なABNF要素に関して見つけられるでしょう。 次の用語は使用のために本書では加えられます。
TCHAR = VCHAR / SP / HTAB ; visible plus white space
RCHAR = ALPHA / DIGIT / "," / "." / ":" / "!" /
"@" / "#" / "$" / "%" / "^" /
"&" / "(" / ")" / "-" / "_" /
"+" / "?" / "/" / "\" / "'" /
DQUOTE ; <"> -- double quote character (%x22)
SCHAR = RCHAR / "=" ;
TCHARはVCHAR/SP/HTABと等しいです。 」 「目に見えて白いスペースRCHARはアルファー/ DIGIT /と等しい」/、」、」 / ":" / "!" / "@" / "#" / "$" / "%" / "^" / "&" / "(" / ")" / "-" / "_" / "+" / "?" 「/」/」 /「\」/「'「/DQUOTE'」。 <、「>--二重引用文字(%x22)シェアーはRCHAR/「=」と等しいです」。
The VCHAR (from [5]), RCHAR, SCHAR, and TCHAR types give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses.
VCHAR、([5])から、RCHAR、シェアー、およびTCHARタイプは様々なコマンドと応答における使用のためにASCII文字の組の異なった部分集合から基本的な字種を与えます。
token = 1*RCHAR
象徴=1*RCHAR
A "token" is a string whose precise meaning depends upon the context in which it is used. In some cases it will be a value from a set of possible values maintained elsewhere. In others it might be a string invented by one party to an FTP conversation from whatever sources it finds relevant.
「象徴」は正確な意味がそれが使用されている文脈によるストリングです。 いくつかの場合、それはほかの場所で維持された1セットの可能な値から値になるでしょう。 他のものでは、それはFTPの会話への1回のパーティーによってそれが関連しているのがわかるどんなソースからも発明されたストリングであるかもしれません。
Note that in ABNF, string literals are case insensitive. That convention is preserved in this document, and implies that FTP commands added by this specification have names that can be represented in any case. That is, "MDTM" is the same as "mdtm", "Mdtm" and "MdTm" etc. However note that ALPHA, in particular, is case sensitive. That implies that a "token" is a case sensitive value. That implication is correct, except where explicitly stated to the contrary in this document, or in some other specification that defines the values this document specifies be used in a particular context.
ABNFでは、文字列リテラルが大文字と小文字を区別しないことに注意してください。 そのコンベンションは、本書では保存されて、この仕様で加えられたFTPコマンドがどのような場合でも、表すことができる名前を持っているのを含意します。 すなわち、"MDTM"は"mdtm"、"Mdtm"、および"MdTm"などと同じです。 しかしながら、アルファーが特に大文字と小文字を区別していることに注意してください。 それは、「象徴」が大文字と小文字を区別する値であることを含意します。 その含意は正しいです、明らかにそれと反対に本書では述べられているか、または特定の文脈でこのドキュメントが指定する値を定義するある他の仕様で使用されるのを除いて。
2.2. Pathnames
2.2. パス名
Various FTP commands take pathnames as arguments, or return pathnames in responses. When the MLST command is supported, as indicated in the response to the FEAT command [6], pathnames are to be transferred in one of the following two formats.
様々なFTPコマンドは、議論としてパス名をみなすか、または応答でリターンパス名をみなします。 FEATコマンド[6]への応答にみられるようにMLSTコマンドをサポートするとき、パス名は以下の2つの形式の1つで移すことです。
Hethmon Standards Track [Page 4] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[4ページ]。
pathname = utf-8-name / raw
utf-8-name = <a UTF-8 encoded Unicode string>
raw = <any string that is not a valid UTF-8 encoding>
いずれも結ぶ>をコード化する有効なUTF-8でないパス名=UTF-8がコード化した生のutf8utf8名/名=<ユニコードストリング>生の=<。
Which format is used is at the option of the user-PI or server-PI sending the pathname. UTF-8 encodings [2] contain enough internal structure that it is always, in practice, possible to determine whether a UTF-8 or raw encoding has been used, in those cases where it matters. While it is useful for the user-PI to be able to correctly display a pathname received from the server-PI to the user, it is far more important for the user-PI to be able to retain and retransmit the identical pathname when required. Implementations are advised against converting a UTF-8 pathname to a local charset that isn't capable of representing the full Unicode character repertoire, and then attempting to invert the charset translation later. Note that ASCII is a subset of UTF-8. See also [1].
ユーザ-PIかサーバ-PIがパス名を送る選択にはどの形式が使用されているかがあります。 UTF-8 encodings[2]はいつもそれがそうです、実際には、可能であるUTF-8か生のコード化が使用されたかどうか決定できるくらいの内部の構造を含んでいます、それが重要であるそれらの場合で。 ユーザ-PIが正しくサーバ-PIからユーザまで受け取られたパス名を表示できるのが、役に立ちますが、必要であると、ユーザ-PIが同じパス名を保有して、再送できるのは、はるかに重要です。 実現は、完全なユニコード文字レパートリーを表して、次に後でcharset翻訳を逆にするのを試みることができない地方のcharsetにUTF-8パス名を変換しないように教えられます。 ASCIIがUTF-8の部分集合であることに注意してください。 また、[1]を見てください。
Unless otherwise specified, the pathname is terminated by the CRLF that terminates the FTP command, or by the CRLF that ends a reply. Any trailing spaces preceding that CRLF form part of the name. Exactly one space will precede the pathname and serve as a separator from the preceding syntax element. Any additional spaces form part of the pathname. See [7] for a fuller explanation of the character encoding issues. All implementations supporting MLST MUST support [7].
別の方法で指定されない場合、パス名はFTPコマンドを終えるCRLF、または回答を終わらせるCRLFによって終えられます。 そのCRLFに先行するどんな引きずっている空間も名前の一部を形成します。 まさに1つのスペースが分離符として前の構文要素からパス名とサーブに先行するでしょう。 どんな追加空間もパス名の一部を形成します。 問題をコード化するキャラクタの、よりふくよかな説明のための[7]を見てください。 MLST MUSTを支持するすべての実現が[7]を支持します。
Note: for pathnames transferred over a data connection, there is no way to represent a pathname containing the characters CR and LF in sequence, and distinguish that from the end of line indication. Hence, pathnames containing the CRLF pair of characters cannot be transmitted over a data connection. Data connections only contain file names transmitted from server-FTP to user-FTP as the result of one of the directory listing commands. Files with names containing the CRLF sequence must either have that sequence converted to some other form, such that the other form can be recognised and be correctly converted back to CRLF, or be omitted from the listing.
以下に注意してください。 データ接続の上に移されたパス名には、連続してキャラクタのCRとLFを含むパス名を表す方法は全くありません、そして、行末指示とそれを区別してください。 したがって、キャラクタのCRLF組を含むパス名はデータ接続の上に伝えることができません。 データ接続はディレクトリリストの1つの結果が命令するようにサーバFTPからユーザFTPまで伝えられたファイル名を含むだけです。 名前がCRLF系列を含んでいるファイルをその系列をもう片方のフォームを認識できるようにある他のフォームに変えて、正しくCRLFに変換して戻すように持たなければならないか、またはリストから忘れなければなりません。
Implementations should also beware that the FTP control connection uses Telnet NVT conventions [8], and that the Telnet IAC character, if part of a pathname sent over the control connection, MUST be correctly escaped as defined by the Telnet protocol.
また、実現はTelnetプロトコルによって定義されるようにFTPコントロール接続がTelnet NVTコンベンション[8]を使用して、パス名の一部がコントロール接続を移動したなら正しくTelnet IACキャラクタから逃げなければならないのに注意するべきです。
NVT also distinguishes between CR, LF, and the end of line CRLF, and so would permit pathnames containing the pair of characters CR and LF to be correctly transmitted. However, because such a sequence cannot be transmitted over a data connection (as part of the result of a LIST, NLST, or MLSD command), such pathnames are best avoided.
NVTも、CR、LF、および行末CRLFを見分けるので、キャラクタのCRとLFの組を含むパス名が正しく伝えられるのを可能にするでしょう。 しかしながら、データ接続(LIST、NLST、またはMLSDコマンドの結果の一部としての)の上にそのような系列を伝えることができないのでそのようなパス名を避けるのは最も良いです。
Hethmon Standards Track [Page 5] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[5ページ]。
Implementors should also be aware that, although Telnet NVT conventions are used over the control connections, Telnet option negotiation MUST NOT be attempted. See section 4.1.2.12 of [9].
また、作成者もTelnet NVTコンベンションがコントロール接続の上で使用されますが、Telnetオプション交渉を試みてはいけないのを意識しているべきです。 セクション4.1を見てください。.2 .12 [9]について。
2.2.1. Pathname Syntax
2.2.1. パス名構文
Except where TVFS is supported (see section 6), this specification imposes no syntax upon pathnames. Nor does it restrict the character set from which pathnames are created. This does not imply that the NVFS is required to make sense of all possible pathnames. Server-PIs may restrict the syntax of valid pathnames in their NVFS in any manner appropriate to their implementation or underlying file system. Similarly, a server-PI may parse the pathname and assign meaning to the components detected.
TVFSが支持される(セクション6を見てください)ところ以外に、この仕様はパス名に構文を全く課しません。 また、それはパス名が作成される文字の組を制限しません。 これは、NVFSがすべての可能なパス名を理解できなければならないのを含意しません。 サーバ-PIsはそれらのどんな方法でも彼らの実現か基本的なファイルシステムに適切なNVFSの有効なパス名の構文を制限するかもしれません。 同様に、サーバ-PIはパス名を分析して、検出されたコンポーネントに意味を割り当てるかもしれません。
2.2.2. Wildcarding
2.2.2. Wildcardingします。
For the commands defined in this specification, all pathnames are to be treated literally. That is, for a pathname given as a parameter to a command, the file whose name is identical to the pathname given is implied. No characters from the pathname may be treated as special or "magic", thus no pattern matching (other than for exact equality) between the pathname given and the files present in the NVFS of the server-FTP is permitted.
すべてのパス名はこの仕様に基づき定義されたコマンドにおいて文字通り扱われることです。 すなわち、パラメタとしてコマンドに与えられたパス名において、名前が与えられたパス名と同じであるファイルは含意されます。 パス名からのキャラクタは全く特別であるか「魔法」として扱われないかもしれません、その結果、サーバFTPのNVFSの現在の与えられたパス名とファイルの間で合っているのが(正確な平等以外に)受入れられるパターンがありません。
Clients that desire some form of pattern matching functionality must obtain a listing of the relevant directory, or directories, and implement their own file name selection procedures.
何らかのフォームのパターン・マッチングの機能性を望んでいるクライアントは、関連ディレクトリ、またはディレクトリのリストを入手して、それら自身のファイル名選択手順を実行しなければなりません。
2.3. Times
2.3. 回
The syntax of a time value is:
時間的価値の構文は以下の通りです。
time-val = 14DIGIT [ "." 1*DIGIT ]
時間-valは14DIGITと等しいです。[「. 」 1*ケタ、]
The leading, mandatory, fourteen digits are to be interpreted as, in order from the leftmost, four digits giving the year, with a range of 1000--9999, two digits giving the month of the year, with a range of 01--12, two digits giving the day of the month, with a range of 01--31, two digits giving the hour of the day, with a range of 00--23, two digits giving minutes past the hour, with a range of 00--59, and finally, two digits giving seconds past the minute, with a range of 00--60 (with 60 being used only at a leap second). Years in the tenth century, and earlier, cannot be expressed. This is not considered a serious defect of the protocol.
主で、義務的な14ケタは解釈されることです、一番左からのオーダーで、4ケタが1年を与えて、さまざまな1000--9999で、2ケタが1年の月を与えて、さまざまな01--12で、2ケタが月の日を与えて; さまざまな01--31、分間の先間の秒を与えながらさまざまな00--23、さまざまな00--59と共に時間の先間の数分を与える2ケタ、および最終的に2ケタで1日の時間を与える2ケタ、さまざまな00--60(60が一足飛びに2番目にだけ、使用されている)で。 10世紀、より早いところの何年も言い表すことができません。 これはプロトコルの重大な欠陥であると考えられません。
Hethmon Standards Track [Page 6] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[6ページ]。
The optional digits, which are preceded by a period, give decimal fractions of a second. These may be given to whatever precision is appropriate to the circumstance, however implementations MUST NOT add precision to time-vals where that precision does not exist in the underlying value being transmitted.
任意のケタ(期間までに先行されている)は1秒の小数を与えます。 実現は、状況に適切ないかなる精度にもこれらを与えるかもしれなくて、しかしながら、その精度が送られる基本的な値で存在しない時間-valsに精度を加えてはいけません。
Symbolically, a time-val may be viewed as
象徴的に、時間-valは見られるかもしれません。
YYYYMMDDHHMMSS.sss
YYYYMMDDHHMMSS.sss
The "." and subsequent digits ("sss") are optional. However the "."
MUST NOT appear unless at least one following digit also appears.
「」 . 」 その後のケタ("sss")は任意です。 しかしながら、「」、」 また、次の少なくとも1ケタが現れない場合、現れてはいけません。
Time values are always represented in UTC (GMT), and in the Gregorian calendar regardless of what calendar may have been in use at the date and time indicated at the location of the server-PI.
時間的価値は(グリニッジ標準時)のUTC、およびどんなカレンダーがサーバ-PIの位置で示された日時に使用中であったかもしれないかにかかわらずグレゴリオ暦でいつも表されます。
The technical differences among GMT, TAI, UTC, UT1, UT2, etc., are not considered here. A server-FTP process should always use the same time reference, so the times it returns will be consistent. Clients are not expected to be time synchronized with the server, so the possible difference in times that might be reported by the different time standards is not considered important.
グリニッジ標準時の技術的な違い、TAI、UTC、UT1、UT2などはここで考えられません。 サーバFTPの過程がいつも同じ時間参照を使用するべきであるので、それが返す回は一貫するでしょう。 クライアントが時間がサーバと同期したということでないと予想されるので、異なった時間規格によって報告されるかもしれない回の違いの可能性は重要であると考えられません。
2.4. Server Replies
2.4. サーバ回答
Section 4.2 of [3] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change.
[3]のセクション4.2はユーザ-PIからサーバ-PIによる回答の書式と意味をFTPコマンドと定義します。 それらの回答コンベンションはここで変化なしで使用されます。
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
エラーコードSP*TCHAR CRLF誤り応答=エラーコードが等しい、(「4インチ/「5インチ) 2DIGIT」
Implementors should note that the ABNF syntax used in this document and in other FTP related documents (but not used in [3]), sometimes shows replies using the one-line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may use the multi-line format described in [3].
作成者は、本書では使用されて他のFTPにおけるABNF構文がドキュメントについて話したことに注意するべきです。(しかし、[3])、時々1線の形式を使用するショー回答で使用されていません。 別の方法で明らかに述べられない場合、それが、マルチ線応答が受入れられないのを含意することを意図しません。 作成者は、それと反対に述べられない場合どんなFTPコマンド(QUITを含んでいる)に関するどんな回答も[3]で説明されたマルチ線形式を使用するかもしれないと仮定するべきです。
Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 reply" means a reply from the server-PI using the three digit code "500".
このドキュメント中では、回答はそれらの最初の要素である3ケタコードによって特定されるでしょう。 したがって、「500回答」という用語は3ケタを使用するサーバ-PIコード「500」から回答を意味します。
Hethmon Standards Track [Page 7] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[7ページ]。
2.5. Interpreting Examples
2.5. 例を解釈します。
In the examples of FTP dialogs presented in this document, lines that begin "C> " were sent over the control connection from the user-PI to the server-PI, lines that begin "S> " were sent over the control connection from the server-PI to the user-PI, and each sequence of lines that begin "D> " was sent from the server-PI to the user-PI over a data connection created just to send those lines and closed immediately after. No examples here show data transferred over a data connection from the client to the server. In all cases, the prefixes shown above, including the one space, have been added for the purposes of this document, and are not a part of the data exchanged between client and server.
本書では提示されたFTP対話に関する例では、「C>」を始めた線はユーザ-PIからサーバ-PIまでのコントロール接続の上に送ります、「S>」を始めた線が送って、「D>」がサーバ-PIからユーザ-PIまでのコントロール接続、および始まる線の各系列の上に、サーバ-PIからただそれらを送るために創造されたデータ接続の上のユーザ-PI線に送られて直後に閉じられたということであったということでした。 ここでどんな例も、データがクライアントからサーバまでのデータ接続の上で移されたのを示しません。ケース(1つのスペースを含んでいて、上に示された接頭語)は、全部で、このドキュメントの目的のために加えられて、クライアントとサーバの間で交換されたデータの一部ではありません。
3. File Modification Time (MDTM)
3. ファイル変更時間(MDTM)
The FTP command, MODIFICATION TIME (MDTM), can be used to determine when a file in the server NVFS was last modified. This command has existed in many FTP servers for many years, as an adjunct to the REST command for STREAM mode, thus is widely available. However, where supported, the "modify" fact that can be provided in the result from the new MLST command is recommended as a superior alternative.
サーバNVFSのファイルが最後にいつ変更されたかを決定するのに、FTPコマンド(MODIFICATION TIME(MDTM))を使用できます。 このコマンドは、何年間も、付属物として多くのFTPサーバでSTREAMモードのためのRESTコマンドに存在していて、その結果、広く利用可能です。 しかしながら、支持されるところでは、新しいMLSTコマンドから結果に提供できる「変更」事実は優れた代替手段としてお勧めです。
When attempting to restart a RETRieve, the user-FTP can use the MDTM command or the "modify" fact to check if the modification time of the source file is more recent than the modification time of the partially transferred file. If it is, then most likely the source file has changed, and it would be unsafe to restart the previously incomplete file transfer.
RETRieveを再開するのを試みるとき、ユーザFTPは、ソースファイルの変更時間が部分的にわたっているファイルの変更時間より最近かどうかチェックするのにMDTMコマンドか「変更」事実を使用できます。 それがあるなら、たぶん、ソースファイルは変化しました、そして、以前に不完全なファイル転送を再開するのは危険でしょう。
Because the user- and server-FTPs' clocks are not necessarily synchronised, user-FTPs intending to use this method should usually obtain the modification time of the file from the server before the initial RETRieval, and compare that with the modification time before a RESTart. If they differ, the files may have changed, and RESTart would be inadvisable. Where this is not possible, the user-FTP should make sure to allow for possible clock skew when comparing times.
ユーザとサーバFTPの時計が必ず使用する連動したユーザFTP意図であるというわけではないので、この方法は、通常、初期のRETRievalの前でサーバからファイルの変更時間を得て、RESTartの前で変更時間とそれを比べるべきです。 彼らが異なるなら、ファイルは変化したかもしれません、そして、RESTartは勧められないでしょう。 これが可能でないところでは、ユーザFTPは、回を比較するとき、可能な時計斜行を考慮するのを確実にするべきです。
When attempting to restart a STORe, the User FTP can use the MDTM command to discover the modification time of the partially transferred file. If it is older than the modification time of the file that is about to be STORed, then most likely the source file has changed, and it would be unsafe to restart the file transfer.
STOReを再開するのを試みるとき、User FTPは部分的にわたっているファイルの変更時間を発見するMDTMコマンドを使用できます。 それがSTORedであろうとしているファイルの変更時間より古いなら、たぶん、ソースファイルは変化しました、そして、ファイル転送を再開するのは危険でしょう。
Hethmon Standards Track [Page 8] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[8ページ]。
Note that using MLST (described below), where available, can provide this information and much more, thus giving an even better indication that a file has changed and that restarting a transfer would not give valid results.
MLST(以下で、説明される)を使用するとこの情報とさらに多くを入手できるところに提供できることに注意してください、その結果、ファイルが変化して、転送を再開する場合有効な結果が与えられないだろうというさらに良い指示を与えます。
Note that this is applicable to any RESTart attempt, regardless of the mode of the file transfer.
これがファイル転送の方法にかかわらずどんなRESTart試みにも適切であることに注意してください。
3.1. Syntax
3.1. 構文
The syntax for the MDTM command is:
MDTMコマンドのための構文は以下の通りです。
mdtm = "MdTm" SP pathname CRLF
mdtmは"MdTm"SPパス名CRLFと等しいです。
As with all FTP commands, the "MDTM" command label is interpreted in a case-insensitive manner.
すべてのFTPコマンドのように、"MDTM"コマンドラベルは大文字と小文字を区別しない方法で解釈されます。
The "pathname" specifies an object in the NVFS that may be the object of a RETR command. Attempts to query the modification time of files that exist but are unable to be retrieved may generate an error- response, or can result in a positive response carrying a time-val with an unspecified value, the choice being made by the server-PI.
「パス名」はRETRコマンドの目的であるかもしれないNVFSの物を指定します。 存在していますが、検索できないファイルの変更時間について質問する試みは、誤り応答を発生させるかもしれないか、または不特定の値(サーバ-PIによってされる選択)で時間-valを運ぶ積極的な応答をもたらすことができます。
The server-PI will respond to the MDTM command with a 213 reply giving the last modification time of the file whose pathname was supplied, or a 550 reply if the file does not exist, the modification time is unavailable, or some other error has occurred.
ファイルが存在していないか、変更時間が入手できないか、またはある他の誤りが発生したなら、213回答がパス名が供給されたファイルの最後の変更時間、または550回答を与えていて、サーバ-PIはMDTMコマンドに応じるでしょう。
mdtm-response = "213" SP time-val CRLF /
error-response
mdtm-応答は「213」SP時間ヴァル誤りCRLF/応答と等しいです。
Note that when the 213 response is issued, that is, when there is no error, the format MUST be exactly as specified. Multi-line responses are not permitted.
すなわち、誤りが全くないとき、213応答が発行されるとき、ちょうど指定されるとして形式があるに違いないことに注意してください。 マルチ線応答は受入れられません。
3.2. Error Responses
3.2. 誤り応答
Where the command is correctly parsed but the modification time is not available, either because the pathname identifies no existing entity or because the information is not available for the entity named, then a 550 reply should be sent. Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in [3]. Various 4xy replies are also possible in appropriate circumstances.
コマンドが正しく分析されますが、変更時間が入手できないところに、そして、パス名がどんな既存の実体も特定しないか、または情報が指定された実体に利用可能でないので、550回答を送るべきです。 正しくコマンドを分析できないところに、[3]で指定されるように500か501回答を送るべきです。 また、様々な4xy回答も適切な事情で可能です。
Hethmon Standards Track [Page 9] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[9ページ]。
3.3. FEAT Response for MDTM
3.3. MDTMのための功績応答
When replying to the FEAT command [6], a server-FTP process that supports the MDTM command MUST include a line containing the single word "MDTM". This MAY be sent in upper or lower case or a mixture of both (it is case insensitive), but SHOULD be transmitted in upper case only. That is, the response SHOULD be:
FEATコマンド[6]に答えるとき、MDTMコマンドをサポートするサーバFTPの過程は一語"MDTM"を含む線を含まなければなりません。 伝えられたコネが大文字専用であったなら上側の、または、低いケースかしかし、両方(それは大文字と小文字を区別しない)の混合物、SHOULDでこれを送るかもしれません。 それはそうであり、応答はSHOULDです。いてください:
C> Feat
S> 211- <any descriptive text>
S> ...
S> MDTM
S> ...
S> 211 End
C>功績S>211<はどんな説明文>S>です…。 S>MDTM S>… S>211エンド
The ellipses indicate place holders where other features may be included, but are not required. The one-space indentation of the feature lines is mandatory [6].
楕円は他の特徴が含まれるかもしれませんが、必要でない場所所有者を示します。 ハイライト線の1スペースの刻み目は義務的な[6]です。
3.4. MDTM Examples
3.4. MDTMの例
If we assume the existence of three files, A B and C, a directory D, two files with names that end with the string "ile6", and no other files at all, then the MDTM command may behave as indicated. The "C>" lines are commands from user-PI to server-PI, the "S>" lines are server-PI replies.
私たちが3個のファイルの存在を仮定するか、そして、A BとC、ディレクトリD、ひもで終わる名前がある2個のファイルが「示されるように、振る舞ile6"が命令しますが、次に、MDTMの他のどんなファイルも命令しないするかもしれない」。 ユーザパイからサーバパイまで「C>」線がコマンドである、「S>」線はサーバパイ回答です。
C> MDTM A
S> 213 19980615100045.014
C> MDTM B
S> 213 19980615100045.014
C> MDTM C
S> 213 19980705132316
C> MDTM D
S> 550 D is not retrievable
C> MDTM E
S> 550 No file named "E"
C> mdtm file6
S> 213 19990929003355
C> MdTm 19990929043300 File6
S> 213 19991005213102
C> MdTm 19990929043300 file6
S> 550 19990929043300 file6: No such file or directory.
C>MDTM A S>213 19980615100045.014C>MDTM B S>213 19980615100045.014C>MDTM C S>213 19980705132316C>MDTM D S>、550、D、回収可能なC>MDTM E S>550が「E」C>mdtm file6 S>213 19990929003355C>MdTm19990929043300File6 S>213 19991005213102C>MdTm19990929043300file6 S>といわないファイルである、全く550、19990929043300file6、: そのようなファイルかディレクトリでない。
From that we can conclude that both A and B were last modified at the same time (to the nearest millisecond), and that C was modified 20 days and several hours later.
それから、私たちは、AとBの両方が同時に(最も近いミリセカンドに)、最後に変更されて、Cが20日間と数時間後に変更されたと結論を下すことができます。
Hethmon Standards Track [Page 10] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[10ページ]。
The times are in GMT, so file A was modified on the 15th of June, 1998, at approximately 11am in London (summer time was then in effect), or perhaps at 8pm in Melbourne, Australia, or at 6am in New York. All of those represent the same absolute time, of course. The location where the file was modified, and consequently the local wall clock time at that location, is not available.
グリニッジ標準時に、回があるので、ファイルAはメルボルン(オーストラリア)、またはニューヨークのロンドン(次に、夏場は有効であった)、または恐らく1998年6月15日午前11時頃午後8時午前6時に変更されました。 ものがすべて、同じ絶対時間を表す、もちろん。 ファイルが変更された位置、およびその結果その位置の地方の柱時計時間は空いていません。
There is no file named "E" in the current directory, but there are files named both "file6" and "19990929043300 File6". The modification times of those files were obtained. There is no file named "19990929043300 file6".
カレントディレクトリの中に「E」というファイルが全くありませんが、指定されたファイルの両方がある、「file6"と「19990929043300File6"。」 それらのファイルの変更倍を得ました。 「19990929043300file6"」というファイルが全くありません。
4. File SIZE
4. ファイルサイズ
The FTP command, SIZE OF FILE (SIZE), is used to obtain the transfer size of a file from the server-FTP process. This is the exact number of octets (8 bit bytes) that would be transmitted over the data connection should that file be transmitted. This value will change depending on the current STRUcture, MODE, and TYPE of the data connection or of a data connection that would be created were one created now. Thus, the result of the SIZE command is dependent on the currently established STRU, MODE, and TYPE parameters.
FTPコマンド(SIZE OF FILE(SIZE))は、サーバFTPプロセスからファイルの転送サイズを得るのに使用されます。 これはそのファイルが送られるならデータ接続の上に伝えられる八重奏(8ビットのバイト)のはっきりした数です。 作成されているのが、今作成されたものであったということである接続かデータ接続に関するデータの現在のSTRUcture、MODE、およびTYPEによって、この値は変化するでしょう。 したがって、SIZEコマンドの結果は現在確立したSTRU、MODE、およびTYPEパラメタに依存しています。
The SIZE command returns how many octets would be transferred if the file were to be transferred using the current transfer structure, mode, and type. This command is normally used in conjunction with the RESTART (REST) command when STORing a file to a remote server in STREAM mode, to determine the restart point. The server-PI might need to read the partially transferred file, do any appropriate conversion, and count the number of octets that would be generated when sending the file in order to correctly respond to this command. Estimates of the file transfer size MUST NOT be returned; only precise information is acceptable.
SIZEコマンドはファイルが経常移転構造を使用することで移すことであるならいくつの八重奏を移すか、そして、モード、およびタイプを返します。 STREAMモードによるリモートサーバへのSTORing aファイルであるときに、通常、このコマンドは、再開ポイントを決定するのにRESTART(REST)コマンドに関連して使用されます。 サーバ-PIは部分的にわたっているファイルを読んで、どんな適切な変換もして、正しくこのコマンドに応じるためにファイルを送るとき生成される八重奏の数を数える必要があるかもしれません。 ファイル転送サイズの見積りを返してはいけません。 正確な情報だけが許容できます。
4.1. Syntax
4.1. 構文
The syntax of the SIZE command is:
SIZEコマンドの構文は以下の通りです。
size = "Size" SP pathname CRLF
サイズは「サイズ」SPパス名CRLFと等しいです。
The server-PI will respond to the SIZE command with a 213 reply giving the transfer size of the file whose pathname was supplied, or an error response if the file does not exist, the size is unavailable, or some other error has occurred. The value returned is in a format suitable for use with the RESTART (REST) command for mode STREAM, provided the transfer mode and type are not altered.
ファイルが存在していないか、サイズが入手できないか、またはある他の誤りが発生したなら、213回答がパス名が供給されたファイルの転送サイズ、または誤り応答を与えていて、サーバ-PIはSIZEコマンドに応じるでしょう。 RESTART(REST)コマンドによってモードSTREAMで使用に適した形式には返された値があります、転送モードとタイプが変更されないなら。
Hethmon Standards Track [Page 11] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[11ページ]。
size-response = "213" SP 1*DIGIT CRLF /
error-response
サイズ応答は「213」SP1*ケタ誤りCRLF/応答と等しいです。
Note that when the 213 response is issued, that is, when there is no error, the format MUST be exactly as specified. Multi-line responses are not permitted.
すなわち、誤りが全くないとき、213応答が発行されるとき、ちょうど指定されるとして形式があるに違いないことに注意してください。 マルチ系列応答は受入れられません。
4.2. Error Responses
4.2. 誤り応答
Where the command is correctly parsed but the size is not available, perhaps because the pathname identifies no existing entity or because the entity named cannot be transferred in the current MODE and TYPE (or at all), then a 550 reply should be sent. Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in [3]. The presence of the 550 error response to a SIZE command MUST NOT be taken by the client as an indication that the file cannot be transferred in the current MODE and TYPE. A server may generate this error for other reasons -- for instance if the processing overhead is considered too great. Various 4xy replies are also possible in appropriate circumstances.
コマンドが正しく分析されますが、サイズが入手できないところに、そして、パス名が恐らくどんな既存の実体も特定しないことができないか、現在のMODEとTYPEで指定された実体は移すことができないので(全く)、550回答を送るべきです。 正しくコマンドを分析できないところに、[3]で指定されるように500か501回答を送るべきです。 SIZEコマンドへの550誤り応答の存在は現在のMODEとTYPEでファイルを移すことができないという指示としてクライアントによってみなされてはいけません。 サーバは他の理由でこの誤りを生成するかもしれません--、例えば、処理オーバヘッドがすばらし過ぎると考えられるなら。 また、様々な4xy回答も適切な事情で可能です。
4.3. FEAT Response for SIZE
4.3. サイズのための功績応答
When replying to the FEAT command [6], a server-FTP process that supports the SIZE command MUST include a line containing the single word "SIZE". This word is case insensitive, and MAY be sent in any mixture of upper or lower case, however it SHOULD be sent in upper case. That is, the response SHOULD be:
FEATコマンド[6]に答えるとき、SIZEコマンドをサポートするサーバFTPプロセスは一語「サイズ」を含む系列を含まなければなりません。 この知らせを大文字と小文字を区別しなく、しかしながら、上側の、または、低いケース、それのどんな混合物の中にも送るかもしれない、SHOULD、大文字の中で送ってください。 それはそうであり、応答はSHOULDです。いてください:
C> FEAT
S> 211- <any descriptive text>
S> ...
S> SIZE
S> ...
S> 211 END
C>FEAT S>211<はどんな説明文>S>です…。 S>サイズS>… S>211エンド
The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [6].
楕円は他の特徴が含まれるかもしれなくて、必要でない場所所有者を示します。 ハイライト線の1スペースの刻み目は義務的な[6]です。
4.4. Size Examples
4.4. サイズの例
Consider a text file "Example" stored on a Unix(TM) server where each end of line is represented by a single octet. Assume the file contains 112 lines, and 1830 octets total. Then the SIZE command would produce:
テキストファイルが各行末がただ一つの八重奏で表されるUnix(TM)サーバに保存された「例」であると考えてください。 ファイルが112の系列、および1830八重奏合計を含むと仮定してください。 次に、SIZEコマンドは作成されるでしょう:
Hethmon Standards Track [Page 12] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[12ページ]。
C> TYPE I
S> 200 Type set to I.
C> size Example
S> 213 1830
C> TYPE A
S> 200 Type set to A.
C> Size Example
S> 213 1942
C>TYPE I S>200TypeはExample S>213 1830C>TYPE A S>200TypeがA.C>Size Example S>213 1942に設定するI.C>サイズにセットしました。
Notice that with TYPE=A the SIZE command reports an extra 112 octets. Those are the extra octets that need to be inserted, one at the end of each line, to provide correct end-of-line semantics for a transfer using TYPE=A. Other systems might need to make other changes to the transfer format of files when converting between TYPEs and MODEs. The SIZE command takes all of that into account.
TYPE=Aと共に、SIZEコマンドが付加的な112の八重奏を報告するのに注意してください。 それらは、挿入される必要がある付加的な八重奏、TYPE=Aを使用することで正しい行末意味論を転送に提供するためにはそれぞれの行の終わりのものです。 他のシステムは、TYPEsとMODEsの間で変換するとき、ファイルの転送形式への他の変更を行う必要があるかもしれません。 SIZEコマンドはそのすべてを考慮に入れます。
Since calculating the size of a file with this degree of precision may take considerable effort on the part of the server-PI, user-PIs should not used this command unless this precision is essential (such as when about to restart an interrupted transfer). For other uses, the "Size" fact of the MLST command (see section 7.5.7) ought be requested.
この度合いの精度があるファイルのサイズがそうするかもしれないと見込んで以来、この精度が不可欠でない場合(いつ中断している転送を再開などになろうとしているかなどの)、サーバ-PI、ユーザ-PIs側のかなりの取り組みがそうするべきである撮影はこのコマンドを使用しませんでした。 他の用途において、MLSTコマンド(セクション7.5.7を見る)の「サイズ」事実は要求されています。
5. Restart of Interrupted Transfer (REST)
5. 中断している転送の再開(休息)
To avoid having to resend the entire file if the file is only partially transferred, both sides need some way to agree on where in the data stream to restart the data transfer.
ファイルを部分的に移すだけであるならファイル全体を再送しなければならないのを避けるなら、両側は、データ転送を再開するためにどこに関してデータ・ストリームで同意するか何らかの方法を必要とします。
The FTP specification [3] includes three modes of data transfer, STREAM, Block, and Compressed. In Block and Compressed modes, the data stream that is transferred over the data connection is formatted, allowing the embedding of restart markers into the stream. The sending DTP can include a restart marker with whatever information it needs to be able to restart a file transfer at that point. The receiving DTP can keep a list of these restart markers, and correlate them with how the file is being saved. To restart the file transfer, the receiver just sends back that last restart marker, and both sides know how to resume the data transfer. Note that there are some flaws in the description of the restart mechanism in STD 9, RFC 959 [3]. See section 4.1.3.4 of RFC 1123 [9] for the corrections.
FTP仕様[3]はデータ転送、STREAM、Block、およびCompressedの3つのモードを含んでいます。 BlockとCompressedモードで、データ接続の上に移されるデータ・ストリームはフォーマットされます、再開マーカーの埋め込みをストリームに許して。 発信しているDTPはそれがその時ファイル転送を再開できるように必要とするどんな情報でも再開マーカーを含むことができます。 受信DTPはこれらの再開マーカーのリストを保って、ファイルがどう保存されているかで彼らを関連させることができます。 ファイル転送を再開するために、受信機はただその最後の再開マーカーを返送します、そして、両側はデータ転送を再開する方法を知っています。 STD9、RFC959[3]の再開メカニズムの記述にはいくつかの欠点があることに注意してください。 セクション4.1を見てください。.3 修正のための.4RFC1123[9]。
Hethmon Standards Track [Page 13] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[13ページ]。
5.1. Restarting in STREAM Mode
5.1. ストリームモードで、再開します。
In STREAM mode, the data connection contains just a stream of unformatted octets of data. Explicit restart markers thus cannot be inserted into the data stream, they would be indistinguishable from data. For this reason, the FTP specification [3] did not provide the ability to do restarts in stream mode. However, there is not really a need to have explicit restart markers in this case, as restart markers can be implied by the octet offset into the data stream.
STREAMモードで、データ接続はまさしくデータの非フォーマットされた八重奏のストリームを含んでいます。 その結果、明白な再開マーカーをデータ・ストリームの中に挿入できないで、彼らはデータから区別がつかないでしょう。 この理由で、仕様[3]がする能力を提供しなかったFTPはストリームモードで再開します。 しかしながら、この場合、明白な再開マーカーがある本当に必要がありません、データ・ストリームの中に相殺された八重奏で再開マーカーを含意できるように。
Because the data stream defines the file in STREAM mode, a different data stream would represent a different file. Thus, an offset will always represent the same position within a file. On the other hand, in other modes than STREAM, the same file can be transferred using quite different octet sequences and yet be reconstructed into the one identical file. Thus an offset into the data stream in transfer modes other than STREAM would not give an unambiguous restart point.
データ・ストリームがSTREAMモードによるファイルを定義するので、異なったデータ・ストリームは異なったファイルを表すでしょう。 したがって、オフセットはファイルの中にいつも同じ位置を表すでしょう。 他方では、STREAM以外のモードで、同じファイルを全く異なった八重奏系列を使用することで移しますが、1個の同じファイルの中に再建できます。 したがって、STREAM以外の転送モードにおけるデータ・ストリームの中へのオフセットは明白な再開ポイントを与えないでしょう。
If the data representation TYPE is IMAGE and the STRUcture is File, for many systems the file will be stored exactly in the same format as it is sent across the data connection. It is then usually very easy for the receiver to determine how much data was previously received, and notify the sender of the offset where the transfer should be restarted. In other representation types and structures more effort will be required, but it remains always possible to determine the offset with finite, but perhaps non-negligible, effort. In the worst case, an FTP process may need to open a data connection to itself, set the appropriate transfer type and structure, and actually transmit the file, counting the transmitted octets.
データ表現TYPEがIMAGEであり、STRUctureがFileであるなら、多くのシステムにおいて、ファイルはちょうどデータ接続の向こう側にそれを送るような同じ形式で保存されるでしょう。 通常、受信機が転送が再開されるべきであるところでどのくらいのデータが以前に受け取られたかを決心して、オフセットについて送付者に通知するのは、その時、非常に簡単です。 他の表現タイプと構造では、より多くの取り組みが必要でしょうが、いつも可能なままで、有限な、しかし、恐らく非取るにたらない取り組みがあるオフセットを決定するのは残っています。 最悪の場合には、FTPプロセスは、データ接続をそれ自体に開くのが必要であり、適切な転送タイプと構造を設定して、実際にファイルを送るかもしれません、伝えられた八重奏を数えて。
If the user-FTP process is intending to restart a retrieve, it will directly calculate the restart marker and send that information in the RESTart command. However, if the user-FTP process is intending to restart sending the file, it needs to be able to determine how much data was previously sent, and correctly received and saved. A new FTP command is needed to get this information. This is the purpose of the SIZE command, as documented in section 4.
ユーザFTPプロセスがaが検索する再開つもりであるいことであると、それは、直接再開マーカーについて計算して、RESTartコマンドにおけるその情報を送るでしょう。 しかしながら、ユーザFTPプロセスがファイルを送りながら再開するつもりであるなら、それは、データが以前にいくらに送られて、受け取られて、正しく保存されたかを決定できる必要があります。 新しいFTPコマンドが、この情報を得るのに必要です。 これはセクション4で記録されるようにSIZEコマンドの目的です。
5.2. Error Recovery and Restart
5.2. エラー回復と再開
STREAM mode transfers with FILE STRUcture may be restarted even though no restart marker has been transferred in addition to the data itself. This is done by using the SIZE command, if needed, in combination with the RESTART (REST) command, and one of the standard file transfer commands.
データ自体に加えて再開マーカーを全く移していませんが、FILE STRUctureとのSTREAMモード転送を再開するかもしれません。 SIZEコマンドを使用することによって、これをします、必要であるなら、RESTART(REST)コマンド、および標準ファイル転送命令の1つと組み合わせて。
When using TYPE ASCII or IMAGE, the SIZE command will return the number of octets that would actually be transferred if the file were
TYPE ASCIIかIMAGEを使用するとき、SIZEコマンドはファイルがあるなら実際に移される八重奏の数を返すでしょう。
Hethmon Standards Track [Page 14] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[14ページ]。
to be sent between the two systems, i.e., with type IMAGE, the SIZE normally would be the number of octets in the file. With type ASCII, the SIZE would be the number of octets in the file including any modifications required to satisfy the TYPE ASCII CR-LF end-of-line convention.
すなわち、2台のシステム、タイプIMAGEで送るために、通常、SIZEはファイルの八重奏の数でしょう。 タイプASCIIで、SIZEはTYPE ASCII CR-LF行末規約を満たすのに必要である変更を含むファイルの八重奏の数でしょう。
5.3. Syntax
5.3. 構文
The syntax for the REST command when the current transfer mode is STREAM is:
経常移転モードがSTREAMであるときに、RESTコマンドのための構文は以下の通りです。
rest = "Rest" SP 1*DIGIT CRLF
=「休息」SP1*DIGIT CRLFを休ませてください。
The numeric value gives the number of octets of the immediately- following transfer to not actually send, effectively causing the transmission to be restarted at a later point. A value of zero effectively disables restart, causing the entire file to be transmitted. The server-PI will respond to the REST command with a 350 reply, indicating that the REST parameter has been saved, and that another command, which should be either RETR or STOR, should then follow to complete the restart.
数値は実際に発信しないようにすぐに次の転送の八重奏の数を与えます、事実上、トランスミッションが後のポイントで再開されることを引き起こして。 ファイル全体が送られることを引き起こして、事実上、ゼロの値は再開を無効にします。 サーバ-PIは350回答でRESTコマンドに応じるでしょう、RESTパラメタが保存されて、次に、別のコマンド(RETRかSTORのどちらかであるべきである)が再開を終了するために続くべきであるのを示して。
rest-response = "350" SP *TCHAR CRLF /
error-response
休息応答は「350」誤りSP*TCHAR CRLF/応答と等しいです。
Server-FTP processes may permit transfer commands other than RETR and STOR, such as APPE and STOU, to complete a restart; however, this is not recommended. STOU (store unique) is undefined in this usage, as storing the remainder of a file into a unique file name is rarely going to be useful. If APPE (append) is permitted, it MUST act identically to STOR when a restart marker has been set. That is, in both cases, octets from the data connection are placed into the file at the location indicated by the restart marker value.
APPEやSTOUなどのRETRとSTORを除いて、プロセスが転送を可能にするかもしれないサーバFTPは再開を終了すると命令します。 しかしながら、これは推薦されません。 STOU(店ユニークな)はこの用法で未定義です、ユニークなファイル名としてファイルの残りを保存するのがめったに役に立たないので。 再開マーカーが用意ができていたとき、APPE(追加する)が受入れられるなら、それは同様にSTORに行動しなければなりません。 すなわち、どちらの場合も、データ接続からの八重奏は再開マーカー価値によって示された位置のファイルの中に置かれます。
The REST command is intended to complete a failed transfer. Use with RETR is comparatively well defined in all cases, as the client bears the responsibility of merging the retrieved data with the partially retrieved file. It may choose to use the data obtained other than to complete an earlier transfer, or to re-retrieve data that had been retrieved before. With STOR, however, the server must insert the data into the file named. The results are undefined if a client uses REST to do other than restart to complete a transfer of a file that had previously failed to completely transfer. In particular, if the restart marker set with a REST command is not at the end of the data currently stored at the server, as reported by the server, or if insufficient data are provided in a STOR that follows a REST to extend the destination file to at least its previous size, then the effects are undefined.
RESTコマンドが失敗した転送を終了することを意図します。 RETRとの使用はすべての場合で比較的よく定義されます、クライアントが部分的に検索されたファイルに検索されたデータを合併する責任を担うとき。 それは、以前の転送を終了するのを除いて、得られたデータを使用するか、または以前検索されたことがあったデータを再検索するのを選ぶかもしれません。 しかしながら、STORと共に、サーバは指定されたファイルの中にデータを挿入しなければなりません。 クライアントが再開を除いて、転送を終了するためにするのにRESTを使用するなら、結果は以前に完全に移したというわけではなかったファイルで未定義です。 RESTコマンドで用意ができている再開マーカーが現在サーバで保存されているデータの終わりにないか、サーバで報告するか、または目的ファイルを少なくとも前のサイズまで広げるためにRESTに続くSTORに不十分なデータを提供するなら、効果は特に、未定義です。
Hethmon Standards Track [Page 15] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[15ページ]。
The REST command must be the last command issued before the data transfer command that is to cause a restarted, rather than a complete, file transfer. The effect of issuing a REST command at any other time is undefined. The server-PI may react to a badly positioned REST command by issuing an error response to the following command, not being a restartable data transfer command, or it may save the restart value and apply it to the next data transfer command, or it may silently ignore the inappropriate restart attempt. Because of this, a user-PI that has issued a REST command, but that has not successfully transmitted the following data transfer command for any reason, should send another REST command before the next data transfer command. If that transfer is not to be restarted, then "REST 0" should be issued.
RESTコマンドはaを引き起こすことになっているデータ転送コマンドがaよりむしろ完全な状態で再開する前に発行された持続コマンドであるに違いありません、ファイル転送。 他の時ならいつでもRESTコマンドを発行するという効果は未定義です。 サーバ-PIは以下のコマンドへの誤り応答を発行することによって、ひどく置かれたRESTコマンドに反応するかもしれません、再開可能データ転送でないことで命令するか、再開が値であると保存して、次のデータ転送コマンドにそれを適用するかもしれません、それは静かに不適当な再開試みを無視するかもしれません。 これのために、RESTコマンドを発行しましたが、どんな理由でも首尾よく以下のデータ転送コマンドを伝えていないユーザ-PIは次のデータ転送コマンドの前に別のRESTコマンドを送るはずです。 その転送が再開されないつもりであるなら、そして、「0インチが発行されるべきである休息。」です。
An error response will follow a REST command only when the server does not implement the command, or when the restart marker value is syntactically invalid for the current transfer mode (e.g., in STREAM mode, something other than one or more digits appears in the parameter to the REST command). Any other errors, including such problems as restart marker out of range, should be reported when the following transfer command is issued. Such errors will cause that transfer request to be rejected with an error indicating the invalid restart attempt.
サーバが単にコマンドを実装しないか、または経常移転モードには、再開マーカー価値がシンタクス上無効であるときに、誤り応答はRESTコマンドに続くでしょう(例えば、STREAMモードで、複数のケタ以外の何かがパラメタにRESTコマンドに現れます)。 以下の転送命令を発行するとき、範囲からマーカーを再出発するような問題を含むいかなる他の誤りも報告するべきです。 そのような誤りは誤りが無効の再開試みを示していて拒絶されるというその転送要求を引き起こすでしょう。
5.4. FEAT Response for REST
5.4. 休息のための功績応答
Where a server-FTP process supports RESTart in STREAM mode, as specified here, it MUST include, in the response to the FEAT command [6], a line containing exactly the string "REST STREAM". This string is not case sensitive, but it SHOULD be transmitted in upper case. Where REST is not supported at all or supported only in block or compressed modes, the REST line MUST NOT be included in the FEAT response. Where required, the response SHOULD be:
サーバFTPプロセスがSTREAMモードでRESTartをサポートするところでは、ここで指定されるように、それはFEATコマンド[6]への応答にちょうどストリング「休息ストリーム」を含む系列を含まなければなりません。 このストリングは大文字と小文字を区別していなくて、唯一のそれはSHOULDです。大文字で、伝えられます。 RESTが全くサポートもされませんし、単にブロックか圧縮されたモードでサポートもされないところでは、FEAT応答にREST系列を含んではいけません。 どこが必要であるか、そして、応答はSHOULDです。いてください:
C> feat
S> 211- <any descriptive text>
S> ...
S> REST STREAM
S> ...
S> 211 end
C>功績S>211<はどんな説明文>S>です…。 S>はストリームS>を休ませています… S>211エンド
The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory [6].
楕円は他の特徴が含まれるかもしれなくて、必要でない場所所有者を示します。 ハイライト線の1スペースの刻み目は義務的な[6]です。
Hethmon Standards Track [Page 16] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[16ページ]。
5.5. REST Example
5.5. 例を休ませてください。
Assume that the transfer of a largish file has previously been interrupted after 802816 octets had been received, that the previous transfer was with TYPE=I, and that it has been verified that the file on the server has not since changed.
802816の八重奏を受けた後に以前に、やや大きいファイルの転送を中断して、前の転送がTYPE=Iと共にあって、サーバのファイルが以来変化していないことを確かめたと仮定してください。
C> TYPE I
S> 200 Type set to I.
C> PORT 127,0,0,1,15,107
S> 200 PORT command successful.
C> REST 802816
S> 350 Restarting at 802816. Send STORE or RETRIEVE
C> RETR cap60.pl198.tar
S> 150 Opening BINARY mode data connection
[...]
S> 226 Transfer complete.
C>TYPE I S>200TypeはI.C>PORT127、0、0、1、15,107秒間の>にうまくいった状態で200PORTコマンドを設定します。 C>は802816秒間、802816で再開する>350を休ませています。 ストアかRETRIEVE C>RETR cap60.pl198.tar S>150Opening BINARYにモードデータ接続[…]を送ってください。 S>226は完全な状態で移されます。
6. A Trivial Virtual File Store (TVFS)
6. 些細な仮想のファイルストア(TVFS)
Traditionally, FTP has placed almost no constraints upon the file store (NVFS) provided by a server. This specification does not alter that. However, it has become common for servers to attempt to provide at least file system naming conventions modeled loosely upon those of the UNIX(TM) file system. This is a tree-structured file system, built of directories, each of which can contain other directories, or other kinds of files, or both. Each file and directory has a name relative to the directory that contains it, except for the directory at the root of the tree, which is contained in no other directory, and hence has no name of its own.
伝統的に、FTPはサーバによって提供されたファイル店(NVFS)に規制をほとんど全く置いていません。この仕様はそれを変更しません。 しかしながら、サーバが、少なくとも緩くUNIX(TM)ファイルシステムのものに倣われたファイルシステム命名規則を供給するのを試みるのが一般的になりました。 これはディレクトリで組立てられたそれのそれぞれが他のディレクトリ、または他の種類のファイル、または両方を含むことができるツリー構造のファイルシステムです。 各ファイルとディレクトリには、それを含むディレクトリに比例して名前があります、他のどんなディレクトリにも含まれていなくて、またしたがって、それ自身の名前を全く持っていない木の根のディレクトリを除いて。
That which has so far been described is perfectly consistent with the
standard FTP NVFS and access mechanisms. The "CWD" command is used
to move from one directory to an embedded directory. "CDUP" may be
provided to return to the parent directory, and the various file
manipulation commands ("RETR", "STOR", the rename commands, etc.) are
used to manipulate files within the current directory.
今までのところ説明されるそれは標準のFTP NVFSとアクセス機構と完全に一致しています。"CWD"コマンドは、1つのディレクトリから埋め込まれたディレクトリまで移行するのに使用されます。 親ディレクトリに戻るために"CDUP"を提供するかもしれません、そして、カレントディレクトリの中でファイルを操作するのに、様々なファイル操作命令("RETR"、"STOR"、改名コマンドなど)を使用します。
However, it is often useful to be able to reference files other than by changing directories, especially as FTP provides no guaranteed mechanism to return to a previous directory. The Trivial Virtual File Store (TVFS), if implemented, provides that mechanism.
しかしながら、変化ディレクトリ以外の参照ファイルにできるのはしばしば役に立ちます、特にFTPが前のディレクトリに戻るために保証されたメカニズムを全く提供しないように。 実装されるなら、Trivial Virtual Fileストア(TVFS)はそのメカニズムを提供します。
Hethmon Standards Track [Page 17] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[17ページ]。
6.1. TVFS File Names
6.1. TVFSファイル名
Where a server implements the TVFS, no elementary file name shall contain the character "/". Where the underlying natural file store permits files, or directories, to contain the "/" character in their names, a server-PI implementing TVFS must encode that character in some manner whenever file or directory names are being returned to the user-PI, and reverse that encoding whenever such names are being accepted from the user-PI.
「サーバがTVFSを実装するところでは、どんな基本のファイル名もキャラクタを含まないものとする」という/、」 「基本的な自然なファイル店がファイル、またはディレクトリを可能にするところ、含む、」 」 それらの名前のキャラクタ、TVFSを実装するサーバパイがそうしなければならない/はファイルしてください。さもないと、ユーザパイにディレクトリ名を返しているときはいつも、何らかの方法でそのキャラクタをコード化して、ユーザパイからそのような名前を受け入れているときはいつも、そのコード化を逆にします。
The encoding method to be used is not specified here. Where some other character is illegal in file and directory names in the underlying file store, a simple transliteration may be sufficient. Where there is no suitable substitute character a more complex encoding scheme, possibly using an escape character, is likely to be required.
使用されるべきコード化メソッドはここで指定されません。 ある他のキャラクタが基本的なファイル店でファイルとディレクトリ名で不法であるところでは、簡単な音訳は十分であるかもしれません。 どんな適当な置換え文字もないところでは、ことによると拡張文字を使用して、より複雑なコード化体系が必要でありそうです。
With the one exception of the unnamed root directory, a TVFS file name may not be empty. That is, all other file names contain at least one character.
無名ルートディレクトリの1つの例外で、TVFSファイル名は空でないかもしれません。 他のすなわちすべてのファイル名が少なくとも1文字を含んでいます。
With the sole exception of the "/" character, any valid IS10646 character [10] may be used in a TVFS file name. When transmitted, file name characters are encoded using the UTF-8 encoding [2]. Note that the two-character sequence CR LF occurring in a file name will make that name impossible to transmit over a data connection. Consequently, it should be avoided, or if that is impossible to achieve, it MUST be encoded in some reversible way.
「唯一の例外、」 /、」 キャラクタ、どんな有効なIS10646キャラクタ[10]もTVFSファイル名で使用されるかもしれません。 伝えられると、ファイル名キャラクタは、[2]をコード化するUTF-8を使用することでコード化されます。 ファイル名に起こる2キャラクタの系列CR LFが、データ接続の上でその名前を伝えるのを不可能にすることに注意してください。 その結果、それが避けられるべきですか、またはそれは達成するのが不可能であるなら、何らかのリバーシブルの方法でそれをコード化しなければなりません。
6.2. TVFS Pathnames
6.2. TVFSパス名
A TVFS "Pathname" combines the file or directory name of a target file or directory, with the directory names of zero or more enclosing directories, so as to allow the target file or directory to be referenced other than when the server's "current working directory" is the directory directly containing the target file or directory.
TVFS「パス名」は目標ファイルかディレクトリのファイルかディレクトリ名を結合します、ゼロのディレクトリ名か目標ファイルかディレクトリを含んでいて、サーバの「現在の働くディレクトリ」が直接ディレクトリである時を除いて、目標ファイルかディレクトリが参照をつけられるのを許容するためにディレクトリをさらに同封するのに。
By definition, every TVFS file or directory name is also a TVFS pathname. Such a pathname is valid to reference the file from the directory containing the name, that is, when that directory is the server-FTP's current working directory.
定義上、また、あらゆるTVFSファイルかディレクトリ名がTVFSパス名です。 そのようなパス名は名前を含むディレクトリからのファイルに参照をつけるために有効です、すなわち、そのディレクトリがサーバFTPの現在の働くディレクトリであるときに。
Other TVFS pathnames are constructed by prefixing a pathname by a name of a directory from which the path is valid, and separating the two with the "/" character. Such a pathname is valid to reference the file or directory from the directory containing the newly added directory name.
「他のTVFSパス名が経路が有効であるディレクトリの名前のパス名を前に置きながら組み立てられて、二人を引き離している、」 /、」 キャラクタ。 そのようなパス名は、新たに加えられたディレクトリ名を含むディレクトリからのファイルかディレクトリに参照をつけるために有効です。
Hethmon Standards Track [Page 18] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[18ページ]。
Where a pathname has been extended to the point where the directory added is the unnamed root directory, the pathname will begin with the "/" character. Such a path is known as a fully qualified pathname. Fully qualified paths may, obviously, not be further extended, as, by definition, no directory contains the root directory. Being unnamed, it cannot be represented in any other directory. A fully qualified pathname is valid to reference the named file or directory from any location (that is, regardless of what the current working directory may be) in the virtual file store.
「加えられたディレクトリが無名ルートディレクトリである、パス名が始まるポイントにパス名を広げてあるところ、」 /、」 キャラクタ。 そのような経路は完全に適切なパス名として知られています。 どんなディレクトリも定義上ルートディレクトリを含んでいないのに従って、完全に適切な経路は明らかにさらに広げられないかもしれません。 無名であり、いかなる他のディレクトリにもそれを表すことができません。 完全に適切なパス名は仮想のファイル店のどんな位置(すなわち、現在の働くディレクトリが何であるかもしれないかにかかわらず)からの命名がファイルする参照かディレクトリにも有効です。
Any pathname that is not a fully qualified pathname may be referred to as a "relative pathname" and will only correctly reference the intended file when the current working directory of the server-FTP is a directory from which the relative pathname is valid.
サーバFTPの現在の働くディレクトリが相対的なパス名が有効であるディレクトリであるときにだけ、完全な適切なパス名であるというわけではないどんなパス名も、「相対的なパス名」と呼ばれるかもしれなくて、正しく意図しているファイルに参照をつけるでしょう。
As a special case, the pathname "/" is defined to be a fully qualified pathname referring to the root directory. That is, the root directory does not have a directory (or file) name, but does have a pathname. This special pathname may be used only as is as a reference to the root directory. It may not be combined with other pathnames using the rules above, as doing so would lead to a pathname containing two consecutive "/" characters, which is an undefined sequence.
「特殊なものとして、パス名、」 /、」 ルートディレクトリを参照する完全に適切なパス名になるように、定義されます。 すなわち、ルートディレクトリには、ディレクトリ(ファイルする)名を持っていませんが、パス名があります。 この特別なパス名はルートディレクトリの参照としてそのままでだけ使用されるかもしれません。 「それは上で規則を使用する他のパス名に結合されないかもしれません、そうするのが」 /をaパス名含んでいるtwo連続しているのに導くだろうというとき」キャラクタ、未定義の系列がどれですか?
6.2.1. Notes
6.2.1. 注意
+ It is not required, or expected, that there be only one fully
qualified pathname that will reference any particular file or
directory.
+は、そこでそれを必要でなかった、または予想しませんでした。1つだけがどんな特定のファイルやディレクトリにも参照をつけるパス名に完全に資格を与えたということになってください。
+ As a caveat, though the TVFS file store is basically tree
structured, there is no requirement that any file or directory
have only one parent directory.
警告としての+、TVFSファイル店は基本的に構造化された木ですが、どんなファイルやディレクトリにも1つの親ディレクトリしかないという要件が全くありません。
+ As defined, no TVFS pathname will ever contain two consecutive "/"
characters. Such a name is not illegal however, and may be
defined by the server for any purpose that suits it. Clients
implementing this specification should not assume any semantics
for such names.
「定義されるとしての+、どんなTVFSパス名も2を含まない、連続、」 /、」 キャラクタ。 そのような名前は、しかしながら、不法でなく、それに合うどんな目的のためにもサーバによって定義されるかもしれません。 この仕様を履行するクライアントはそのような名前のために少しの意味論も仮定するべきではありません。
+ Similarly, other than the special case path that refers to the
root directory, no TVFS pathname constructed as defined here will
ever end with the "/" character. Such names are also not illegal,
but are undefined.
「同様に、特別なケース以外のルートディレクトリを参照する経路、ここで定義されるように構成されなかったTVFSパス名が全くそうする+が終わる、」 /、」 キャラクタ。 そのような名前は、また、不法ではありませんが、未定義です。
+ While any legal IS10646 character is permitted to occur in a TVFS
file or directory name, other than "/", server FTP implementations
are not required to support all possible IS10646 characters. The
「どんな法的なIS10646キャラクタである間も、+がTVFSファイルかディレクトリ名に起こるのが許容されています、」 /を除いて」、サーバFTP実装。すべての可能なIS10646がキャラクタであるとサポートするのが必要ではありません。 The
Hethmon Standards Track [Page 19] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[19ページ]。
subset supported is entirely at the discretion of the server. The
case (where it exists) of the characters that make up file,
directory, and pathnames may be significant. Unless determined
otherwise by means unspecified here, clients should assume that
all such names are comprised of characters whose case is
significant. Servers are free to treat case (or any other
attribute) of a name as irrelevant, and hence map two names that
appear to be distinct onto the same underlying file.
完全にサーバの裁量にはサポートされた部分集合があります。ファイル、ディレクトリ、およびパス名を作るキャラクタのケース(それが存在するところ)は重要であるかもしれません。 別の方法でここで不特定の手段で決定しない場合、クライアントは、そのようなすべての名前がケースが重要であるキャラクタから成ると仮定するべきです。 サーバは、無関係であるとして名前に関するケース(または、いかなる他の属性も)を扱って、したがって、無料で同じ基本的なファイルに異なるように見える2つの名前を写像できます。
+ There are no defined "magic" names, like ".", ".." or "C:".
Servers may implement such names, with any semantics they choose,
but are not required to do so.
「+ そこでは、定義されなかった「名前の、そして、同様の魔法」がそうです」、」、」、「C:」 サーバは、彼らが選ぶどんな意味論でもそのような名前を実装するかもしれませんが、そうするのに必要ではありません。
+ TVFS imposes no particular semantics or properties upon files,
guarantees no access control schemes, or any of the other common
properties of a file store. Only the naming scheme is defined.
+ TVFSはファイル店の他の通有性のファイル、アクセスコントロールが全く計画されないという保証、またはどれかにどんな特定の意味論も特性も課しません。 命名体系だけが定義されます。
6.3. FEAT Response for TVFS
6.3. TVFSのための功績応答
In response to the FEAT command [6] a server that wishes to indicate support for the TVFS as defined here will include a line that begins with the four characters "TVFS" (in any case, or mixture of cases, upper case is not required). Servers SHOULD send upper case.
FEATコマンド[6]に対応して、ここで定義されるようにTVFSのサポートを示したがっているサーバは4キャラクタ「TVFS」と共に始まる系列を含むでしょう(どんなケース、またはケースの混合物でも、大文字は必要ではありません)。 サーバSHOULDは大文字を送ります。
Such a response to the FEAT command MUST NOT be returned unless the server implements TVFS as defined here.
サーバがここで定義されるようにTVFSを実装しない場合、FEATコマンドへのそのような応答を返してはいけません。
Later specifications may add to the TVFS definition. Such additions should be notified by means of additional text appended to the TVFS feature line. Such specifications, if any, will define the extra text.
後の仕様はTVFS定義の一助となるかもしれません。 そのような追加はTVFSハイライト線に追加された追加テキストによって通知されるべきです。 もしあればそのような仕様は付加的なテキストを定義するでしょう。
Until such a specification is defined, servers should not include anything after "TVFS" in the TVFS feature line. Clients, however, should be prepared to deal with arbitrary text following the four defined characters, and simply ignore it if unrecognized.
TVFSの特徴の「TVFS」が立ち並んだ後にそのような仕様が定義されるまで、サーバは何も含むべきではありません。 認識されていないなら、しかしながら、クライアントは、4つの定義されたキャラクタに続いて、任意のテキストに対処するように準備されて、単にそれを無視するべきです。
A typical response to the FEAT command issued by a server implementing only this specification would be:
この仕様だけを履行するサーバによって発行されたFEATコマンドへの典型的反応は以下の通りでしょう。
C> feat
S> 211- <any descriptive text>
S> ...
S> TVFS
S> ...
S> 211 end
C>功績S>211<はどんな説明文>S>です…。 S>TVFS S>… S>211エンド
Hethmon Standards Track [Page 20] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[20ページ]。
The ellipses indicate place holders where other features may be included, but are not required. The one-space indentation of the feature lines is mandatory [6] and is not counted as one of the first four characters for the purposes of this feature listing.
楕円は他の特徴が含まれるかもしれませんが、必要でない場所所有者を示します。 ハイライト線の1スペースの刻み目は、義務的な[6]であり、この特徴リストの目的のために最初の4つのキャラクタのひとりにみなされません。
The TVFS feature adds no new commands to the FTP command repertoire.
TVFSの特徴はどんな新しいコマンドもFTPコマンドレパートリーに追加しません。
6.4. OPTS for TVFS
6.4. TVFSを選びます。
There are no options in this TVFS specification, and hence there is no OPTS command defined.
このTVFS仕様にはオプションが全くありません、そして、したがって、コマンドが定義したOPTSが全くありません。
6.5. TVFS Examples
6.5. TVFSの例
Assume a TVFS file store is comprised of a root directory, which contains two directories (A and B) and two non-directory files (X and Y). The A directory contains two directories (C and D) and one other file (Z). The B directory contains just two non-directory files (P and Q) and the C directory also two non-directory files (also named P and Q, by chance). The D directory is empty, that is, contains no files or directories. This structure may depicted graphically as...
TVFSファイル店がルートディレクトリから成ると仮定してください。(ルートディレクトリは2つのディレクトリ(AとB)と2個の非ディレクトリファイル(XとY)を含みます)。 Aディレクトリは2つのディレクトリ(CとD)と他の1個のファイル(Z)を含んでいます。 Bディレクトリはちょうど2個の非ディレクトリファイル(PとQ)とCディレクトリを含んでいます、また、2非ディレクトリはファイルされます(また、機会によってPとQと命名されます)。 Dディレクトリは、空であり、すなわち、どんなファイルもディレクトリも含んでいません。 …としてグラフィカルに表現されて、この構造はそうするかもしれません。
(unnamed root)
/ | \ \
/ | \ \
A X B Y
/|\ / \
/ | \ / \
C D Z P Q
/ \
/ \
P Q
(無名根) /| \ \ / | \\はX B Y/です。|\ / \ / | \/\C D Z P Q/\/\P Q
Given this structure, the following fully qualified pathnames exist.
この構造を考えて、以下の完全に適切なパス名は存在しています。
/
/A
/B
/X
/Y
/A/C
/A/D
/A/Z
/A/C/P
/A/C/Q
/B/P
/B/Q
/ /A /B /X /Y /A/C /A/D /A/Z /A/C/P /A/C/Q /B/P /B/Q
Hethmon Standards Track [Page 21] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[21ページ]。
It is clear that none of the paths / /A /B or /A/D refer to the same directory, as the contents of each is different. Nor do any of / /A /A/C or /A/D. However /A/C and /B might be the same directory, there is insufficient information given to tell. Any of the other pathnames (/X /Y /A/Z /A/C/P /A/C/Q /B/P and /B/Q) may refer to the same underlying files, in almost any combination.
経路/ /A /Bか/A/Dのいずれも同じディレクトリを示さないのは、明確です、それぞれのコンテンツが異なっているとき。 / /A /A/Cか/A/Dのいずれもそうしません。 /A/Cと/Bがどのように同じディレクトリであるかもしれなくても、言うために与えられた不十分な情報があります。 他のパス名(/X /Y /A/Z /A/C/P /A/C/Q /B/Pと/B/Q)のどれかは同じ基本的なファイルを示すかもしれません、ほとんどどんな組み合わせでも。
If the current working directory of the server-FTP is /A then the following pathnames, in addition to all the fully qualified pathnames, are valid
サーバFTPの現在の働くディレクトリが/Aであるなら、すべての完全に適切なパス名に加えて、以下のパス名は有効です。
C
D
Z
C/P
C/Q
C D Z C/P C/Q
These all refer to the same files or directories as the corresponding fully qualified path with "/A/" prepended.
"/A/"がある対応する完全に適切な経路がprependedされたとき、これらはすべて、同じファイルかディレクトリを参照します。
That those pathnames all exist does not imply that the TVFS sever will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights.
それらのパス名がすべて存在しているのがTVFSが当然のことが平等の権利であったなら必ず必ず異なったパス名でアクセス権で命名された経路、またはそれに親切ないずれも同じファイルにアクセスする交付金が断ち切る意志を断ち切るのを含意しません。
None of the following relative paths are valid when the current directory is /A
カレントディレクトリが/Aであるときに、以下の相対パスのいずれも有効ではありません。
A
B
X
Y
B/P
B/Q
P
Q
B X Y B/P B/Q P Q
Any of those could be made valid by changing the server-FTP's current working directory to the appropriate directory. Note that the paths "P" and "Q" might refer to different files depending upon which directory is selected to cause those to become valid TVFS relative paths.
サーバFTPの現在の働くディレクトリを適切なディレクトリに変えることによって、それらのいずれも有効にすることができるでしょう。 経路「P」と「Q」がそれらが有効なTVFS相対パスになることをどのディレクトリを引き起こすのが選択されるかによる異なったファイルを示すかもしれないことに注意してください。
Hethmon Standards Track [Page 22] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[22ページ]。
7. Listings for Machine Processing (MLST and MLSD)
7. マシン処理のためのリスト(MLSTとMLSD)
The MLST and MLSD commands are intended to standardize the file and directory information returned by the server-FTP process. These commands differ from the LIST command in that the format of the replies is strictly defined although extensible.
MLSTとMLSDコマンドが情報がサーバFTPプロセスで返したファイルとディレクトリを標準化することを意図します。 これらのコマンドは広げることができますが、回答の書式が厳密に定義されるという点においてLISTコマンドと異なっています。
Two commands are defined, MLST and MLSD. MLST provides data about exactly the object named on its command line, and no others. MLSD, on the other, lists the contents of a directory if a directory is named, otherwise a 501 reply is returned. In either case, if no object is named, the current directory is assumed. That will cause MLST to send a one-line response, describing the current directory itself, and MLSD to list the contents of the current directory.
MLSTとMLSD、2つのコマンドが定義されます。 MLSTはおよそちょうどオブジェクトがコマンドラインにもかかわらず、他のものの上ではなく命名したデータを提供します。 ディレクトリが命名されるなら、MLSDはディレクトリのコンテンツをもう片方に記載します。さもなければ、501回答を返します。 どちらの場合ではも、オブジェクトが全く命名されないなら、カレントディレクトリは想定されます。 それで、MLSTは1系列の応答を送るでしょう、カレントディレクトリのコンテンツを記載するためにカレントディレクトリ自体、およびMLSDについて説明して。
In the following, the term MLSx will be used wherever either MLST or MLSD may be inserted.
以下では、MLSTかMLSDのどちらかがどこに挿入されても、MLSxという用語は使用されるでしょう。
The MLST and MLSD commands also extend the FTP protocol as presented in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow that transmission of 8-bit data over the control connection. Note this is not specifying character sets which are 8-bit, but specifying that FTP implementations are to specifically allow the transmission and reception of 8-bit bytes, with all bits significant, over the control connection. That is, all 256 possible octet values are permitted. The MLSx command allows both UTF-8/Unicode and "raw" forms as arguments, and in responses both to the MLST and MLSD commands, and all other FTP commands which take pathnames as arguments.
また、MLSTとMLSDコマンドはSTD9、RFC959[3]、およびSTD3(コントロール接続の上で8ビットのデータのその伝達を許すRFC1123[9])に提示されるようにFTPプロトコルを広げています。 すべてのビットが重要な状態でコントロール接続の上でこれが8ビットである文字集合を指定するのではなく、8ビットのバイトのFTP実装が明確にトランスミッションを許容することであると指定して、レセプションであることに注意してください。 すなわちすべての256の可能な八重奏値が受入れられます。 MLSxコマンドは議論、およびMLSTとMLSDコマンドへの応答におけるUTF-8/ユニコードと「生」のフォームと議論としてパス名をみなす他のすべてのFTPコマンドの両方を許容します。
7.1. Format of MLSx Requests
7.1. MLSx要求の形式
The MLST and MLSD commands each allow a single optional argument. This argument may be either a directory name or, for MLST only, a file name. For these purposes, a "file name" is the name of any entity in the server NVFS which is not a directory. Where TVFS is supported, any TVFS relative pathname valid in the current working directory, or any TVFS fully qualified pathname, may be given. If a directory name is given then MLSD must return a listing of the contents of the named directory, otherwise it issues a 501 reply, and does not open a data connection. In all cases for MLST, a single set of fact lines (usually a single fact line) containing the information about the named file or directory shall be returned over the control connection, without opening a data connection.
MLSTとMLSDコマンドはそれぞれただ一つの任意の議論を許容します。 MLSTだけのために、この議論は、ディレクトリ名かファイル名のどちらかであるかもしれません。 これらの目的のために、「ファイル名」はディレクトリでないサーバNVFSのどんな実体の名前です。 TVFSがサポートされるところに、現在の働くディレクトリ、またはどんなTVFSでも有効などんなTVFS相対的なパス名も完全にパス名に資格を与えて、与えるかもしれません。 ディレクトリ名を与えるならMLSDが命名されたディレクトリのコンテンツのリストを返さなければならなくて、さもなければ、それは、501回答を発行して、データ接続を開きません。 MLSTのためのすべての場合では、指定されたファイルかディレクトリの情報を含む1セットの事実系列(通常ただ一つの事実系列)をコントロール接続の上に返すものとします、データ接続を開かないで。
If no argument is given then MLSD must return a listing of the contents of the current working directory, and MLST must return a listing giving information about the current working directory itself. For these purposes, the contents of a directory are whatever
議論を全く与えないなら、MLSDは現在の働くディレクトリのコンテンツのリストを返さなければなりません、そして、MLSTは現在の働くディレクトリ自体に関して知らせるリストを返さなければなりません。 これらの目的のために、ディレクトリの中身は何でもです。
Hethmon Standards Track [Page 23] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[23ページ]。
file or directory names (not pathnames) the server-PI will allow to be referenced when the current working directory is the directory named, and which the server-PI desires to reveal to the user-PI. Note that omitting the argument is the only defined way to obtain a listing of the current directory, unless a pathname that represents the directory happens to be known. In particular, there is no defined shorthand name for the current directory. This does not prohibit any particular server-PI implementing such a shorthand.
ファイルかサーバ-PIがサーバ-PIが、現在の働くディレクトリが指定されたディレクトリであるときに、参照をつけられるのを許容して、ユーザ-PIに明らかにすることを望んでいるディレクトリ名(パス名でない)。 議論を省略するのが、カレントディレクトリのリストを入手する唯一の定義された方法であることに注意してください、ディレクトリを表すパス名がたまたま知られていない場合。 特に、カレントディレクトリのための定義された速記名が全くありません。 これは、そのような速記を実装しながら、少しの特定のサーバ-PIも禁止しません。
No title, header, or summary, lines, or any other formatting, other than as is specified below, is ever returned in the output of an MLST or MLSD command.
タイトル(指定されているのを除いた以下のヘッダー、概要、系列、またはいかなる他の形式も)は、全く今までに、MLSTかMLSDコマンドの出力で返されません。
If the Client-FTP sends an invalid argument, the server-FTP MUST reply with an error code of 501.
Client-FTPが根拠のない議論を送るなら、サーバFTPは501のエラーコードで返答しなければなりません。
The syntax for the MLSx command is:
MLSxコマンドのための構文は以下の通りです。
mlst = "MLst" [ SP pathname ] CRLF
mlsd = "MLsD" [ SP pathname ] CRLF
mlst="MLst"[SPパス名]CRLF mlsdは"MLsD"[SPパス名]CRLFと等しいです。
7.2. Format of MLSx Response
7.2. MLSx応答の形式
The format of a response to an MLSx command is as follows:
MLSxコマンドへの応答の形式は以下の通りです:
mlst-response = control-response / error-response
mlsd-response = ( initial-response final-response ) /
error-response
mlst-応答は誤り操舵応答/応答mlsd-応答=(初期の応答の最終的な応答)/誤り応答と等しいです。
control-response = "250-" [ response-message ] CRLF
1*( SP entry CRLF )
"250" [ SP response-message ] CRLF
操舵応答=「250」[応答メッセージ]CRLF1*(SPエントリーCRLF)「250」[SP応答メッセージ]CRLF
initial-response = "150" [ SP response-message ] CRLF
final-response = "226" SP response-message CRLF
「150」[SP応答メッセージ]CRLFの最終的な初期の応答=応答は「226」SP応答メッセージCRLFと等しいです。
response-message = *TCHAR
応答メッセージ=*TCHAR
data-response = *( entry CRLF )
データ応答は*と等しいです。(エントリーCRLF)
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
factname = "Size" / "Modify" / "Create" /
"Type" / "Unique" / "Perm" /
"Lang" / "Media-Type" / "CharSet" /
os-depend-fact / local-fact
os-depend-fact = <IANA assigned OS name> "." token
エントリー..等しい..事実..パス名..事実..事実..事実..等しい..値..等しい..サイズ..変更..作成..タイプ..ユニーク..パーマ..ラング..メディア..タイプ..OS..よる..事実..地方..事実..OS..よる..事実..割り当てる..OS..命名..トークン
Hethmon Standards Track [Page 24] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[24ページ]。
local-fact = "X." token
value = *SCHAR
ローカルの事実=「X.」トークン価値は*シェアーと等しいです。
Upon receipt of an MLSx command, the server will verify the parameter, and if invalid return an error-response. For this purpose, the parameter should be considered to be invalid if the client issuing the command does not have permission to perform the requested operation.
MLSxコマンドを受け取り次第、サーバは、パラメタと病人が誤り応答を返すかどうか確かめるでしょう。 このために、命令を発するクライアントが要求された操作を実行する許可を持っていないなら、パラメタが無効であると考えられるべきです。
If the parameter is valid, then for an MLST command, the server-PI will send the first (leading) line of the control response, the entry for the pathname given, or the current directory if no pathname was provided, and the terminating line. Normally exactly one entry would be returned, more entries are permitted only when required to represent a file that is to have multiple "Type" facts returned. In this case, the pathname component of every response MUST be identical.
パラメタが有効であるなら、MLSTコマンドのために、サーバ-PIは操舵応答、与えられたパス名のためのエントリー、またはカレントディレクトリの最初の(主)の系列にパス名を全く提供しなかったか、そして、終わり系列を送るでしょう。 通常ちょうど1つのエントリーを返して、複数の「タイプ」事実を返すことになっているファイルを表すのが必要であるときにだけ、より多くのエントリーを受入れます。 この場合、あらゆる応答のパス名コンポーネントは同じであるに違いありません。
Note that for MLST the fact set is preceded by a space. That is provided to guarantee that the fact set cannot be accidentally interpreted as the terminating line of the control response, but is required even when that would not be possible. Exactly one space exists between the set of facts and the pathname. Where no facts are present, there will be exactly two leading spaces before the pathname. No spaces are permitted in the facts, any other spaces in the response are to be treated as being a part of the pathname.
MLSTに関して、スペースが事実セットに先行することに注意してください。 それを操舵応答の終わり系列として偶然事実セットを解釈できないのを保証するために提供しますが、それが可能でないだろうというときにさえ、必要とします。 まさに1つのスペースが事実のセットとパス名の間に存在しています。 事実がないのが存在しているところに、2つの主な空間がパス名の前にまさにあるでしょう。 応答におけるいかなる他の空間も空間が全く事実で受入れられないで、パス名の一部であるとして扱われることです。
If the command was an MLSD command, the server will open a data connection as indicated in section 3.2 of STD 9, RFC 959 [3]. If that fails, the server will return an error-response. If all is OK, the server will return the initial-response, send the appropriate data-response over the new data connection, close that connection, and then send the final-response over the control connection. The grammar above defines the format for the data-response, which defines the format of the data returned over the data connection established.
コマンドがMLSDコマンドであったなら、サーバはSTD9(RFC959[3])のセクション3.2にみられるようにデータ接続を開くでしょう。 それが失敗すると、サーバは誤り応答を返すでしょう。 すべてがOKであるなら、サーバは、コントロール接続の上に初期の応答を返して、新しいデータ接続の上に適切なデータ応答を送って、その接続を終えて、最終的な応答を送るでしょう。 上の文法はデータ応答のためにフォーマットを定義します。(それは、接続が確立したデータの上に返されたデータの書式を定義します)。
The data connection opened for a MLSD response shall be a connection as if the "TYPE L 8", "MODE S", and "STRU F" commands had been given, whatever FTP transfer type, mode and structure had actually been set, and without causing those settings to be altered for future commands. That is, this transfer type shall be set for the duration of the data connection established for this command only. While the content of the data sent can be viewed as a series of lines, implementations should note that there is no maximum line length defined. Implementations should be prepared to deal with arbitrarily long lines.
MLSD応答のために開かれたデータ接続が接続である、「タイプL8インチ、「モードS」、および「STRU F」コマンドを与えました、そして、どんなFTP転送もタイプされても、モードと構造は実際に設定されました、そして、それらの設定を引き起こさないで、未来に変更されるのは命令します」。 すなわち、この転送タイプはこのコマンドだけのために確立されたデータ接続の持続時間に用意ができているものとします。 一連の系列として送られたデータの内容を見なすことができる間、実装は、長さが定義したどんな最大の系列もないことに注意するべきです。 実装は任意に長い系列に対処するように準備されるべきです。
Hethmon Standards Track [Page 25] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[25ページ]。
The facts part of the specification would contain a series of "file facts" about the file or directory named on the same line. Typical information to be presented would include file size, last modification time, creation time, a unique identifier, and a file/directory flag.
仕様の事実部分は同じ系列で指定されたファイルかディレクトリに関する一連の「ファイル事実」を含んでいるでしょう。 提示される典型的な情報はファイルサイズ、最後の変更時間、作成時間、ユニークな識別子、およびファイル/ディレクトリ旗を含んでいるでしょう。
The complete format for a successful reply to the MLSD command would be:
MLSDコマンドに関するうまくいっている回答のための完全な形式は以下の通りでしょう。
facts SP pathname CRLF
facts SP pathname CRLF
facts SP pathname CRLF
...
事実SPパス名CRLF事実SPパス名CRLF事実SPパス名CRLF…
Note that the format is intended for machine processing, not human viewing, and as such the format is very rigid. Implementations MUST NOT vary the format by, for example, inserting extra spaces for readability, replacing spaces by tabs, including header or title lines, or inserting blank lines, or in any other way alter this format. Exactly one space is always required after the set of facts (which may be empty). More spaces may be present on a line if, and only if, the pathname presented contains significant spaces. The set of facts must not contain any spaces anywhere inside it. Facts should be provided in each output line only if they both provide relevant information about the file named on the same line, and they are in the set requested by the user-PI. See section 7.9 (page 51). There is no requirement that the same set of facts be provided for each file, or that the facts presented occur in the same order for each file.
人間の見るのではなく、マシン処理、そのような形式が非常に堅いので形式が意図することに注意してください。 実装は、ヘッダーかタイトル系列を含んでいるか、または空白行を挿入して、例えば、空間をタブに取り替えて、読み易さのために付加的な空間を挿入することによって形式を変えてはいけませんし、またいかなる他の方法でもこの形式を変更してはいけません。 まさに1つのスペースが事実(空であるかもしれない)のセット後にいつも必要です。 より多くの空間が系列に存在しているかもしれない、唯一、提示されたパス名は重要な空間を含んでいます。 事実のセットはそれの中でどこでも少しの空間も含んではいけません。 それらの両方が同じ系列で指定されたファイルの関連情報を提供して、ユーザ-PIによって要求されたセットにそれらがある場合にだけ、それぞれの出力系列に事実を提供するべきです。 セクション7.9(51ページ)を見てください。 同じセットの事実を各ファイルに提供するか、または提示された事実がそれぞれのファイルの同じ注文に現れるという要件が全くありません。
7.2.1. Error Responses to MLSx commands
7.2.1. MLSxコマンドへの誤りResponses
Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. In particular, syntax errors can generate 500 or 501 replies. Giving a pathname that exists but is not a directory as the argument to a MLSD command generates a 501 reply. Giving a name that does not exist, or for which access permission (to obtain directory information as requested) is not granted will elicit a 550 reply. Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances.
応答がSTD9、RFC959[3]のセクション4.2で定義した4xyと5xyの多くがMLSTとMLSDコマンドに対応して可能です。 特に、構文エラーは500か501の回答を生成することができます。 それをパス名に与えるのは、存在していますが、MLSDコマンドへの議論が501回答を生成するとき、ディレクトリではありません。 それを名前に与えるのは、存在していないか、またはどの参照許可(要求された通りディレクトリ情報を得る)が承諾されないように550回答を引き出すだろうか。 また、他の回答(4xy回答の530、553、503、504、およびどれか)も適切な事情で可能です。
7.3. File Name Encoding
7.3. ファイル名コード化
An FTP implementation supporting the MLSx commands must be 8-bit clean. This is necessary in order to transmit UTF-8 encoded file names. This specification recommends the use of UTF-8 encoded file
清潔な状態でMLSxコマンドをサポートするFTP実装は8ビットでなければなりません。 これがUTF-8が伝わるようにファイル名をコード化したのが必要です。 この仕様は、UTF-8の使用がファイルをコード化したことを勧めます。
Hethmon Standards Track [Page 26] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[26ページ]。
names. FTP implementations SHOULD use UTF-8 whenever possible to encourage the maximum inter-operability.
名前。 最大の相互運用性を奨励するのにおいて可能であるときはいつも、FTP実装SHOULDはUTF-8を使用します。
File names are not restricted to UTF-8, however treatment of arbitrary character encodings is not specified by this standard. Applications are encouraged to treat non-UTF-8 encodings of file names as octet sequences.
ファイル名はUTF-8に制限されないで、またしかしながら、気紛れな質encodingsの処理はこの規格によって指定されません。 アプリケーションがファイル名の非UTF-8 encodingsを八重奏系列として扱うよう奨励されます。
Note that this encoding is unrelated to that of the contents of the file, even if the file contains character data.
このコード化がファイルのコンテンツのものに関係ないことに注意してください、ファイルがキャラクタデータを含んでも。
Further information about file name encoding for FTP may be found in "Internationalization of the File Transfer Protocol" [7].
FTPのためのファイル名コード化に関する詳細は「ファイル転送プロトコルの国際化」[7]で見つけられるかもしれません。
7.3.1. Notes about the File Name
7.3.1. ファイル名に関する注
The file name returned in the MLST response should be the same name as was specified in the MLST command, or, where TVFS is supported, a fully qualified TVFS path naming the same file. Where no argument was given to the MLST command, the server-PI may either include an empty file name in the response, or it may supply a name that refers to the current directory, if such a name is available. Where TVFS is supported, a fully qualified pathname of the current directory SHOULD be returned.
MLST応答で返されたファイル名は、MLSTコマンドで指定された同じ名前、またはTVFSがサポートされるところの同じファイルを命名する完全に適切なTVFS経路であるべきです。 議論を全くMLSTコマンドに与えなかったか、サーバ-PIが応答で空のファイル名を含めるかもしれないか、またはそれが名前を提供するかもしれないところと、それはカレントディレクトリを呼びます、そのような名前が利用可能であるなら。 どこTVFSはサポートされるか、そして、カレントディレクトリの完全に適切なパス名はSHOULDです。返します。
File names returned in the output from an MLSD command SHOULD be unqualified names within the directory named, or the current directory if no argument was given. That is, the directory named in the MLSD command SHOULD NOT appear as a component of the file names returned.
議論を全く与えなかったなら、MLSDから出力で返されたファイル名は、SHOULDが指定されたディレクトリ、またはカレントディレクトリの中の資格のない名前であると命令します。 すなわち、SHOULD NOTがファイル名の成分として見えるMLSDコマンドで指定されたディレクトリは戻りました。
If the server-FTP process is able, and the "type" fact is being returned, it MAY return in the MLSD response, an entry whose type is "cdir", which names the directory from which the contents of the listing were obtained. Where TVFS is supported, the name MAY be the fully qualified pathname of the directory, or MAY be any other pathname that is valid to refer to that directory from the current working directory of the server-FTP. Where more than one name exists, multiple of these entries may be returned. In a sense, the "cdir" entry can be viewed as a heading for the MLSD output. However, it is not required to be the first entry returned, and may occur anywhere within the listing.
サーバFTPプロセスができて、「タイプ」事実が返されるなら、それはMLSD応答(タイプがリストのコンテンツが得られたディレクトリを命名する"cdir"であるエントリー)で戻るかもしれません。 TVFSがサポートされるところでは、名前は、ディレクトリの完全に適切なパス名であるかもしれない、またはいかなる他のサーバFTPの現在の働くディレクトリからそのディレクトリを参照するために有効なパス名であるかもしれません。 1つ以上の名前が存在するところに、これらのエントリーの倍数は返されるかもしれません。 ある意味で、MLSD出力のための見出しとして"cdir"エントリーを見なすことができます。 しかしながら、それは、返された初記入であることが必要でなく、リストの中にどこでも起こるかもしれません。
When TVFS is supported, a user-PI can refer to any file or directory in the listing by combining a type "cdir" name, with the appropriate name from the directory listing using the procedure defined in section 6.2.
TVFSがサポートされるとき、ユーザ-PIはリストのタイプ"cdir"名を結合するのによるどんなファイルやディレクトリも示すことができます、ディレクトリからの適切な名前がセクション6.2で定義された手順を用いることで記載していて。
Hethmon Standards Track [Page 27] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[27ページ]。
Alternatively, whether TVFS is supported or not, the user-PI can issue a CWD command ([3]) giving a name of type "cdir" from the listing returned, and from that point reference the files returned in the MLSD response from which the cdir was obtained by using the file name components of the listing.
あるいはまた、TVFSがサポートされるか否かに関係なく、ユーザ-PIは、返す、およびファイルがcdirがリストのファイル名の部品を使用することによって入手されたMLSD応答で返したそのポイント参照からのリストからタイプ"cdir"の名前を与えながら、CWDコマンド([3])を発行できます。
7.4. Format of Facts
7.4. 事実の形式
The "facts" for a file in a reply to a MLSx command consist of
information about that file. The facts are a series of keyword=value
pairs each followed by semi-colon (";") characters. An individual
fact may not contain a semi-colon in its name or value. The complete
series of facts may not contain the space character. See the
definition or "RCHAR" in section 2.1 for a list of the characters
that can occur in a fact value. Not all are applicable to all facts.
MLSxコマンドに関する回答におけるファイルのための「事実」はそのファイルの情報から成ります。 事実がセミコロンがそれぞれいうことになった一連のキーワード=値組である、(「」、)、キャラクタ。 個々の事実はその名前か値におけるセミコロンを含まないかもしれません。 完全なシリーズの事実は間隔文字を含まないかもしれません。 定義を見てください。さもないと、キャラクタのリストのためのそうすることができるセクション2.1の"RCHAR"は事実値で起こります。 すべてがすべての事実に適切であるというわけではありません。
A sample of a typical series of facts would be: (spread over two lines for presentation here only)
典型的なシリーズの事実のサンプルは以下の通りでしょう。 (ここでのプレゼンテーションだけのための2つの系列の上の普及)
size=4161;lang=en-US;modify=19970214165800;create=19961001124534; type=file;x.myfact=foo,bar;
サイズ=4161; langはアン米国と等しいです; =19970214165800を変更してください; =19961001124534を作成してください。 タイプ=はファイルします; x.myfact=foo、バー
7.5. Standard Facts
7.5. 標準の事実
This document defines a standard set of facts as follows:
このドキュメントは以下の事実の標準セットを定義します:
size -- Size in octets
modify -- Last modification time
create -- Creation time
type -- Entry type
unique -- Unique id of file/directory
perm -- File permissions, whether read, write, execute is
allowed for the login id.
lang -- Language of the file name per IANA [11] registry.
media-type -- MIME media-type of file contents per IANA registry.
charset -- Character set per IANA registry (if not UTF-8)
サイズ(中の八重奏が変更するサイズ)はユニークな状態で--作成時間タイプ--エントリータイプを創造してください--ファイル/ディレクトリのユニークなイドがパーマをかける変更時間を持続します--許容をファイルしてください、読まれるか否かに関係なく書いてください、実行. ログインイドlang--IANA[11]登録メディアファイル形式がIANA登録charset単位で満足させるメディアタイプ--MIMEあたりのファイル名の用語--IANA登録あたりの文字集合には、許容されています。(まして、UTF-8)
Fact names are case-insensitive. Size, size, SIZE, and SiZe are the same fact.
事実名は大文字と小文字を区別しないです。 サイズ、サイズ、SIZE、およびSiZeは同じ事実です。
Further operating system specific keywords could be specified by using the IANA operating system name as a prefix (examples only):
接頭語(例専用)としてIANAオペレーティングシステム名を使用することによって、さらなるオペレーティングシステムの特定のキーワードを指定できるでしょう:
OS/2.ea -- OS/2 extended attributes
MACOS.rf -- MacIntosh resource forks
UNIX.mode -- Unix file modes (permissions)
OS/2.ea--OS/2拡張属性MACOS.rf--MacIntoshリソースフォークUNIX.mode--unixファイルモード(許容)
Hethmon Standards Track [Page 28] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[28ページ]。
Implementations may define keywords for experimental, or private use. All such keywords MUST begin with the two character sequence "x.". As type names are case independent, "x." and "X." are equivalent. For example:
実装は実験的であるか、または私用のためのキーワードを定義するかもしれません。 そのようなすべてのキーワードが2キャラクタシーケンスで「x.」を始めなければなりません。 型名がケース独立者であるので、「x.」と「X.」は同等です。 例えば:
x.ver -- Version information
x.desc -- File description
x.type -- File type
x.ver--バージョン情報x.desc--ファイル記述x.タイプ--ファイルの種類
7.5.1. The Type Fact
7.5.1. タイプ事実
The type fact needs a special description. Part of the problem with current practices is deciding when a file is a directory. If it is a directory, is it the current directory, a regular directory, or a parent directory? The MLST specification makes this unambiguous using the type fact. The type fact given specifies information about the object listed on the same line of the MLST response.
タイプ事実は特別な記述を必要とします。 現在の実務に関する問題の一部が、いつファイルがディレクトリであるかを決めています。 ディレクトリであるなら、それは、カレントディレクトリ、通常のディレクトリ、または親ディレクトリですか? MLST仕様で、これは、タイプ事実を使用することで明白になります。 与えられたタイプ事実はMLST応答の同じ系列に記載されたオブジェクトの情報を指定します。
Five values are possible for the type fact:
タイプ事実に、5つの値が可能です:
file -- a file entry
cdir -- the listed directory
pdir -- a parent directory
dir -- a directory or sub-directory
OS.name=type -- an OS or file system dependent file type
ファイル--ファイル項目cdir--記載されたディレクトリpdir--親ディレクトリdir--ディレクトリかサブディレクトリOS.name=タイプ--OSかファイルシステムに依存するファイルの種類
The syntax is defined to be:
構文は、である:なるように定義されます。
type-fact = type-label "=" type-val
type-label = "Type"
type-val = "File" / "cdir" / "pdir" / "dir" /
os-type
「タイプ」タイプタイプ事実=タイプラベル「=」タイプヴァルタイプラベル=ヴァルはOS「ファイル」/"cdir"/"pdir"/"dir"/タイプと等しいです。
The value of the type fact (the "type-val") is a case independent string.
タイプ事実(「タイプ-val」)の値はケースの独立しているストリングです。
7.5.1.1. type=file
7.5.1.1. タイプ=はファイルします。
The presence of the type=file fact indicates the listed entry is a file containing non-system data. That is, it may be transferred from one system to another of quite different characteristics, and perhaps still be meaningful.
ファイルタイプの存在=事実は、記載されたエントリーが非システムデータを含むファイルであることを示します。 すなわち、それは、1台のシステムから全く異なった特性の別のものまで移されて、恐らくまだ重要であるかもしれません。
7.5.1.2. type=cdir
7.5.1.2. =cdirをタイプしてください。
The type=cdir fact indicates the listed entry contains a pathname of the directory whose contents are listed. An entry of this type will only be returned as a part of the result of an MLSD command when the
タイプ=cdir事実は、記載されたエントリーがコンテンツが記載されているディレクトリのパス名を含むのを示します。 MLSDコマンドの結果の一部としてこのタイプのエントリーを返すだけである、いつ
Hethmon Standards Track [Page 29] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[29ページ]。
type fact is included, and provides a name for the listed directory, and facts about that directory. In a sense, it can be viewed as representing the title of the listing, in a machine friendly format. It may appear at any point of the listing, it is not restricted to appearing at the start, though frequently may do so, and may occur multiple times. It MUST NOT be included if the type fact is not included, or there would be no way for the user-PI to distinguish the name of the directory from an entry in the directory.
タイプ事実は、含まれていて、記載されたディレクトリに名前を供給して、そのディレクトリに関して事実を供給します。 ある意味で、マシンの好意的な形式のリストのタイトルを表すとそれを見なすことができます。 任意な点でリストでは、したがって、制限されないで、頻繁ですが、始めに現れるように、そうするかもしれなくなってください、複数の回起こってもよいということであるように見えるかもしれません。 タイプ事実が含まれていないか、またはディレクトリにユーザ-PIがエントリーとディレクトリの名前を区別する方法が全くなければ、それを含んではいけません。
Where TVFS is supported by the server-FTP, this name may be used to construct pathnames with which to refer to the files and directories returned in the same MLSD output (see section 6.2). These pathnames are only expected to work when the server-PI's position in the NVFS file tree is the same as its position when the MLSD command was issued, unless a fully qualified pathname results.
TVFSがサーバFTPによってサポートされるところでは、この名前は、同じMLSD出力で返されたファイルとディレクトリを参照するパス名を構成するのに使用されるかもしれません(セクション6.2を見てください)。 NVFSファイル木のサーバ-PI位置がMLSDが命令するとき、位置が発行されたのと同じであるときに、これらのパス名が働くと予想されるだけです、完全に適切なパス名が結果として生じない場合。
Where TVFS is not supported, the only defined semantics associated with a "type=cdir" entry are that, provided the current working directory of the server-PI has not been changed, a pathname of type "cdir" may be used as an argument to a CWD command, which will cause the current directory of the server-PI to change so that the directory that was listed in its current working directory.
「タイプ=cdir」エントリーに関連している唯一の定義された意味論はサーバ-PIの現在の働くディレクトリが変えられていないならタイプ"cdir"のパス名が議論としてCWDコマンドに使用されるかもしれないというTVFSがサポートされないところのことです。(したがって、サーバ-PIのカレントディレクトリはコマンドでそれを変えるでしょう)。現在の働くディレクトリにリストアップされたディレクトリ。
7.5.1.3. type=dir
7.5.1.3. =dirをタイプしてください。
If present, the type=dir entry gives the name of a directory. Such an entry typically cannot be transferred from one system to another using RETR, etc., but should (permissions permitting) be able to be the object of an MLSD command.
存在しているなら、dirタイプ=エントリーはディレクトリの名前を与えます。 そのようなエントリーは、RETRなどを使用することで通常1台のシステムから別のシステムまで移すことができませんが、MLSDコマンドの目的であることをできるべきです(許容が可能にして)。
7.5.1.4. type=pdir
7.5.1.4. =pdirをタイプしてください。
If present, which will occur only in the response to a MLSD command when the type fact is included, the type=pdir entry represents a pathname of the parent directory of the listed directory. As well as having the properties of a type=dir, a CWD command that uses the pathname from this entry should change the user to a parent directory of the listed directory. If the listed directory is the current directory, a CDUP command may also have the effect of changing to the named directory. User-FTP processes should note not all responses will include this information, and that some systems may provide multiple type=pdir responses.
存在しているなら、タイプ事実が含まれている、pdirタイプ=エントリーが記載されたディレクトリに関する親ディレクトリのパス名を表すMLSDコマンドへの応答だけで起こるどれです。 タイプの特性がdirとの等しさにすることと同様に、このエントリーからパス名を使用するCWDコマンドはユーザを記載されたディレクトリに関する親ディレクトリに変えるべきです。 また、記載されたディレクトリがカレントディレクトリであるなら、CDUPコマンドには命名されたディレクトリに変化するという効果があるかもしれません。 ユーザFTPプロセスは、すべての応答がこの情報を含むというわけではないことに注意するはずです、そして、いくつかのシステムが複数のタイプを提供するかもしれないのはpdir応答と等しいです。
Where TVFS is supported, a "type=pdir" name may be a relative pathname, or a fully qualified pathname. A relative pathname will be relative to the directory being listed, not to the current directory of the server-PI at the time.
TVFSがサポートされるところでは、「タイプ=pdir」名は、相対的なパス名、または完全に適切なパス名であるかもしれません。 相対的なパス名は当時サーバ-PIのカレントディレクトリではなく、リストアップされているディレクトリに比例しているでしょう。
Hethmon Standards Track [Page 30] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[30ページ]。
For the purposes of this type value, a "parent directory" is any directory in which there is an entry of type=dir that refers to the directory in which the type=pdir entity was found. Thus it is not required that all entities with type=pdir refer to the same directory. The "unique" fact (if supported and supplied) can be used to determine whether there is a relationship between the type=pdir entries or not.
このタイプ価値の目的のために、「親ディレクトリ」はpdirタイプ=実体が見つけられたディレクトリを示すタイプ=dirのエントリーがあるあらゆるディレクトリです。 したがって、タイプ=pdirがあるすべての実体が同じディレクトリを参照するのが必要ではありません。 pdirタイプ=エントリーの間には、関係があるかどうか決定するのに、「ユニークな」事実(サポートして、供給するなら)を使用できます。
7.5.1.5. System Defined Types
7.5.1.5. システムの定義されたタイプ
Files types that are specific to a specific operating system, or file system, can be encoded using the "OS." type names. The format is:
コード化された使用が. タイプが命名する「OS」であることができたなら特定のオペレーティングシステム、またはファイルシステムに特定のタイプをファイルします。 形式は以下の通りです。
os-type = "OS." os-name "=" os-kind
os-name = <an IANA registered operating system name>
os-kind = token
OSタイプ=「OS」 OS名の「=」IANAが登録したOS種類のOS名=<オペレーティングシステム名前>OS種類=トークン
The "os-name" indicates the specific system type that supports the particular localtype. OS specific types are registered by the IANA using the procedures specified in section 10. The "os-kind" provides the system dependent information as to the type of the file listed. The os-name and os-kind strings in an os-type are case independent. "OS.unix=block" and "OS.Unix=BLOCK" represent the same type (or would, if such a type were registered.)
「OS名」は特定のlocaltypeをサポートする特定のシステムタイプを示します。 OS特定のタイプは、セクション10で指定された手順を用いることでIANAによって示されます。 「OS種類」はファイルのタイプの依存する情報が記載したシステムを提供します。 OSタイプのOS名とOS種類のストリングはケース独立者です。 「OS.unixはブロックと等しく、OS.Unixはブロックと等しいです。」と、同じタイプは表します。または、(そのようなタイプが示されたなら)であるだろう
Note: Where the underlying system supports a file type that is essentially an indirect pointer to another file, the NVFS representation of that type should normally be to represent the file that the reference indicates. That is, the underlying basic file will appear more than once in the NVFS, each time with the "unique" fact (see immediately following section) containing the same value, indicating that the same file is represented by all such names. User-PIs transferring the file need then transfer it only once, and then insert their own form of indirect reference to construct alternate names where desired, or perhaps even copy the local file if that is the only way to provide two names with the same content. A file which would be a reference to another file, if only the other file actually existed, may be represented in any OS dependent manner appropriate, or not represented at all.
以下に注意してください。 基本的なシステムが本質的には間接的な指針であるファイルの種類を別のファイルにサポートするところでは、そのタイプのNVFS表現は通常、参照が示すファイルを表すはずであることです。 すなわち、基本的な基本のファイルはNVFSで一度より多く見えるでしょう、同じ値を含んでいる「ユニークな」事実(すぐに次のセクションを見る)がある各回、同じファイルがそのようなすべての名前によって表されるのを示して。 ファイルを移すユーザ-PIsは、それが同じ内容を2つの名前に提供する唯一の方法であるなら必要であるところで別名称を構成するか、または恐らくローカルファイルをコピーするのさえ次に、一度だけそれを移して、次に、それら自身の間接的な言及のフォームを挿入しなければなりません。 もう片方のファイルだけが実際に存在しているなら別のファイルを参照であるファイルは依存する方法適切であるか、または全く表されなかった少しのOSでも表されるかもしれません。
7.5.1.6. Multiple Types
7.5.1.6. 複数のタイプ
Where a file is such that it may validly, and sensibly, treated by the server-PI as being of more than one of the above types, then multiple entries should be returned, each with its own "Type" fact of the appropriate type, and each containing the same pathname. This may occur, for example, with a structured file, which may contain sub-files, and where the server-PI permits the structured file to be
それ自身の適切なタイプの「タイプ」事実と共にそれぞれ返して、上のタイプのより多くのひとりの存在としてサーバ-PIによって扱われて、同じパス名を含んでいて、当時の多回入国はファイルが確実に、分別よくそうするかもしれないようにものであるところでそれぞれ返すべきです。 これは起こるかもしれません、例えば、構造化ファイルで、いてください。そこでは、サブファイルを含むかもしれなくて、サーバ-PIは構造化ファイルを可能にします。
Hethmon Standards Track [Page 31] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[31ページ]。
treated as a unit, or treated as a directory allowing the sub-files within it to be referenced. When this is done, the pathname returned with each entry MUST be identical to the others representing the same file.
ユニットとして扱われるか、またはそれの中のサブファイルが参照をつけられるのを許容するディレクトリとして扱われます。 これが完了しているとき、同じファイルを表す他のものにとって、各エントリーと共に返されたパス名は同じであるに違いありません。
7.5.2. The unique Fact
7.5.2. ユニークなFact
The unique fact is used to present a unique identifier for a file or directory in the NVFS accessed via a server-FTP process. The value of this fact should be the same for any number of pathnames that refer to the same underlying file. The fact should have different values for names that reference distinct files. The mapping between files, and unique fact tokens should be maintained, and remain consistent, for at least the lifetime of the control connection from user-PI to server-PI.
ユニークな事実は、サーバFTPプロセスを通してアクセスされたNVFSのファイルかディレクトリのためのユニークな識別子を提示するのに使用されます。 同じ基本的なファイルを示すいろいろなパス名に、この事実の値は同じであるべきです。 事実には、異なったファイルに参照をつける名前のための異価があるべきです。 ファイルと、少なくともユーザ-PIからサーバ-PIまでのコントロール接続の生涯のためのトークンが維持されて、一貫していたままで残るべきであるというユニークな事実の間のマッピング。
unique-fact = "Unique" "=" token
ユニークな事実=「ユニークである」「=」トークン
This fact would be expected to be used by server-FTPs whose host system allows things such as symbolic links so that the same file may be represented in more than one directory on the server. The only conclusion that should be drawn is that if two different names each have the same value for the unique fact, they refer to the same underlying object. The value of the unique fact (the token) should be considered an opaque string for comparison purposes, and is a case dependent value. The tokens "A" and "a" do not represent the same underlying object.
ホストシステムがサーバの1つ以上のディレクトリに同じファイルを表すことができるようにシンボリックリンクなどのものを許容するサーバFTPによってこの事実が使用されると予想されるでしょう。達せられるべきである唯一の結論はそれぞれ2つの異なった名前にユニークな事実のための同じ値があるなら、彼らが同じ基本的なオブジェクトについて言及するということです。 ユニークな事実(トークン)の値は、比較目的のための不透明なストリングであると考えられるべきであり、ケースの依存する値です。 トークン「A」と“a"は同じ基本的なオブジェクトを表しません。
7.5.3. The modify Fact
7.5.3. Factを変更してください。
The modify fact is used to determine the last time the content of the file (or directory) indicated was modified. Any change of substance to the file should cause this value to alter. That is, if a change is made to a file such that the results of a RETR command would differ, then the value of the modify fact should alter. User-PIs should not assume that a different modify fact value indicates that the file contents are necessarily different than when last retrieved. Some systems may alter the value of the modify fact for other reasons, though this is discouraged wherever possible. Also a file may alter, and then be returned to its previous content, which would often be indicated as two incremental alterations to the value of the modify fact.
使用される事実を変更して、ファイル(または、ディレクトリ)の中身が示した最後の時間が変更されたことを決定してください。 ファイルへの物質のどんな変化でも、この値は変わるべきです。 事実を変更してください。次に、RETRコマンドの結果が異なるように変更をファイルにするならそれが値である、変わるべきです。 事実値を変更してください。ユーザ-PIsが、そのaが異なっていると仮定するはずがない、ファイルコンテンツが必ずいつと最後に検索されていた状態で異なっているかを示します。 いくつかのシステムが値を変更するかもしれない、これはどこでも、可能であるところでがっかりしていますが、他の理由で事実を変更してください。 また、ファイルは変わって、次に、前の内容に返すかもしれない、事実を変更してください。(内容は2つの増加の変更としてしばしば値に示されるでしょう)。
For directories, this value should alter whenever a change occurs to the directory such that different file names would (or might) be included in MLSD output of that directory.
ディレクトリに関して、この値が変わるべきである、変化があれほどそんなに異なったファイルが命名するディレクトリの心に浮かぶときはいつも、(or might)はそのディレクトリのMLSD出力に含まれているでしょうか?
modify-fact = "Modify" "=" time-val
事実を変更している=「変更」は時間-valと「等しいです」。
Hethmon Standards Track [Page 32] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[32ページ]。
7.5.4. The create Fact
7.5.4. Factを作成してください。
The create fact indicates when a file, or directory, was first created. Exactly what "creation" is for this purpose is not specified here, and may vary from server to server. About all that can be said about the value returned is that it can never indicate a later time than the modify fact.
事実を作成してください。ファイル、またはディレクトリが最初にいつ作成されたかを示します。 ちょうどどんな「作成」がこの目的のためのものであるかは、ここで指定されないで、サーバによって異なるかもしれません。それを言うことができるすべてに関して、返された値が後の時間を決して示すことができないということである、事実を変更してください。
create-fact = "Create" "=" time-val
事実を作成している=「作成」は時間-valと「等しいです」。
Implementation Note: Implementors of this fact on UNIX(TM) systems
should note that the unix "stat" "st_ctime" field does not give
creation time, and that unix file systems do not record creation
time at all. Unix (and POSIX) implementations will normally not
include this fact.
実装注意: UNIX(TM)システムに関するこの事実の作成者がそれに注意するべきである、unix「スタット」、「_全く記録的な作成時間ではなく、」 分野が作成時間を与えないで、unixファイルシステムがする第ctime。 通常、unix(そして、POSIX)実装はこの事実を含まないでしょう。
7.5.5. The perm Fact
7.5.5. パーマFact
The perm fact is used to indicate access rights the current FTP user has over the object listed. Its value is always an unordered sequence of alphabetic characters.
パーマ事実は、現在のFTPユーザがオブジェクトの上に持っているアクセス権が記載したのを示すのに使用されます。 いつも値は英字の順不同の系列です。
perm-fact = "Perm" "=" *pvals
pvals = "a" / "c" / "d" / "e" / "f" /
"l" / "m" / "p" / "r" / "w"
“a"/「c」/「d」/「e」/「f」/「l」/「m」パーマ事実=「パーマ」「=」*pvals pvals=/「p」/「r」/「w」
There are ten permission indicators currently defined. Many are meaningful only when used with a particular type of object. The indicators are case independent, "d" and "D" are the same indicator.
現在定義されている10の許可インディケータがあります。 特定のタイプのオブジェクトと共に使用される場合にだけ、多くが重要です。 インディケータがケース独立者である、「d」と「D」は同じインディケータです。
The "a" permission applies to objects of type=file, and indicates that the APPE (append) command may be applied to the file named.
“a"許可は、タイプ=ファイルのオブジェクトに申し込んで、APPE(追加する)コマンドが指定されたファイルに適用されるかもしれないのを示します。
The "c" permission applies to objects of type=dir (and type=pdir, type=cdir). It indicates that files may be created in the directory named. That is, that a STOU command is likely to succeed, and that STOR and APPE commands might succeed if the file named did not previously exist, but is to be created in the directory object that has the "c" permission. It also indicates that the RNTO command is likely to succeed for names in the directory.
「c」許可はタイプ=dirのオブジェクトに適用されます(=pdirをタイプしてください、そして、=cdirをタイプしてください)。 それは、ファイルが指定されたディレクトリで作成されるかもしれないのを示します。 すなわち、STOUコマンドが引き継ぎそうであって、STORとAPPEコマンドが指定されたファイルが以前に存在しませんでしたが、「c」許可を持っているディレクトリオブジェクトで作成されることであるなら引き継ぐかもしれないそれ。 また、それは、RNTOコマンドにディレクトリの名前のために成功しそうであるのを示します。
The "d" permission applies to all types. It indicates that the object named may be deleted, that is, that the RMD command may be applied to it if it is a directory, and otherwise that the DELE command may be applied to it.
「d」許可はすべてのタイプに適用されます。 それは、指定されたオブジェクトが削除されるかもしれなくて、すなわち、RMDコマンドがそれがディレクトリであるならそれに適用されるかもしれなくて、さもなければ、DELEコマンドがそれに適用されるかもしれないのを示します。
The "e" permission applies to the directory types. When set on an object of type=dir, type=cdir, or type=pdir it indicates that a CWD
「e」許可はディレクトリタイプに適用されます。 オブジェクトの上に設定されると、タイプ=dir、タイプ=cdir、またはタイプ=pdirでは、それはそのa CWDを示します。
Hethmon Standards Track [Page 33] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[33ページ]。
command naming the object should succeed, and the user should be able to enter the directory named. For type=pdir it also indicates that the CDUP command may succeed (if this particular pathname is the one to which a CDUP would apply.)
オブジェクトを命名するコマンドは成功するべきです、そして、ユーザは指定されたディレクトリを入力できるべきです。 またそれが示すCDUPコマンドが引き継ぐかもしれないタイプ=pdirのために(この特定のパス名がCDUPが適用するものであるなら。)
The "f" permission for objects indicates that the object named may be renamed - that is, may be the object of an RNFR command.
オブジェクトのための「f」許可は、指定されたオブジェクトが改名されるかもしれないのを示します--すなわち、RNFRコマンドの目的であるかもしれません。
The "l" permission applies to the directory file types, and indicates that the listing commands, LIST, NLST, and MLSD may be applied to the directory in question.
「l」許可は、ディレクトリファイルの種類に申し込んで、リストのコマンド、LIST、NLST、およびMLSDが問題のディレクトリに適用されるかもしれないのを示します。
The "m" permission applies to directory types, and indicates that the MKD command may be used to create a new directory within the directory under consideration.
「m」許可は、ディレクトリの中で考慮で新しいディレクトリを作成するためにディレクトリタイプに申し込んで、MKDコマンドが使用されるかもしれないのを示します。
The "p" permission applies to directory types, and indicates that objects in the directory may be deleted, or (stretching naming a little) that the directory may be purged. Note: it does not indicate that the RMD command may be used to remove the directory named itself, the "d" permission indicator indicates that.
「p」許可が、ディレクトリタイプに申し込んで、ディレクトリのオブジェクトが削除されるかもしれないのを示すか、または(少し命名しながら、伸びます)それはディレクトリを示します。掃除されるかもしれません。 以下に注意してください。 それは、RMDコマンドがそれ自体で指定されたディレクトリを取り外すのに使用されるかもしれないのを示さないで、「d」許可インディケータはそれを示します。
The "r" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the RETR command may be applied to that object.
「r」許可は、ファイルタイプ=オブジェクト、およびいくつかのシステムのために恐らく他のタイプのオブジェクトに申し込んで、RETRコマンドがそのオブジェクトに適用されるかもしれないのを示します。
The "w" permission applies to type=file objects, and for some systems, perhaps to other types of objects, and indicates that the STOR command may be applied to the object named.
「w」許可は、ファイルタイプ=オブジェクト、およびいくつかのシステムのために恐らく他のタイプのオブジェクトに申し込んで、STORコマンドが指定されたオブジェクトに適用されるかもしれないのを示します。
Note: That a permission indicator is set can never imply that the
appropriate command is guaranteed to work -- just that it might.
Other system specific limitations, such as limitations on
available space for storing files, may cause an operation to fail,
where the permission flags may have indicated that it was likely
to succeed. The permissions are a guide only.
以下に注意してください。 適切なコマンドをある缶が決して含意しないセットは、働くためにただ保証されます。そのa許可インディケータ、それはそうするかもしれません。 ファイルを保管するための利用可能なスペースにおける制限などの他のシステムの特定の制限は操作に失敗されるかもしれません、許可旗が、それが成功しそうであるのを示したかもしれないところで。 許容はガイド専用です。
Implementation note: The permissions are described here as they apply
to FTP commands. They may not map easily into particular
permissions available on the server's operating system. Servers
are expected to synthesize these permission bits from the
permission information available from operating system. For
example, to correctly determine whether the "D" permission bit
should be set on a directory for a server running on the UNIX(TM)
operating system, the server should check that the directory named
is empty, and that the user has write permission on both the
directory under consideration, and its parent directory.
実装注意: FTPコマンドに適用するとき、許容はここで説明されます。 彼らは容易にサーバのオペレーティングシステムで利用可能な許容を特定に写像しないかもしれません。 サーバがオペレーティングシステムから利用可能な許可情報からのこれらの許可ビットを統合すると予想されます。 例えば、サーバが「D」許可ビットがUNIX(Tm)オペレーティングシステムで動くサーバのためのディレクトリのセットであるべきであるか否かに関係なく、指定されたディレクトリが空であり、ユーザがそうしたのをチェックするべきであることを正しく決定するには、考慮しているディレクトリとその親ディレクトリの両方に許可を書いてください。
Hethmon Standards Track [Page 34] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[34ページ]。
Some systems may have more specific permissions than those listed
here, such systems should map those to the flags defined as best
they are able. Other systems may have only more broad access
controls. They will generally have just a few possible
permutations of permission flags, however they should attempt to
correctly represent what is permitted.
いくつかのシステムには、ここに記載されたものより特定の許容があるかもしれなくて、それらが最もよくできるとき、そのようなシステムは定義された旗にそれらを写像するはずです。 他のシステムには、より広いアクセス制御しかないかもしれません。 彼らには、一般に、許可旗のわずかいくつかの可能な順列があって、しかしながら、それらは、正しく受入れられることを表すのを試みるべきです。
7.5.6. The lang Fact
7.5.6. lang Fact
The lang fact describes the natural language of the file name for use in display purposes. Values used here should be taken from the language registry of the IANA. See [12] for the syntax, and procedures, related to language tags.
lang事実はディスプレイ目的における使用のためのファイル名の自然言語について説明します。 IANAの言語登録からここで使用された値を取るべきです。 構文、および手順のための[12]が言語タグに関連したのを確実にしてください。
lang-fact = "Lang" "=" token
lang-事実=「ラング」「=」トークン
Server-FTP implementations MUST NOT guess language values. Language values must be determined in an unambiguous way such as file system tagging of language or by user configuration. Note that the lang fact provides no information at all about the content of a file, only about the encoding of its name.
サーバFTP実装は言語値を推測してはいけません。 言語のファイルシステムタグ付けなどの明白な方法かユーザ構成で言語値を決定しなければなりません。 lang事実がファイルの中身の周りと、そして、名前のコード化の周りに関してだけ情報を全く提供しないことに注意してください。
7.5.7. The size Fact
7.5.7. サイズFact
The size fact applies to non-directory file types and should always reflect the approximate size of the file. This should be as accurate as the server can make it, without going to extraordinary lengths, such as reading the entire file. The size is expressed in units of octets of data in the file.
サイズ事実は、非ディレクトリファイルの種類に当てはまって、いつもファイルの大体のサイズを反映するべきです。 これはサーバがそれを作ることができるのと同じくらい正確であるべきです、並はずれた長さまで行かないで、ファイル全体を読むのなどように。 サイズはファイルにおける、データのユニットの八重奏で表されます。
Given limitations in some systems, Client-FTP implementations must understand this size may not be precise and may change between the time of a MLST and RETR operation.
いくつかのシステムにおける制限を考えて、Client-FTP実装は、このサイズが正確でないかもしれないことを理解しなければならなくて、MLSTの時間とRETR操作の間で変化するかもしれません。
Clients that need highly accurate size information for some particular reason should use the SIZE command as defined in section 4. The most common need for this accuracy is likely to be in conjunction with the REST command described in section 5. The size fact, on the other hand, should be used for purposes such as indicating to a human user the approximate size of the file to be transferred, and perhaps to give an idea of expected transfer completion time.
何らかの特定の理由に高精度なサイズ情報を必要とするクライアントはセクション4で定義されるようにSIZEコマンドを使用するべきです。 この精度の最も一般的な必要性はセクション5で説明されたRESTコマンドに関連していそうです。 他方では、サイズ事実は、ファイルの大体のサイズを人間のユーザに示すことなどの目的を移して、恐らく予想された転送完成時間の考えを与えるのに使用されるべきです。
size-fact = "Size" "=" 1*DIGIT
サイズ事実=「サイズ」「=」1*ケタ
Hethmon Standards Track [Page 35] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[35ページ]。
7.5.8. The media-type Fact
7.5.8. メディアタイプFact
The media-type fact represents the IANA media type of the file named, and applies only to non-directory types. The list of values used must follow the guidelines set by the IANA registry.
メディアタイプ事実は、ファイルのタイプが命名したIANAメディアを代表して、非ディレクトリタイプだけに適用されます。 使用される値のリストはIANA登録のそばでガイドラインセットに続かなければなりません。
media-type = "Media-Type" "=" <per IANA guidelines>
メディアタイプ=「メディアタイプ」はIANAガイドライン>あたりの<と「等しいです」。
Server-FTP implementations MUST NOT guess media type values. Media type values must be determined in an unambiguous way such as file system tagging of media-type or by user configuration. This fact gives information about the content of the file named. Both the primary media type, and any appropriate subtype should be given, separated by a slash "/" as is traditional.
サーバFTP実装は、メディアが値をタイプすると推測してはいけません。 メディアタイプのファイルシステムタグ付けなどの明白な方法かユーザ構成でタイプが評価するメディアを決定しなければなりません。 この事実は指定されたファイルの中身に関する情報を与えます。 そのままで「両方のプライマリメディアがタイプされて、どんな適切な「副-タイプ」も、与えられるべきであり、スラッシュで」 /を切り離しました」。伝統的。
7.5.9. The charset Fact
7.5.9. charset Fact
The charset fact provides the IANA character set name, or alias, for the encoded pathnames in a MLSx response. The default character set is UTF-8 unless specified otherwise. FTP implementations SHOULD use UTF-8 if possible to encourage maximum inter-operability. The value of this fact applies to the pathname only, and provides no information about the contents of the file.
charset事実はMLSx応答でIANA文字集合名を通称コード化されたパス名に提供します。 別の方法で指定されない場合、デフォルト文字集合はUTF-8です。 FTP実装SHOULDは、できれば、最大の相互運用性を奨励するのにUTF-8を使用します。 この事実の値は、パス名だけに適用して、ファイルのコンテンツに関して情報を全く提供しません。
charset-type = "Charset" "=" token
charset-タイプ="Charset"はトークンと「等しいです」。
7.5.10. Required Facts
7.5.10. 必要な事実
Servers are not required to support any particular set of the available facts. However, servers SHOULD, if conceivably possible, support at least the type, perm, size, unique, and modify facts.
サーバは、利用可能な事実のどんな特定のセットも支えるのに必要ではありません。 しかしながら、サーバSHOULDは多分可能であるなら少なくともタイプ、パーマ、ユニークなサイズをサポートして、事実を変更します。
7.6. System Dependent and Local Facts
7.6. システムに依存してローカルの事実
By using an system dependent fact, or a local fact, a server-PI may communicate to the user-PI information about the file named that is peculiar to the underlying file system.
システムに依存する事実、またはローカルの事実を使用することによって、サーバ-PIは指定された基本的なファイルシステムに独特のファイルのユーザ-PI情報に交信するかもしれません。
7.6.1. System Dependent Facts
7.6.1. システムに依存する事実
System dependent fact names are labeled by prefixing a label identifying the specific information returned by the name of the appropriate operating system from the IANA maintained list of operating system names.
システムに依存する事実名は、適切なオペレーティングシステムの名前によってオペレーティングシステム名のリストであることが支持されたIANAから返された特殊情報を特定するラベルを前に置くことによって、ラベルされます。
The value of an OS dependent fact may be whatever is appropriate to convey the information available. It must be encoded as a "token" as defined in section 2.1 however.
OSに依存する事実の値は利用可能な情報を伝えるのが適切であることなら何でもであるかもしれません。 しかしながら、セクション2.1で定義される「トークン」としてそれをコード化しなければなりません。
Hethmon Standards Track [Page 36] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[36ページ]。
In order to allow reliable inter-operation between users of system dependent facts, the IANA will maintain a registry of system dependent fact names, their syntax, and the interpretation to be given to their values. Registrations of system dependent facts are to be accomplished according to the procedures of section 10.
システムのユーザの間の信頼できる相互操作に依存する事実を許容するために、IANAは、システムの登録がそれらの値にされる依存する事実名と、それらの構文と、解釈であることを支持するでしょう。 システムに依存する事実の登録証明書はセクション10の手順によると、達成されることです。
7.6.2. Local Facts
7.6.2. ローカルの事実
Implementations may also make available other facts of their own choosing. As the method of interpretation of such information will generally not be widely understood, server-PIs should be aware that clients will typically ignore any local facts provided. As there is no registration of locally defined facts, it is entirely possible that different servers will use the same local fact name to provide vastly different information. Hence user-PIs should be hesitant about making any use of any information in a locally defined fact without some other specific assurance that the particular fact is one that they do comprehend.
また、実装はそれら自身が選ぶ他の利用可能な事実を作るかもしれません。 そのような情報の解釈のメソッドが一般に広く理解されないので、サーバ-PIsはクライアントが提供されたどんなローカルの事実も通常無視するのを意識しているべきです。 局所的に定義された事実の登録が全くないとき、異なったサーバが広大に異なった情報を提供するのに同じローカルの事実名を使用するのは、完全に可能です。 したがって、ユーザ-PIsは特定の事実が彼らが理解するものであるというある他の特定の保証なしで局所的に定義された事実におけるどんな情報のどんな使用もすることに関してためらっているべきです。
Local fact names all begin with the sequence "X.". The rest of the name is a "token" (see section 2.1). The value of a local fact can be anything at all, provided it can be encoded as a "token".
ローカルの事実名は系列「X.」ですべて始まります。 名前の残りは「トークン」(セクション2.1を見る)です。 「トークン」としてそれをコード化できるなら、ローカルの事実の値は全く何かであるかもしれません。
7.7. MLSx Examples
7.7. MLSxの例
The following examples are all taken from dialogues between existing FTP clients and servers. Because of this, not all possible variations of possible response formats are shown in the examples. This should not be taken as limiting the options of other server implementors. Where the examples show OS dependent information, that is to be treated as being purely for the purposes of demonstration of some possible OS specific information that could be defined. As at the time of the writing of this document, no OS specific facts or file types have been defined, the examples shown here should not be treated as in any way to be preferred over other possible similar definitions. Consult the IANA registries to determine what types and facts have been defined. Finally also beware that as the examples shown are taken from existing implementations, coded before this document was completed, the possibility of variations between the text of this document and the examples exists. In any such case of inconsistency, the example is to be treated as incorrect.
既存のFTPクライアントとサーバとの対話から以下の例をすべて取ります。 これのために、可能な応答形式のすべての可能な変化が例に示されるというわけではありません。 他のサーバ作成者のオプションを制限するとこれをみなすべきではありません。 例がOSに依存する情報を示しているところでは、それは純粋に定義できた何らかの可能なOS特殊情報のデモンストレーションの目的のためにあるとして扱われることになっています。 このドキュメントの書くこと時点でどんなOSの特定の事実もファイルの種類も定義していないとき、他の可能な同様の定義より好まれるべきどんな方法のようにもここに示された例を扱うべきではありません。 IANA登録に相談して、どんなタイプと事実が定義されたか決定してください。 このドキュメントが完成する前に、また、既存の実装から示された例を取るとき最終的にそれに注意して、コード化されて、このドキュメントの原本と例の間の変化の可能性は存在しています。 矛盾のどんなそのような場合でも、例は不正確であるとして扱われることです。
In the examples shown, only relevant commands and responses have been included. This is not to imply that other commands (including authentication, directory modification, PORT or PASV commands, or similar) would not be present in an actual connection, or were not, in fact, actually used in the examples before editing. Note also that the formats shown are those that are transmitted between client
示された例では、関連コマンドと応答だけが含まれています。 これは、他のコマンド(コマンド、または同様の状態で認証、ディレクトリ変更、PORTまたはPASVを含んでいる)が実際の接続で存在していないだろうか、または事実上、編集の前に実際に例で使用されなかったのを含意しないためのものです。 また、示された書式がクライアントの間に伝えられるものであることに注意してください。
Hethmon Standards Track [Page 37] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[37ページ]。
and server, not formats that would normally ever be reported to the user of the client.
サーバ、通常、かつてクライアントのユーザに報告される書式でない。
7.7.1. Simple MLST
7.7.1. 簡単なMLST
C> PWD S> 257 "/tmp" is current directory. C> MLst cap60.pl198.tar.gz S> 250- Listing cap60.pl198.tar.gz S> Type=file;Size=1024990;Perm=r; /tmp/cap60.pl198.tar.gz S> 250 End
「C>PWD S>257インチ/tmp」はカレントディレクトリです。 cap60.pl198.tar.gz S>Typeを記載するC>MLst cap60.pl198.tar.gz S>250=ファイル; サイズ=1024990; =rにパーマをかけてください。 /tmp/cap60.pl198.tar.gz S>250エンド
The client first asked to be told the current directory of the server. This was purely for the purposes of clarity of this example. The client then requested facts about a specific file. The server returned the "250-" first control-response line, followed by a single line of facts about the file, followed by the terminating "250 " line. The text on the control-response line and the terminating line can be anything the server decides to send. Notice that the fact line is indented by a single space. Notice also that there are no spaces in the set of facts returned, until the single space before the file name. The file name returned on the fact line is a fully qualified pathname of the file listed. The facts returned show that the line refers to a file, that file contains approximately 1024990 bytes, though more or less than that may be transferred if the file is retrieved, and a different number may be required to store the file at the client's file store, and the connected user has permission to retrieve the file but not to do anything else particularly interesting.
クライアントは、最初に、サーバのカレントディレクトリが言われるように頼みました。これは純粋にこの例の明快の目的のためのものでした。 そして、クライアントは特定のファイルに関する事実を要求しました。 サーバは「250」が裏打ちする終わりがあとに続いた「250」最初の操舵応答系列を返しました、続いて、ファイルに関する事実の単線を返します。 操舵応答系列と終わり系列に関するテキストはサーバが送ると決める何かであるかもしれません。 事実系列がシングルスペースによって字下がりにされるのに注意してください。 また、ファイル名の前にシングルスペースまで返された事実のセットに空間が全くないのに注意してください。 系列がファイルの完全に適切なパス名であるという事実で返されたファイル名はリストアップされました。 ファイルが取られて、異なった数がクライアントのファイル店にファイルを保存するのに必要であるかもしれないなら、返された事実は、系列がファイルを示して、多少ですが、ファイルがそれを移すかもしれないよりおよそ1024990バイトを含むのを示します、そして、接続ユーザには、特に他の何かおもしろいことをするのではなく、ファイルを取る許可があります。
7.7.2. MLST of a directory
7.7.2. ディレクトリのMLST
C> PWD S> 257 "/" is current directory. C> MLst tmp S> 250- Listing tmp S> Type=dir;Modify=19981107085215;Perm=el; /tmp S> 250 End
「C>PWD S>257インチ/」はカレントディレクトリです。 tmp S>Type=dirを記載するC>MLst tmp S>250; =19981107085215を変更してください; =高架鉄道にパーマをかけてください。 tmp S>250が終わらせる/
Again the PWD is just for the purposes of demonstration for the example. The MLST fact line this time shows that the file listed is a directory, that it was last modified at 08:52:15 on the 7th of November, 1998 UTC, and that the user has permission to enter the directory, and to list its contents, but not to modify it in any way. Again, the fully qualified pathname of the directory listed is given.
一方、PWDはまさしく例のためのデモンストレーションの目的のためのものです。 今回のMLST事実系列はリストアップされたファイルがディレクトリであり、11月7日08:52:15に変更された最終、協定世界時1998であり、ユーザにはディレクトリを入力して、何らかの方法でそれを変更するのではなく、コンテンツを記載する許可があるのを示します。 一方、リストアップされたディレクトリの完全に適切なパス名を与えます。
Hethmon Standards Track [Page 38] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[38ページ]。
7.7.3. MLSD of a directory
7.7.3. ディレクトリのMLSD
C> MLSD tmp S> 150 BINARY connection open for MLSD tmp D> Type=cdir;Modify=19981107085215;Perm=el; tmp D> Type=cdir;Modify=19981107085215;Perm=el; /tmp D> Type=pdir;Modify=19990112030508;Perm=el; .. D> Type=file;Size=25730;Modify=19940728095854;Perm=; capmux.tar.z D> Type=file;Size=1830;Modify=19940916055648;Perm=r; hatch.c D> Type=file;Size=25624;Modify=19951003165342;Perm=r; MacIP-02.txt D> Type=file;Size=2154;Modify=19950501105033;Perm=r; uar.netbsd.patch D> Type=file;Size=54757;Modify=19951105101754;Perm=r; iptnnladev.1.0.sit.hqx D> Type=file;Size=226546;Modify=19970515023901;Perm=r; melbcs.tif D> Type=file;Size=12927;Modify=19961025135602;Perm=r; tardis.1.6.sit.hqx D> Type=file;Size=17867;Modify=19961025135602;Perm=r; timelord.1.4.sit.hqx D> Type=file;Size=224907;Modify=19980615100045;Perm=r; uar.1.2.3.sit.hqx D> Type=file;Size=1024990;Modify=19980130010322;Perm=r; cap60.pl198.tar.gz S> 226 MLSD completed
MLSD tmp D>Type=cdirに、オープンなC>MLSD tmp S>150BINARY接続; =19981107085215を変更してください; =高架鉄道にパーマをかけてください。 tmp D>Type=cdir; =19981107085215を変更してください; =高架鉄道にパーマをかけてください。 /tmp D>タイプはpdirと等しいです; =19990112030508を変更してください; =高架鉄道にパーマをかけてください。 .. D>タイプ=ファイル; サイズ=25730; =19940728095854を変更してください; =にパーマをかけてください。 capmux.tar.z D>Type=ファイル; サイズ=1830; =19940916055648を変更してください; =rにパーマをかけてください。 hatch.c D>Type=ファイル; サイズ=25624; =19951003165342を変更してください; =rにパーマをかけてください。 MacIP-02.txt D>タイプ=ファイル; サイズ=2154; =19950501105033を変更してください; =rにパーマをかけてください。 uar.netbsd.patch D>Type=ファイル; サイズ=54757; =19951105101754を変更してください; =rにパーマをかけてください。 iptnnladev.1.0.sit.hqx D>Type=ファイル; サイズ=226546; =19970515023901を変更してください; =rにパーマをかけてください。 melbcs.tif D>Type=ファイル; サイズ=12927; =19961025135602を変更してください; =rにパーマをかけてください。 tardis.1.6.sit.hqx D>Type=ファイル; サイズ=17867; =19961025135602を変更してください; =rにパーマをかけてください。 timelord.1.4.sit.hqx D>Type=ファイル; サイズ=224907; =19980615100045を変更してください; =rにパーマをかけてください。 uar.1.2.3.sit.hqx D>Type=ファイル; サイズ=1024990; =19980130010322を変更してください; =rにパーマをかけてください。 >226MLSDが完成したcap60.pl198.tar.gz S
In this example notice that there is no leading space on the fact lines returned over the data connection. Also notice that two lines of "type=cdir" have been given. These show two alternate names for the directory listed, one a fully qualified pathname, and the other a local name relative to the servers current directory when the MLSD was performed. Note that all other file names in the output are relative to the directory listed, though the server could, if it chose, give a fully qualified pathname for the "type=pdir" line. This server has chosen not to. The other files listed present a fairly boring set of files that are present in the listed directory. Note that there is no particular order in which they are listed. They are not sorted by file name, by size, or by modify time. Note also that the "perm" fact has an empty value for the file "capmux.tar.z" indicating that the connected user has no permissions at all for that file. This server has chosen to present the "cdir" and "pdir" lines before the lines showing the content of the directory, it is not required to do so. The "size" fact does not provide any meaningful information for a directory, so is not included in the fact lines for the directory types shown.
あるこの例の通知では、事実系列でどんな主なスペースもデータ接続の上で戻りませんでした。 また、「タイプ=cdir」の2つの系列が与えられているのに注意してください。 これらは、MLSDであるときに、サーバカレントディレクトリに比例した地方名が実行されたのをリストアップされたディレクトリ、完全に適切なパス名あたり1つ、およびもう片方のための2つの別名称に示します。 出力における他のすべてのファイル名が選ぶならサーバが「タイプ=pdir」系列のために完全に適切なパス名を与えるかもしれませんが、リストアップされたディレクトリに比例していることに注意してください。 このサーバは、そうしないのを選びました。 リストアップされた他のファイルはかなり退屈なセットの記載されたディレクトリに存在しているファイルを提示します。 それらが記載されているどんな特定のオーダーもないことに注意してください。 彼らは、ファイル名、サイズによって分類されないか、または時間を変更します。 また、接続ユーザには許容がそのファイルのために全くないのを示しながら「パーマ」事実に"capmux.tar.z"というファイルのための空の値があることに注意してください。 このサーバは、ディレクトリの中身を示している系列の前に"cdir"と"pdir"系列を提示するのを選んで、それは、そうするのに必要ではありません。 「サイズ」事実は、少しの有意義な情報もディレクトリに供給しないので、見せられたディレクトリタイプのために事実系列で含められていません。
Hethmon Standards Track [Page 39] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[39ページ]。
7.7.4. A More Complex Example
7.7.4. より複雑な例
C> MLst test S> 250- Listing test S> Type=dir;Perm=el;Unique=keVO1+ZF4 test S> 250 End C> MLSD test S> 150 BINARY connection open for MLSD test D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test D> Type=pdir;Perm=e;Unique=keVO1+d?3; .. D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar D> Type=OS.unix=chr-13/29;Perm=;Unique=keVO1+5G4; device D> Type=OS.unix=blk-11/108;Perm=;Unique=keVO1+6G4; block D> Type=file;Perm=awr;Unique=keVO1+8G4; writable D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; promiscuous D> Type=dir;Perm=;Unique=keVO1+1t2; no-exec D> Type=file;Perm=r;Unique=keVO1+EG4; two words D> Type=file;Perm=r;Unique=keVO1+IH4; leading space D> Type=file;Perm=r;Unique=keVO1+1G4; file1 D> Type=dir;Perm=cpmel;Unique=keVO1+7G4; incoming D> Type=file;Perm=r;Unique=keVO1+1G4; file2 D> Type=file;Perm=r;Unique=keVO1+1G4; file3 D> Type=file;Perm=r;Unique=keVO1+1G4; file4 S> 226 MLSD completed C> MLSD test/incoming S> 150 BINARY connection open for MLSD test/incoming D> Type=cdir;Perm=cpmel;Unique=keVO1+7G4; test/incoming D> Type=pdir;Perm=el;Unique=keVO1+ZF4; .. D> Type=file;Perm=awdrf;Unique=keVO1+EH4; bar D> Type=file;Perm=awdrf;Unique=keVO1+LH4; D> Type=file;Perm=rf;Unique=keVO1+1G4; file5 D> Type=file;Perm=rf;Unique=keVO1+1G4; file6 D> Type=dir;Perm=cpmdelf;Unique=keVO1+!s2; empty S> 226 MLSD completed
テストS>Type=dirを記載するC>MLstテストS>250; パーマ=高架鉄道; MLSDテストD>Type=cdirに、オープンなユニークな=keVO1+ZF4テストS>250End C>MLSDテストS>150BINARY接続; =高架鉄道にパーマをかけてください; ユニークな=keVO1+ZF4 テストD>Type=pdir; e; =ユニークな=keVO1+dにパーマをかけてください--3 .. D>タイプ=OS.unix=はそっと歩きます: /foobar; パーマ=; ユニークな=keVO1+4G4 foobar D>Type=OS.unix=chr-13/29; =にパーマをかけてください; ユニークな=keVO1+5G4 デバイスD>Type=OS.unix=blk-11/108; =にパーマをかけてください; ユニークな=keVO1+6G4 ブロックD>Type=はファイルします; =awrにパーマをかけてください; ユニークな=keVO1+8G4 書き込み可能なD>Type=dir; =cpmelにパーマをかけてください; ユニークな=keVO1+7G4 無差別なD>Type=dir; =にパーマをかけてください; ユニークな=keVO1+1t2 幹部がないD>Type=はファイルします; =rにパーマをかけてください; ユニークな=keVO1+EG4 2つの単語Dの>Type=ファイル; =rにパーマをかけてください; ユニークな=keVO1+IH4 主なスペースD>Type=はファイルします; =rにパーマをかけてください; ユニークな=keVO1+1G4 file1D>Type=dir; =cpmelにパーマをかけてください; ユニークな=keVO1+7G4 入って来るD>Type=はファイルします; =rにパーマをかけてください; ユニークな=keVO1+1G4 file2D>Type=はファイルします; =rにパーマをかけてください; ユニークな=keVO1+1G4 file3D>Type=はファイルします; =rにパーマをかけてください; ユニークな=keVO1+1G4 file4 S>226MLSDはMLSDテスト/入って来るD>Type=cdirに、オープンなC>MLSDテスト/入って来るS>150BINARY接続を終了しました; =cpmelにパーマをかけてください; ユニークな=keVO1+7G4 テスト/入って来るD>Type=pdir; =高架鉄道にパーマをかけてください; ユニークな=keVO1+ZF4 .. D>タイプ=はファイルします; =awdrfにパーマをかけてください; ユニークな=keVO1+EH4 バーD>Type=はファイルします; =awdrfにパーマをかけてください; ユニークな=keVO1+LH4 D>タイプ=はファイルします; =rfにパーマをかけてください; ユニークな=keVO1+1G4 file5D>Type=はファイルします; =rfにパーマをかけてください; ユニークな=keVO1+1G4 file6D>Type=dir; =cpmdelfにパーマをかけてください; ユニークな=keVO1+!s2 226MLSDが完成した空のS>。
For the purposes of this example the fact set requested has been modified to delete the "size" and "modify" facts, and add the "unique" fact. First, facts about a file name have been obtained via MLST. Note that no fully qualified pathname was given this time. That was because the server was unable to determine that information. Then having determined that the file name represents a directory, that directory has been listed. That listing also shows no fully qualified pathname, for the same reason, thus has but a single "type=cdir" line. This directory (which was created especially for the purpose) contains several interesting files. There are some with OS dependent file types, several sub-directories, and several ordinary files.
この例の目的において、要求された事実セットは、「サイズ」を削除して、事実を「変更し」て、「ユニークな」事実を加えるように変更されました。 まず最初に、MLSTを通してファイル名に関する事実を得ました。今回がどんな完全に適切なパス名にも与えられなかったことに注意してください。 それはサーバがその情報を決定できなかったからです。 次に、ファイル名がディレクトリを表すことを決定したので、そのディレクトリはリストアップされています。 また、そのリストは、同じ理由で、その結果、どんな完全に適切なパス名も持っていないのを示しますが、単一の「タイプ=cdir」は立ち並んでいます。 このディレクトリ(特に目的のために作成された)はいくつかのおもしろいファイルを含んでいます。 何かが依存するファイルがタイプするOS、いくつかのサブディレクトリ、およびいくつかの普通のファイルであります。
Hethmon Standards Track [Page 40] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[40ページ]。
Not much can be said here about the OS dependent file types, as none of the information shown there should be treated as any more than possibilities. It can be seen that the OS type of the server is "unix" though, which is one of the OS types in the IANA registry of Operating System names.
ここで依存するファイルがタイプするOSに関して多くを言うことができるというわけではありません、そこに示された情報のどれかを可能性よりもっと多くのものとして扱うべきでないとき。 もっとも、サーバのOSタイプが「unix」であると見ることができて、どれがOSのひとりであるかはOperating System名のIANA登録をタイプします。
Of the three directories listed, "no-exec" has no permission granted to this user to access at all. From the "Unique" fact values, it can be determined that "promiscuous" and "incoming" in fact represent the same directory. Its permissions show that the connected user has permission to do essentially anything other than to delete the directory. That directory was later listed. It happens that the directory can not be deleted because it is not empty.
リストアップされた3つのディレクトリでは、「幹部がありません」は全くアクセスするこのユーザに許可を全く与えさせません。 「ユニークな」事実値から、事実上、「無差別」、そして、「入来」が同じディレクトリを表すことを決定できます。 許容は、接続ユーザには本質的にはディレクトリを削除するのを除いた何でもする許可があるのを示します。 そのディレクトリは後でリストアップされました。 それが空でないので、偶然、ディレクトリを削除できません。
Of the normal files listed, two contain spaces in their names. The file called " leading space" actually contains two spaces in its name, one before the "l" and one between the "g" and the "s". The two spaces that separate the facts from the visible part of the pathname make that clear. The file "writable" has the "a" and "w" permission bits set, and consequently the connected user should be able to STOR or APPE to that file.
リストアップされた正常なファイルでは、2がそれらの名前の空間を含んでいます。 「主なスペース」と呼ばれるファイルは実際に名前、「l」の前の1、および「g」と「s」の間の1に2つの空間を含んでいます。 パス名の目に見える部分と事実を切り離す2つの空間がそれを明らかにします。 「書き込み可能な」ファイルで“a"と「w」許可ビットを用意ができさせます、そして、その結果、接続ユーザはそのファイルへのSTORかAPPEにできるべきです。
The other four file names, "file1", "file2", "file3", and "file4" all represent the same underlying file, as can be seen from the values of the "unique" facts of each. It happens that "file1" and "file2" are Unix "hard" links, and that "file3" and "file4" are "soft" or "symbolic" links to the first two. None of that information is available via standard MLST facts, it is sufficient for the purposes of FTP to note that all represent the same file, and that the same data would be fetched no matter which of them was retrieved, and that all would be simultaneously modified were data stored in any.
他の4が名前をファイルする、「file1"、「file2"、「file3"、および「それぞれの「ユニークな」事実の値から見ることができるようにファイルの基礎となるすべてが同じように表すfile4"。」 そして、偶然、「file1"、「Unixが「困難である」というfile2"リンク、およびそれ、「file3"と「file4"は最初の2への「柔らかい」か「シンボリックな」リンクです」。 その情報のいずれも標準のMLST事実で利用可能でない、FTPの目的が、すべてが同じファイルを表して、それらのどれが検索されても同じデータがとって来られて、格納されたデータがいずれかにあるならすべてが同時に変更されることに注意するのは、十分です。
Finally, the sub-directory "incoming" is listed. Since "promiscuous"
is the same directory there would be no point listing it as well. In
that directory, the files "file5" and "file6" represent still more
names for the "file1" file we have seen before. Notice the entry
between that for "bar" and "file5". Though it is not possible to
easily represent it in this document, that shows a file with a name
comprising exactly three spaces (" "). A client will have no
difficulty determining that name from the output presented to it
however. The directory "empty" is, as its name implies, empty,
though that is not shown here. It can, however, be deleted, as can
file "bar" and the file whose name is three spaces. All the files
that reside in this directory can be renamed. This is a consequence
of the UNIX semantics of the directory that contains them being
modifiable.
最終的に、「入来」というサブディレクトリは記載されています。 「無差別である」時から、あるだろう同じディレクトリはまた、それを記載するポイントではありませんか? そして、そのディレクトリ、ファイル、「file5"、「まして、file6"は「私たちが以前見たことがあるfile1"ファイル」のために名前を表します。 「バー」へのそれと"file5""の間のエントリーに注意してください。 容易に本書ではそれを表すのが可能ではありませんが、それが名前がまさに3つの空間を包括しているファイルを見せている、(「「)、」 クライアントはしかしながら、それに寄贈された出力からその名前を決定するのに全く苦労しないでしょう。名前が含意するように「空になる」というディレクトリは空です、それがここに示されませんが。 しかしながら、「バー」というファイルと名前が3つの空間であるファイルであることができることのようにそれを削除できます。 このディレクトリにあるすべてのファイルは改名できます。 これは修正できるのでそれらを含むディレクトリのUNIX意味論の結果です。
Hethmon Standards Track [Page 41] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[41ページ]。
7.7.5. More Accurate Time Information
7.7.5. より正確な時間情報
C> MLst file1 S> 250- Listing file1 S> Type=file;Modify=19990929003355.237; file1 S> 250 End
file1 S>Type=を記載するC>MLst file1 S>250がファイルします; =19990929003355.237を変更してください。 file1 S>250End
In this example, the server-FTP is indicating that "file1" was last modified 237 milliseconds after 00:33:55 UTC on the 29th of September, 1999.
この例では、「file1"は1999年9月29日協定世界時0時33分55秒の237ミリセカンドと同じくらいの後に最後に変更されました。」と、サーバFTPは示しています。
7.7.6. A Different Server
7.7.6. 異なったサーバ
C> MLST S> 250-Begin S> type=dir;unique=AQkAAAAAAAABCAAA; / S> 250 End. C> MLSD S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABCAAA; / D> type=dir;unique=AQkAAAAAAAABEAAA; bin D> type=dir;unique=AQkAAAAAAAABGAAA; etc D> type=dir;unique=AQkAAAAAAAAB8AwA; halflife D> type=dir;unique=AQkAAAAAAAABoAAA; incoming D> type=dir;unique=AQkAAAAAAAABIAAA; lib D> type=dir;unique=AQkAAAAAAAABWAEA; linux D> type=dir;unique=AQkAAAAAAAABKAEA; ncftpd D> type=dir;unique=AQkAAAAAAAABGAEA; outbox D> type=dir;unique=AQkAAAAAAAABuAAA; quake2 D> type=dir;unique=AQkAAAAAAAABQAEA; winstuff S> 226 Listing completed. C> MLSD linux S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABWAEA; /linux D> type=pdir;unique=AQkAAAAAAAABCAAA; / D> type=dir;unique=AQkAAAAAAAABeAEA; firewall D> type=file;size=12;unique=AQkAAAAAAAACWAEA; helo_world D> type=dir;unique=AQkAAAAAAAABYAEA; kernel D> type=dir;unique=AQkAAAAAAAABmAEA; scripts D> type=dir;unique=AQkAAAAAAAABkAEA; security S> 226 Listing completed. C> MLSD linux/kernel S> 150 Opening ASCII mode data connection for MLS. D> type=cdir;unique=AQkAAAAAAAABYAEA; /linux/kernel D> type=pdir;unique=AQkAAAAAAAABWAEA; /linux D> type=file;size=6704;unique=AQkAAAAAAAADYAEA; k.config D> type=file;size=7269221;unique=AQkAAAAAAAACYAEA; linux-2.0.36.tar.gz D> type=file;size=12514594;unique=AQkAAAAAAAAEYAEA; linux-2.1.130.tar.gz
C>MLST S>、250、-始まってください、S>は=dirをタイプします; ユニークな=AQkAAAAAAAABCAAA /S>250は終わります。 MLSのためのC>MLSD S>150Opening ASCIIモードデータ接続。 D>は=cdirをタイプします; ユニークな=AQkAAAAAAAABCAAA /D>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABEAAA 容器D>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABGAAA などD>は=dirをタイプします; ユニークな=AQkAAAAAAAAB8AwA 半減期D>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABoAAA 入って来るD>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABIAAA リブD>は=dirをタイプします; ユニークな=AQkAAAAAAAABWAEA linux D>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABKAEA ncftpd D>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABGAEA 送信トレイD>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABuAAA quake2D>は=dirをタイプします; ユニークな=AQkAAAAAAAABQAEA 226Listingが完成したwinstuff S>。 MLSのためのC>MLSD linux S>150Opening ASCIIモードデータ接続。 D>は=cdirをタイプします; ユニークな=AQkAAAAAAAABWAEA /linux D>タイプはpdirと等しいです; ユニークな=AQkAAAAAAAABCAAA /D>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABeAEA ファイアウォールD>タイプはファイル; サイズ=12; ユニークな=AQkAAAAAAAACWAEAと等しいです。 helo_世界D>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABYAEA カーネルD>タイプはdirと等しいです; ユニークな=AQkAAAAAAAABmAEA D>がタイプするスクリプトはdirと等しいです; ユニークな=AQkAAAAAAAABkAEA >226Listingが完成したセキュリティS。 MLSのためのC>MLSD linux/カーネルS>150Opening ASCIIモードデータ接続。 D>は=cdirをタイプします; ユニークな=AQkAAAAAAAABYAEA /linux/kernel D>は=pdirをタイプします; ユニークな=AQkAAAAAAAABWAEA /linux D>タイプはファイル; サイズ=6704; ユニークな=AQkAAAAAAAADYAEAと等しいです。 k. コンフィグD>は=ファイル; サイズ=7269221; ユニークな=AQkAAAAAAAACYAEAをタイプします。 linux-2.0.36.tar.gz D>は=ファイル; サイズ=12514594; ユニークな=AQkAAAAAAAAEYAEAをタイプします。 linux-2.1.130.tar.gz
Hethmon Standards Track [Page 42] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[42ページ]。
S> 226 Listing completed.
226リストが完成したS>。
Note that this server returns its "unique" fact value in quite a different format. It also returns fully qualified pathnames for the "pdir" entry.
このサーバがかなり異なった形式で「ユニークな」事実値を返すことに注意してください。 また、それは"pdir"エントリーに完全に適切なパス名を返します。
7.7.7. Some IANA Files
7.7.7. いくつかのIANAファイル
C> MLSD S> 150 BINARY connection open for MLSD . D> Type=cdir;Modify=19990219183438; /iana/assignments D> Type=pdir;Modify=19990112030453; .. D> Type=dir;Modify=19990219073522; media-types D> Type=dir;Modify=19990112033515; character-set-info D> Type=dir;Modify=19990112033529; languages D> Type=file;Size=44242;Modify=19990217230400; character-sets D> Type=file;Size=1947;Modify=19990209215600; operating-system-names S> 226 MLSD completed C> MLSD media-types S> 150 BINARY connection open for MLSD media-types D> Type=cdir;Modify=19990219073522; media-types D> Type=cdir;Modify=19990219073522; /iana/assignments/media-types D> Type=pdir;Modify=19990219183438; .. D> Type=dir;Modify=19990112033045; text D> Type=dir;Modify=19990219183442; image D> Type=dir;Modify=19990112033216; multipart D> Type=dir;Modify=19990112033254; video D> Type=file;Size=30249;Modify=19990218032700; media-types S> 226 MLSD completed C> MLSD character-set-info S> 150 BINARY connection open for MLSD character-set-info D> Type=cdir;Modify=19990112033515; character-set-info D> Type=cdir;Modify=19990112033515; /iana/assignments/character-set-info D> Type=pdir;Modify=19990219183438; .. D> Type=file;Size=1234;Modify=19980903020400; windows-1251 D> Type=file;Size=4557;Modify=19980922001400; tis-620 D> Type=file;Size=801;Modify=19970324130000; ibm775 D> Type=file;Size=552;Modify=19970320130000; ibm866 D> Type=file;Size=922;Modify=19960505140000; windows-1258 S> 226 MLSD completed C> MLSD languages S> 150 BINARY connection open for MLSD languages D> Type=cdir;Modify=19990112033529; languages D> Type=cdir;Modify=19990112033529; /iana/assignments/languages D> Type=pdir;Modify=19990219183438; .. D> Type=file;Size=2391;Modify=19980309130000; default D> Type=file;Size=943;Modify=19980309130000; tags D> Type=file;Size=870;Modify=19971026130000; navajo
MLSD D>Type=cdirに、オープンなC>MLSD S>150BINARY接続; =19990219183438を変更してください。 /iana/assignments D>は=pdirをタイプします; =19990112030453を変更してください。 .. D>は=dirをタイプします; =19990219073522を変更してください。 メディアタイプD>Type=dir; =19990112033515を変更してください。 キャラクタセットインフォメーションD>Type=dir; =19990112033529を変更してください。 言語D>Type=ファイル; サイズ=44242; =19990217230400を変更してください。 文字の組D>Type=ファイル; サイズ=1947; =19990209215600を変更してください。 操作システム名のS>226MLSDはMLSDメディアタイプD>Type=cdirに、オープンなCメディアタイプS>150BINARY>MLSD接続を終了しました; =19990219073522を変更してください。 メディアタイプD>Type=cdir; =19990219073522を変更してください。 /iana/assignments/media-タイプD>タイプはpdirと等しいです; =19990219183438を変更してください。 .. D>は=dirをタイプします; =19990112033045を変更してください。 テキストD>Type=dir; =19990219183442を変更してください。 イメージD>Type=dir; =19990112033216を変更してください。 複合D>Type=dir; =19990112033254を変更してください。 ビデオD>Type=ファイル; サイズ=30249; =19990218032700を変更してください。 メディアタイプS>226MLSDはMLSDキャラクタセットインフォメーションD>Type=cdirに、オープンなCキャラクタセットインフォメーションS>150BINARY>MLSD接続を終了しました; =19990112033515を変更してください。 キャラクタセットインフォメーションD>Type=cdir; =19990112033515を変更してください。 /iana/assignments/characterセットインフォメーションD>は=pdirをタイプします; =19990219183438を変更してください。 .. D>タイプ=ファイル; サイズ=1234; =19980903020400を変更してください。 窓-1251D>Type=ファイル; サイズ=4557; =19980922001400を変更してください。 tis-620 D>Type=ファイル; サイズ=801; =19970324130000を変更してください。 ibm775 D>Type=ファイル; サイズ=552; =19970320130000を変更してください。 ibm866 D>Type=ファイル; サイズ=922; =19960505140000を変更してください。 窓1258秒間のMLSD言語D>Type=cdirに、オープンな>226のMLSDの完成したC>MLSD言語S>150BINARY接続; =19990112033529を変更してください。 言語D>Type=cdir; =19990112033529を変更してください。 /iana/assignments/languages D>は=pdirをタイプします; =19990219183438を変更してください。 .. D>タイプ=ファイル; サイズ=2391; =19980309130000を変更してください。 デフォルトD>Type=ファイル; サイズ=943; =19980309130000を変更してください。 >Type=がファイルするタグD; サイズ=870; =19971026130000を変更してください。 navajo
Hethmon Standards Track [Page 43] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[43ページ]。
D> Type=file;Size=699;Modify=19950911140000; no-bok S> 226 MLSD completed C> PWD S> 257 "/iana/assignments" is current directory.
D>タイプ=ファイル; サイズ=699; =19950911140000を変更してください。 bok Sの>の226のMLSDの完成したC>がないPWD S>257"/iana/assignments"はカレントディレクトリです。
This example shows some of the IANA maintained files that are relevant for this specification in MLSD format. Note that these listings have been edited by deleting many entries, the actual listings are much longer.
この例はMLSD形式におけるこの仕様において、関連しているファイルであることが支持されたいくらかのIANAを示しています。 これらのリストが多くのエントリーを削除することによって編集されたことに注意してください、そして、実際のリストははるかに長いです。
7.7.8. A Stress Test of Case (In)dependence
7.7.8. ケース(In)の依存のストレス試験
The following example is intended to make clear some cases where case dependent strings are permitted in the MLSx commands, and where case independent strings are required.
以下の例は依存するストリングがMLSxで受入れられるケースがケースから独立しているところで命令するいくつかのケースを明らかにすることを意図して、ストリングが必要であるということです。
Note first that the "MLSD" command, shown here as "MlsD" is case independent. Clients may issue this command in any case, or combination of cases, they desire. This is the case for all FTP commands.
"MlsD"がケース独立者であるのにここに示された最初に、その"MLSD"コマンドに注意してください。 それらは、クライアントがどんな場合でもこのコマンド、またはケースの組み合わせを発行するかもしれないことを望んでいます。 これはすべてのFTPコマンドのためのそうです。
C> MlsD S> 150 BINARY connection open for MLSD . D> Type=pdir;Modify=19990929011228;Perm=el;Unique=keVO1+ZF4; .. D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; FILE2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+aG8; file3 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+ag8; FILE3 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file1 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; file2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Ag8; File3 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bD8; File1 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+Bd8; File2 D> Type=file;Size=4096;Modify=19990929011440;Perm=r;Unique=keVO1+bd8; FILE1 S> 226 MLSD completed
MLSD D>Type=pdirに、オープンなC>MlsD S>150BINARY接続; =19990929011228を変更してください; =高架鉄道にパーマをかけてください; ユニークな=keVO1+ZF4 .. D>タイプ=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+Bd8 FILE2D>タイプ=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+aG8 file3D>Type=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+ag8 FILE3D>タイプ=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+bD8 file1D>Type=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+bD8 file2D>Type=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+Ag8 File3D>タイプ=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+bD8 File1D>タイプ=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+Bd8 File2D>タイプ=はファイルします; サイズ=4096、=19990929011440を変更してください; =rにパーマをかけてください; ユニークな=keVO1+bd8 226MLSDが完成したFILE1 S>。
Next, notice the labels of the facts. These are also case- independent strings; the server-FTP is permitted to return them in any case desired. User-FTP must be prepared to deal with any case, though it may do this by mapping the labels to a common case if desired.
次に、事実のラベルに注意してください。 また、これらはケースの独立しているストリングです。 サーバFTPがどのような場合でも、必要な状態でそれらを返すことが許可されています。 あらゆるケースに対処するようにユーザFTPを準備しなければなりません、望まれているならラベルをよくある例に写像することによって、これをするかもしれませんが。
Then, notice that there are nine objects of "type" file returned. In a case-independent NVFS these would represent three different file names, "file1", "file2", and "file3". With a case-dependent NVFS all nine represent different file names. Either is possible, server-FTPs may implement a case dependent or a case independent NVFS. User-FTPs must allow for case dependent selection of files to manipulate on the server.
そして、返された「タイプ」ファイルの9個の物があるのに注意してください。 ケースから独立しているNVFSでは、これらが3つの異なったファイル名を表すだろう、「file1"、「file2"、および"file3""。 ケース依存するNVFSと共に、すべての9が異なったファイル名を表します。 どちらかが可能である、サーバFTPはケース扶養家族かケースの独立しているNVFSを実行するかもしれません。 ユーザFTPはサーバで操作するファイルのケースの依存する品揃えを考慮しなければなりません。
Hethmon Standards Track [Page 44] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[44ページ]。
Lastly, notice that the value of the "unique" fact is case dependent.
In the example shown, "file1", "File1", and "file2" all have the same
"unique" fact value "keVO1+bD8", and thus all represent the same
underlying file. On the other hand, "FILE1" has a different "unique"
fact value ("keVO1+bd8") and hence represents a different file.
Similarly, "FILE2" and "File2" are two names for the same underlying
file, whereas "file3", "File3" and "FILE3" all represent different
underlying files.
最後に、「ユニークな」事実の値がケース扶養家族であるのに注意してください。 示された例で「file1"、「File1"、「すべてが同じ「ユニークな」事実に評価させるfile2"、「keVO1+bD8"、その結果、すべてが同じ基本的なファイルを表す、」 そして、他方では、「FILE1"には異なった「ユニークな」事実値がある、(「keVO1+bd8")、したがって、異なったファイルを表す、」 そして、同様である、「FILE2"、「ところが、File2"が同じ基本的なファイルのための2つの名前である、「file3"、「File3"、そして、「FILE3"は異なった基本的なファイルをすべて表します」。
That the approximate sizes ("size" fact) and last modification times
("modify" fact) are the same in all cases might be no more than a
coincidence.
大体のサイズ(「サイズ」事実)と最後の変更時間(事実を「変更する」)がすべての場合で同じであることは、偶然の一致であるにすぎないかもしれません。
It is not suggested that the operators of server-FTPs create an NVFS that stresses the protocols to this extent; however, both user and server implementations must be prepared to deal with such extreme examples.
サーバFTPのオペレータがこの程度までプロトコルを強調するNVFSを作成することが提案されません。 しかしながら、そのような極端な例に対処するようにユーザとサーバ実現の両方を準備しなければなりません。
7.7.9. Example from Another Server
7.7.9. 別のサーバからの例
C> MlsD S> 150 File Listing Follows in IMAGE / Binary mode. D> type=cdir;modify=19990426150227;perm=el; /MISC D> type=pdir;modify=19791231130000;perm=el; / D> type=dir;modify=19990426150227;perm=el; CVS D> type=dir;modify=19990426150228;perm=el; SRC S> 226 Transfer finished successfully. C> MlsD src S> 150 File Listing Follows in IMAGE / Binary mode. D> type=cdir;modify=19990426150228;perm=el; /MISC/src D> type=pdir;modify=19990426150227;perm=el; /MISC D> type=dir;modify=19990426150228;perm=el; CVS D> type=dir;modify=19990426150228;perm=el; INSTALL D> type=dir;modify=19990426150230;perm=el; INSTALLI D> type=dir;modify=19990426150230;perm=el; TREES S> 226 Transfer finished successfully. C> MlsD src/install S> 150 File Listing Follows in IMAGE / Binary mode. D> type=cdir;modify=19990426150228;perm=el; /MISC/src/install D> type=pdir;modify=19990426150228;perm=el; /MISC/src D> type=file;modify=19990406234304;perm=r;size=20059; BOOTPC.C D> type=file;modify=19980401170153;perm=r;size=278; BOOTPC.H D> type=file;modify=19990413153736;perm=r;size=54220; BOOTPC.O D> type=file;modify=19990223044003;perm=r;size=3389; CDROM.C D> type=file;modify=19990413153739;perm=r;size=30192; CDROM.O D> type=file;modify=19981119155324;perm=r;size=1055; CHANGELO D> type=file;modify=19981204171040;perm=r;size=8297; COMMANDS.C D> type=file;modify=19980508041749;perm=r;size=580; COMMANDS.H
IMAGE/バイナリ・モードによるC>MlsD S>150File Listing Follows。 D>は=cdirをタイプします; =19990426150227を変更してください; パーマ=高架鉄道 /MISC D>タイプはpdirと等しいです; =19791231130000を変更してください; パーマ=高架鉄道 /D>タイプはdirと等しいです; =19990426150227を変更してください; パーマ=高架鉄道 CVS D>タイプはdirと等しいです; =19990426150228を変更してください; パーマ=高架鉄道 SRC S>226Transferは首尾よく終わりました。 IMAGE/バイナリ・モードによるC>MlsD src S>150File Listing Follows。 D>は=cdirをタイプします; =19990426150228を変更してください; パーマ=高架鉄道 /MISC/src D>タイプはpdirと等しいです; =19990426150227を変更してください; パーマ=高架鉄道 /MISC D>タイプはdirと等しいです; =19990426150228を変更してください; パーマ=高架鉄道 CVS D>タイプはdirと等しいです; =19990426150228を変更してください; パーマ=高架鉄道 INSTALL D>タイプはdirと等しいです; =19990426150230を変更してください; パーマ=高架鉄道 INSTALLI D>タイプはdirと等しいです; =19990426150230を変更してください; パーマ=高架鉄道 TREES S>226Transferは首尾よく終わりました。 C>MlsD src/はS>150File Listing FollowsをIMAGE/バイナリ・モードにインストールします。 D>は=cdirをタイプします; =19990426150228を変更してください; パーマ=高架鉄道 /MISC/src/install D>は=pdirをタイプします; =19990426150228を変更してください; パーマ=高架鉄道 /MISC/src D>タイプ=はファイルします; =19990406234304を変更してください; =rにパーマをかけてください; サイズ=20059 BOOTPC.C D>タイプ=はファイルします; =19980401170153を変更してください; =rにパーマをかけてください; サイズ=278 BOOTPC.H D>タイプ=はファイルします; =19990413153736を変更してください; =rにパーマをかけてください; サイズ=54220 BOOTPC.O D>タイプ=はファイルします; =19990223044003を変更してください; =rにパーマをかけてください; サイズ=3389 CDROM.C D>タイプ=はファイルします; =19990413153739を変更してください; =rにパーマをかけてください; サイズ=30192 CDROM.O D>タイプ=はファイルします; =19981119155324を変更してください; =rにパーマをかけてください; サイズ=1055 CHANGELO D>タイプ=はファイルします; =19981204171040を変更してください; =rにパーマをかけてください; サイズ=8297 COMMANDS.C D>タイプ=はファイルします; =19980508041749を変更してください; =rにパーマをかけてください; サイズ=580 COMMANDS.H
Hethmon Standards Track [Page 45] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[45ページ]。
...
D> type=file;modify=19990419052351;perm=r;size=54264; URLMETHO.O
D> type=file;modify=19980218161629;perm=r;size=993; WINDOWS.C
D> type=file;modify=19970912154859;perm=r;size=146; WINDOWS.H
D> type=file;modify=19990413153731;perm=r;size=16812; WINDOWS.O
D> type=file;modify=19990322174959;perm=r;size=129; _CVSIGNO
D> type=file;modify=19990413153640;perm=r;size=82536; _DEPEND
S> 226 Transfer finished successfully.
C> MLst src/install/windows.c
S> 250-Listing src/install/windows.c
S> type=file;perm=r;size=993; /misc/src/install/windows.c
S> 250 End
S> ftp> mlst SRC/INSTALL/WINDOWS.C
C> MLst SRC/INSTALL/WINDOWS.C
S> 250-Listing SRC/INSTALL/WINDOWS.C
S> type=file;perm=r;size=993; /misc/SRC/INSTALL/WINDOWS.C
S> 250 End
... D>タイプ=はファイルします; =19990419052351を変更してください; =rにパーマをかけてください; サイズ=54264 URLMETHO.O D>タイプ=はファイルします; =19980218161629を変更してください; =rにパーマをかけてください; サイズ=993 WINDOWS.C D>タイプ=はファイルします; =19970912154859を変更してください; =rにパーマをかけてください; サイズ=146 WINDOWS.H D>タイプ=はファイルします; =19990413153731を変更してください; =rにパーマをかけてください; サイズ=16812 WINDOWS.O D>タイプ=はファイルします; =19990322174959を変更してください; =rにパーマをかけてください; サイズ=129 _CVSIGNO D>タイプ=はファイルします; =19990413153640を変更してください; =rにパーマをかけてください; サイズ=82536 _DEPEND S>226Transferは首尾よく終わりました。 C>MLst src/はwindows.c S>タイプ=がファイルする/windows.c S>src/がインストールする250リスト/をインストールします; =rにパーマをかけてください; サイズ=993 /misc/src/install/windows.c S>250End S>ftp>mlst SRC/INSTALL/WINDOWS.C C>MLst SRC/INSTALL/WINDOWS.C Sの>の250リストのSRC/INSTALL/WINDOWS.C S>タイプ=ファイル; =rにパーマをかけてください; サイズ=993 /misc/SRC/INSTALL/WINDOWS.C S>250エンド
Note that this server gives fully qualified pathnames for the "pdir" and "cdir" entries in MLSD listings. Also notice that this server does, though it is not required to, sort its directory listing outputs. That may be an artifact of the underlying file system access mechanisms of course. Finally notice that the NVFS supported by this server, in contrast to the earlier ones, implements its pathnames in a case independent manner. The server seems to return files using the case in which they were requested, when the name was sent by the client, and otherwise uses an algorithm known only to itself to select the case of the names it returns.
このサーバがMLSDリストの"pdir"と"cdir"エントリーに完全に適切なパス名を与えることに注意してください。 また、それは必要ではありませんが、このサーバが出力を記載するディレクトリを分類するのに注意してください。 それはもちろん基本的なファイルシステムアクセス機構の人工物であるかもしれません。 以前のものと対照してこのサーバによって支持されたNVFSがケースの独立している方法でパス名を実行するのに最終的に注意してください。 サーバはそれらが要求された場合を使用することでファイルを返すように思えます、クライアントによって送られて、そうでなければ、名前がそれが返す名前に関するケースを選択するのがそれ自体だけで知られているアルゴリズムを使用すると。
7.7.10. A Server Listing Itself
7.7.10. それ自体を記載するサーバ
C> MLst f S> 250-MLST f S> Type=dir;Modify=20000710052229;Unique=AAD/AAAABIA; f S> 250 End C> CWD f S> 250 CWD command successful. C> MLSD S> 150 Opening ASCII mode data connection for 'MLSD'. D> Type=cdir;Unique=AAD/AAAABIA; . D> Type=pdir;Unique=AAD/AAAAAAI; .. D> Type=file;Size=987;Unique=AAD/AAAABIE; Makefile D> Type=file;Size=20148;Unique=AAD/AAAABII; conf.c D> Type=file;Size=11111;Unique=AAD/AAAABIM; extern.h D> Type=file;Size=38721;Unique=AAD/AAAABIQ; ftpcmd.y D> Type=file;Size=17922;Unique=AAD/AAAABIU; ftpd.8 D> Type=file;Size=60732;Unique=AAD/AAAABIY; ftpd.c D> Type=file;Size=3127;Unique=AAD/AAAABIc; logwtmp.c
C>MLst f S>250-MLST f S>タイプはdirと等しいです; =20000710052229を変更してください; ユニークな=AAD/AAAABIA f S>250終わりのC>CWD f S>250CWDはうまくいった状態で命令します。 'MLSD'のためのC>MLSD S>150Opening ASCIIモードデータ接続。 D>は=cdirをタイプします; ユニークな=AAD/AAAABIA . D>は=pdirをタイプします; ユニークな=AAD/AAAAAAI .. D>は=ファイル; サイズ=987; ユニークな=AAD/AAAABIEをタイプします。 メイクファイルD>は=ファイル; サイズ=20148; ユニークな=AAD/AAAABIIをタイプします。 conf.c D>Typeはファイル; サイズ=11111; ユニークな=AAD/AAAABIMと等しいです。 extern.h D>Typeはファイル; サイズ=38721; ユニークな=AAD/AAAABIQと等しいです。 ftpcmd.y D>Typeはファイル; サイズ=17922; ユニークな=AAD/AAAABIUと等しいです。 ftpd.8D>Type=ファイル; サイズ=60732; ユニークな=AAD/AAAABIY。 ftpd.c D>Typeはファイル; サイズ=3127; ユニークな=AAD/AAAABIcと等しいです。 logwtmp.c
Hethmon Standards Track [Page 46] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[46ページ]。
D> Type=file;Size=2294;Unique=AAD/AAAABIg; pathnames.h D> Type=file;Size=7605;Unique=AAD/AAAABIk; popen.c D> Type=file;Size=9951;Unique=AAD/AAAABIo; ftpd.conf.5 D> Type=file;Size=5023;Unique=AAD/AAAABIs; ftpusers.5 D> Type=file;Size=3547;Unique=AAD/AAAABIw; logutmp.c D> Type=file;Size=2064;Unique=AAD/AAAABI0; version.h D> Type=file;Size=20420;Unique=AAD/AAAAAAM; cmds.c D> Type=file;Size=15864;Unique=AAD/AAAAAAg; ls.c D> Type=file;Size=2898;Unique=AAD/AAAAAAk; ls.h D> Type=file;Size=2769;Unique=AAD/AAAAAAo; lsextern.h D> Type=file;Size=2042;Unique=AAD/AAAAAAs; stat_flags.h D> Type=file;Size=5708;Unique=AAD/AAAAAAw; cmp.c D> Type=file;Size=9280;Unique=AAD/AAAAAA0; print.c D> Type=file;Size=4657;Unique=AAD/AAAAAA4; stat_flags.c D> Type=file;Size=2664;Unique=AAD/AAAAAA8; util.c D> Type=file;Size=10383;Unique=AAD/AAAABJ0; ftpd.conf.cat5 D> Type=file;Size=3631;Unique=AAD/AAAABJ4; ftpusers.cat5 D> Type=file;Size=17729;Unique=AAD/AAAABJ8; ftpd.cat8 S> 226 MLSD complete.
D>は=ファイル; サイズ=2294; ユニークな=AAD/AAAABIgをタイプします。 pathnames.h D>Typeはファイル; サイズ=7605; ユニークな=AAD/AAAABIkと等しいです。 popen.c D>Typeはファイル; サイズ=9951; ユニークな=AAD/AAAABIoと等しいです。 ftpd.conf.5 D>Typeはファイル; サイズ=5023; ユニークな=AAD/AAAABIsと等しいです。 ftpusers.5D>Type=ファイル; サイズ=3547; ユニークな=AAD/AAAABIw。 logutmp.c D>Typeはファイル; サイズ=2064; ユニークな=AAD/AAAABI0と等しいです。 version.h D>Typeはファイル; サイズ=20420; ユニークな=AAD/AAAAAAMと等しいです。 cmds.c D>Typeはファイル; サイズ=15864; ユニークな=AAD/AAAAAAgと等しいです。 ls.c D>Typeはファイル; サイズ=2898; ユニークな=AAD/AAAAAAkと等しいです。 ls.h D>Typeはファイル; サイズ=2769; ユニークな=AAD/AAAAAAoと等しいです。 lsextern.h D>Typeはファイル; サイズ=2042; ユニークな=AAD/AAAAAAsと等しいです。 スタット_flags.h D>Typeはファイル; サイズ=5708; ユニークな=AAD/AAAAAAwと等しいです。 cmp.c D>Typeはファイル; サイズ=9280; ユニークな=AAD/AAAAAA0と等しいです。 print.c D>Typeはファイル; サイズ=4657; ユニークな=AAD/AAAAAA4と等しいです。 スタット_flags.c D>Typeはファイル; サイズ=2664; ユニークな=AAD/AAAAAA8と等しいです。 util.c D>Typeはファイル; サイズ=10383; ユニークな=AAD/AAAABJ0と等しいです。 ftpd.conf.cat5 D>Typeはファイル; サイズ=3631; ユニークな=AAD/AAAABJ4と等しいです。 ftpusers.cat5 D>Typeはファイル; サイズ=17729; ユニークな=AAD/AAAABJ8と等しいです。 226MLSDが完成するftpd.cat8 S>。
This examples shows yet another server implementation, showing a listing of its own source code. Note that this implementation does not include the fully qualified path name in its "cdir" and "pdir" entries, nor in the output from "MLST". Also note that the facts requested were modified between the "MLST" and "MLSD" commands, though that exchange has not been shown here.
それ自身のソースコードのリストを見せているこの例のショーにもかかわらず、別のサーバ実現。 この実現が"cdir"と"pdir"エントリー、および"MLST"からの出力に完全に適切なパス名を含んでいないことに注意してください。 また、事実が要求した注意は"MLST"と"MLSD"コマンドの間で変更されました、その交換はここに示されていませんが。
7.7.11. A Server with a Difference
7.7.11. 違いがあるサーバ
C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,46) C> MLSD S> 150 I tink I tee a trisector tree D> Type=file;Unique=aaaaafUYqaaa;Perm=rf;Size=15741; x D> Type=cdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=file;Unique=aaaaajUYqaaa;Perm=rf;Size=5760; x4 D> Type=dir;Unique=aaabcaUYqaaa;Perm=elf; sub D> Type=file;Unique=aaaaagUYqaaa;Perm=rf;Size=8043; x1 D> Type=dir;Unique=aaab8aUYqaaa;Perm=cpmelf; files D> Type=file;Unique=aaaaahUYqaaa;Perm=rf;Size=4983; x2 D> Type=file;Unique=aaaaaiUYqaaa;Perm=rf;Size=6854; x3 S> 226 That's all folks... C> CWD sub S> 250 CWD command successful. C> PWD S> 257 "/sub" is current directory. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,44)
C>PASV S>227Entering Passive Mode(127、0、0、1,255、46)C>MLSD S>150I tink Iは「3-セクター」木D>Type=ファイルの第1球を打ちます; ユニークな=aaaaafUYqaaa; パーマ=rf; サイズ=15741 x D>タイプ=cdir; ユニークな=aaaaacUYqaaa; =cpmelにパーマをかけてください。 /D>タイプ=はファイルします; ユニークな=aaaaajUYqaaa; パーマ=rf; サイズ=5760 x4D>タイプ=dir; ユニークな=aaabcaUYqaaa; =小妖精にパーマをかけてください。 潜水艦D>Type=はファイルします; ユニークな=aaaaagUYqaaa; パーマ=rf; サイズ=8043 x1D>タイプ=dir; ユニークな=aaab8aUYqaaa; =cpmelfにパーマをかけてください。 ファイルD>Type=はファイルされます; ユニークな=aaaaahUYqaaa; パーマ=rf; サイズ=4983 x2D>タイプ=はファイルします; ユニークな=aaaaaiUYqaaa; パーマ=rf; サイズ=6854 x3 S>226Thatは皆、人々です… C>CWD潜水艦S>250CWDはうまくいった状態で命令します。 「C>PWD S>257インチ/潜水艦」はカレントディレクトリです。 受け身の形態を入れるC>PASV S>227(127,0,0,1,255,44)
Hethmon Standards Track [Page 47] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[47ページ]。
C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabceUYqaaa;Perm=elf; dir D> Type=file;Unique=aaabcbUYqaaa;Perm=rf;Size=0; y1 D> Type=file;Unique=aaabccUYqaaa;Perm=rf;Size=0; y2 D> Type=file;Unique=aaabcdUYqaaa;Perm=rf;Size=0; y3 D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=cdir;Unique=aaabcaUYqaaa;Perm=el; /sub S> 226 That's all folks... C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,42) C> MLSD dir S> 150 I tink I tee a trisector tree D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; /sub D> Type=pdir;Unique=aaabcaUYqaaa;Perm=el; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=r;Size=15039; mlst.c D> Type=dir;Unique=aaabcfUYqaaa;Perm=el; ect D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; dir D> Type=cdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=dir;Unique=aaabchUYqaaa;Perm=el; misc D> Type=file;Unique=aaab8bUYqaaa;Perm=r;Size=34589; ftpd.c S> 226 That's all folks... C> CWD dir/ect S> 250 CWD command successful. C> PWD S> 257 "/sub/dir/ect" is current directory. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,40) C> MLSD S> 150 I tink I tee a trisector tree D> Type=dir;Unique=aaabcgUYqaaa;Perm=el; ory D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; /sub/dir D> Type=pdir;Unique=aaabceUYqaaa;Perm=el; .. D> Type=cdir;Unique=aaabcfUYqaaa;Perm=el; /sub/dir/ect S> 226 That's all folks... C> CWD /files S> 250 CWD command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,36) C> MLSD S> 150 I tink I tee a trisector tree D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; mlst.c D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c S> 226 That's all folks...
C>MLSD S>150I tink Iティーa「3-セクター」木Dの>Type=dir; ユニークな=aaabceUYqaaa; =小妖精にパーマをかけてください。 dir D>Type=はファイルします; ユニークな=aaabcbUYqaaa; パーマ=rf; サイズ=0 y1D>タイプ=はファイルします; ユニークな=aaabccUYqaaa; パーマ=rf; サイズ=0 y2D>タイプ=はファイルします; ユニークな=aaabcdUYqaaa; パーマ=rf; サイズ=0 y3D>タイプ=pdir; ユニークな=aaaaacUYqaaa; =cpmelにパーマをかけてください。 /D>タイプ=pdir; ユニークな=aaaaacUYqaaa; =cpmelにパーマをかけてください。 .. D>タイプ=cdir; ユニークな=aaabcaUYqaaa; =高架鉄道にパーマをかけてください。 /潜水艦S>226Thatは皆、人々です… C>PASV S>227Entering Passive Mode(127、0、0、1,255、42)C>MLSD dir S>150I tink Iティーa「3-セクター」木Dの>Type=pdir; ユニークな=aaabcaUYqaaa; =高架鉄道にパーマをかけてください。 /潜水艦D>タイプ=pdir; ユニークな=aaabcaUYqaaa; =高架鉄道にパーマをかけてください。 .. D>タイプ=はファイルします; ユニークな=aaab8cUYqaaa; パーマ=r; サイズ=15039 mlst.c D>Type=dir; ユニークな=aaabcfUYqaaa; =高架鉄道にパーマをかけてください。 ect D>Type=cdir; ユニークな=aaabceUYqaaa; =高架鉄道にパーマをかけてください。 dir D>Type=cdir; ユニークな=aaabceUYqaaa; =高架鉄道にパーマをかけてください。 /sub/dir D>タイプ=dir; ユニークな=aaabchUYqaaa; =高架鉄道にパーマをかけてください。 雑ネタDの>Type=はファイルします; ユニークな=aaab8bUYqaaa; パーマ=r; サイズ=34589 ftpd.c S>226Thatは皆、人々です… C>CWD dir/ect S>250CWDはうまくいった状態で命令します。 C>PWD S>257"/sub/dir/ect"はカレントディレクトリです。 C>PASV S>227Entering Passive Mode(127、0、0、1,255、40)C>MLSD S>150I tink Iティーa「3-セクター」木Dの>Type=dir; ユニークな=aaabcgUYqaaa; =高架鉄道にパーマをかけてください。 ory D>Type=pdir; ユニークな=aaabceUYqaaa; =高架鉄道にパーマをかけてください。 /sub/dir D>タイプ=pdir; ユニークな=aaabceUYqaaa; =高架鉄道にパーマをかけてください。 .. D>タイプ=cdir; ユニークな=aaabcfUYqaaa; =高架鉄道にパーマをかけてください。 /sub/dir/ect S>226Thatは皆、人々です… C>CWD/ファイルS>250CWDはうまくいった状態で命令します。 C>PASV S>227Entering Passive Mode(127、0、0、1,255、36)C>MLSD S>150I tink Iティーa「3-セクター」木Dの>Type=cdir; ユニークな=aaab8aUYqaaa; =cpmelにパーマをかけてください。 /ファイルD>タイプ=pdir; ユニークな=aaaaacUYqaaa; =cpmelにパーマをかけてください。 /D>タイプ=pdir; ユニークな=aaaaacUYqaaa; =cpmelにパーマをかけてください。 .. D>タイプ=はファイルします; ユニークな=aaab8cUYqaaa; パーマ=rf; サイズ=15039 mlst.c D>Type=はファイルします; ユニークな=aaab8bUYqaaa; パーマ=rf; サイズ=34589 ftpd.c S>226Thatは皆、人々です…
Hethmon Standards Track [Page 48] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[48ページ]。
C> RNFR mlst.c S> 350 File exists, ready for destination name C> RNTO list.c S> 250 RNTO command successful. C> PASV S> 227 Entering Passive Mode (127,0,0,1,255,34) C> MLSD S> 150 I tink I tee a trisector tree D> Type=file;Unique=aaab8cUYqaaa;Perm=rf;Size=15039; list.c D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; / D> Type=pdir;Unique=aaaaacUYqaaa;Perm=cpmel; .. D> Type=file;Unique=aaab8bUYqaaa;Perm=rf;Size=34589; ftpd.c D> Type=cdir;Unique=aaab8aUYqaaa;Perm=cpmel; /files S> 226 That's all folks...
C>RNFR mlst.c S>350Fileは目的地名Cのために>RNTO list.c S>250RNTOコマンドうまくいった状態で準備して存在しています。 C>PASV S>227Entering Passive Mode(127、0、0、1,255、34)C>MLSD S>150I tink Iは「3-セクター」木D>Type=ファイルの第1球を打ちます; ユニークな=aaab8cUYqaaa; パーマ=rf; サイズ=15039 list.c D>Type=pdir; ユニークな=aaaaacUYqaaa; =cpmelにパーマをかけてください。 /D>タイプ=pdir; ユニークな=aaaaacUYqaaa; =cpmelにパーマをかけてください。 .. D>タイプ=はファイルします; ユニークな=aaab8bUYqaaa; パーマ=rf; サイズ=34589 ftpd.c D>Type=cdir; ユニークな=aaab8aUYqaaa; =cpmelにパーマをかけてください。 /ファイルS>226Thatは皆、人々です…
The server shown here returns its directory listings in seemingly random order, and even seems to modify the order of the directory as its contents change -- perhaps the underlying directory structure is based upon hashing of some kind. Note that the "pdir" and "cdir" entries are interspersed with other entries in the directory. Note also that this server does not show a "pdir" entry when listing the contents of the root directory of the virtual filestore; however, it does however include multiple "cdir" and "pdir" entries when it feels inclined. The server also uses obnoxiously "cute" messages.
ディレクトリリストがここで戻りさえするのが示されたサーバは内容が変化するときディレクトリの注文を変更するように思えます--恐らく、基本的なディレクトリ構造はある種を論じ尽くすことに基づいています。 "pdir"と"cdir"エントリーがディレクトリにおける他のエントリーで点在することに注意してください。 また、仮想のfilestoreに関するルートディレクトリのコンテンツを記載するとき、このサーバが"pdir"エントリーを示さないことに注意してください。 しかしながら、しかしながら、気がするとき、それは複数の"cdir"と"pdir"エントリーを含んでいます。 また、サーバは不愉快に「かわいい」メッセージを使用します。
7.8. FEAT Response for MLSx
7.8. MLSxのための功績応答
When responding to the FEAT command, a server-FTP process that supports MLST, and MLSD, plus internationalization of pathnames, MUST indicate that this support exists. It does this by including a MLST feature line. As well as indicating the basic support, the MLST feature line indicates which MLST facts are available from the server, and which of those will be returned if no subsequent "OPTS MLST" command is sent.
FEATコマンドに応じるとき、MLST、およびMLSDを支持するサーバFTPの過程、およびパス名の国際化は、このサポートが存在するのを示さなければなりません。 それは、MLSTハイライト線を含んでいることによって、これをします。 基本的なサポート、MLSTハイライト線がサーバからどのMLST事実が利用可能であるかを示して、いいえその後ならそれらのどれを返すかが「MLSTを選ぶこと」を示すことと同様に、コマンドを送ります。
mlst-feat = SP "MLST" [SP factlist] CRLF
factlist = 1*( factname ["*"] ";" )
mlst-功績=SP"MLST"[SP factlist]CRLF factlist=1*「(factname[「*」]、」、;、」、)
The initial space shown in the mlst-feat response is that required by the FEAT command, two spaces are not permitted. If no factlist is given, then the server-FTP process is indicating that it supports MLST, but implements no facts. Only pathnames can be returned. This would be a minimal MLST implementation, and useless for most practical purposes. Where the factlist is present, the factnames included indicate the facts supported by the server. Where the optional asterisk appears after a factname, that fact will be included in MLST format responses, until an "OPTS MLST" is given to alter the list of facts returned. After that, subsequent FEAT
初期のスペースがmlst-功績応答でそれがFEATコマンドで必要であることが示されて、2つの空間は受入れられません。 factlistを全く与えないなら、サーバFTPの過程はMLSTを支持しますが、事実を全く実行しないのを示すことです。 パス名しか返すことができません。 これは、最小量のMLST実現であって、ほとんどの実用的な目的のために役に立たないでしょう。 factlistが存在しているところで、factnamesを含んでいて、事実がサーバで支持したのを示してください。その事実がMLST形式応答に任意のアスタリスクがfactnameの後に現れるところに含まれる、「MLSTを選ぶ、」 返された事実のリストを変更するために、与えます。 後それの、そして、その後のFEAT
Hethmon Standards Track [Page 49] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[49ページ]。
commands will return the asterisk to show the facts selected by the most recent "OPTS MLST".
コマンドは、最新によって選択された事実が「MLSTを選ぶこと」を示すためにアスタリスクを返すでしょう。
Note that there is no distinct FEAT output for MLSD. The presence of the MLST feature indicates that both MLST and MLSD are supported.
MLSDのためのどんな異なったFEAT出力もないことに注意してください。 MLSTの特徴の存在は、MLSTとMLSDの両方が支持されるのを示します。
7.8.1. Examples
7.8.1. 例
C> Feat S> 211- Features supported S> REST STREAM S> MDTM S> SIZE S> TVFS S> UTF8 S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End
>211が特徴とするC>功績SはS>REST STREAM S>MDTM S>SIZE S>TVFS S>UTF8 S>MLST Type*を支持しました; サイズ*; *を変更してください; *にパーマをかけてください; ユニークな*; UNIX.mode; UNIX.chgd; 隠されたX. S>211エンド
Aside from some features irrelevant here, this server indicates that it supports MLST including several, but not all, standard facts, all of which it will send by default. It also supports two OS dependent facts, and one locally defined fact. The latter three must be requested expressly by the client for this server to supply them.
ここで無関係のいくつかの特徴は別として、このサーバは、それがデフォルトでそれのすべてを送る標準の事実ではなく、数個を含むMLSTを支持するのを示します。 また、それはOSに依存する2つの事実、および1つの局所的に定義された事実を支持します。 クライアントは、このサーバがそれらを供給するよう明白に後者の3を要求しなければなりません。
C> Feat S> 211-Extensions supported: S> CLNT S> MDTM S> MLST type*;size*;modify*;UNIX.mode*;UNIX.owner;UNIX.group;unique; S> PASV S> REST STREAM S> SIZE S> TVFS S> Compliance Level: 19981201 (IETF mlst-05) S> 211 End.
C、211拡大が支持した>功績S>: S>CLNT S>MDTM S>MLSTタイプ*; サイズ*; *を変更してください; UNIX.mode*; UNIX.owner; UNIX.group; ユニークです。 S>PASV S>は流れのS>サイズS>TVFS S>承諾レベルを休ませています: 19981201 (IETF mlst-05)S>211End。
Again, in addition to some irrelevant features here, this server
indicates that it supports MLST, four of the standard facts, one of
which ("unique") is not enabled by default, and several OS dependent
facts, one of which is provided by the server by default. This
server actually supported more OS dependent facts. Others were
deleted for the purposes of this document to comply with document
formatting restrictions.
一方、ここのいくつかの無関係の特徴に加えてこのサーバは、MLST、4つの標準の事実、およびOSに依存するいくつかの事実を支持するのを示します。それの1つはデフォルトで事実のために可能にされません(「ユニークな」)。その1つはデフォルトでサーバによって提供されます。 このサーバは実際により多くのOSに依存する事実を支持しました。 このドキュメントの目的がドキュメント形式制限に従うように、他のものは削除されました。
Hethmon Standards Track [Page 50] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[50ページ]。
C> FEAT S> 211-Features supported S> MDTM S> MLST Type*;Size*;Modify*;Perm;Unique*; S> REST STREAM S> SIZE S> TVFS S> 211 End
C>FEAT S>支持されたS>MDTM S>MLST Type*(サイズ*)が変更する211特徴*; パーマをかけてください; ユニークな* S>は流れのS>サイズS>TVFS S>211エンドを休ませています。
This server has wisely chosen not to implement any OS dependent facts. At the time of writing this document, no such facts have been defined (using the mechanisms of section 10.1) so rational support for them would be difficult at best. All but one of the facts supported by this server are enabled by default.
このサーバは、OSに依存するどんな事実も実行しないのを賢明に選びました。 これを書いている時点でこのドキュメント、どんなそのような事実も定義されていないので(セクション10.1のメカニズムを使用して)、それらの合理的なサポートはせいぜい難しいでしょう。 このサーバによって支持された事実の1つ以外のすべてがデフォルトで可能にされます。
7.9. OPTS Parameters for MLST
7.9. MLSTのためのパラメタを選びます。
For the MLSx commands, the Client-FTP may specify a list of facts it wishes to be returned in all subsequent MLSx commands until another OPTS MLST command is sent. The format is specified by:
MLSxコマンドとして、Client-FTPはすべてのその後のMLSxコマンドでそれを別のOPTS MLSTコマンドを送るまで返したいという事実のリストを指定するかもしれません。 形式は以下によって指定されます。
mlst-opts = "OPTS" SP "MLST"
[ SP 1*( factname ";" ) ]
=が「選ばれる」というSP"MLST"をmlst選びます。「[SP1*、(factname、」、;、」、]
By sending the "OPTS MLST" command, the client requests the server to include only the facts listed as arguments to the command in subsequent output from MLSx commands. Facts not included in the "OPTS MLST" command MUST NOT be returned by the server. Facts that are included should be returned for each entry returned from the MLSx command where they meaningfully apply. Facts requested that are not supported, or that are inappropriate to the file or directory being listed should simply be omitted from the MLSx output. This is not an error. Note that where no factname arguments are present, the client is requesting that only the file names be returned. In this case, and in any other case where no facts are included in the result, the space that separates the fact names and their values from the file name is still required. That is, the first character of the output line will be a space, (or two characters will be spaces when the line is returned over the control connection) and the file name will start immediately thereafter.
発信する、「MLSTを選ぶ、」 コマンド、クライアントは事実だけを含むサーバがMLSxからのその後の出力におけるコマンドへの議論についてコマンドに記載したよう要求します。 サーバはコマンドを返してはいけません。事実が中に含んでいなかった、「MLSTを選ぶ、」 それらが意味深長に適用するMLSxコマンドから返された各エントリーに含まれている事実を返すべきです。 要求されたサポートしていないか、または記載されていて、MLSx出力から単に省略されるべきであるということであるファイルかディレクトリに不適当な事実。 これは誤りではありません。 どんなfactname議論も存在していないところでクライアントが、ファイル名だけが返されるよう要求していることに注意してください。 この場合、そして、および事実が全く結果に含まれていないいかなる他のケース、事実を切り離すスペースではも、存在というファイル名からの名前とそれらの値がまだ必要です。 すなわち、出力系列の最初のキャラクタがスペースであるために望んでいる、(2つのキャラクタがコントロール接続の上に系列を返すときの空間であるために望んでいます) そして、意志がその後すぐに始めるファイル名。
Clients should note that generating values for some facts can be possible, but very expensive, for some servers. It is generally acceptable to retrieve any of the facts that the server offers as its default set before any "OPTS MLST" command has been given, however clients should use particular caution before requesting any facts not in that set. That is, while other facts may be available from the server, clients should refrain from requesting such facts unless
クライアントは、いくつかの事実のために値を生成するのが可能ですが、いくつかのサーバに、非常に高価である場合があることに注意するべきです。 一般に、与えられているいずれも「MLSTを選ぶ」前に設定されたデフォルトとしてのサーバ申し出が、命令する事実のどれかを検索するのが許容できる、しかしながら、設定されないのでどんな事実も要求する前に、クライアントは特定の警告を使用するべきです。 すなわち、他の事実がサーバから利用可能であるかもしれない間、クライアントは、そのような事実を要求するのを控えるべきです。
Hethmon Standards Track [Page 51] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[51ページ]。
there is a particular operational requirement for that particular information, which ought be more significant than perhaps simply improving the information displayed to an end user.
その特定の情報のための特定の操作上の要件があって、どちらが恐らく単に情報を改良するより重要であるかはエンドユーザに表示しました。
Note, there is no "OPTS MLSD" command, the fact names set with the "OPTS MLST" command apply to both MLST and MLSD commands.
注意、いいえが「MLSDを選ぶ」というコマンドがあります、名前がセットした事実、「」 コマンドがMLSTとMLSDコマンドの両方に適用するMLSTを選びます。
Servers are not required to accept "OPTS MLST" commands before authentication of the user-PI, but may choose to permit them.
サーバは、ユーザパイの認証の前の受け入れるのが「MLSTを選ぶ」という必要なコマンドではありませんが、それらを可能にするのを選ぶかもしれません。
7.9.1. OPTS MLST Response
7.9.1. MLST応答を選びます。
The "response-message" from [6] to a successful OPTS MLST command has the following syntax.
[6]からうまくいっているOPTS MLSTコマンドまでの「応答メッセージ」には、以下の構文があります。
mlst-opt-resp = "MLST OPTS" [ SP 1*( factname ";" ) ]
「MLSTは選ぶ」mlstがrespを選んでいる=「[SP1*、(factname、」、;、」、]
This defines the "response-message" as used in the "opts-good" message in RFC 2389 [6].
これが中で使用される「応答メッセージ」を定義する、「利益を選ぶ、」 メッセージ、RFC2389[6]で。
The facts named in the response are those that the server will now
include in MLST (and MLSD) response, after the processing of the
"OPTS MLST" command. Any facts from the request not supported by the
server will be omitted from this response message. If no facts will
be included, the list of facts will be empty. Note that the list of
facts returned will be the same as those marked by a trailing
asterisk ("*") in a subsequent FEAT command response. There is no
requirement that the order of the facts returned be the same as that
in which they were requested, or that in which they will be listed in
a FEAT command response, or that in which facts are returned in MLST
responses. The fixed string "MLST OPTS" in the response may be
returned in any case, or mixture of cases.
応答で指定された事実はサーバが現在MLST(そして、MLSD)応答に含んでいるものです、処理の後に「MLSTを選ぶ」、命令してください。 サーバで後押しされていない要求からのどんな事実もこの応答メッセージから省略されるでしょう。 事実が全く含まれないと、事実のリストは空になるでしょう。 事実のリストが戻ったというメモは引きずることでマークされたものがその後の功績コマンド応答における(「*」)に星をつけるのと同じになるでしょう。 返された事実の注文がそれらが要求されたそれ、それらがFEATコマンド応答で記載されているそれ、または事実がMLST応答で返されるそれと同じであるという要件が全くありません。 どんなケース、またはケースの混合物でも固定ストリング応答で「MLSTは選ぶこと」を返すかもしれません。
7.9.2. Examples
7.9.2. 例
C> Feat S> 211- Features supported S> MLST Type*;Size;Modify*;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> OptS Mlst Type;UNIX.mode;Perm; S> 200 MLST OPTS Type;Perm;UNIX.mode; C> Feat S> 211- Features supported S> MLST Type*;Size;Modify;Perm*;Unique;UNIX.mode*;UNIX.chgd;X.hidden; S> 211 End C> opts MLst lang;type;charset;create; S> 200 MLST OPTS Type; C> Feat
>211が特徴とするC>功績Sは*;パーマ; ユニークな; UNIX.mode;UNIX.chgd; 隠されたX.をMLST Type*(サイズ)が変更するS>にサポートしました。 S>211エンドC>はMlstタイプを選びます; UNIX.mode; パーマをかけてください。 S>200MLSTはタイプを選びます; パーマをかけてください; UNIX.mode >211が特徴とするC>功績Sは、SがMLST Type*(サイズ)が変更する>であるとサポートしました; パーマ*; ユニークな; UNIX.mode*;UNIX.chgd; 隠されたX. >がMLst langを選ぶS>211エンドC; タイプ; charset; 作成します。 S>200MLSTはタイプを選びます。 C>功績
Hethmon Standards Track [Page 52] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[52ページ]。
S> 211- Features supported S> MLST Type*;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> OPTS mlst size;frogs; S> 200 MLST OPTS Size; C> Feat S> 211- Features supported S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> opts MLst unique type; S> 501 Invalid MLST options C> Feat S> 211- Features supported S> MLST Type;Size*;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End
S>MLST Type*であるとサポートされた特徴(サイズ)が変更するS>211; パーマ; ユニークな; UNIX.mode;UNIX.chgd; X. 隠されます。 S>211はC>OPTS mlstサイズを終わらせます; カエル S>200MLSTはサイズを選びます。 >211が特徴とするC>功績Sは、SがMLST Type(サイズ*)が変更する>であるとサポートしました; パーマ; ユニークな; UNIX.mode;UNIX.chgd; 隠されたX. S>211エンドC>はMLstのユニークなタイプを選びます。 S>MLST Typeであるとサポートされた特徴(サイズ*)が変更するS>501の無効のMLSTオプションC>Feat S>211; パーマ; ユニークな; UNIX.mode;UNIX.chgd; X. 隠されます。 S>211エンド
For the purposes of this example, features other than MLST have been deleted from the output to avoid clutter. The example shows the initial default feature output for MLST. The facts requested are then changed by the client. The first change shows facts that are available from the server being selected. Subsequent FEAT output shows the altered features as being returned. The client then attempts to select some standard features that the server does not support. This is not an error, however the server simply ignores the requests for unsupported features, as the FEAT output that follows shows. Then, the client attempts to request a non-standard, and unsupported, feature. The server ignores that, and selects only the supported features requested. Lastly, the client sends a request containing a syntax error (spaces cannot appear in the factlist.) The server-FTP sends an error response and completely ignores the request, leaving the fact set selected as it had been previously.
この例の目的において、MLST以外の特徴は、散乱を避けるために出力から削除されました。 そして、MLST事実のための初期のデフォルト特徴出力が要求した例のショーはクライアントによって変えられます。 最初の変化は、サーバから利用可能な事実が選択されるのを示します。 その後のFEAT出力は返すとして変えられた特徴を示しています。 そして、クライアントは、サーバがサポートしないいくつかの標準装備を選択するのを試みます。 これが誤りでない、しかしながら、サーバは単にサポートされない特徴に関する要求を無視します、続くFEAT出力が目立っているように。 そして、クライアントは、標準的でなくて、サポートされない特徴を要求するのを試みます。 サーバは、それを無視して、特徴が要求したサポートすることだけを選択します。 最後に、クライアントは構文エラーを含む要求を送ります(空間はfactlistに現れることができません。)。 サーバFTPは、誤り応答を送って、要求を完全に無視します、それが以前にままにしたので事実セットを選択されたままにして。
Note that in all cases, except the error response, the response lists the facts that have been selected.
誤り応答以外のすべての場合では、応答が選択された事実をリストアップすることに注意してください。
C> Feat S> 211- Features supported S> MLST Type*;Size*;Modify*;Perm*;Unique*;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> Opts MLST S> 200 MLST OPTS C> Feat S> 211- Features supported S> MLST Type;Size;Modify;Perm;Unique;UNIX.mode;UNIX.chgd;X.hidden; S> 211 End C> MLst tmp S> 250- Listing tmp S> /tmp
>211が特徴とするC>功績Sは、S>がMLST Type*であるとサポートしました; サイズ*; *を変更してください; *にパーマをかけてください; ユニークな*; UNIX.mode; UNIX.chgd; 隠されたX. S>MLST Typeであるとサポートされた特徴(サイズ)が変更する200MLST OPTS CのS>211エンドC>Opts MLST S>>Feat S>211; パーマ; ユニークな; UNIX.mode;UNIX.chgd; X. 隠されます。 tmp S>/tmpを記載するS>211エンドC>MLst tmp S>250
Hethmon Standards Track [Page 53] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[53ページ]。
S> 250 End C> OPTS mlst unique;size; S> 200 MLST OPTS Size;Unique; C> MLst tmp S> 250- Listing tmp S> Unique=keVO1+YZ5; /tmp S> 250 End C> OPTS mlst unique;type;modify; S> 200 MLST OPTS Type;Modify;Unique; C> MLst tmp S> 250- Listing tmp S> Type=dir;Modify=19990930152225;Unique=keVO1+YZ5; /tmp S> 250 End C> OPTS mlst fish;cakes; S> 200 MLST OPTS C> MLst tmp S> 250- Listing tmp S> /tmp S> 250 End C> OptS Mlst Modify;Unique; S> 200 MLST OPTS Modify;Unique; C> MLst tmp S> 250- Listing tmp S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp S> 250 End C> opts MLst fish cakes; S> 501 Invalid MLST options C> MLst tmp S> 250- Listing tmp S> Modify=19990930152225;Unique=keVO1+YZ5; /tmp S> 250 End
S>250はユニークな状態で; サイズ;C>OPTS mlstを終わらせます。 S>200MLSTはサイズを選びます; ユニークです。 tmp S>Unique=keVO1+YZ5を記載するC>MLst tmp S>250。 /tmp S>250End C>OPTS mlstユニーク; タイプ;である、変更します。 S>200MLSTはタイプを選びます;、変更、; ユニーク。 tmp S>Type=dirを記載するC>MLst tmp S>250; =19990930152225を変更してください; ユニークな=keVO1+YZ5 tmp S>250End C>OPTS mlstが釣りをする/; ケーキ。 tmp S>/tmp S>250End C>OptS Mlst Modifyを記載する200MLST OPTS CのS>>MLst tmp S>250; ユニーク。 S>200MLSTが選ぶ、変更、; ユニーク。 tmp S>Modify=19990930152225を記載するC>MLst tmp S>250; ユニークな=keVO1+YZ5。 /tmp S>250End C>はMLst魚肉団子を選びます。 tmp S>Modify=19990930152225を記載するS>501の無効のMLSTオプションC>MLst tmp S>250; ユニークな=keVO1+YZ5。 tmp S>250が終わらせる/
This example shows the effect of changing the facts requested upon subsequent MLST commands. Notice that a syntax error leaves the set of selected facts unchanged. Also notice exactly two spaces preceding the pathname when no facts were selected, either deliberately, or because none of the facts requested were available.
この例は、事実がその後のMLSTでコマンドを要求したのを変化するという効果に示します。 構文エラーが選択された事実のセットを変わりがないままにするのに注意してください。 また、事実が全く選択されなかったとき、まさに2つの空間がパス名に先行しているのに注意してください、故意にまたは要求された事実のいずれも利用可能でなかったので。
8. Impact on Other FTP Commands
8. 他のFTPコマンドのときに、影響を与えてください。
Along with the introduction of MLST, traditional FTP commands must be extended to allow for the use of more than US-ASCII [1] or EBCDIC character sets. In general, the support of MLST requires support for arbitrary character sets wherever file names and directory names are allowed. This applies equally to both arguments given to the following commands and to the replies from them, as appropriate.
MLSTの導入と共に、十二分に米国のASCIIの[1]かEBCDIC文字集合の使用を考慮するために伝統的なFTPコマンドを広げなければなりません。 一般に、ファイル名とディレクトリ名がどこに許容されていても、MLSTのサポートは気紛れな質セットに支持を要します。 これは等しく両方の議論に以下のコマンドと、そして、それらからの回答に与えて、適切な状態で適用されます。
Hethmon Standards Track [Page 54] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[54ページ]。
APPE RMD
CWD RNFR
DELE RNTO
MKD STAT
PWD STOR
RETR STOU
APPE RMD CWD RNFR DELE RNTO MKDスタットPWD STOR RETR STOU
The arguments to all of these commands should be processed the same way that MLST commands and responses are processed with respect to handling embedded spaces, CRs and NULs. See section 2.2.
これらのコマンドのすべてへの議論はMLSTが命令するのと同じように処理されるべきです、そして、応答は取り扱いの埋め込まれた空間、CRs、およびNULsに関して処理されます。 セクション2.2を見てください。
9. Character Sets and Internationalization
9. 文字コードと国際化
FTP commands are protocol elements, and are always expressed in ASCII. FTP responses are composed of the numeric code, which is a protocol element, and a message, which is often expected to convey information to the user. It is not expected that users normally interact directly with the protocol elements, rather the user-FTP process constructs the commands, and interprets the results, in the manner best suited for the particular user. Explanatory text in responses generally has no particular meaning to the protocol. The numeric codes provide all necessary information. Server-PIs are free to provide the text in any language that can be adequately represented in ASCII, or where an alternative language and representation has been negotiated (see [7]) in that language and representation.
FTPコマンドは、プロトコル要素であり、ASCIIでいつも表されます。 FTP応答は数字コード、およびメッセージで構成されます。(数字コードはプロトコル要素です)。(それは、ユーザに情報を伝達するとしばしば予想されます)。 通常、ユーザが直接プロトコル要素と対話して、むしろユーザFTPプロセスがコマンドを構成して、結果を機械言語に翻訳処理をしないと予想されます、特定のユーザに最もよく合う方法で。 一般に、応答における説明しているテキストはどんな特定の意味もプロトコルに持っていません。 数字コードはすべての必要事項を提供します。 サーバ-PIsはASCIIで適切に表すことができるか、または代替手段言語と表現が交渉されたどんな言語でも自由にテキストを提供できます。(その言語と表現における[7])を見てください。
Pathnames are expected to be encoded in UTF-8 allowing essentially any character to be represented in a pathname. Meaningful pathnames are defined by the server NVFS.
本質的にはどんなキャラクタもパス名で代理をされるのを許容するUTF-8でパス名がコード化されると予想されます。 重要なパス名はサーバNVFSによって定義されます。
No restrictions at all are placed upon the contents of files transferred using the FTP protocols. Unless the "media-type" fact is provided in a MLSx response nor is any advice given here that would allow determining the content type. That information is assumed to be obtained via other means.
全くいいえ制限はFTPプロトコルを使用することで移されたファイルのコンテンツに置かれます。 「メディアタイプ」事実がMLSx応答に提供されて、ここに与えられたあらゆるアドバイスでないなら、それで、content typeを決定するでしょう。 他の手段でその情報が得られると思われます。
10. IANA Considerations
10. IANA問題
This specification makes use of some lists of values currently maintained by the IANA, and creates two new lists for the IANA to maintain. It does not add any values to any existing registries.
この仕様は、現在IANAによって維持されている値のいくつかのリストを利用して、IANAが維持する2つの新しいリストを作成します。 それはどんな既存の登録にも少しの値も加えません。
The existing IANA registries used by this specification are modified using mechanisms specified elsewhere.
IANA登録がこの仕様で使用した存在は、ほかの場所で指定されたメカニズムを使用することで変更されています。
Hethmon Standards Track [Page 55] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[55ページ]。
10.1. The OS-Specific Fact Registry
10.1. OS特有の事実登録
A registry of OS specific fact names shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a fact name to this OS specific registry of OS specific facts, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific fact name, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific fact name has not been previously defined, the IANA will add the specification to the registry.
OSの特定の事実名の登録はIANAによって維持されるものとします。 事実名のOS部分へのOS名はIANAの登録されたOS名のリストから抜粋されなければなりません。 OSの特定の事実のこのOSの特定の登録に事実名を加えるために、応募者は要求をIANAに送らなければなりません。(そこでは、指定されます)OS名、OSの特定の事実名、特定の事実とその値に関連しているようにこのドキュメント、および仕様で意味論を与えるようにトークンの構文に従わなければならない事実価値の構文の定義。 そのようなアプリケーションとOS名とOSの特定の事実名の組み合わせが以前に定義されていないかどうかを受け取り次第、IANAは登録に仕様を加えるでしょう。
Any examples of OS specific facts found in this document are to be treated as examples of possible OS specific facts, and do not form a part of the IANA's registry merely because of being included in this document.
本書では見つけられたOSの特定の事実に関するどんな例も、可能なOS特定の事実に関する例として扱われて、単に本書では含まれているのでIANAの登録の一部を形成しないことです。
10.2. The OS-Specific Filetype Registry
10.2. OS特有のFiletype登録
A registry of OS specific file types shall be maintained by the IANA. The OS names for the OS portion of the fact name must be taken from the IANA's list of registered OS names. To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values. Upon receipt of such an application, and if the combination of OS name and OS specific file type has not been previously defined, the IANA will add the specification to the registry.
OSの特定のファイルの種類の登録はIANAによって維持されるものとします。 事実名のOS部分へのOS名はIANAの登録されたOS名のリストから抜粋されなければなりません。 OSの特定のファイルの種類のこのOSの特定の登録にファイルの種類を加えるために、応募者は要求をIANAに送らなければなりません。(そこでは、指定されます)OS名、OSの特定のファイルの種類、特定の事実とその値に関連しているようにこのドキュメント、および仕様で意味論を与えるようにトークンの構文に従わなければならない事実価値の構文の定義。 そのようなアプリケーションとOS名とOSの特定のファイルの種類の組み合わせが以前に定義されていないかどうかを受け取り次第、IANAは登録に仕様を加えるでしょう。
Any examples of OS specific file types found in this document are to be treated as potential OS specific file types only, and do not form a part of the IANA's registry merely because of being included in this document.
本書では見つけられたOSの特定のファイルの種類に関するどんな例も、潜在的OS特定のファイルの種類だけとして扱われて、単に本書では含まれているのでIANAの登録の一部を形成しないことです。
Hethmon Standards Track [Page 56] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[56ページ]。
11. Security Considerations
11. セキュリティ問題
This memo does not directly concern security. It is not believed that any of the mechanisms documented here impact in any particular way upon the security of FTP.
このメモは直接セキュリティに関係がありません。 ここに記録されたメカニズムのどれかにFTPのセキュリティでどんな特定の方法でも影響を与えるのは信じられていません。
Implementing the SIZE command, and perhaps some of the facts of the MLSx commands, may impose a considerable load on the server, which could lead to denial of service attacks. Servers have, however, implemented this for many years, without significant reported difficulties.
MLSxコマンドの事実のSIZEがコマンドであると実装して、恐らくいくつかがかなりの負荷をサーバに課すかもしれません。(それは、サービス不能攻撃につながることができました)。 しかしながら、サーバは何年間も重要な報告された困難なしでこれを実装しています。
The server-FTP should take care not to reveal sensitive information about files to unauthorised parties. In particular, some underlying filesystems provide a file identifier that, if known, can allow many of the filesystem protection mechanisms to be by-passed. That identifier would not be a suitable choice to use as the basis of the value of the unique fact.
サーバFTPは、権限のないパーティーにファイルに関する機密情報を明らかにしないように注意されるべきです。 特に、いくつかの基本的なファイルシステムが知られているならファイルシステム保護メカニズムの多くが迂回できるファイル識別名を提供します。 その識別子はユニークな事実の価値の基礎として使用する適当な選択でないでしょう。
The FEAT and OPTS commands may be issued before the FTP authentication has occurred [6]. This allows unauthenticated clients to determine which of the features defined here are supported, and to negotiate the fact list for MLSx output. No actual MLSx commands may be issued however, and no problems with permitting the selection of the format prior to authentication are foreseen.
FEATとOPTSコマンドは発行されて、FTP認証の前に[6]が起こっていたということであるかもしれません。 これで、非認証されたクライアントは、ここで定義された特徴のどれがサポートされるかを決定して、MLSx出力のための事実リストを交渉します。 しかしながら、どんな実際のMLSxコマンドも発行しないかもしれません、そして、認証の前に形式の選択を可能にすることに関する問題について全く見通しません。
A general discussion of issues related to the security of FTP can be found in [13].
[13]でFTPのセキュリティに関連する問題の一般的な議論を見つけることができます。
Hethmon Standards Track [Page 57] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[57ページ]。
12. Normative References
12. 引用規格
[1] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[1]コード化文字集合--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[2] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
3629, November 2003.
[2]Yergeau、2003年11月のF.、「UTF-8、ISO10646の変換形式」RFC3629。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
9, RFC 959, October 1985.
[3] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、1985年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[5] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[6] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the
File Transfer Protocol", RFC 2389, August 1998.
[6] ヘスマンとP.とR.Elz、「File Transferプロトコルのための特徴交渉メカニズム」、RFC2389、1998年8月。
[7] Curtin, B., "Internationalization of the File Transfer
Protocol", RFC 2640, July 1999.
[7] カーティン、B.、「ファイル転送プロトコルの国際化」、RFC2640、1999年7月。
[8] Postel, J. and J. Reynolds, "Telnet protocol Specification", STD
8, RFC 854, May 1983.
[8] ポステルとJ.とJ.レイノルズ、「telnetプロトコルSpecification」、STD8、RFC854、1983年5月。
[9] Braden, R,. "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989.
[9] ブレーデン、R、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[10] ISO/IEC 10646-1:1993 "Universal multiple-octet coded character
set (UCS) -- Part 1: Architecture and basic multilingual plane",
International Standard -- Information Technology, 1993.
[10] ISO/IEC10646-1:1993、「普遍的な複数の八重奏コード化文字集合(UCS)--、第1部:、」 情報Technology、国際「アーキテクチャと基本的な多言語飛行機」Standard--1993。
[11] Internet Assigned Numbers Authority. http://www.iana.org
Email: iana@iana.org.
[11] 規定番号権威インターネット http://www.iana.org はメールします: iana@iana.org 。
[12] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP
47, RFC 4646, September 2006.
フィリップス(A.とM.デイヴィス)が「言語を特定するためにタグ付けをする」[12]、BCP47、RFC4646、2006年9月。
[13] Allman, M. and S. Ostermann, "FTP Security Considerations" RFC
2577, May 1999.
[13] オールマン、M.、およびS.オステルマン(「FTPセキュリティ問題」RFC2577)は1999がそうするかもしれません。
Hethmon Standards Track [Page 58] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[58ページ]。
Acknowledgments
承認
This document is a product of the FTPEXT working group of the IETF.
このドキュメントはIETFのFTPEXTワーキンググループの製品です。
The following people are among those who have contributed to this document:
以下の人々はこのドキュメントに貢献した人の中にいます:
Alex Belits
D. J. Bernstein
Dave Cridland
Martin J. Duerst
Bill Fenner (and the rest of the IESG)
Paul Ford-Hutchinson
Mike Gleason
Mark Harris
Stephen Head
Alun Jones
Andrew Main
James Matthews
Luke Mewburn
Jan Mikkelsen
Keith Moore
Buz Owen
Mark Symons
Stephen Tihor
and the entire FTPEXT working group of the IETF.
アレックス・Belits D.J.バーンスタイン・デーヴ・Cridlandマーチン・J.Duerstビル・フェナー(そして、IESGの残り)ポールフォード-ハッチンソンマイクグリーソンマークハリススティーブンHeadアランジョーンズアンドリューMainジェームスマシューズルークMewburnジャンミッケルセンキースムーアBuzオーエンマークシモンズスティーブンTihorとIETFの全体のFTPEXTワーキンググループ。
Apologies are offered to any inadvertently omitted.
いずれにもうっかり省略されていた状態で謝られます。
The description of the modifications to the REST command and the MDTM and SIZE commands comes from a set of modifications suggested for STD 9, RFC 959 by Rick Adams in 1989. A document containing just those commands, edited by David Borman, has been merged with this document.
RESTコマンド、MDTM、およびSIZEコマンドへの変更の記述はSTD9(1989年のリック・アダムスによるRFC959)のために示された1セットの変更から来ます。 まさしくデヴィッド・ボーマンによって編集されたそれらのコマンドを含むドキュメントはこのドキュメントに合併されました。
Mike Gleason, Alun Jones and Luke Mewburn provided access to FTP servers used in some of the examples.
マイク・グリーソン、アラン・ジョーンズ、およびルークMewburnは例のいくつかで使用されるFTPサーバへのアクセスを提供しました。
All of the examples in this document are taken from actual client/server exchanges, though some have been edited for brevity, or to meet document formatting requirements.
実際のクライアント/サーバ交換から例のすべてを本書では取ります、或るものは簡潔さかドキュメント形式必要条件を満たすために編集されましたが。
RFC Editor Note:
RFCエディタ注意:
Several of the examples in this document exceed the RFC standard line length of 72 characters. Since this document is a standards-track result of an IETF working group and is important to an IETF sub- community, the RFC Editor is publishing it with the margin violations. This is not a precedent.
いくつかの例が本書では72のキャラクタのRFCの標準の行長を超えています。 このドキュメントがIETFワーキンググループの標準化過程結果であり、IETFサブ共同体に重要であるので、RFC Editorはマージン違反でそれを発行しています。 これは先例ではありません。
Hethmon Standards Track [Page 59] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[59ページ]。
Author's Address
作者のアドレス
Paul Hethmon Hethmon Software 10420 Jackson Oaks Way, Suite 201 Knoxville, TN 37922
ノクスビル、Suite201テネシー ポールヘスマンヘスマンSoftware10420ジャクソンオーク道、37922
EMail: phethmon@hethmon.com
メール: phethmon@hethmon.com
Hethmon Standards Track [Page 60] RFC 3659 Extensions to FTP March 2007
ヘスマンStandardsは2007年のFTP行進までRFC3659拡張子を追跡します[60ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hethmon Standards Track [Page 61]
ヘスマン標準化過程[61ページ]
一覧
スポンサーリンク
