RFC221 日本語訳

Network Working Group                                          R. Watson
Request for Comments: 221                                        SRI-ARC
NIC: 7612                                                 25 August 1971

コメントを求めるワーキンググループR.ワトソン要求をネットワークでつないでください: 221 様アークNIC: 7612 1971年8月25日

                     A Mail Box Protocol, Version-2

メールボックスプロトコル、バージョン-2

INTRODUCTION

序論

   Initial reaction to RFC 196, "A Mail Box Protocol", NIC (7141,)
   indicates general agreement on the need for such a mechanism.  The
   conventions suggested in RFC 196 assumed only the use of the Data
   Transfer Protocol (in NIC 7104) in order to simplify an initial
   implementation.  The valid argument, we believe, has been made that
   sites will also implement the File Transfer Protocol and that as much
   as possible the Mail Box Protocol should be a subset of it.  This
   version is in answer to this suggestion.

そのようなメカニズムの必要性でRFC196、NIC(7141)が示す「メールボックスプロトコル」一般協定への反応に頭文字をつけてください。 コンベンションは初期の実装を簡素化するためにData Transferプロトコル(NIC7104の)の使用だけであると思われたRFC196に示されました。 私たちは、また、サイトがFile Transferプロトコルを実装して、メールBoxプロトコルができるだけ、それの部分集合であるべきであるという有効な主張をしたと信じています。 このバージョンはこの提案に答えています。

   The purpose of a mail box protocol is to provide at each site a
   standard mechanism to receive sequential files for immediate or
   deferred printing or other uses.  The files for deferred printing
   would probably be stored in intermediate disk files, although details
   of how a file is handled, stored, manipulated, or printed at a site
   are not the concern of this protocol.

メールボックスプロトコルの目的は即座の、または、延期された印刷か他の用途のための順編成ファイルを受け取るために各サイトで標準のメカニズムを提供することです。 延期された印刷のためのファイルはたぶん中間的ディスクファイルに保存されるでしょう、ファイルがサイトで扱われるか、保存されるか、操作されるか、またはどう印刷されるかに関する詳細がこのプロトコルの関心ではありませんが。

   A mail box, as we see it, is simply a write only (from the Network)
   sequential file to which messages and documents are appended,
   separated by an appropriate site dependent code.

メッセージとドキュメントが追加される順編成ファイルだけを書いて、適切なサイトに依存するコードによって切り離されて、私たちがそれを見るとき、メールボックスは単にaです。

   It is also assumed that there would be a program at the sending site
   which sends the file in the format given below with the optional
   control codes when appropriate.  This program could probably be
   accessed as a subcommand of the Telnet program.

また、プログラムが適切であるときに随意コントロールコードと共に以下に与えられた書式でファイルを送る送付サイトにあると思われます。 たぶんTelnetプログラムのサブコマンドとしてこのプログラムにアクセスできました。

   The motivation for developing this protocol is the Network
   Information Center's (NIC) need to be able to deliver messages and
   documents to remote sites, and to be able to receive documents for
   cataloging, redistribution, and other purposes from remote sites
   without having to know the details of path name conventions and file
   system commands at each site.  Multiple mail boxes (256) are allowed
   at each site and are identified as described below.  The default is
   mail box number 0 for use with the standard mail printer defined
   below.

このプロトコルを開発することに関する動機はインフォメーション・センターの(NIC)がメッセージとドキュメントをリモートサイトに提供して、リモートサイトから各サイトでパス名コンベンションとファイルシステム・コマンドの詳細を知る必要はなくてカタログに載せる、再分配、および他の目的のためのドキュメントを受け取ることができる必要があるNetworkです。 複数のメールボックス(256)が、各サイトに許容されていて、以下で説明されるように特定されます。 デフォルトは郵便プリンタが以下で定義されている使用のメールボックスNo.0です。

   The only place where the Mail Box Protocol has a potential conflict
   with the File Transfer Protocol is in file naming conventions.  The
   File Transfer Protocol assumes that the using site will use a
   filename which follows the access and file path name conventions of

ファイル命名規則にはメールBoxプロトコルがFile Transferプロトコルとの潜在的闘争を持っている唯一の場所があります。 File Transferプロトコルは、それが意志がアクセスに続くファイル名を使用して、パス名コンベンションをファイルする使用サイトであると仮定します。

Watson                                                          [Page 1]

RFC 221               MAIL BOX PROTOCOL, VERSION-2        25 August 1971

