FTP extension: XRSQ/XRCP
RFC 743
|
Document |
Type |
|
RFC - Unknown
(December 1977; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 743 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
FTP extension: 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.
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.
Scheme Selection: 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 [<SP> <scheme>] <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.
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.
Three aspects of XRSQ need to be pointed out here. The first is that
[Page 1]
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
An Extension to FTP
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.
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:
215 <SP> <scheme> [<SP> <arbitrary text>] <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.
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.
Message Text Specification: MAIL/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.
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".
Recipient specification: 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>
Reply for no scheme:
507 No scheme specified yet; use XRSQ.
Replies for scheme T are identical to those for MAIL/MLFL.
[Page 2]
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
An Extension to FTP
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.
Show full document text