Browse Prior Art Database

FTP comments and response to RFC 430 (RFC0463)

IP.com Disclosure Number: IPCOM000003612D
Original Publication Date: 1973-Feb-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 3 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.K. Bhushan: AUTHOR

Related Documents

10.17487/RFC0463: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 58% of the total text.

Network Working Group Abhay K. Bhushan RFC # 463 MIT-DMCG NIC # 14573 February 21, 1973

FTP Comments and Response to RFC 430

Most of the comments in RFC 430 by Bob Braden are useful suggestions which should be included in the forthcoming official FTP specification. This RFC represents my response to Braden’s comments and other views. These comments should be useful for the FTP meeting on March 16 at BBN (announcement warning AAM NIC #14417). The results of the FTP subgroup meeting held at BBN on January 25 will be published in RFC 4541 (are published?).

SPECIFIC RESPONSES TO RFC 430.

Item A1 - I will let Bob Braden handle the "print file" issues (the "still" should be removed).

Item A2 - I agree that concessions are undesirable and should be removed unless people cannot "live" without them.

Item A3 - I strongly support "bit flag coding" for descriptors. Other definition improvement suggestions are ok too.

Item A4 - The diagram was useful. An alternate one is given on page 17 of RFC 454. I prefer the latter.

Item A5 - The FTP may not be privileged enough to alter passwords in many Host systems (e.g. Multics). I know that CCN allows changing passwords on-line. We can define a format for changing passwords in the pass command, but I don’t think we can require that all servers allow password changing. This is a minor problem that can be easily solved.

Item A6 - Yes, the comment that TYPE should be before BYTE was for bad implementations. The server should reject data transfer parameters only when the data transfer command is received. The order of the parameter-change commands is not important.

Item A7 - I do agree that NCP’s should be fixed. A 255 (socket number) reply should be required at a specific time, and NCP’s should be able to provide it (this also permits the proposed GSOC command). Let us find out at next meeting if there is anyone who cannot live with this new requirement.

Bhushan [Page 1]

RFC 463 FTP Comments and Response to RFC 430 February 1973

Item A8 - Yes.

Item B - There are at least two ways to solve the FTP parameter encoding problem presented by Bob Braden. One is to allow multiple letter in the TYPE command as suggested by Bob and the other is to have a new command such as FORM (which could be P or U). Other solutions are equally acceptable to me.

Item C - Our emphasis should be on working protocol as well as elegance. I like the proposed GSOC command over the listen. In fact GSOC can be used for all data connection security checking. The 255 reply should be sent with GSOC only, and the server should use only those sockets for data connection.

Item D - We need more discussion on the issue of site dependent FTP parameters. I will put it on the agenda for the forthcoming FTP meeting.

FURTHER COMMENTS

1. The command-reply sequence needs to be tightened in both specification and implementations to allow convenient use of FTP by programs or...

Processing...
Loading...