RFC555 日本語訳

Network Working Group                               James E. White (JEW)
Request for Comments: 555                                        SRI-ARC
NIC: 17993                                                 July 27, 1973

白の(JEW)がコメントのために要求するワーキンググループジェームスE.をネットワークでつないでください: 555 様アークNIC: 17993 1973年7月27日

          Response to Critiques of the Proposed Mail Protocol

提案されたメールプロトコルの批評への応答

   A number of people have responded to my proposal for a Mail Protocol
   (JEW RFC 524 -- 17140,2:y).  In the current RFC, I've attempted to
   collect and respond to the questions, complaints, and suggestions
   that various individuals in the Network community have offered.  I
   intend to critique myself in a forthcoming RFC.

多くの人々がメールプロトコル(JEW RFC524 -- 17140、2: y)のための私の提案に応じました。 現在のRFCでは、私は、Network共同体の様々な個人が提供した質問、苦情、および提案に集まって、応じるのを試みました。 私は今度のRFCで自分を批判するつもりです。

   I hope that dialog on the protocol proposal will continue, and that
   others will join in the discussion.  I will respond via RFC to any
   additional critiques I receive (I hope there'll be many).

プロトコル提案での対話が続いて、他のものが討議に加わることを願っています。 私は私が受けるどんな追加批評へのRFCを通しても応じるつもりです(多くがあることを願っています)。

I.  QUESTIONS

I. 問題

   HOW DOES THE SERVER VERIFY AN ID?

サーバはどのようにIDについて確かめますか?

      References:

参照:

         (DHC JBP RFC 539 -- 17644,3g:gy)

(3g: DHC JBP RFC539 -- 17644、gy)

      Discussion:

議論:

         One postulates the existence of AT LEAST ONE host whose Mail
         server process implements the User Verification Function (JEW
         RFC 524 -- 17140,5f7:gy).  Any process can contact that server,
         give him the name of any Individual in the Net and a test Id,
         and the server will determine whether or not the Individual and
         Id agree.

人はメールサーバプロセスがUser Verification Functionが(5f7: JEW RFC524 -- 17140、gy)であると実装するAT LEAST ONEホストの存在を仮定します。 どんなプロセスも、ネットにおけるどんなIndividualとテストIdという名前も彼に与えて、そのサーバに連絡できます、そして、サーバはIndividualとIdが同意するかどうか決定するでしょう。

            The NIC, for one, will without question provide this
            service.

NICは個人的には確かにこのサービスを提供するでしょう。

         With such support available to it, ANY FTP server process can
         then require (of any or all user processes that contact it) an
         ID command wherever it wishes within the user-server
         interchange (within the constraints of the Protocol).  The
         server simply prompts for the Id, gets it, opens a connection
         to the User Verification Agent, presents to it the Individual's
         name and purported Id, receives a positive or negative
         response, and deals with the original user process accordingly.

そして、それに利用可能なそのようなサポートで、ユーザサーバ置き換え(プロトコルの規制の中の)の中でどこで願っても、どんなFTPサーバプロセスもIDコマンドを必要とすることができます(それに連絡するいずれかすべてのユーザ・プロセスについて)。 サーバがIdのために単にうながして、それを得て、User Verificationエージェントに接続を公開していて、Individualの名義の、そして、主張されたIdをそれに寄贈して、肯定しているか否定している応答、および取引を受け取る、オリジナルのユーザはそれに従って、処理します。

White                                                           [Page 1]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[1ページ]RFC555応答

         Example:

例:

            Suppose a user process opens a connection to UCLA-NMC's
            server process, invokes the Delivery function, and in the
            course of the interchange identifies the Author as Roberts
            at USC-ISI.

ユーザ・プロセスが、UCLA-NMCのサーバプロセスに接続を開いて、Delivery機能を呼び出して、置き換えの間にUSC-ISIでAuthorがロバーツであると認識すると仮定してください。

            The implementors at UCLA-NMC's server process chose to
            require proof, in all Delivery transactions, that the Author
            is who he claims he is.  It therefore prompts for an Id in
            response to the AUTHOR command from the user process, and
            receives in return the command 'ID arpawheel <CA>'.

UCLA-NMCのサーバプロセスの作成者は、Authorが彼による主張彼が人であるというすべてのDeliveryトランザクションにおける証拠を必要とするのを選びました。 したがって、それは、コマンド'ID arpawheel<カリフォルニア>'をユーザ・プロセスからのAUTHORコマンドに対応したIdのためにうながして、リターンで受けます。

            UCLA-NMC's server then connects to the NIC's server, invokes
            the User Verification function there, specifying 'REQUESTOR
            roberts @ usc-isi <CA>' and 'ID arpawheel <CA>'.  The NIC
            informs UCLA-NMS that the Id is incorrect.

UCLA-NMCのサーバは、次に、NICのサーバに接続して、そこにUser Verification機能を呼び出します、'REQUESTOR roberts@usc-isi<カリフォルニア>'と'ID arpawheel<カリフォルニア>'を指定して。 NICは、Idが不正確であることをUCLA-NMSに知らせます。

            UCLA-NMC then rejects the original ID command.

そして、UCLA-NMCはオリジナルのIDコマンドを拒絶します。

         Of course, the Protocol does not require that a server demand
         Ids from users that contact it.  Servers who choose not to
         require proof of identity simply never prompt for ID commands,
         and treat any they receive as NOPs.  For such implementations
         (which represent the current, FTP mail protocol situation), no
         third-part interchanges are ever required.

もちろん、プロトコルはサーバがそれに連絡するユーザからIdsを要求するのを必要としません。 単に身元の証拠を必要としないのを選ぶサーバは、IDにコマンドを決してうながさないで、彼らが受けるいずれもNOPsとして扱います。 そのような実装(現在のFTPメールプロトコル状況を表す)において、3番目の部分置き換えは全く今までに、必要ではありません。

         Each user in the Net has a single Id that he uses throughout
         the Net for purposes of sending and receiving mail.  That Id
         need not (but may, either coincidentally or by design) have any
         other use.  In particular, a user's Id is independent of the
         passwords by which he gains access to accounts that he might
         possess on hosts around the Net.

ネットにおける各ユーザは送受信メールの目的にネット中で使用する独身のIdを持っています。 しかし、そのIdがそうする必要はない、(デザイン) いかなる他の使用も持つかもしれなくなってください。 ユーザのIdは彼が彼がホストの上にネットの周りに持っているかもしれないアカウントへのアクセスを得るパスワードから特に、独立しています。

            Of course, a user could and might see to it that his
            passwords and Id are the same.  The NIC, for example, might
            require that a user log in to its system with NIC ident and
            Id, rather than with host name and password, as it does
            currently.

もちろん、ユーザは取り計らうことができて、彼のパスワードとIdが同じであるように取り計らうかもしれません。 例えば、NICは、システムへの中のユーザログが現在NIC identとホスト名とそれとしてのパスワードでというよりむしろIdと共にするのを必要とするかもしれません。

         I emphasize again that Ids have nothing whatsoever to do with
         accounting.  UCLA-NMC doesn't force the Author to prove his
         identity so UCLA has someone to whom it can bill the resources
         consumed in processing the Delivery transaction.  It does so to
         prevent Jim White from authoring a piece of mail and claiming
         that Larry Roberts wrote it.

私は、Idsには何も会計を処理する全くものがないと再び強調します。 AuthorがUCLA-NMCによってやむを得ず彼のアイデンティティを立証しないので、UCLAは、それが消費されたコネをリソースに請求できるそのだれかがDelivery取引を処理するのを持っています。 そう、ジム・ホワイトが、1つのメールを書いて、ラリー・ロバーツがそれを書いたと主張するのを防ぎます。

White                                                           [Page 2]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[2ページ]RFC555応答

            UCLA-NMC does have the option of requiring that a user
            process log in before it delivers mail so that it can be
            billed for the resources it uses.  The appropriate commands
            to require of the user process are USER, PASS, and ACCT.
            But, the billing process is separable from that of
            identifying Author, Clerk, etc.

UCLA-NMCには、それの前のユーザ・プロセスログインがそれが使用するリソースのためにそれを請求できるようにメールを提供するのが必要であることのオプションがあります。 ユーザ・プロセスに要求する適切なコマンドは、USERと、PASSと、ACCTです。 しかし、課金プロセスはAuthor、Clerkなどを特定するものから分離できます。

            The NIC, for example, in its role as a Distribution Agent,
            might establish an account at UCLA-NMC to use whenever it
            delivers mail there.  UCLA-NMC will bill ALL of the NIC's
            activity at UCLA to that account.  But when the NIC delivers
            a piece of mail it claims was authored by Larry Roberts,
            UCLA-NMC may still wish to verify that claim.  Hence the ID
            command.

例えばDistributionエージェントとしての役割では、メールをそこに提供するときはいつも、NICはUCLA-NMCでアカウントを使用に確立するかもしれません。 UCLA-NMCはそのアカウントへのUCLAでNICの活動のすべてに請求するでしょう。 しかし、NICが書かれたそれがラリー・ロバーツが主張する1つのメールを提供するとき、UCLA-NMCはまだそのクレームについて確かめていたがっているかもしれません。 したがって、IDコマンド。

   ACK, PROGRESS REPORT, OR REPLY WITH NO REFERENCE SERIAL NUMBER

参照通し番号のないACK、経過報告書、または回答

      References:

参照:

         (DHC JBP RFC 539 -- 17644,3h:gy)

(3h: DHC JBP RFC539 -- 17644、gy)

      Discussion:

議論:

         A Delivery of type POSITIVE or NEGATIVE ACKNOWLEDGMENT,
         PROGRESS REPORT, or REPLY requires a Reference Serial Number of
         the user process.  Should the server determine that one is
         lacking when the final EXIT command is given, he should reject
         the EXIT command with an appropriate error response.

タイプPOSITIVE、NEGATIVE ACKNOWLEDGMENT、PROGRESS REPORT、またはREPLYのDeliveryはReference Serial Numberにユーザ・プロセスを要求します。 サーバが、最終的なEXITコマンドを与えるとき、1つが欠けていることを決定するなら、彼は適切な誤り応答でEXITコマンドを拒絶するべきです。

            The same applies in the Distribution function:  a Reference
            Serial Number MUST be specified if the Delivery Type is
            REPLY.

同じくらいはDistribution機能で適用されます: Delivery TypeがREPLYであるならReference Serial Numberを指定しなければなりません。

         The Protocol document is deficient in that it doesn't state the
         above.

上記を述べないので、プロトコルドキュメントは不完全です。

II.  COMPLAINTS

II。 苦情

   TERMINATING BOTH THE SUBSYSTEM AND FUNCTIONS WITH EXIT

出口でサブシステムと機能の両方を終えます。

      References:

参照:

         (AAM -- 17404,)

(AAM--17404)

White                                                           [Page 3]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[3ページ]RFC555応答

      Discussion:

議論:

         I have no objection to defining two terminating commands, one
         to exit a function, the other to exit the subsystem.  I guess
         I'd suggest defining a command 'GO <CA>' to be used to
         terminate a function.

私は機能、サブシステムを出るもう片方を出るために2つの終わりコマンド、1を定義するのに異論を全く持っていません。 私は、機能を終えるのに使用されるべきコマンド'GO<カリフォルニア>'を定義することを提案すると推測します。

         I don't believe, however, that's it's necessary to distinguish
         the two cases to avoid confusion by human users.

私は信じないで、それによる人間のユーザによる混乱を避けるために2つのケースを区別するのが必要であるというしかしながら、ことです。

         Even though the command language is ASCII, rather than binary,
         and even though I've adopted Mike Padlipsky's concept of a
         Unified USER Level Protocol', I don't consider that MP is a
         protocol for direct use by humans (although nothing can STOP a
         human user from speaking MP if he has access to a TELNET user
         program and is determined to do so).

'コマンド言語はバイナリーよりむしろASCIIであり、私はマイクPadlipskyのUnified USER Levelプロトコルの概念を採用しました'が、私は、MPが人間によるダイレクト使用のためにプロトコルであると考えません(無はそうすることができますが、彼であるならMPを話すのからのSTOPのa人間のユーザは、TELNETユーザ・プログラムに近づく手段を持って、そうすると決心しています)。

         The concept I mean to extract from the UULP and exploit is its
         model of a single process with many subsystems, not its
         philosophy of a Network-standard command language for use by
         human users (the latter may be a good idea, too, but it's not
         the one I'm concerned with at the moment).

私がUULPと功績から抜粋するのを意図する概念は人間のユーザによる使用のためにNetwork標準のコマンド言語の哲学ではなく、その多くのサブシステムがある単一のプロセスのモデル(後者はまた、名案であるかもしれませんが、それは私が現在関するものでない)です。

         I don't think that designing a protocol to govern an exchange
         between processes is the same task as designing a protocol to
         mediate a conversation between a process and a human user.
         Using ASCII commands suggests (as it did for FTP, RJE, etc.)
         that the latter problem is the one being addressed; it's not.

私は、プロセスの間の交換を治めるようにプロトコルを設計するのが、プロセスと人間のユーザとの会話を調停するようにプロトコルを設計するのと同じタスクであると思いません。 ASCIIコマンドを使用するのは、後者の問題が扱われるものであると示唆します(FTPのためにしたように、RJEですなど)。 それはそうではありません。

   USING TELNET GO AHEAD TO TERMINATE CERTAIN COMMANDS

telnetを使用して、前に進んで、あるコマンドを終えてください。

      References:

参照:

         (AAM -- 17404,)

(AAM--17404)

         (RCC -- 17822,1a:gy)

(RCC--17822、1a: gy)

         (DHC JBP RFC 539 -- 17644,3b:gy)

(3b: DHC JBP RFC539 -- 17644、gy)

      Discussion:

議論:

         Agreed.  My mistake.

同意にされる。 私の誤り。

         I simply have a strong distaste for the current FTP convention
         of terminating commands whose argument may itself contain CR LF
         with 'CR LF . CR LF'.  That seems a little extravagant to me.
         Personally, I'd prefer a single NVT character as a delimiter.

私は議論が終えるコマンドを終える現在のFTPコンベンション自体に、強い嫌悪に'CR LF CR LF'があるCR LFを単に含ませます。 それは私には少し金遣いが荒く見えます。 直接、私はデリミタとして単独のNVTキャラクタを好むでしょう。

White                                                           [Page 4]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[4ページ]RFC555応答

         <CA2> only terminates two MP commands (COMMENTS and TEXT).
         Some NVT character (ESC? EXT? ...) can easily be chosen that
         need not appear (and can therefore be prohibited from appearing
         by the Protocol) in the argument to either of those commands.

<CA2>は2つのMPコマンド(COMMENTSとTEXT)しか終えません。 何人かのNVTキャラクタ(ESC? EXT? ...) 選ばれて、それが議論にそれらのどちらのコマンドにも現れる必要はないという(そして、したがって、プロトコルで現れるのを禁止できます)容易にことであることができます。

   SUBSYSTEM OR SEPARATE RJE-LIKE SERVER PROCESS

サブシステムか別々のRJEのようなサーバプロセス

      References:

参照:

         (DHC JBP RFC 539 -- 17644,4a:gy)

(4a: DHC JBP RFC539 -- 17644、gy)

         (AAM -- 17404,)

(AAM--17404)

         (ADO RFC 552 -- 17809,3:y)

(騒動RFC552 -- 17809、3: y)

      Discussion:

議論:

         There are two separable issues here:

分離できる2冊がここにあります:

            (1)  Server Process Proliferation of Not?

(1)サーバが増殖を処理する、--

               If the consensus of the Network community is that
               Padlipsky's UULP approach to protocol design and
               implementation is in fact superior to the current scheme,
               which calls for the implementation of each new Network
               protocol as a distinct server process with its own
               contact socket, then we should begin to embrace that
               concept and begin reshuffling existing protocol
               implementations accordingly.  Even more surely, NEW
               protocols (like MP), should be designed in accordance
               with the new standards, not the old.

Network共同体のコンセンサスがPadlipskyのUULPがデザインについて議定書の中で述べるためにアプローチするということであり、事実上、実装が現在の体系(異なったサーバプロセスとしてそれ自身の接触ソケットでそれぞれの新しいNetworkプロトコルの実装を求める)より優れているなら、私たちは、その概念を受け入れて、それに従って、既存のプロトコル実装を改造し始め始めるべきです。 以上、さえ確実にNEWプロトコル(MPのような)、新しい規格、老人でないのによると、設計されるべきです。

               I think Buz Owen's suggestion (ADO RFC 552 -- 17809,3:y)
               -- that a skeletal UULP be defined, a socket assigned to
               server processes which implement it, and MP defined as a
               subsystem under it -- is excellent.  I retract my
               suggestion (JEW RFC 524 -- 17140,3a2:gy) in favor of
               Owen's.

ソケットはそれを実装するプロセス、およびそれの下でサブシステムと定義されたMPをサーバに選任しました--私は、Buzが骨格のUULPが定義されるというオーエンの提案(ADO RFC552 -- 17809、3: y)であると思って、素晴らしいです。 私はオーエンを支持して提案(3a2: JEW RFC524 -- 17140、gy)を引っ込めます。

               I further suggest that the latest revision of FTP (NJN
               RFC 542 -- 17759,) be similarly implemented (i.e., as a
               UULP subsystem), rather then implemented temporarily
               under a new socket and later moved over to socket 3 as
               suggested in RFC 542.

私は、FTP(NJN RFC542 -- 17759)の最新の改正がRFC542に示されるように同様に実装されて(すなわち、UULPサブシステムとして)、次に、新しいソケットの下でむしろ一時実装されて、後でソケット3に譲られることをさらに提案します。

White                                                           [Page 5]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[5ページ]RFC555応答

            (2)  RJE's model for FTP Use or Not?

(2) RJEのFTP UseかNotのモデル?

               If both MP (as currently defined) and RJE were instated
               as UULP subsystems, they would still embrace different
               philosophies regarding their use of FTP.  As the person
               who proposed and fought for the current RJE model (i.e.,
               to its use of FTP),  I (still) believe it to be an
               elegant one, more elegant by far then the one I've
               proposed for MP.

MP(現在定義されているとしての)とRJEの両方がUULPサブシステムとして任命されるなら、それらはまだ彼らのFTPの使用に関する異なった哲学を受け入れているでしょうに。 現在のRJEモデル(すなわち、FTPの使用への)を提案して、守るために争った人として、私は、それが断然上品なものであって、上品であると(まだ)信じていて、次に、私が持っているのはMPのために提案しました。

               An alternative I considered and discarded SOLELY for
               reasons of efficiency (neglecting, perhaps, the issue of
               cleanness of implementation), is that the command
               currently defined as 'FILE <CA>' (JEW RFC 524 --
               17140,4q2a:gy), both in specifying Content and in the
               Citation Retrieval function, be 'FILE <fileaddr> <CA>'
               instead.

効率(恐らく、実装の清潔の問題を無視する)の理由による私が考えた代替手段と捨てられたSOLELYによること現在'FILE<カリフォルニア>'(4q2a: JEW RFC524 -- 17140、gy)と定義されているコマンドが代わりにContentを指定して、Citation Retrieval機能で'FILE<fileaddr><カリフォルニア>'であるです。

                  The server is then obliged to retrieve the Content of
                  the Mail from the designated server process via a
                  third-party exchange.

そして、サーバが指定されたサーバプロセスから第三者交換でメールのContentを検索するのが強いられます。

               The redefined FILE command would be similar to the
               LOCATION command, except that the former would specify
               JUST Content (and none of the other Static Attributes),
               and that the Server must retrieve the file (which may be
               a temporary file created by the user process) in real
               time, i.e. BEFORE it sends its response to the FILE
               command.

再定義されたFILEコマンドはLOCATIONコマンドと同様でしょう、前者が、JUST Content(そして、他のStatic Attributesのいずれも)でないと、Serverがリアルタイムでファイル(ユーザ・プロセスで作成された一時ファイルであるかもしれない)を取らなければならないと指定するだろうというのを除いて、すなわち、それがFILEコマンドへの応答を送るBEFORE。

               This alternative eliminates the need to borrow the BYTE,
               SOCK, PASV, TYPE, STRU, MODE, REST, and SITE commands
               from FTP (JEW RFC 524 -- 17140,7c1:gy).  It also allows
               the user process the flexibility of specifying a file at
               a host other than his own.

この代替手段はFTP(7c1: JEW RFC524 -- 17140、gy)からBYTE、SOCK、PASV、TYPE、STRU、MODE、REST、およびSITEコマンドを借りる必要性を排除します。 また、それは彼自身のを除いたホストでファイルを指定する柔軟性をユーザ・プロセスに許容します。

               After some thought, I think I agree with Crocker and
               Postel that theirs is the better implementation.

或るものが考えた後に、私は、彼等のものが、より良い実装であるとクロッカーとポステルに同意すると思います。

                  As they point out, however, this implementation
                  introduces the problem of somehow reconciling the
                  desire to permit (in general) the transfer of mail
                  files without requiring a login, with a server's
                  inability to distinguish that case from the general
                  case of file retrieval (for which many hosts will
                  require a login).

しかしながら、彼らが指摘するように、この実装はログインを必要としないでメールファイルの転送を可能にする(一般に)願望をどうにか和解させるという問題を紹介します、サーバのものがファイル検索(多くのホストがログインを必要とする)の一般的なケースとそのケースを区別できないことで。

White                                                           [Page 6]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[6ページ]RFC555応答

   USE OF THE DATE FORM 1/2/73 (JAN 2 OR FEB 1?)

1/2/73の日付のフォームの使用(1月2日か2月1日)?

      References:
         (RCC -- 17822,1b)
      Discussion:
         Agreed.

参照: (RCC--17822、1b) 議論: 同意にされる。

   ORDER OF PARAMETER SPECIFICATION

パラメタ仕様の注文

      References:

参照:

         (DHC JBP RFC 539 -- 17644,31:gy)

(DHC JBP RFC539 -- 17644、31: gy)

      Discussion:

議論:

         The Protocol does not, as Crocker and Postel state, impose an
         order upon command specification within a function (see for
         example, JEW RFC 524 -- 17140,5f1b:gy).

クロッカーとポステルが述べるようにプロトコルは機能の中でコマンド仕様にオーダーを押しつけません(5f1b: JEW RFC524 -- 17140、例えばgyを見てください)。

         Having considered their suggestion only briefly, it does seem
         to me appropriate to impose some constraints on the order of
         parameter specification by the user.  Off hand, the order
         suggested -- Dynamic, Optional, Static -- seems good.

簡潔にだけ彼らの提案を考えたので、私にとって、ユーザによるパラメタ仕様の注文にいくつかの規制を課すのは適切に思えます。 手では、示されたオーダー(動力、Optional、Static)は良く見えます。

III.  SUGGESTED ADDITIONS

III。 提案された追加

   FORWARDING AT DELIVERY TIME

納期の推進

      References:

参照:

         (DHC JBP 539 -- 17644,4b:g)

(4b: DHC JBP539 -- 17644、g)

      Discussion:

議論:

      Including provision for the forwarding of mail at Delivery Time,
      in contrast to sometime after Delivery in response to a specific
      Forward request (i.e., function), seems to me a useful addition to
      the Protocol.

特定のForwardに対応したDeliveryが(すなわち、機能)を要求した後にいつかと対照してDelivery Timeのメールの推進への支給を含んでいると、私にとって、役に立つ追加はプロトコルに思えます。

      As Crocker and Postel note, only one of the three mechanisms for
      such forwarding bears upon the Protocol (although the Protocol
      might mention the other two and either encourage or discourage
      their use).

クロッカーとポステルが注意するように、そのような推進弱気筋のためのプロトコル(プロトコルは、彼らの使用に他の2について言及して、奨励するか、または水をさしているかもしれませんが)の3つのメカニズムの唯一の1つです。

      I suggest the following reply format, however, rather than the one
      suggested by Crocker and Postel (DHC JBP RFC 539 --
      17644,4b3c2:gy):

しかしながら、私はクロッカーとポステル(4b3c2: DHC JBP RFC539 -- 17644、gy)によって提案されたものよりむしろ以下の回答書式を勧めます:

White                                                           [Page 7]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[7ページ]RFC555応答

         476 <localname> -- is his location.

476 <localname>--彼の位置はそうですか?

   DEFAULT SIGNATURE SHOULD BE THE AUTHOR

デフォルト署名は作者であるべきです。

      References:
         (DHC JBP 539 -- 17644,3c:gy)
      Discussion:
         Agreed.

参照: (3c: DHC JBP539 -- 17644、gy) 議論: 同意にされる。

   LEVELS OF INTERRUPT

中断のレベル

      References:

参照:

      (DHC JBP 539 -- 17644,3d:gy)

(3d: DHC JBP539 -- 17644、gy)

   Discussion:

議論:

         I see no value to defining numeric shades of urgency,
         unless the Protocol suggests some particular action the
         server might take in response to each one.

私は緊急の数値色合いを定義するのに値を全く見ません、プロトコルがサーバがそれぞれに対応して取るかもしれない何らかの特定の行動を示さない場合。

         The whole notion of flagging some pieces of mail as
         urgent seems to me useless unless the MP server process
         (not the human recipient) takes some kind of special
         action for urgent mail, BEFORE the human recipient
         would otherwise be apt to read the mail.  If one
         accepts that argument, there's clearly no point to
         defining shades of urgency if they have meaning only to
         the human recipient.  True, any pair of human users
         could privately agree on meanings, but it seems to me
         preferable to define those meanings formally or not at
         all.

MPサーバの過程(人間の受取人でない)が速達便(そうでなければ人間の受取人がメールを読み込む傾向があるだろうBEFORE)のためのある種の特別な行動を取らない場合、緊急であるとして数片のメールに旗を揚げさせるという全体の概念は私にとって役に立たなく見えます。 1つがその議論を受け入れるなら、人間の受取人だけに意味を持っているなら緊急の色合いを定義することへのポイントが全く明確にありません。 本当に、人間のユーザのどんな組も意味に個人的に同意できましたが、私にとって、それらの意味を正式か全く定義しないのは望ましく思えます。

   WARNING THE SERVER OF THE SIZE OF MAIL

メールのサイズのサーバに警告します。

      References:
         (DHC JBP RFC 539 -- 17644,3f:gy)
      Discussion:
         Agreed.  Further suggestions as to the implementation?

参照: (3f: DHC JBP RFC539 -- 17644、gy) 議論: 同意にされる。 実現に関するさらなる提案?

   DISCOURAGING SERVERS FROM REQUIRING LOGINS

ログインを必要とするのからのがっかりしているサーバ

      References:
         (DHC JBP RFC 539 -- 17644,3j:gy)
      Discussion:
         Agreed.  This is not a new issue.

参照: (3j: DHC JBP RFC539 -- 17644、gy) 議論: 同意にされる。 これは新規発行ではありません。

White                                                           [Page 8]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[8ページ]RFC555応答

IV.  META-COMMENTS

IV。 メタコメント

   SIZE OF THE PROTOCOL DOCUMENT

プロトコルドキュメントのサイズ

      References:

参照:

         (RCC -- 17822,1e:gy)

(RCC--17822、1e: gy)

      Discussion:

議論:

         I offer an apology for the format of the the Protocol document.
         It differs radically from that of previous Protocol documents
         (e.g., FTP, RJE), and is certainly not tutorial in its
         orientation.  The glossary is a device I found useful in
         designing the Protocol.  If the substance of the Protocol were
         agreed upon, then friendlier documentation would have to be
         written.  The choice of approach was greatly affected by my own
         time constraints.

私はプロトコルドキュメントの形式のために詫びます。 それは、前のプロトコルドキュメント(例えば、FTP、RJE)のものと根本的に違って、確かに、オリエンテーションで家庭教師ではありません。 用語集は私がプロトコルを設計する際に役に立つのがわかった装置です。 プロトコルの実体が同意されるなら、より好意的なドキュメンテーションは書かれなければならないでしょうに。 アプローチの選択は私自身の時間規制で大いに影響を受けました。

         As I find time, I would like to define the minimum
         implementation subsets that Clements requests.  For the moment,
         consider the command breakdown below.  It represents the case
         where the server permits only the function by which mail is
         delivered to users in his host.  It has the following
         attributes:

私は余暇があるように、クレメンツが要求する最小の実現部分集合を定義したいと思います。 さしあたり、以下のコマンド故障を考えてください。 それはサーバがメールが彼のホストでユーザに配達される機能だけを可能にするケースを表します。 それには、以下の属性があります:

            (1) It supports all of the functions of the current FTP mail
            protocol.  In addition,

(1) それは現在のFTPメールプロトコルの機能のすべてを支持します。 さらに

            (2) It makes specification of author and title explicit,
            avoiding the current problem of multiple headers (one
            supplied by the server, the other embedded by the user in
            the text of the message),

(2) 作者とタイトルの仕様を明白にします、複数のヘッダー(サーバによって供給されたもの、メッセージの本文のユーザによって埋め込まれたもう片方)の現在の問題を避けて

            (3) It allows the text of the message to reside at a third
            host, and

そして(3) メッセージの本文がそれで3番目のホストに住むことができる。

            (4) It permits multiple recipients.

(4) それは複数の受取人を可能にします。

         The breakdown is the following:

故障は以下です:

            COMMANDS THAT MUST BE IMPLEMENTED
            (Author and Title could be treated as NOPs)

実行しなければならないコマンド(作者とTitleをNOPsとして扱うことができました)

               To enter the Mail subsystem:
                  MAIL <CA>
               To invoke the Delivery function:
                  DELIVER <CA>

メールサブシステムに入るために: メール<カリフォルニア>ToはDelivery機能を呼び出します: <カリフォルニア>を届けてください。

White                                                           [Page 9]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[9ページ]RFC555応答

               To specify the text of the message:
                  FILE <CA>
                  LOCATION <fileaddr> <CA>
                  TEXT <string> <CA2>
               To identify author(s), recipient(s), and title:
                  AUTHOR <individual> <CA>
                  RECIPIENT <individual> <CA>
                  TITLE <title> <CA>
               To exit the function or subsystem:
                  ABORT <CA>
                  EXIT <CA>

メッセージの本文を指定するために: FILE<カリフォルニア>LOCATION<fileaddr><カリフォルニア>TEXT<ストリング><CA2>Toは作者、受取人、およびタイトルを特定します: 個々の個々のAUTHORの<カリフォルニア>TITLE<<><カリフォルニア>RECIPIENT<>タイトル><カリフォルニア>Toは機能かサブシステムを出ます: <カリフォルニア>出口<カリフォルニア>を中止してください。

            COMMANDS THAT CAN BE TREATED AS NOPS
            (they can legally appear in the Delivery function)

NOPSとして扱うことができるコマンド(彼らはDelivery機能に法的に現れることができます)

               ACCESS <individual> <CA>
               ACCESSTYPES <accesstypes> <CA>
               CATALOG <catalog> <CA>
               CLERK <individual> <CA>
               COMMENTS <comments> <CA2>
               CREATIONDATE <datetime> <CA>
               DELIVERYTYPE <deliverytype> <CA>
               DISPOSITION <disposition> <CA>
               GENERALDELIVERY <CA>
               GREETING <greeting> <CA>
               ID <id> <CA>
               REFERENCESERIAL <serialnumber> <CA>
               SERIAL <serialnumber> <CA>
               SIGNATURE <signature> <CA>

個々のアクセスの><カリフォルニア>カタログ<><カリフォルニア>ACCESSTYPES<accesstypes<は<が><CA2>CREATIONDATE<datetime><カリフォルニア>DELIVERYTYPE<deliverytype>について論評するという>の個々の><カリフォルニアの><カリフォルニアの>事務員<コメントをカタログに載せます; <カリフォルニア>気質<気質><カリフォルニア>GENERALDELIVERY<カリフォルニア>挨拶<挨拶><カリフォルニア>ID連続の<の<カリフォルニアの>署名<イド><カリフォルニアの>REFERENCESERIAL<serialnumber><カリフォルニアの><serialnumber>署名><カリフォルニア>。

            COMMANDS THAT NEEDN'T BE RECOGNIZED
            (they cannot legally appear in the Delivery function)

認識される必要はないコマンド(彼らはDelivery機能に法的に現れることができません)

            Commands that invoke unsupported functions:

サポートされない機能を呼び出すコマンド:

               DISTRIBUTE <CA>
               FORWARD <CA>
               RECORD <CA>
               RETRIEVE <CA>
               UPDATE <CA>
               VERIFY <CA>

分配、<カリフォルニア>が<カリフォルニア>アップデート<カリフォルニア>を検索するという<の>の前進の<カリフォルニアの>カリフォルニアの記録は<カリフォルニア>について確かめます。

            Miscellaneous parameter specification commands:

種々雑多なパラメタ仕様は命令します:

               ACKCONDITION <ackcondition> <CA>
               ACKTYPE <acktype> <CA>
               CITATIONTEMPLATE <citationtemp> <CA>
               CUTOFF <interval> <CA>

ACKCONDITION<ackcondition><カリフォルニア>ACKTYPE<acktype><カリフォルニア>CITATIONTEMPLATE<citationtemp><カリフォルニア>締切りの<間隔><カリフォルニア>。

White                                                          [Page 10]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973

提案されたメールプロトコル1973年7月の批評への白い[10ページ]RFC555応答

               FORWARDEE <individual> <CA>
               MONITOR <individual> <CA>
               PATHNAME <pathname> <CA>
               REPORTINTERVAL <interval> <CA>
               REQUESTOR <individual> <CA>
               UPDATETYPE <updatetype> <CA>

個々の個々の個々のFORWARDEE間隔><カリフォルニアの><><カリフォルニア>モニター<><カリフォルニア>パス名<パス名><カリフォルニア>REPORTINTERVAL<要請者の<updatetype><カリフォルニア<><カリフォルニア>UPDATETYPE>。

   CA AND CA2 NOT EXPLAINED SOON ENOUGH

間に合うようにしてすぐ説明されなかったカリフォルニアとCA2

      References:
         (DHC JBP RFC 539 -- 17644,3a:gy)
      Discussion:
         Agreed.

参照: (3a: DHC JBP RFC539 -- 17644、gy) 議論: 同意にされる。

   CHANGE 'INTERRUPT' TO 'URGENT' OR 'PRIORITY'

'緊急'への変化'中断'か'優先権'

      References:
         (DHC JBP RFC 539 -- 17644,3e:gy)
      Discussion:
         Agreed.
         How about 'URGENT'.

参照: (3e: DHC JBP RFC539 -- 17644、gy) 議論: 同意にされる。 '緊急'はどうですか?

   CARRY STATIC/DYNAMIC ATTRIBUTE DISTINCTION INTO FORMAL SYNTAX

静的であるかダイナミックな属性区別を正式な構文まで運んでください。

      References:
         (DHC JBP RFC 539 -- 17644,3i:gy)
      Discussion:
         Agreed.

参照: (3i: DHC JBP RFC539 -- 17644、gy) 議論: 同意にされる。

   CRYPTIC DEFAULT DESCRIPTIONS

不可解なデフォルト記述

      References:
         (DHC JBP RFC 539 -- 17644,3k:gy)
      Discussion:
         Agreed.

参照: (3k: DHC JBP RFC539 -- 17644、gy) 議論: 同意にされる。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Sergio Kleiman  12/99 ]

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

White                                                          [Page 11]

ホワイト[11ページ]