rfc944.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 2,321 行 · 第 1/5 页
TXT
2,321 行
Official ARPA-Internet Protocols RFC 944
things the TCP must do to make connection reliable in
a more complex world.
LIST and NLST:
There is some confusion about the LIST an NLST commands, and
what is appropriate to return. Some clarification and
motivation for these commands should be added to the
specification.
Multiple 1xx Replies:
There is some difference of opinion about the use of
multiple 1xx responses during command processing. This
issue comes up particularly in processing the RETR and STOR
commands. The two opinions are summarized below.
For Exactly One 1xx Response:
When a RETR or SEND command is started, the server is
supposed to give an "intermediate reply" of 1xx when it
is opening the data connection. Currently, some FTP
servers give two 1xx messages. This causes problems for
single-thread FTP user implementations. After reading
the first intermediate reply, they go off to do the
transfer. The second 1xx message is not seen until the
end of the transfer. The RFC gives a state diagram of
the form:
--------->Wait--------->
/ \
^ |
| V
\ /
<-----
This implies any number of 1xx's (including 0). There is
a suspicion that this is just sloppy diagraming, and that
the intent is clear from other parts of the RFC.
The FTP specification states that the reason for
intermediate replies is to allow implementations that
can't do any better to know when to stop listening to the
control channel and switch their attention to the data
channel. Given this intent, it seems clear that there
should be exactly one 1xx reply at the start of the
transfer.
The FTP specification is ambiguous in this regard. The
Reynolds & Postel [Page 17]
Official ARPA-Internet Protocols RFC 944
state diagrams appear to sanction any number of
responses. But the charts before them do not. And from
the intent, it seems obvious that exactly one is the
right thing.
Consider an implementation on a PC. It is fairly hard to
do parallel processing there. It should be possible for
a PC implementation to stop paying attention to the
control channel and start reading the file from the data
channel when he sees the 1xx response. The only way this
can work is if there is only one 1xx response.
Of course, one could make it a requirement that every FTP
implementation must be based on good enough interrupt
technology so that it can field extra responses during
the transfer. But what would such a constraint buy?
Just the ability to have both a 125 and a 150 response.
It doesn't seem worth the price. You could just as well
combine the information in those responses into a single
one.
For Multiple 1xx Responses:
The multiple 1xx messages arose because the new TCP
specification omitted the 050 spontaneous reply code. A
solution was to change an 050 informational message to a
1xx message, creating both a 125 and a 150.
The state diagrams clearly allow this, and the
"Command-Reply Sequences" section does not contradict it.
A multiple 1xx implementation is in accord with the
formal reply specifications.
A multiple 1xx implementation works with the TOPS-20
FTP's and with a number of different UNIX
implementations, and the LOCUS system. So, a lot of
implementors must follow state diagrams in preference to
prose.
However, the observation is certainly correct that
page 34 of the specification suggests that 1xx replies
can be used by single-thread user implementations to
switch attention to the data connection. This would
allow only a single 1xx message, in contradiction to the
state diagrams. It seems a bit strong, however, to call
the one sentence on page 34 "the intent" of the
specification, since it is contradicted by the format
specification of replies.
Reynolds & Postel [Page 18]
Official ARPA-Internet Protocols RFC 944
A side discussion favoring more status information:
One view has always assumed a two-thread
implementation. In this view, most user
implementations are deficient because they do not
allow the user to enter a STATUS command during data
transfer. A cynic might say that is because the
Computer Scientists who did these implementations only
do "Toy" file transfers, and often use "Toy" operating
systems.
There has been some complaints from the Toy systems
crowd recently that FTP is too complicated. Well, it
may be too complicated for Toy systems, but in fact it
is too simple for many Real file systems. For
example, it has no way to encode a "library" (i.e., a
named collection of subfiles). It is (barely)
adequate for shipping around files of text, but not
much more.
With the notable exception of Multics and UNIX, many
operating systems support complex file structures of
which the user must be aware. One is not doing the
user a favor by hiding details that may reach out and
bite him. That is the reason some FTPs put out a
large informative message at the beginning of the
transfer, specifying the file baroqueness that is
involved. As a Computer Scientist, you may find that
message annoying, but if you had to use MVS very much,
you would find it helpful, informative, and maybe even
reassuring. Some believe that as DARPA technology
moves into the production environment of DDN, there
will be user requirements for such informative
messages for a variety of vendor operating systems.
To provide important information to the user the
specification should either allow multiple 1xx messages,
or restore the old spontaneous reply category. In fact,
the latter is preferable; this information should be
displayed to the user, but a user FTP might swallow 1xx
messages without displaying their text.
The Answer:
Following the Robustness Principle (a protocol
implementation ought to inflict minimal pain and accept
maximal pain) there should be only one 1xx response.
That is, those FTP servers that now issue two 1xx
responses should combine them.
Reynolds & Postel [Page 19]
Official ARPA-Internet Protocols RFC 944
OTHER REFERENCES:
RFC 678 - Document File Format Standards
MIL-STD-1780 - File Transfer Protocol
DEPENDENCIES: Transmission Control Protocol
CONTACT: Postel@USC-ISIF.ARPA
Trivial File Transfer Protocol ------------------------------ (TFTP)
STATUS: Elective
SPECIFICATION: RFC 783 (in IPTW)
COMMENTS:
A very simple file moving protocol, no access control is
provided.
This is in use in several local networks.
Ambiguities in the interpretation of several of the transfer
modes should be clarified, and additional transfer modes could
be defined. Additional error codes could be defined to more
clearly identify problems.
OTHER REFERENCES:
DEPENDENCIES: User Datagram Protocol
CONTACT: Postel@USC-ISIF.ARPA
Simple File Transfer Protocol ------------------------------- (SFTP)
STATUS: Experimental
SPECIFICATION: RFC 913
COMMENTS:
SFTP is a simple file transfer protocol. It fills the need of
people wanting a protocol that is more useful than TFTP but
easier to implement (and less powerful) than FTP. SFTP
supports user access control, file transfers, directory
listing, directory changing, file renaming and deleting.
SFTP can be implemented with any reliable 8-bit byte stream
Reynolds & Postel [Page 20]
Official ARPA-Internet Protocols RFC 944
oriented protocol, this document describes its TCP
specification. SFTP uses only one TCP connection; whereas TFTP
implements a connection over UDP, and FTP uses two TCP
connections (one using the TELNET protocol).
Please discuss any plans for implementation or use of this
protocol with the contact.
OTHER REFERENCES:
DEPENDENCIES: Transmission Control Protocol
CONTACT: MKL@MIT-XX.ARPA
Simple Mail Transfer Protocol ------------------------------- (SMTP)
STATUS: Recommended
SPECIFICATION: RFC 821 (in "Internet Mail Protocols")
COMMENTS:
The procedure for transmitting computer mail between hosts.
This has been revised since the IPTW, it is in the "Internet
Mail Protocols" volume of November 1982. RFC 788 (in IPTW) is
obsolete.
There have been many misunderstandings and errors in the early
implementations. Some documentation of these problems can be
found in the file [ISIF]<SMTP>MAIL.ERRORS.
Some minor differences between RFC 821 and RFC 822 should be
resolved.
OTHER REFERENCES:
RFC 822 - Mail Header Format Standards
This has been revised since the IPTW, it is in the "Internet
Mail Protocols" volume of November 1982. RFC 733 (in IPTW)
is obsolete. Further revision of RFC 822 is needed to
correct some minor errors in the details of the
specification.
MIL-STD-1781 - Simple Mail Transfer Protocol (SMTP)
DEPENDENCIES: Transmission Control Protocol
Reynolds & Postel [Page 21]
Official ARPA-Internet Protocols RFC 944
CONTACT: Postel@USC-ISIF.ARPA
Resource Location Protocol ----------------------------------- (RLP)
STATUS: Elective
SPECIFICATION: RFC 887
COMMENTS:
A resource location protocol for use in the ARPA-Internet.
This protocol utilizes the User Datagram Protocol (UDP) which
in turn calls on the Internet Protocol to deliver its
datagrams.
OTHER REFERENCES:
DEPENDENCIES: User Datagram Protocol
CONTACT: Accetta@CMU-CS-A.ARPA
Loader Debugger Protocol ------------------------------------- (LDP)
STATUS: Experimental
SPECIFICATION: RFC 909
COMMENTS:
Specifies a protocol for loading, dumping and debugging target
machines from hosts in a network environment. It is also
designed to accommodate a variety of target CPU types. It
provides a powerful set of debugging services, while at the
same time, it is structured so that a simple subset may be
implemented in applications like boot loading where efficiency
and space are at a premium.
OTHER REFERENCES:
DEPENDENCIES: Reliable Data Protocol
CONTACT: Hinden@BBN-UNIX.ARPA
Reynolds & Postel [Page 22]
Official ARPA-Internet Protocols RFC 944
Remote Job Entry --------------------------------------------- (RJE)
STATUS: Elective
SPECIFICATION: RFC 407 (in APH)
COMMENTS:
The general protocol for submitting batch jobs and retrieving
the results.
Some changes needed for use with TCP.
No known active implementations.
OTHER REFERENCES:
DEPENDENCIES: File Transfer Protocol
Transmission Control Protocol
CONTACT: Postel@USC-ISIF.ARPA
Remote Job Service ---------------------------------------- (NETRJS)
STATUS: Elective
SPECIFICATION: RFC 740 (in APH)
COMMENTS:
A special protocol for submitting batch jobs and retrieving the
results used with the UCLA IBM OS system.
Please discuss any plans for implementation or use of this
protocol with the contact.
Revision in progress.
OTHER REFERENCES:
DEPENDENCIES: Transmission Control Protocol
CONTACT: Braden@UCLA-CCN.ARPA
Reynolds & Postel [Page 23]
Official ARPA-Internet Protocols RFC 944
Remote Telnet Service ------------------------------------ (RTELNET)
STATUS: Elective
SPECIFICATION: RFC 818
COMMENTS:
Provides special access to user Telnet on a remote system.
OTHER REFERENCES:
DEPENDENCIES: Telnet, Transmission Control Protocol
CONTACT: Postel@USC-ISIF.ARPA
Graphics Protocol --------------------------------------- (GRAPHICS)
STATUS: Elective
SPECIFICATION: NIC 24308 (in APH)
COMMENTS:
The protocol for vector graphics.
Very minor changes needed for use with TCP.
No known active implementations.
OTHER REFERENCES:
DEPENDENCIES: Telnet, Transmission Control Protocol
CONTACT: Postel@USC-ISIF.ARPA
Reynolds & Postel [Page 24]
Official ARPA-Internet Protocols RFC 944
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?