RFC539 日本語訳

Network Working Group                              D. Crocker (UCLA-NMC)
Request For Comment: #539                           J. Postel (UCLA-NMC)
NIC 17644                                                   July 9, 1973
References: 524

クロッカー(UCLA-NMC)がコメントのために要求するワーキンググループD.をネットワークでつないでください: #539 J。 ポステル(UCLA-NMC)NIC17644 1973年7月9日参照: 524

           Thoughts on the Mail Protocol Proposed in RFC 524

RFC524で提案されたメールプロトコルに関する考え

Generally, we feel that the protocol is extremely rich. We also feel
that there are some minor and some major problems.

一般に、私たちは、プロトコルが非常に豊かであると感じます。 また、私たちは、何らかの小さい方の問題といくつかの重大な問題があると感じます。

The minor points first:

未成年者は最初に、指します:

    1.  <CA> and <CA2> are not explained until the formal syntax. It
    would be more convenient, if they were explained sooner.

1. <カリフォルニア>と<CA2>は正式な構文まで説明されません。 それらが、より早く説明されるなら、より便利でしょうに。

    2. The Proposed <CA2> is a bad thing, since it is the Telnet Go-
    Ahead, which should not be used by higher level protocols.

2. Proposed<CA2>は悪いものです、それが先のTelnet Go(より高いレベルによって使用されるべきでない)プロトコルであるので。

    3. The default SIGNATURE should be the sign-on or ident of the
    author(s).

3. デフォルトSIGNATUREはサインするべきですか、作者のidentが(s)です。

    4. The Disposition INTERRUPT would be more useful if it had
    author/clerk-assigned "levels". Currently mail would be either
    urgent or not. With levels (say 1 to 10), the sender could rate the
    degree of urgency.

4. それに事務員によって割り当てられた作者/「レベル」があるなら、Disposition INTERRUPTは、より役に立つでしょうに。 現在の、メールは緊急でしょう。 レベル(1〜10に、言う)で、送付者は緊急度を評定できました。

        There would be no precise defined meaning to any of these
        levels, merely the opportunity for a subjective evaluation by
        the sender. The receiver (process or person) may do whatever
        they wish with the information.

これらのレベル(単に送付者による主観的な評価の機会)のどれかへのどんな正確な定義された意味もないでしょう。 受信機(過程か人)は彼らが情報で願っていることなら何でもします。

        A user could thereby direct a receiving process to notify him
        immediately of Priority 5 or higher Short mail or any Priority
        10 mail immediately, but defer notification of any other mail.
        (Length is discussed later in this note.)

その結果、ユーザは、至急すぐPriority5、より高いShortメールまたはあらゆるPriority10メールについて彼に通知するよう受信の過程に指示できましたが、いかなる他のメールの通知も延期してください。 (後でこの注意で長さについて議論します。)

    5. Also, we would like the  word, "INTERRUPT", to be changed to
    URGENT or PRIORITY

5. また、単語、「中断」を緊急に変えられたいと思う、優先権

    6. In keeping with offering the sender the opportunity to 'rate' his
    mail, we would like to allow him the chance to warn the receiver of
    the size of the mail.  This could be a byte count and/or an
    imprecise SHORT/MEDIUM/LONG.  Again, the receiver may use this
    information as he/it sees fit.

6. 彼のメールを'評定する'機会を送付者に提供するのに保つ際に、警告する機会を彼に許したいと思います。メールのサイズの受信機。 これは、バイト・カウント、そして/または、不正確なSHORT/MEDIUM/LONGであるかもしれません。 一方、受信機はそれが見る/が彼のように合ったというこの情報を使用するかもしれません。

D. Crocker & Postel                                             [Page 1]

RFC 539          Thoughts on the RFC 524 Mail Protocol         July 1973

D。 RFC524メールプロトコル1973年7月に関するクロッカーとポステル[1ページ]RFC539考え

    7. The ID command seems confusing.

7. IDコマンドは紛らわしく見えます。

        If I am a clerk and sending to someone on another host, that
        host may ask me to 'prove' my identity by using an ID. How can
        the Sigma-7 at UCLA-NMC know WHITE's id? He does not have one on
        the Sigma, but certainly should be able to send mail to us
        there.

私が事務員であり、別のホストの上でだれかに発信するなら、そのホストは、IDを使用することによって私のアイデンティティを'立証する'ように私に尋ねるかもしれません。 UCLA-NMCのSigma-7はどのようにホワイトのイドを知ることができますか? 彼は、Sigmaの上の1つを持っていませんが、確かに、そこでメールを私たちに送ることができるべきです。

    8. How do ACK's, Progress Reports, or Replies work when there is no
    Reference Serial number?

8. Reference Serial番号が全くないとき、ACK、Progress Reports、またはRepliesがどのように扱いますか?

    9. Please include the  distinction between Static and Dynamic
    attributes as part of the formal syntax.

9. 正式な構文の一部としてStaticとDynamic属性の区別を含めてください。

    10. Though hosts must be allowed to require a login, before they
    will accept mail,  would like the Protocol document to reflect a
    negative attitude towards such a requirement.

10. ホストを許容しなければなりませんが、彼らがメールを受け入れる前にログインを必要とするのは、プロトコルドキュメントにそのような要件に対する否定的態度を反映して欲しいです。

    11. In describing defaults, relatively cryptic phrases such as
    "Author to the Clerk" are sometimes used. Please be a bit more
    clear.

