rfc743.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 472 行 · 第 1/2 页

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



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!

   * 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.

   * 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.

   * "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.

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













                                                                [Page 5]

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



                           On FTP reply codes

   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.

   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.































                                                                [Page 6]

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



                  Example of XRSQ R (Recipients first)

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

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

   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.

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

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

      U: XRCP Foo
      S: 200 OK

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

      U: XRCP bar
      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:

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

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















                                                                [Page 7]

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



                     Example of XRSQ T (Text first)

   Using the same message as the previous example:

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

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

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

   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:

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

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

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

   Now recipients can be specified:

      U: XRCP Foo
      S: 256 Stored mail sent.

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

      U: XRCP bar
      S: 256 Stored mail sent.

   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:

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

   Which resets things without altering the scheme in effect.





                                                                [Page 8]