RFC448 日本語訳

NETWORK WORKING GROUP                                  R.T. Braden
REQUEST FOR COMMENT NO. 448                            UCLA/CCN
NIC #13299                                             February 27, 1973
UPDATES: RFC 354, 385, 454

UCLA/CCN NIC#13299が1973年2月27日にアップデートするコメントNo.448を求めるワーキンググループR.T.ブレーデン要求をネットワークでつないでください: RFC354、385、454

                           PRINT FILES IN FTP

FTPにおける印刷ファイル

INTRODUCTION
------------

序論------------

    Many of those who contributed to the definition of the FTP and RJE
protocols have expressed varying degrees of uncertainty or unhappiness
with the "print file" type in FTP.  This RFC is intended to review the
problem of print files in preparation for the forthcoming FTP meeting.
Originally drafted on the basis of RFC 385, this RFC has been updated to
reflect the terminology of the latest FTP document 454.  (Changing the
terminology doesn't solve the problem!)

「印刷ファイル」に従って不確実性か不幸の度合いを変えるプロトコルが急送したFTPの定義に貢献した人とRJEの多くがFTPをタイプします。 このRFCが今度のFTPミーティングに備えて印刷ファイルの問題を見直すことを意図します。 元々、RFC385に基づいて作成されています、最新のFTPドキュメント454の用語を反映するためにこのRFCをアップデートしました。 (用語を変えるのは問題を解決しません!)

    It turns out that the Network RJE protocol as presently defined (see
NIC 12112) seems to force a particular interpretation of print files in
FTP and in fact, this interpretation is probably different from the one
assumed by most FTP implementors.

現在定義されているとしての(NIC12112を見ます)Network RJEプロトコルがFTPにおける、印刷ファイルの特定の解釈を強制するように思えると判明して、事実上、この解釈はたぶんほとんどのFTP作成者によって想定されたものと異なっています。

VERTICAL FORMAT CONTROL
-----------------------

垂直書式コントロール-----------------------

    What is a print file?  Presumably it is a file which is intended to
be sent (eventually) to a printer process to create a hard copy.  Many
operating systems (particularly those which are batch-processing
oriented) allow the programmer to include control codes within a file to
be printed, to control the vertical format of the printed page--for
example, single/double line spacing, overprinting, and page ejection.  A
"print file" is one which includes such vertical format control ("VFC")
information.  There are three common ways for printer processes to
determine VFC:

印刷ファイルは何ですか? おそらく、ハードコピーを作成するために(結局)どれによってプリンタプロセスに送られることを意図するかは、ファイルです。 多くのオペレーティングシステム(特に指向していた状態でバッチ処理されているもの)で、プログラマは印刷されたページの垂直書式を制御するために印刷されるためにファイルの中で制御コードを入れることができます--例えば、系列スペース、重ね打ち、およびページ射出を選抜するか、または倍にしてください。 「印刷ファイル」はそのような垂直書式コントロール("VFC")情報を含んでいるものです。 3つの一般的な方法で、決定するプリンタプロセスのために、VFCがあります:

CASE N:  Non-Print File
         --------------
         The file contains no VFC information.  The printer process
         applies a standard format (e.g., single space, standard
         vertical margins) if the file is printed.

ケースN: 非印刷ファイル-------------- ファイルはVFC情報を全く含んでいません。 ファイルが印刷されるなら、プリンタプロセスは標準書式(例えば、シングルスペース、標準の垂直なマージン)を適用します。

CASE T:  Print File with ASCII Format Effectors
         --------------------------------------
         The file is "Telnet-like", containing the ASCII controls CR,
         LF, and FF to provide VFC.

ケースT: ASCII書式制御文字がある印刷ファイル-------------------------------------- VFCを提供するASCIIコントロールのCR、LF、およびFFを含んでいて、ファイルは「telnetのようです」。

Braden                                                          [Page 1]

RFC 448                    PRINT FILES IN FTP              February 1973

ブレーデン[1ページ]RFC448はFTP1973年2月にファイルを印刷します。

CASE A:  Print File with ASA (Fortran) VFC
         ---------------------------------
         The first character of each record is a VFC code; see RFC 454
         for the codes.

ケースA: ASA(Fortran)VFCがある印刷ファイル--------------------------------- それぞれの記録の最初のキャラクタはVFCコードです。 コードに関してRFC454を見てください。

    Assuming there are to be print files in FTP, these _three_ cases
need to be considered.  These three cases are explicitly included within
the RJE protocol as "transmission" modes; we have borrowed the RJE
labels N,T, and A from NIC #12112.  The current FTP (RFC 454) seems to
provide only _two_ cases: _unformatted_ and _print_file_.  It is unclear
from RFC 454 how these two FTP formats are related to the three VFC
cases.  For example, it is unclear whether the FTP format is meant to be
a property of the file as transferred over the Network or of the file as
stored by the server.

FTPには印刷ファイルがあると仮定して、これらの_3_ケースは、考えられる必要があります。 これらの3つのケースが「トランスミッション」モードとしてRJEプロトコルの中に明らかに含まれています。 私たちはNIC#12112からRJEラベルN、T、およびAを借りました。 現在のFTP(RFC454)は_2_ケースだけを供給するように思えます: _非フォーマットされた_と_は_ファイル_を印刷します。RFC454から、これらの2つのFTP形式がどのように3つのVFCケースに関連するかは、不明瞭です。 例えば、FTP形式がサーバによって保存されるようにNetworkの上に移すか、ファイルのファイルの特性であることが意味されるかどうかが、不明瞭です。

    As I understand it, the Tenex system supports only case T.  The
distinction between Case N and Case T is not always clear, however.  If
a Tenex file which contains only the CR LF combination of format
effectors is printed, it may be considered Case N where CR LF delimits a
logical record, and where the standard format is to begin printing each
record on a new line.  The RJE protocol uses this ambiguity to
advantage; see below.

私の知るところでは、Tenexシステムは、唯一のケースT.がCase Nの区別であるとサポートします、そして、しかしながら、Case Tはいつも明確であるというわけではありません。書式制御文字のCR LF組み合わせだけを含むTenexファイルが印刷されるなら、標準書式がCR LFが論理レコードをどこに区切るか、そして、どこで復帰改行に関する各記録を印刷し始めるかことであることはCase Nであると考えられるかもしれません。 RJEプロトコルはこのあいまいさを利点に使用します。 以下を見てください。

    The IBM operating systems, on the other hand, support Cases N and A.
The "output writer" process which drives the printer must know whether
or not a file to be printed contains ASA VFC, so the system
distinguishes internally between "print files" (Case A) and non-print
files (Case N).  The "print file" attribute is normally attached to a
print file when it is created.  For example, the language processors
typically create print files for their "printer" output streams.

他方では、IBMオペレーティングシステムは、Cases NとA.が印刷されるべきファイルがASA VFCを入れてあるので、システムが内部的に、「印刷ファイル」(ケースA)と非印刷ファイル(ケースN)を見分けるか否かに関係なく、プリンタがそれのドライブを知らなければならない「出力ライタ」プロセスであるとサポートします。 それが作成されるとき、通常、「印刷ファイル」属性は印刷ファイルに取り付けられます。 例えば、言語プロセッサはそれらの「プリンタ」出力ストリームのための印刷ファイルを通常作成します。

    Hence, when CCN's server FTP executes a STOR command, it must decide
whether or not the new file is to be marked with the internal print file
attribute.  As noted earlier, FTP does not explicitly distinguish the
three possible cases.  We must either add some additional assumptions or
server-dependent information outside FTP, or we must add a new format to
FTP.

CCNのサーバFTPがSTORコマンドを実行するとき、したがって、それは、新しいファイルが内部の印刷ファイル属性で著しいかどうかことであると決めなければなりません。 より早く注意されるように、FTPは明らかに3つの可能なケースを区別しません。 私たちが何らかの追加仮定か情報のサーバ依存する外部FTPを追加しなければなりませんか、または私たちは新しい書式をFTPに追加しなければなりません。

IMPLICATIONS OF RJE
-------------------

RJEの含意-------------------

To send an output ("printer") file to a user host, the RJE server will
cause his FTP user process to send the file with the following
attributes*:

出力(「プリンタ」)ファイルをユーザー・ホストに送るために、RJEサーバで、彼のFTPユーザ・プロセスは以下の属性*があるファイルを送るでしょう:

*Note:  Making the obvious conversion from RFC 385 to RFC 454
terminology.

*以下に注意してください。 明白なRFC385からRFC454までの変換を用語にします。

Braden                                                          [Page 2]

RFC 448                    PRINT FILES IN FTP              February 1973

ブレーデン[2ページ]RFC448はFTP1973年2月にファイルを印刷します。

 VFC Case      |     FORMat            |     STRUcture
-------------------------------------------------------------------
  N            |     Unformatted       |     Record structure
               |     -                 |     -
  T            |     Unformatted       |     File structure
               |     -                 |     -
  A            |     Print File        |     Record structure
               |     -                 |     -

VFCケース| 形式| 構造------------------------------------------------------------------- N| Unformattedしました。| 構造を記録してください。| - | - T| Unformattedしました。| ファイル構造| - | - A| 印刷ファイル| 構造を記録してください。| - | -

Thus, the authors of RJE intended to use the _structure_ attribute to
resolve Cases N and T.  This is perhaps a reasonable choice, but we
should understand the consequences and make them explicit within the FTP
document.

したがって、RJEの作者がCases Nを決議するのに_構造_属性を使用するつもりであり、T.Thisが恐らく正当な選択ですが、私たちは、結果を理解して、それらをFTPドキュメントの中に明白にするべきです。

Assume for the moment that we want to maintain perfect consistency
between FTP and RJE.  An FTP server which uses ASA VFC internally should
convert _every_ (Unformatted, Unstructured) file it receives to an
internal print file!  That is, the file must be mapped into a set of
physical lines (which are really logical records internally), and an ASA
VFC character must be appended to the beginning of each line before it
is stored.  Note that this implies that the default file structure in
FTP should be changed to _record_structure_.  (This reinforces the point
made by Wayne Hathaway in RFC 414 that if a Tenex user transmits a
source file to an IBM host and expects to manipulate it in some useful
way, he'd better send it with _record_ structure.)

さしあたり、FTPとRJEの間の完全な一貫性を維持したいと思うと仮定してください。 内部的にASA VFCを使用するFTPサーバは_それが内部の印刷ファイルに受け取るあらゆる_(Unformatted、Unstructured)ファイルを変換するべきです! 1セットの物理行(本当に内部的に論理レコードである)にすなわち、ファイルを写像しなければなりません、そして、それを保存する前にそれぞれの系列の始まりまでASA VFCキャラクタを追加しなければなりません。 これが、FTPにおけるデフォルトファイル構造が_記録_構造_に変わるはずであるのを含意することに注意してください。(これはTenexユーザが、IBMのホストにソースファイルを送って、何らかの役に立つ方法でそれを操ると予想するなら、彼が_記録_構造でそれを送るほうがよいというRFC414のウェインハザウェイによって指摘されたポイントを補強します。)

ANOTHER CHOICE
--------------

別の選択--------------

    If the loss of (unformatted, unstructured) as a simple default case
is too offensive, we can simply change FTP to include three formats
corresponding to Cases N, A, and T.  RJE would be changed
correspondingly.

損失である、(非フォーマットされて、不統一な) 簡単な不履行格が攻撃用過ぎるときに、私たちはCases Nに対応する3つの形式を含むように単にFTPを変えることができます、A、そして、T. RJEを対応する変えるでしょう。

ACKNOWLEDGMENTS
---------------

承認---------------

    Discussions with Steve Wolfe, Jon Postel, and Eric Harslem were very
helpful in clarifying the print file problem in FTP.

スティーブ・ウルフ、ジョン・ポステル、およびエリックHarslemとの議論はFTPにおける印刷ファイル問題をはっきりさせる際に非常に役立っていました。

RTB/gjm

RTB/gjm

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社9/99]

Braden                                                          [Page 3]

ブレーデン[3ページ]