ワトソン[1ページ]RFC221メールボックスプロトコル、バージョン-2 1971年8月25日

   the serving site and that this information would be supplied by the
   user.  In the Mail Box protocol we would like not to have to
   explicitly know the path name conventions at each site.

サイトとそれに役立って、この情報はユーザによって提供されるでしょう。 メールBoxプロトコルでは、各サイトで明らかにパス名コンベンションを知る必要はなくたいと思います。

   In other words there is a need for a network virtual pathname
   convention.  We did not want to solve this problem in general at this
   time and in RFC 196, NIC 7141, proposed the use of a separate socket
   for mail type delivery and the use of an integer 0-127 to specify the
   address of a specific file (Mail Box) to be appended to as the
   simplest form of network-wide standard file name convention for an
   initial implementation.

言い換えれば、ネットワークの仮想のパス名コンベンションの必要があります。 私たちはこのとき一般に、この問題を解決したくはありませんでした、そして、RFCでは、メールタイプ配送と整数0-127の使用が初期の実装のための最も簡単なフォームのネットワーク全体の標準ファイル名前コンベンションとして追加される特定のファイル(Boxに郵送する)のアドレスを指定するように、196(NIC7141)は別々のソケットの使用を提案しました。

   To follow more closely the spirit of the File Transfer Protocol, I
   would now recommend the Append Request be specifically used and that
   the standard socket agreed on for use with the File Transfer Protocol
   also be used.  Following the byte indicating an Append request, there
   would be a standard agreed-upon string of letters followed by a
   number, indicating that this is a mail box append request.  A
   suggested name string would be NETMAIL#, where # is a byte
   interpreted as a mail box number 0-255.  If the above suggested Mail
   Box file naming convention is unsuitable and some other network-wide
   standard mail box naming can be agreed on, then it can be used.
   Please let me know how you feel about this naming convention.

より密接にFile Transferプロトコルの精神に従うために、私は、現在Append Requestが明確に使用されることを勧めるでしょう、そして、また、File Transferプロトコルとの使用のために同意された標準のソケットは使用されます。 数が、Append要求であり、手紙の標準の同意しているストリングがあるのを示すバイトに続くということになって、これがメールボックスであることを示して、要求を追加してください。 #提案された名前ストリングはNETMAIL#であるだろう、解釈された1バイトはどこのメール私書箱番号0-255ですか? 上の提案されたメールBoxファイル命名規則が不適当であり、ある他のネットワーク全体の郵便箱の命名に同意できるなら、それを使用できます。 この命名規則に関してどのように感じるかを私にお知らせください。

   Given agreement on a standard mail box pathname, then the Mail Box
   Protocol can utilize a subset of the File Transfer Protocol
   conventions to be given below.

郵便箱のパス名の協定を考えて、そして、メールBoxプロトコルは以下に与えられているFile Transferプロトコルコンベンションの部分集合を利用できます。

   The other problem which was raised about the Mail Box Protocol was
   the possibility of someone accidentally or deliberately flooding the
   printer of a site with garbage, as there are no access or file size
   controls.  Some thinking and discussions of this problem have yielded
   no simple satisfactory solutions.  I would recommend initial
   implementations without standard special safeguards in this area.
   Safeguards would be a site-dependent option.  Standard safeguards for
   the above problem can be easily added later if they really prove
   necessary and satisfactory ones can be agreed on.

メールBoxプロトコルに関して提起されたもう片方の問題はだれかが偶然か故意にゴミでサイトのプリンタをあふれさせる可能性でした、どんなアクセスもファイルサイズコントロールもないとき。 この問題のいくつかの考えと議論はどんな簡単な満足な解決ももたらしていません。 私はこの領域で標準の特別セーフガードなしで初期の実装を推薦するでしょう。 安全装置はサイト依存するオプションでしょう。 本当に必要であると判明して、満足できるものに同意できるなら、後で容易に上の問題のための標準の安全装置を加えることができます。

Watson                                                          [Page 2]

RFC 221               MAIL BOX PROTOCOL, VERSION-2        25 August 1971

ワトソン[2ページ]RFC221メールボックスプロトコル、バージョン-2 1971年8月25日

                       MAIL BOX PROTOCOL - VERSION 2

メールボックスプロトコル--バージョン2

   The Mail Box Protocol will use established network conventions,
   specifically the Network Control Program, Initial Connection
   Protocol, Data Transfer Protocol, and File Transfer Protocol (as
   described in Current Network Protocols, NIC 7104).

