RFC 463 (rfc463) - Page 1 of 3

FTP comments and response to RFC 430

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