RFC743 日本語訳

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
Network Working Group                                     K. Harrenstien
Request for Comments: 743                                         SRI-KL
NIC: 42758                                              30 December 1977

42759ネットワークワーキンググループK.Harrenstienがコメントのために要求するNWG/RFC#743KLH1977年12月30日8時39分: 743 様キロリットルNIC: 42758 1977年12月30日

                        FTP extension: XRSQ/XRCP

FTP拡大: XRSQ/XRCP

This RFC describes an extension to FTP which allows the user of an ITS
FTP server (i.e. on MIT-(AI/ML/MC/DMS)) to mail the text of a message to
several recipients simultaneously; such message transmission is far more
efficient than the current practice of sending the text again and again
for each additional recipient at a site.

このRFCはITS FTPサーバ(すなわち、MIT(AI/ML/M.C./DMS)の)のユーザが同時にメッセージのテキストを数人の受取人に郵送できるFTPに拡大について説明します。 メッセージ送信はサイトのそれぞれの追加受取人のためにテキストを再三送る現在の習慣とはるかに同じくらい効率的です。

Within this extension, there are two basic ways of sending a single text
to several recipients.  In one, all recipients are specified first, and
then the text is sent; in the other, the order is reversed and the text
is sent first, followed by the recipients.  Both schemes are necessary
becaue neither by itself is optimal for all systems, as will be
explained later.  To select a particular scheme, the XRSQ command is
used; to specify recipients after a scheme is chosen, XRCP commands are
given; and to furnish text, the usual MAIL or MLFL commands apply.

この拡大の中に、ただ一つのテキストを数人の受取人に送る2つの基本的な方法があります。 1では、最初にすべての受取人を指定します、そして、次に、テキストを送ります。 もう片方では、オーダーを逆にします、そして、受取人によって後をつけられて、最初に、テキストを送ります。 両方の計画はbecaueにどちらもそれ自体で必要でない、すべてのシステムに最適であることで、意志として、後で説明されてください。 特定の計画を選択するために、XRSQコマンドは使用されています。 計画が選ばれた後に受取人を指定するために、XRCPコマンドを与えます。 そして、テキスト、普通のメールまたはMLFLコマンドを提供するには、申し込んでください。

Scheme Selection: XRSQ

選択を計画してください: XRSQ

   XRSQ is the means by which a user program can test for implementation
   of XRSQ/XRCP, select a particular scheme, reset its state thereof,
   and even do some rudimentary negotiation.  Its format is like that of
   the TYPE command, as follows:

XRSQはユーザ・プログラムがXRSQ/XRCPの実現がないかどうかテストして、特定の計画を選択して、それについて状態をリセットして、何らかの初歩的な交渉ができさえする手段です。 形式は以下の通りTYPEコマンドのものに似ています:

      XRSQ [<SP> <scheme>] <CRLF>

XRSQ[<SP><計画>]<CRLF>。

      <scheme> = a single character.  The following are defined:
         R  Recipients first.  If not implemented, T must be.
         T  Text first.  If this is not implemented, R must be.
         ?  Request for preference.  Must always be implemented.

<計画>は単独のキャラクタと等しいです。 以下は定義されます: R受取人、1番目。 実行されないなら、Tは実行されるに違いありません。 Tテキスト、1番目。 これが実行されないなら、Rは実行されるに違いありません。 ? 好みのために、要求します。 いつも実行しなければなりません。

         No argument means a "selection" of none of the schemes (the
         default).

どんな議論も計画(デフォルト)のいずれの「選択」でないのを意味しません。

      Replies:
         200 OK, we'll use specified scheme.
         215 <scheme> This is the scheme I prefer.
         501 I understand XRSQ but can't use that scheme.
         5xx Command unrecognized or unimplemented.
         See Appendix A for more about the choice of reply codes.

