📄 rfc743.txt
字号:
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759An Extension to FTPStray 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 42759Appendix 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 42759Appendix 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 42759Appendix 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]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -