CARVIEW |
Select Language
HTTP/2 200
date: Thu, 17 Jul 2025 16:37:35 GMT
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self' 'unsafe-inline' data: https://datatracker.ietf.org/ https://www.ietf.org/ https://ietf.org/ https://analytics.ietf.org https://static.ietf.org; frame-ancestors 'self' ietf.org *.ietf.org meetecho.com *.meetecho.com
cross-origin-opener-policy: unsafe-none
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=3600; includeSubDomains
vary: Cookie, Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
cf-cache-status: REVALIDATED
expires: Thu, 17 Jul 2025 20:37:35 GMT
cache-control: public, max-age=14400
server: cloudflare
cf-ray: 960b2a304c5bc181-BLR
content-encoding: gzip
alt-svc: h3=":443"; ma=86400
RFC 238 - Comments on DTP and FTP proposals
Report a datatracker bug
Network Working Group R. T. Braden
Request for Comments #238 UCLA-CCN
NIC #7663 September 29, 1971
Category:
Updates: RFC #171, RFC #172
COMMENTS ON DTP AND FTP PROPOSALS
Data Transfer Protocol
----------------------
1. In the Descriptor/Count mode, the Information Separators should
have a transaction sequence number field. Otherwise, the receiver
cannot be sure he received all transactions before the separation.
This requires that there be two forms of information separators, one
for Descriptor/Count mode, the other for the DLE mode.
2. The modes-available handshake should not be mandatory, as it makes
no sense in the simplex case. The receiver doesn't care what modes
the transmitter _might_ use; he only cares what mode _is_ used, which
he discovers when the first data or control transaction arrives. Even
in the duplex case, it is not clear what use the receiver should make
of the modes-available information from the transmitter.
File Transfer Protocol
----------------------
1. The protocol allows an end-of-file to be indicated by closing the
connection. This is the same mistake which we made in an early
version of NETRJS. Closing the connection without a File Separator
transaction should only be used to indicate an error, i.e., to abort
the transmission; it should never be used to indicate normal
completion of file transfer. The reason is obvious: there is no way
for the receiver to tell whether CLS indicates normal completion or an
abnormal condition in the other host (e.g. the file transfer program
died).
2. There should be two forms of the _store_ request, one which fails
if a file of the same name already exists, and one which replaces an
existing file of the same name (as now).
3. A service center host may be expected to require username and
password transactions before any others are accepted.
4. There are no error transactions defined for lost data or lost
synch. It is assumed there are handled at the DTP level?
5. All of the defined error codes should be allowed (and encouraged)
to have explanatory text following them.
[Page 1]
RTB:gjm
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
[Page 2]
Datatracker
RFC 238
RFC
- Unknown
Document | Document type |
RFC
- Unknown
September 1971 Report errata
This RFC is labeled as "Legacy"; it was published before a formal source was recorded.
This RFC is not endorsed by the IETF and has no formal standing in the
IETF standards process.
|
|
---|---|---|---|
Select version | |||
Authors |
Email authors |
||
RFC stream | Legacy | ||
Other formats |