回答: 200 OK、私たちは指定された計画を使用するつもりです。 215 <計画>Thisは私が好む計画です。 501 私は、XRSQを理解していますが、その計画を使用できません。 5xx Command認識されていないか非実行されています。 詳しい情報については、回答コードの選択に関してAppendix Aを見てください。

   Three aspects of XRSQ need to be pointed out here.  The first is that

XRSQの3つの局面が、ここに指されている必要があります。 1番目はそれです。

                                                                [Page 1]

[1ページ]

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
An Extension to FTP

NWG/RFC#743KLH1977年12月30日8時39分、FTPへの1拡大あたり42759

   an XRSQ with no argument must always return a 200 reply and restore
   the default state of having no scheme selected.  Any other reply
   implies that XRSQ and hence XRCP are not understood or cannot be
   performed correctly.

議論のないXRSQはいつも200回答を返して、計画を全く選択させないデフォルト状態を回復しなければなりません。 いかなる他の回答も、XRSQとしたがって、XRCPを理解しないことができないか、正しく実行できないのを含意します。

   The second is that the use of "?" as a <scheme> asks the FTP server
   to return a 215 reply in which the server specifies a "preferred"
   scheme.  The format of this reply is simple:

2番目は<計画>としての“?"の使用が、サーバが「都合のよい」計画を指定する215回答を返すようにFTPサーバに頼むということです。 この回答の形式は簡単です:

      215 <SP> <scheme> [<SP> <arbitrary text>] <CRLF>

215 <SP><計画>[<のSPの>の<の任意のテキスト>]<CRLF>。

      Any other reply (e.g. 4xx or 5xx) implies that XRSQ and XRCP are
      not implemented, because "?" must always be implemented if XRSQ
      is.

いかなる他の回答(例えば、4xxか5xx)も、XRSQとXRCPが実行されないのを含意します、XRSQが実行するならいつも“?"を実行しなければならないので。

   The third important thing about XRSQ is that it always has the side
   effect of resetting all schemes to their initial state.  This reset
   must be done no matter what the reply will be - 200, 215, or 501.
   The actions necessary for a reset will be explained when discussing
   how each scheme actually works.

XRSQの周りの3番目の重要なものはそれにはそれらの初期状態にすべての計画をリセットする副作用がいつもあるということです。 回答が何になっても、このリセットをしなければなりません--200、215、または501。 各計画が実際にどううまくいくかについて議論するとき、リセットに必要な動作は説明されるでしょう。

Message Text Specification: MAIL/MLFL

メッセージ・テキスト仕様: メール/MLFL

   Regardless of which scheme (if any) has been selected, a MAIL or MLFL
   with a non-null argument will behave exactly as before; this
   extension has no effect on them.  However, such normal MAIL/MLFL
   commands do have the same side effect as XRSQ; they "reset" the
   current scheme to its initial state.

どの計画(もしあれば)が選択されたかにかかわらず、非空の項があるメールかMLFLがまさに従来と同様振る舞うでしょう。 この拡大はそれらの上で効き目がありません。 しかしながら、そのような正常なメール/MLFLコマンドには、XRSQと同じ副作用があります。 彼らは現在の計画を初期状態に「リセットしました」。

   It is only when the argument is null (e.g. MAIL<CRLF> or MLFL<CRLF>)
   that the particular scheme being used is important, because rather
   than producing an error (as most servers currently do), the server
   will accept message text for this "null" specification; what it does
   with it depends on which scheme is in effect, and will be described
   in "Scheme Mechanics".

使用される特定の計画が重要であることは、議論がヌルである(例えば、メール<CRLF>かMLFL<CRLF>)時にすぎません、サーバがこの「ヌル」の仕様のために誤り(ほとんどのサーバとして、現在、する)を起こすよりむしろメッセージ・テキストを受け入れるので。 それがそれで何をするかはどの計画が有効であるかよって、「計画整備士」で説明されるでしょう。

Recipient specification: XRCP

受取人仕様: XRCP

   In order to specify recipient names and receive some acknowledgement
   (or refusal) for each name, the following new command is also
   defined:

