As per Relevance of the word appendix, we have this rfc below:
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
Network Working Group K.
Request for Comments: 743 SRI-
NIC: 42758 30 December 1977
FTP extension: XRSQ/
This RFC describes an extension to FTP which allows the user of an
FTP server (i.e. on MIT-(AI/ML/MC/DMS)) to mail the text of a message
several recipients simultaneously; such message transmission is far
efficient than the current practice of sending the text again and
for each additional recipient at a site
Within this extension, there are two basic ways of sending a single
to several recipients. In one, all recipients are specified first,
then the text is sent; in the other, the order is reversed and the
is sent first, followed by the recipients. Both schemes are
becaue neither by itself is optimal for all systems, as will
explained later. To select a particular scheme, the XRSQ command
used; to specify recipients after a scheme is chosen, XRCP commands
given; and to furnish text, the usual MAIL or MLFL commands apply
Scheme Selection:
XRSQ is the means by which a user program can test for
of XRSQ/XRCP, select a particular scheme, reset its state thereof
and even do some rudimentary negotiation. Its format is like that
the TYPE command, as follows
XRSQ [ ]
= 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 (
default).
Replies
200 OK, we'll use specified scheme
215 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
[Page 1]
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
An Extension to
an XRSQ with no argument must always return a 200 reply and
the default state of having no scheme selected. Any other
implies that XRSQ and hence XRCP are not understood or cannot
performed correctly
The second is that the use of "?" as a asks the FTP
to return a 215 reply in which the server specifies a "preferred
scheme. The format of this reply is simple
215 [ <arbitrary text>]
Any other reply (e.g. 4xx or 5xx) implies that XRSQ and XRCP
not implemented, because "?" must always be implemented if
is
The third important thing about XRSQ is that it always has the
effect of resetting all schemes to their initial state. This
must be done no matter what the reply will be - 200, 215, or 501.
The actions necessary for a reset will be explained when
how each scheme actually works
Message Text Specification: MAIL/
Regardless of which scheme (if any) has been selected, a MAIL or
with a non-null argument will behave exactly as before;
extension has no effect on them. However, such normal MAIL/
commands do have the same side effect as XRSQ; they "reset"
current scheme to its initial state
It is only when the argument is null (e.g. MAIL or MLFL)
that the particular scheme being used is important, because
than producing an error (as most servers currently do), the
will accept message text for this "null" specification; what it
with it depends on which scheme is in effect, and will be
in "Scheme Mechanics".
Recipient specification:
In order to specify recipient names and receive some
(or refusal) for each name, the following new command is
defined
XRCP <Recipient name>
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
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
Note that use of this command is an error if no scheme has
selected yet; an XRSQ must have been given if XRCP is to
used
Scheme mechanics: XRSQ R (Recipients first
In the recipients-first scheme, XRCP is used to specify names
the FTP server stores in a list or table. Normally the reply
each XRCP will be either a 200 for acceptance, or a 4xx/5xx code
rejection; 450 and all 5xx codes are permanent rejections (e.g.
not known) which should be reported to the human sender, whereas 4
codes in general connote some temporary error that may be
later. None of the 4xx/5xx replies impinge on previous or
XRCP commands, except for 440 which indicates that no further XRCP'
will succeed unless a message is sent to the already
recipients or a reset is done
Sending message text to stored recipients is done by giving a MAIL
MLFL command with no argument; that is, just MAIL
MLFL. Transmission of the message text is exactly the same
for normal MAIL/MLFL; however, a positive acknowledgement at the
of transmission means that the message has been sent to
recipients that were remembered with XRCP, and a failure code
that it should be considered to have failed for ALL of
specified recipients. This applies regardless of the actual
code; and whether the reply signifies success or failure, all
recipient names are flushed and forgotten - in other words,
are reset to their initial state. This purging of the recipient
list must also be done as the "reset" side effect of any use of XRSQ
A 440 reply to an XRCP can thus be handled by using a MAIL/MLFL
specify the message for currently stored recipients, and then
more XRCP's and another MAIL/MLFL, as many times as necessary;
example, if a server only had room for 10 names this would result
a 50-recipient message being sent 5 times, to 10 different
each time
If a user attempts to specify message text (MAIL/MLFL with
[Page 3]
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
An Extension to
argument) before any successful XRCP's have been given, this
be treated exactly as a "normal" MAIL/MLFL with a null
would be; most servers will return an error of some type, such
"450 Null recipient".
See Appendix B for an example using XRSQ R
Scheme mechanics: XRSQ T (Text first
In the text-first scheme, MAIL/MLFL with no argument is used
specify message text, which the server stores away.
XRCP's are then treated as if they were MAIL/MLFL commands,
that none of the text transfer manipulations are done; the
message text is sent to the specified recipient, and a reply code
returned identical to that which an actual MAIL/MLFL would invoke
(Note ANY 2xx code indicates success.)
The stored message text is not forgotten until the next MAIL/MLFL
XRSQ, which will either replace it with new text or flush
entirely. Any use of XRSQ will reset this scheme by flushing
text, as will any use of MAIL/MLFL with a non-null argument
If an XRCP is seen before any message text has been stored, the
in effect is trying to send a null message; some servers might
this, others would return an error code
See Appendix C for an example using XRSQ T
Why two schemes anyway
Because neither by itself is optimal for all systems. XRSQ R
more of a "bulk" mailing, because everything is saved up and
mailed simultaneously; this is very useful for systems such as
where the FTP server does not itself write mail directly, but
it on to a central mailer demon of great power; the more
(e.g. recipients) associated with a single "hand-off", the
efficiently mail can be delivered
By contrast, XRSQ T is geared to FTP servers which want to
mail directly, in one-by-one incremental fashion. This way they
return an individual success/failure reply code for each
given which may depend on variable file system factors such
exceeding disk allocation, mailbox access conflicts, and so forth;
they tried to emulate XRSQ R's bulk mailing, they would have
ensure that a success reply to the MAIL/MLFL indeed meant that it
been delivered to ALL recipients specified - not just some
[Page 4]
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
An Extension to
Stray notes
* Because this is after all an extension of FTP protocol, one must
prepared to deal with sites which don't recognize either XRSQ
XRCP. "XRSQ" and "XRSQ ?" are explicitly designed as tests to
whether either scheme is implemented; XRCP is not, and a
return of the "unimplemented" variety could be confused with "
scheme selected yet", or even with "Recipient unknown". Be safe,
sure, use XRSQ
* There is no way to indicate in a positive response to "XRSQ ?"
the preferred "scheme" for a server is that of the default state
i.e. none of the multi-recipient schemes. The rationale is that
this case, it would be pointless to implement XRSQ/XRCP at all,
the response would therefore be negative
* One reason that the use of MAIL/MLFL is restricted to
arguments with this multi-recipient extension is the ambiguity
would result if a non-null argument were allowed; for example,
XRSQ R was in effect and some XRCP's had been given, and a
FOO was done, there would be no way to distinguish a
reply for mailbox "FOO" from a global failure for all
specified. A similar situation exists for XRSQ T; it would not
clear whether the text was stored and the mailbox failed, or
versa, or both
* "Resets" are done by all XRSQ's and "normal" MAIL/MLFL's to
confusion and overly complicated implementation. The XRSQ
implies a change or uncertainty of status, and the latter
would otherwise have to use some independent mechanisms to
clobbering the data bases (e.g. message text storage area) used
the T/R schemes. However, once a scheme is selected, it remains "
effect" just as a "TYPE A" or "BYTE 8" remains selected.
recommended way for doing a reset, without changing the
selection, is with "XRSQ ?". Remember that "XRSQ" alone reverts
the no-scheme state
* It is permissible to intersperse other FTP commands among
XRSQ/XRCP/MAIL sequences
[Page 5]
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
Appendix A - on FTP reply
On FTP reply
The choice of appropriate reply codes for new or
commands is difficult because there have been three
"official" sets of codes which one may draw on, and it is not
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
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
is the simple observation that I know of no site which
"new FTP", and RFC 691 incorporates much of the "new FTP" reply
logic into the framework of "old FTP". The only sharp conflict
treated by allowing 450 to have its "old" meaning, equivalent to 520
- permanent failure. Note that when testing to see whether a
understands a FTP command, a reply of 5xx (specifically, 500)
generally indicate, for all sets of codes, that the command
unrecognized
By the way, I recommend RFC 691 as required reading for
implementors; maybe if enough people get together this mess can
straightened out
[Page 6]
NWG/RFC# 743 KLH 30-Dec-77 08:39 42759
Appendix B - Example of XRSQ
Example of XRSQ R (Recipients first
This is an example of how XRSQ R is used; first the user
establish that the server in fact implements XRSQ
U:
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
implemented, a code of 4xx or 5xx would be returned
U: XRSQ
S: 200 OK, using that
All's well; now the recipients can be specified
U: XRCP
S: 200
U: XRCP
S: 520 Who's that? No such user here
U: XRCP
S: 200
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
message text, by giving a MAIL or MLFL with no argument
U:
S: 350 Type mail, ended by .
U: Blah blah blah blah....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
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
S: 501 Sorry, I really can't do that
Oh well. It's possible that it could have understood "R" also,
in general it's best to use the "preferred" scheme, since the
knows which is most efficient for its particular site. Anyway
U: XRSQ
S: 200 OK, using that scheme
Scheme "T" is now selected, and the text must be sent
U:
S: 350 Type mail, ended by .
U: Blah blah blah blah....etc etc
U: .
S: 256 Mail stored
Now recipients can be specified
U: XRCP
S: 256 Stored mail sent
U: XRCP
S: 520 Who's that? No such user here
U: XRCP
S: 256 Stored mail sent
Again, the text has now been sent to both "Foo" and "bar", and
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
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