メールBoxプロトコルは既存のネットワークコンベンション、明確にNetwork Control Program、Initial Connectionプロトコル、Data Transferプロトコル、およびFile Transferプロトコルを使用するでしょう(Current Networkプロトコル、NIC7104で説明されるように)。

   The normal transmission for Mail Box 0 is to be Network ASCII.  The
   standard receiving mail printer for mail box number 0 is assumed to
   have a print line 72 characters wide, and a page of 66 lines.  The
   new line convention will be carriage return (Hex '0D'), (Octal '015')
   followed by line feed (Hex '0A') (Octal '012') as per the Telnet
   Protocol, RFC 158, NIC 6768.  The standard printer will accept form
   feed (Hex '0C') (Octal '014') as meaning move paper to the top of a
   new page.

メールBox0において通常のトランスミッションはNetwork ASCIIであることです。 メールボックスNo.0のための標準の受信メールプリンタには印刷系列があると思われる、72のキャラクタ、広さ、そして、1ページの66の系列。 '復帰改行コンベンションが復帰('0D'に魔法をかける)である、(8進015年、'、)、改行(十六進法'0A')があとに続いている、(8進012年、'、)、テルネット・プロトコルのように、RFC158、NIC6768です。 '標準のプリンタが改ページ(十六進法'0C')を受け入れる、(8進014年、'、)、意味として、紙を新しいページの上部に動かしてください。

   It is the sender's responsibility to control the length of the print
   line and page.  If more than 72 characters per line are sent, or if
   more than 66 lines are sent without a form feed, then the receiving
   site can handle these situations as appropriate for them.  These
   conventions can be changed by control codes as described below.

印刷系列とページの長さを制御するのは、送付者の責任です。 1系列あたり72以上のキャラクタを送るか、または改ページなしで66以上の系列を送るなら、受信サイトはそれらのために適宜これらの状況を扱うことができます。 制御コードは以下で説明されるようにこれらのコンベンションを変えることができます。

   At the head of the message or document sent to mail box number 0
   there is to be an initial address string terminated by a form feed.
   This address string is to contain the sender's name and address, and
   the receiver's name and address formatted in some reasonable, easy-
   to-read form for a clerk to read and distribute.  Comments could also
   be included in the address string.

メールに送られたメッセージかドキュメントのヘッドでは、そこの箱のNo.0は初期のアドレスストリングである改ページで終えられたことです。 このアドレスストリングは読書への事務員が読んで、配布する何らかの妥当で、簡単な書式でフォーマットされた受信機の差出人住所氏名、名前、およびアドレスを含むことです。 また、アドレスストリングにコメントを含むことができました。

   The format of information in mail boxes other than mail box number 0
   is not explicitly defined by this protocol.

メールボックスNo.0以外のメールボックスの中の情報の書式はこのプロトコルによって明らかに定義されません。

Initial Connection

初期の接続

   Initial Connection will be as per the Official Initial Connection
   Protocol, Document #2, NIC 7101, to the standard File Transfer socket
   not yet assigned.  A candidate socket number, socket #3, has been
   suggested.

初期のConnectionがOfficial Initial Connectionプロトコルに従ってあるでしょう、Document#2、NIC7101、まだ割り当てられていなかった標準のFile Transferソケットに。 候補ソケット番号(ソケット#3)は示されました。

File Transfer

ファイル転送

   The mail item (file) to be transferred would be transferred according
   to the File Transfer Protocol.

File Transferプロトコルに応じて、移されるべきメール商品(ファイル)を移すでしょう。

   As per the File Transfer Protocol, a file (mail item) can be sent in
   more than one data transaction as defined in the Data Transfer
   Protocol.  End of file is indicated by the file separator (as defined
   in Data Transfer Protocol) or by closing the connection.

File Transferプロトコルに従って、Data Transferプロトコルで定義されるように1つ以上のデータトランザクションでファイル(メール項目)を送ることができます。 ファイルの終りは、ファイル分離文字(Data Transferプロトコルで定義されるように)か接続を終えることによって、示されます。

Watson                                                          [Page 3]

RFC 221               MAIL BOX PROTOCOL, VERSION-2        25 August 1971

ワトソン[3ページ]RFC221メールボックスプロトコル、バージョン-2 1971年8月25日

Order of Transactions

トランザクションの注文

   The only basic operation required is an append.

必要である唯一の基本的な操作がそう、追加します。

                    Append Request

要求を追加してください。

   (Mailer) User  -------------------->  server (Mail Box)

(メイラー)ユーザ-------------------->サーバ(メールボックス)

                     <File - data>

<ファイル--データ>。

                   ------------------->

------------------->。

                   End of File indication

File指示の終わり

                   ------------------->

------------------->。

                       Acknowledge

承認します。

                   <-------------------

<。-------------------

   The data type default is network ASCII.  The standard line printer
   default is as defined above.  Other control transactions can be used.

データ型デフォルトはASCIIをネットワークでつなぐことです。 上で定義されるとして標準のラインプリンタデフォルトがあります。 他のコントロールトランザクションを使用できます。

CONTROL TRANSACTIONS TO BE USED

トランザクションを制御して、使用されてください。

   OP CODE

オペコード

   Hex     Octal
   00      000     Change data type identifier
   09      011     Error or unsuccessful terminate
   0A      012     Acknowledge or successful terminate
   0B      013     Append request (add to existing file)
   5A      132     Change printer control settings

十六進法Octal00 000Changeデータ型識別子09 011Errorか失敗、Acknowledgeかうまくいった状態で0A012を終えてください、0B013Append要求(既存ファイルに追加する)5A132Change印刷制御機構設定を終えてください。

DATA TYPE CODES

データ型コード

   All data types of the File Transfer Protocol can be used for special
   applications.  For Mail Box 0, default is 8 bit bytes of Network
   ASCII characters.

特別なアプリケーションにFile Transferプロトコルに関するすべてのデータ型を使用できます。 メールBox0に関しては、デフォルトはNetwork ASCII文字の8ビットのバイトです。

ERROR CODES

エラーコード

   All error codes defined in the File Transfer Protocol could be
   returned.

File Transferプロトコルで定義されたすべてのエラーコードは返すことができました。

Watson                                                          [Page 4]

RFC 221               MAIL BOX PROTOCOL, VERSION-2        25 August 1971

ワトソン[4ページ]RFC221メールボックスプロトコル、バージョン-2 1971年8月25日

PRINTER CONTROL CODES

印刷制御機構コード

     Hex     Octal
     01      321     Meaning:  Set line width to 72 characters
     02      322     Meaning:  Use the full width of your printer
     03      323     Meaning:  Set page size to 66 lines
     04      324     Meaning:  Set page size to infinite

以下を意味する8進01 321人に魔法をかけてください。 72のキャラクタ02 322Meaningに線幅を設定してください: プリンタ03 323Meaningの全幅を使用してください: 66の系列04 324Meaningにページ・サイズを設定してください: 無限にページ・サイズを設定してください。

   Other virtual printer control codes can be added in the future.
   Other classes of control codes can be added as the need arises.

将来、他の仮想のプリンタ制御コードを加えることができます。 必要に応じて他のクラスの制御コードを加えることができます。

   <JOURNAL>7612.NLS;1, 27-AUG-71 10:41 RWW ; (Expedite) Title:
   Author(s): Richard W. Watson/RWW; Distribution: SDC2 TFL JWM JFH REL
   AOJO JEW AWH DLM PWF RAW HRVZ AAM RLS JMM JMW AKB PMK TNP ASL BMW JAM
   EAF RTB JMP BDW JTM JCL AJB CDS RFH EMA;/NWG; Sub-Collections: NWG
   ARC NIC; RFC# 221; Clerk: RWW;
   Origin: <WATSON>MAIL.NLS;4, 27-AUG-71 9:51 RWW ;

<ジャーナル>7612.NLS; 1 27 8月の71 10: 41RWW。 (速めます) タイトル: 作者: リチャードW.ワトソン/RWW。 分配: SDC2 TFL JWM JFH REL AOJOのAWH DLM PWFの生のHRVZ AAM RLS JMM JMW AKB PMK TNP ASL BMWジャムユダヤ人EAF RTB JMP BDW JTM JCL AJB CDS RFH EMA; /NWG。 サブ収集: NWGアークNIC。 RFC#221。 事務員: RWW。 発生源: <ワトソン>MAIL.NLS; 4 27 8月の71 9:51RWW。

         [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Ryan Kato 6/01 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ライアン・加藤6/01によるオンラインRFCアーカイブへの]

Watson                                                          [Page 5]

ワトソン[5ページ]