また、各名前のために受取人名を指定して、何らかの承認を受ける(または、拒否)ために、以下の新しいコマンドは定義されます:

      XRCP <SP> <Recipient name> <CRLF>

XRCP<SP><Recipient名前><CRLF>。

      Reply for no scheme:
         507 No scheme specified yet; use XRSQ.
      Replies for scheme T are identical to those for MAIL/MLFL.

計画を全く代わって答えないでください: 507 計画は全くまだ指定していませんでした。 XRSQを使用してください。 メール/MLFLに、計画Tのための回答はそれらと同じです。

                                                                [Page 2]

[2ページ]

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
An Extension to FTP

NWG/RFC#743KLH1977年12月30日8時39分、FTPへの1拡大あたり42759

      Replies for scheme R (recipients first):
         200 OK, name stored.
         440 Recipient table full, this name not stored.
         450 Recipient name rejected. (Permanent!)
         520 Recipient name rejected.
         4xx Temporary error, try this name again later.
         5xx Permanent error, report to sender.
         See Appendix A for more about the choice of reply codes.

計画Rのための回答、(受取人、1番目)、: 200 OK、格納された名前。 いっぱいに、この名前が収納しなかった440受取人テーブル。 拒絶された450受取人名。 (永久的な!) 拒絶された520受取人名。 4xx Temporary誤り、これが後で再び命名するトライ。 5xx Permanent誤り、送付者へのレポート。 詳しい情報については、回答コードの選択に関してAppendix Aを見てください。

   Note that use of this command is an error if no scheme has been
   selected yet; an XRSQ <scheme> must have been given if XRCP is to be
   used.

計画が全くまだ選択されていないならこのコマンドの使用が誤りであることに注意してください。 XRCPが使用されているつもりであるなら、XRSQ<計画>を与えたに違いありません。

Scheme mechanics: XRSQ R (Recipients first)

整備士を計画してください: XRSQ R(受取人、1番目)

   In the recipients-first scheme, XRCP is used to specify names which
   the FTP server stores in a list or table.  Normally the reply for
   each XRCP will be either a 200 for acceptance, or a 4xx/5xx code for
   rejection; 450 and all 5xx codes are permanent rejections (e.g. user
   not known) which should be reported to the human sender, whereas 4xx
   codes in general connote some temporary error that may be rectified
   later.  None of the 4xx/5xx replies impinge on previous or succeeding
   XRCP commands, except for 440 which indicates that no further XRCP's
   will succeed unless a message is sent to the already stored
   recipients or a reset is done.

最初に受取人計画では、XRCPは、FTPサーバがリストかテーブルに格納する名前を指定するのに使用されます。 通常、各XRCPのための回答は、拒絶のために承認のための200か4xx/5xxコードのどちらかになるでしょう。 450とすべての5xxコードが人間の送付者に報告されるべきである永久的な拒絶(例えば知られないユーザ)ですが、一般に、4xxコードは後で正されるかもしれない何らかの一時的な誤りを内包します。 4xx/5xx回答のいずれにも前であることの状態で衝突しないか、または440を除いて、続くXRCPは、どれが、メッセージが既に格納された受取人かリセットに送られないとXRCPのどんな一層のものも成功しないのを示すか完了していると命令します。

   Sending message text to stored recipients is done by giving a MAIL or
   MLFL command with no argument; that is, just MAIL<CRLF> or
   MLFL<CRLF>.  Transmission of the message text is exactly the same as
   for normal MAIL/MLFL; however, a positive acknowledgement at the end
   of transmission means that the message has been sent to ALL
   recipients that were remembered with XRCP, and a failure code means
   that it should be considered to have failed for ALL of these
   specified recipients.  This applies regardless of the actual error
   code; and whether the reply signifies success or failure, all stored
   recipient names are flushed and forgotten - in other words, things
   are reset to their initial state.  This purging of the recipient name
   list must also be done as the "reset" side effect of any use of XRSQ.

議論なしでメールかMLFLにコマンドを与えることによって、格納された受取人にメッセージ・テキストを送ります。 すなわち、まさしくメール<CRLF>かMLFL<CRLF>。 メッセージ・テキストの送信はまさに正常なメール/MLFLのように同じです。 しかしながら、トランスミッションの端の積極的な承認は、XRCPと共に覚えていられたすべての受取人にメッセージを送ることを意味します、そして、失敗コードはこれらの指定された受取人のすべてのために失敗したのが考えられるべきであることを意味します。 これは実際のエラーコードにかかわらず適用されます。 そして、回答が成否を意味するか否かに関係なく、すべての格納された受取人名が、洗い流されて、忘れられています--言い換えれば、事態はそれらの初期状態にリセットされます。 また、「リセットされて」XRSQのどんな使用の副作用としても受取人人名簿をこの除くことをしなければなりません。

   A 440 reply to an XRCP can thus be handled by using a MAIL/MLFL to
   specify the message for currently stored recipients, and then sending
   more XRCP's and another MAIL/MLFL, as many times as necessary; for
   example, if a server only had room for 10 names this would result in
   a 50-recipient message being sent 5 times, to 10 different recipients
   each time.

その結果、現在格納された受取人にメッセージを指定するのにメール/MLFLを使用して、次に、より多くのXRCPと別のメール/MLFLを送ることによって、XRCPへの440回答を扱うことができます、必要なだけの回。 例えば、サーバに10の名前の余地があるだけであるなら、これは5回が送られる50受取人のメッセージをもたらすでしょうに、各回10人の異なった受取人に。

   If a user attempts to specify message text (MAIL/MLFL with no

ユーザが、メッセージ・テキストを指定するのを試みる、(メール/MLFL

                                                                [Page 3]

[3ページ]

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
An Extension to FTP

NWG/RFC#743KLH1977年12月30日8時39分、FTPへの1拡大あたり42759

   argument) before any successful XRCP's have been given, this should
   be treated exactly as a "normal" MAIL/MLFL with a null recipient
   would be; most servers will return an error of some type, such as
   "450 Null recipient".

議論) うまくいっているXRCPのどんなものも与える前に、ちょうどヌル受取人がいる「正常な」メール/MLFLであるだろうことのようにこれを扱うべきです。 ほとんどのサーバが「450Null受取人」などのタイプの誤りを返すでしょう。

   See Appendix B for an example using XRSQ R.

XRSQ Rを使用して、例に関してAppendix Bを見てください。

Scheme mechanics: XRSQ T (Text first)

整備士を計画してください: XRSQ T(テキスト、1番目)

   In the text-first scheme, MAIL/MLFL with no argument is used to
   specify message text, which the server stores away.  Succeeding
   XRCP's are then treated as if they were MAIL/MLFL commands, except
   that none of the text transfer manipulations are done; the stored
   message text is sent to the specified recipient, and a reply code is
   returned identical to that which an actual MAIL/MLFL would invoke.
   (Note ANY 2xx code indicates success.)

最初にテキスト計画では、議論のないメール/MLFLは、メッセージ・テキストを指定するのに使用されます。(サーバはメッセージ・テキストを蓄えます)。 次に、XRCPの続くものはまるでそれらがメール/MLFLコマンドであるかのように扱われます、テキスト転送操作のいずれも完了していないのを除いて。 格納されたメッセージ・テキストを指定された受取人に送ります、そして、実際のメール/MLFLが呼び出すそれと同じ状態で回答コードを返します。 (どんな2xxコードも成功を示すことに注意してください。)

   The stored message text is not forgotten until the next MAIL/MLFL or
   XRSQ, which will either replace it with new text or flush it
   entirely.  Any use of XRSQ will reset this scheme by flushing stored
   text, as will any use of MAIL/MLFL with a non-null argument.

格納されたメッセージ・テキストは次のメール/MLFLかXRSQまで忘れられていません。(XRSQはそれを新しいテキストに取り替えるか、またはそれを完全に洗い流すでしょう)。 XRSQのどんな使用も格納されたテキストを洗い流すことによって、この計画をリセットするでしょう、非空の項によるメール/MLFLのどんな使用のようにも。

   If an XRCP is seen before any message text has been stored, the user
   in effect is trying to send a null message; some servers might allow
   this, others would return an error code.

どんなメッセージ・テキストも格納される前にXRCPが見られるなら、事実上、ユーザはヌルメッセージを送ろうとしています。 いくつかのサーバがこれを許容するかもしれなくて、他のものはエラーコードを返すでしょう。

   See Appendix C for an example using XRSQ T.

XRSQ Tを使用して、例に関してAppendix Cを見てください。

Why two schemes anyway?

2がとにかく計画される理由?

   Because neither by itself is optimal for all systems.  XRSQ R allows
   more of a "bulk" mailing, because everything is saved up and then
   mailed simultaneously; this is very useful for systems such as ITS
   where the FTP server does not itself write mail directly, but hands
   it on to a central mailer demon of great power; the more information
   (e.g. recipients) associated with a single "hand-off", the more
   efficiently mail can be delivered.

どちらもそれ自体、システムXRSQ Rがさらに許容する「大量」の郵送のすべてにおいて、すべてを貯金して、次に、同時に郵送するので、最適です。 これは、FTPサーバがそれ自体をするというわけではないITSなどのシステムが直接メールを書くので非常に役に立ちますが、大国の主要な郵送者悪霊にそれを手渡します。 より多くの情報(例えば、受取人)が単一の「ハンドオフ」に関連づければ関連づけるほど、より効率的にメールを配達できます。

   By contrast, XRSQ T is geared to FTP servers which want to deliver
   mail directly, in one-by-one incremental fashion.  This way they can
   return an individual success/failure reply code for each recipient
   given which may depend on variable file system factors such as
   exceeding disk allocation, mailbox access conflicts, and so forth; if
   they tried to emulate XRSQ R's bulk mailing, they would have to
   ensure that a success reply to the MAIL/MLFL indeed meant that it had
   been delivered to ALL recipients specified - not just some.

対照的に、XRSQ Tは直接と中にメールをひとつずつ配達したがっているFTPサーバに適合した増加のファッションです。 どれを上回っているディスク配分、メールボックスアクセス闘争などなどのバリアブル・ファイルシステム要素に依存するかもしれないかを考えて、彼らが各受取人のために個々の成功/失敗回答コードを返すことができるこの道。 彼らがXRSQ Rの大量の郵送を見習おうとするなら、本当に、メール/MLFLへの成功回答が、指定されたすべての受取人にそれを届けました--どんなほんのいくつかも意味しなかったのを保証しなければならないでしょうに。

                                                                [Page 4]

[4ページ]

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
An Extension to FTP

NWG/RFC#743KLH1977年12月30日8時39分、FTPへの1拡大あたり42759

Stray notes:

随想録:

   * Because this is after all an extension of FTP protocol, one must be
   prepared to deal with sites which don't recognize either XRSQ or
   XRCP.  "XRSQ" and "XRSQ ?" are explicitly designed as tests to see
   whether either scheme is implemented; XRCP is not, and a failure
   return of the "unimplemented" variety could be confused with "No
   scheme selected yet", or even with "Recipient unknown".  Be safe, be
   sure, use XRSQ!

* これがFTPプロトコル、1の拡大がなければならない後であるので、XRSQかXRCPのどちらかを認識しないサイトに対処するように用意してください。 "XRSQ"と"XRSQ?"はどちらの計画も実行されるかどうか確認するようにテストとして明らかに設計されています。 XRCPはそうではありません、そして、"非実行"のバラエティーの失敗復帰は「まだ選択されていなかった計画全く」、または「受取人未知」があっても混乱できました。 安全であってください、そして、確認してください、そして、XRSQを使用してください!

   * There is no way to indicate in a positive response to "XRSQ ?" that
   the preferred "scheme" for a server is that of the default state;
   i.e. none of the multi-recipient schemes.  The rationale is that in
   this case, it would be pointless to implement XRSQ/XRCP at all, and
   the response would therefore be negative.

* 積極的な応答でサーバの都合のよい「計画」がデフォルト状態のものであることを"XRSQ?"に示す方法が全くありません。 すなわち、マルチ受取人のだれも計画しません。 原理はこの場合全くXRSQ/XRCPを実行するのが無意味であるだろうということです、そして、したがって、応答は否定的でしょう。

   * One reason that the use of MAIL/MLFL is restricted to null
   arguments with this multi-recipient extension is the ambiguity that
   would result if a non-null argument were allowed; for example, if
   XRSQ R was in effect and some XRCP's had been given, and a MAIL
   FOO<CRLF> was done, there would be no way to distinguish a failure
   reply for mailbox "FOO" from a global failure for all recipients
   specified.  A similar situation exists for XRSQ T; it would not be
   clear whether the text was stored and the mailbox failed, or vice
   versa, or both.

* メール/MLFLの使用がこのマルチ受取人拡大との空の項に制限される1つの理由が非空の項が許容されているなら結果として生じるあいまいさです。 例えば、XRSQ Rが有効であり、いくらかのXRCPを与えて、メールFOO<CRLF>をするなら、すべての受取人のためのグローバルな失敗からの"FOO"が指定したメールボックスのための失敗回答を区別する方法が全くないでしょうに。 同様の状況はXRSQ Tのために存在しています。 それはテキストが格納されて、メールボックスが失敗したか、逆もまた同様ですか両方をクリアすることでないでしょう。

   * "Resets" are done by all XRSQ's and "normal" MAIL/MLFL's to avoid
   confusion and overly complicated implementation.  The XRSQ command
   implies a change or uncertainty of status, and the latter commands
   would otherwise have to use some independent mechanisms to avoid
   clobbering the data bases (e.g. message text storage area) used by
   the T/R schemes.  However, once a scheme is selected, it remains "in
   effect" just as a "TYPE A" or "BYTE 8" remains selected.  The
   recommended way for doing a reset, without changing the current
   selection, is with "XRSQ ?".  Remember that "XRSQ" alone reverts to
   the no-scheme state.

* 「リセット」が、混乱とひどく複雑な実現を避けるためにすべてのXRSQと「正常な」MLFLのメール/ものによって行われます。 XRSQコマンドは状態の変化か不確実性を含意します。そうでなければ、後者のコマンドは、T/R計画によって使用されるデータベース(例えば、メッセージ・テキスト格納領域)を打ち負かすのを避けるのにいくつかの独立しているメカニズムを使用しなければならないでしょう。 しかしながら、計画がいったん選択されると、それはちょうど「タイプA」か「8インチの残りが選択したバイト」として「有効な」ままで残っています。 現在の選択を変えないでリセットするためのお勧めの方法が"XRSQ?"と共にあります。 その"XRSQ"だけ、が計画がない状態に振り向けるのを覚えていてください。

   * It is permissible to intersperse other FTP commands among the
   XRSQ/XRCP/MAIL sequences.

* XRSQ/XRCP/メール系列の中に他のFTPコマンドを点在させるのは許されています。

                                                                [Page 5]

[5ページ]

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
Appendix A - on FTP reply codes

NWG/RFC#743KLH1977年12月30日8時39分、FTP回答コードの42759Appendix A

                           On FTP reply codes