11. デフォルトについて説明する際に、「事務員の作者」などの比較的不可解な句は時々使用されます。 もう少し明確であってください。

    12. The sender is required to send Static, Dynamic, and then
    Optional parameters.

12. 送付者はStatic、Dynamic、および当時のOptionalにパラメタを送らなければなりません。

        This requires receiving hosts to buffer the contents before
        passing them on to the appropriate recipient. (In fact, before
        finding out whether it can/will accept the mail.)

これは、適切な受取人に彼らを渡す前に受信ホストがコンテンツをバッファリングするのを必要とします。 (事実上、それがそうすることができるかどうか見つける前に、/はメールを受け入れるでしょう。)

        The order should be: Dynamic, Optional, Static.

オーダーは以下の通りであるべきです。 ダイナミックで、任意で、静的です。

        By requiring the sending host to transmit the dynamic and
        optional attributes first, the receiving host can also reroute
        mail based upon its Priority and Length.

また、送付ホストが最初にダイナミックで任意の属性を伝えるのを必要とすることによって、受信ホストはそのPriorityとLengthに基づくメールを別ルートで送ることができます。

Now for the hairier problems:

現在、より毛深い問題のために:

    1. We would like to make a strong statement in favor of the
    unified-access (one selector process with one listening socket)
    approach.  However, since it does not exist, yet:

1. 統一されたアクセス(1個の聴取ソケットがある1つのセレクタの過程)アプローチを支持して強く言い切りたいと思います。 しかしながら、まだ存在していないので:

        The Mail Protocol should NOT be a subsystem of FTP. The Mail
        Protocol USES the File Transfer Protocol, the same as RJE uses
        FTP. We therefore suggest the use of the RJE model.

メールプロトコルはFTPのサブシステムであるべきではありません。 メールプロトコルUSES File Transferプロトコルであり、RJEと同じくらいはFTPを使用します。 したがって、私たちはRJEモデルの使用を勧めます。

        This unfortunately opens up the issue of logging in, to send
        mail. The advantage of having FTP have a MAIL command is that it
        defines a class of data transfer which many hosts will allow for

残念ながら、これはメールを送るためにログインする問題を開けます。 FTPにメールコマンドを持たせる利点は多くのホストが考慮するデータ転送のクラスを定義するということです。

D. Crocker & Postel                                             [Page 2]

RFC 539          Thoughts on the RFC 524 Mail Protocol         July 1973

D。 RFC524メールプロトコル1973年7月に関するクロッカーとポステル[2ページ]RFC539考え

        free, while maintaining control over other, 'normal' file
        transfer.

他の、そして、'正常な'ファイル転送のコントロールを維持している間、解放します。

        The solution should be the same as that currently used by RJE.

解決策は現在RJEによって使用されているそれと同じであるべきです。

    2. The FORWARD function allows a site to receive and hold mail
    during and/or, until a transfer request is received from the
    'recipient' at another host.

2. そして/または、サイトがFORWARD機能で受信して、メールを保持する、別のホストに'受取人'から転送要求を受け取るまで。

        This action takes place AFTER receipt of the mail, so we would
        like to suggest a command for "Rerouting" mail just PRIOR to its
        receipt.

この動作がメールの場所AFTER領収書を取るので、メールがただPRIORであることを領収書に「別ルートで送る」であるためのコマンドを勧めたいと思います。

        This allows a receiving host to refuse a given piece of mail,
        but suggest an alternate receiver. This would be useful if the
        recipient were using  another host for a while, or if the
        recipient  didn't want to rack up storage charges at the first
        site.

これで、受信ホストは与えられた片のメールを拒否できますが、交互の受信機を示してください。受取人がしばらく別のホストを使用していて、受取人が最初のサイトで保管料を獲得したくないなら、これは役に立つでしょうに。

        Three variation can occur, one of which will require a special
        MP reply code:

3変化は起こることができて、特別なMP回答を必要とするものの1つは以下をコード化します。

            Automatic forwarding:  Accept the mail and then
            automatically transfer it to the user's alternate mailbox.

自動推進: メールを受け入れてください、そして、次に、自動的にユーザの交互のメールボックスにそれを移してください。

                This could be classed as a user  "feature"  and would
                not be part of the protocol.  However, it would be quite
                useful.

これは、ユーザ「特徴」として分類できて、プロトコルの一部でないでしょう。 しかしながら、それはかなり役に立つでしょう。

            Automatic forwarding with copy held:  The same as the first
            case, but the transferring server keeps a copy of the mail.

コピーによる自動推進は成立しました: 同じように、最初のケースとして、移すサーバだけがメールの写しを取っておきます。

            Rerouting without accepting:  The mail is never accepted
            from the sender. The sender is, however, informed of an
            alternate mailbox.

受け入れないで以下のコースを変更すること。 送付者からメールを決して受け入れません。 しかしながら、送付者に交互のメールボックスについて知らされます。

                The Rerouting information would be in reply to a
                RECIPIENT command.

Rerouting情報がRECIPIENTコマンドに対してあるでしょう。

                476 <recipient> IS AT <pathname>

476<受取人>が<パス名>にあります。

       [ 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.            10/99 ]

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

D. Crocker & Postel                                             [Page 3]

D。 クロッカーとポステル[3ページ]