FTP回答コードに関して

   The choice of appropriate reply codes for new or experimental
   commands is difficult because there have been three possible
   "official" sets of codes which one may draw on, and it is not clear
   which of them might be in use at any particular site; these are (1)
   Old FTP, (2) New FTP, (3) Revised New FTP.  In my choice of code
   assignments, I have for the most part ignored these and used RFC 691,
   "One More Try on the FTP", by Brian Harvey.  My motivation for this
   is the simple observation that I know of no site which implements
   "new FTP", and RFC 691 incorporates much of the "new FTP" reply code
   logic into the framework of "old FTP".  The only sharp conflict is
   treated by allowing 450 to have its "old" meaning, equivalent to 520
   - permanent failure.  Note that when testing to see whether a site
   understands a FTP command, a reply of 5xx (specifically, 500) will
   generally indicate, for all sets of codes, that the command is
   unrecognized.

利用されるかもしれない3つの可能な「公式」のコードがあったので、新しいか実験的なコマンドのための適切な回答コードの選択は難しいです、そして、それらのどれが何か特定のサイトで使用中であるかは、明確ではありません。 これらは(1)の古いFTP、(2)の新しいFTP、(3)の改訂されたNew FTPです。 コード課題の選択では、私はこれらと中古のRFC691、「FTPをもうひとつ試着します」、ブライアンでハーヴェイをだいたい無視しました。 私の動機は、これが私が「新しいFTP」、およびRFC691を実行するサイトを全く知らない簡単な観測であるので、「新しいFTP」回答コード論理の多くを「古いFTP」の枠組みに取り入れます。 450には520に同等な「古い」意味があるのを許容することによって、唯一の急激な闘争が扱われます--永久的な失敗。 サイトがFTPコマンドを理解しているかどうか確認するためにテストするとき、一般に、5xx(明確に500)の回答が、すべてのセットのコードのためにコマンドが認識されていないのを示すことに注意してください。

   By the way, I recommend RFC 691 as required reading for FTP
   implementors; maybe if enough people get together this mess can be
   straightened out.

ところで、私は必要に応じてFTP作成者をめざして勉強するRFC691を推薦します。 多分十分な人々が集まるなら、この混乱をまっすぐにすることができます。

                                                                [Page 6]

[6ページ]

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
Appendix B - Example of XRSQ R

NWG/RFC#743KLH1977年12月30日8時39分の42759付録B--XRSQ Rに関する例

                  Example of XRSQ R (Recipients first)

XRSQ Rに関する例(受取人、1番目)

   This is an example of how XRSQ R is used; first the user must
   establish that the server in fact implements XRSQ:

これはXRSQ Rがどう使用されているかに関する例です。 まず最初に、ユーザは、事実上、サーバがXRSQを実行すると証明しなければなりません:

      U: XRSQ
      S: 200 OK, no scheme selected.

U: XRSQ S: 200 OK、計画は選択されませんでした。

   An XRSQ with a null argument always returns a 200 if implemented,
   selecting the "scheme" of null, i.e. none of them.  If XRSQ were not
   implemented, a code of 4xx or 5xx would be returned.

実行されるなら、空の項があるXRSQはいつも200を返します、ヌル(すなわち、それらのどれか)でない「計画」を選択して XRSQが実行されないなら、4xxか5xxのコードは返されるでしょうに。

      U: XRSQ R
      S: 200 OK, using that scheme

U: XRSQ R S: 200 OK、その計画を使用すること。

   All's well; now the recipients can be specified.

すべてが順調です。 現在、受取人を指定できます。

      U: XRCP Foo
      S: 200 OK

U: XRCP Foo S: 200 OK

      U: XRCP Raboof
      S: 520 Who's that?  No such user here.

U: XRCP Raboof S: 520 それはだれですか? ここのそのようなユーザでない。

      U: XRCP bar
      S: 200 OK

U: XRCPはSを禁じます: 200 OK

   Well, two out of three ain't bad.  Note that the demise of "Raboof"
   has no effect on the storage of "Foo" or "bar".  Now to furnish the
   message text, by giving a MAIL or MLFL with no argument:

さて、3つのうちの2は悪くはありません。 "Raboof"の終焉は"Foo"か「バー」の格納のときに効き目がないことに注意してください。 現在、議論なしでメールかMLFLに与えることによってメッセージ・テキストを提供するために:

      U: MAIL
      S: 350 Type mail, ended by <CRLF>.<CRLF>
      U: Blah blah blah blah....etc etc etc
      U: .
      S: 256 Mail sent.

U: メールS: 350 <CRLF><CRLF>Uが終わらせたメールをタイプしてください: 何のかの、たわごと…などなどなどU: . S: 256メールは発信しました。

   The text has now been sent to both "Foo" and "bar".

現在、"Foo"と「バー」の両方にテキストを送りました。

                                                                [Page 7]

[7ページ]

NWG/RFC# 743                                  KLH 30-Dec-77 08:39  42759
Appendix C - Example of XRSQ T

NWG/RFC#743KLH1977年12月30日8時39分の42759付録C--XRSQ Tに関する例

                     Example of XRSQ T (Text first)

XRSQ Tに関する例(テキスト、1番目)

   Using the same message as the previous example:

前の例と同じメッセージを使用します:

      U: XRSQ ?
      S: 215 T Text first, please.

U: XRSQ? S: 215Tテキスト、1番目をお願いします。

   XRSQ is indeed implemented, and the server says that it prefers "T",
   but that needn't stop the user from trying something else:

本当に、XRSQは実行されます、そして、サーバは、「T」を好むと言いますが、ユーザはそれによって他の何かを試みる必要はないことができません:

      U: XRSQ R
      S: 501 Sorry, I really can't do that.

U: XRSQ R S: 501 すみません、私は本当にそれができません。

   Oh well.  It's possible that it could have understood "R" also, but
   in general it's best to use the "preferred" scheme, since the server
   knows which is most efficient for its particular site.  Anyway:

まあいいや。 「R」も理解したかもしれないのが、可能ですが、一般に、「都合のよい」計画を使用するのは最も良いです、サーバが、特定のサイトに、どれが最も効率的であるかを知っているので。 とにかく:

      U: XRSQ T
      S: 200 OK, using that scheme.

U: XRSQ T S: 200 OK、その計画を使用すること。

   Scheme "T" is now selected, and the text must be sent:

現在計画「T」を選択します、そして、テキストを送らなければなりません:

      U: MAIL
      S: 350 Type mail, ended by <CRLF>.<CRLF>
      U: Blah blah blah blah....etc etc etc
      U: .
      S: 256 Mail stored.

U: メールS: 350 <CRLF><CRLF>Uが終わらせたメールをタイプしてください: 何のかの、たわごと…などなどなどU: . S: 格納された256メール。

   Now recipients can be specified:

現在、受取人を指定できます:

      U: XRCP Foo
      S: 256 Stored mail sent.

U: XRCP Foo S: 256 格納されたメールは発信しました。

      U: XRCP Raboof
      S: 520 Who's that?  No such user here.

U: XRCP Raboof S: 520 それはだれですか? ここのそのようなユーザでない。

      U: XRCP bar
      S: 256 Stored mail sent.

U: XRCPはSを禁じます: 256 格納されたメールは発信しました。

   Again, the text has now been sent to both "Foo" and "bar", and still
   remains stored.  A new message can be sent with another MAIL/XRCP...
   sequence, but the fastidious or paranoid could chose to do:

一方、テキストは、現在"Foo"と「バー」の両方に送られて、まだ格納されたままで残っています。 別のメール/XRCP…系列と共に新しいメッセージを送ることができましたが、気難しいかパラノイアが送ることができた、以下をするのを選びました。

      U: XRSQ ?
      S: 215 T Text first, please.

U: XRSQ? S: 215Tテキスト、1番目をお願いします。

   Which resets things without altering the scheme in effect.

事実上、計画を変更しないで、ものをリセットします。

                                                                [Page 8]

[8ページ]