more FTP protocol violations

Benson I. Margulies (Margulies@SCRC-YUKON.ARPA)
Thu, 3 Apr 86 07:50 EST

    Date: Wed, 2 Apr 86 17:44 EST
    From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

        Date: Wed, 2 Apr 86 17:37:01 est
        From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

           Date: Wed, 2 Apr 86 17:06 EST
           From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>

               Date: Wed, 2 Apr 86 14:15:37 est
               From: romkey@BORAX.LCS.MIT.EDU (John Romkey)

                  Date: Wed, 2 Apr 86 09:36 EST
                  From: Benson I. Margulies <Margulies@SCRC-YUKON.ARPA>



           Wait a minute. A spec is a spec. What's the point of the two digits if
           (a) some hosts send the wrong ones, and (b) some hosts don't bother to
           look at them. If the spec said you could be lazy, then it would be OK.
           If the spec doesn't, an implementation is INCORRECT if it sends the
           wrong codes and an implementation is ASKING FOR TROUBLE if it accepts
           more than what the spec says.

        I probably should've just done this the first time, but I had to go
        reread the spec to be sure. From RFC 959, last paragraph of page 36:

             "The three digits of the reply each have a special significance.
              This is intended to allow a range of very simple to very
              sophisticated responses by the user-process. The first digit
              denotes whether the response is good, bad or incomplete.
              (Referring to the state diagram), an unsophisticated user-process
              will be able to determine its next action (proceed as planned,
              redo, retrench, etc.) by simply examining this first digit. A
              user-process that wants to know approximately what kind of error
              occurred (e.g. file system error, command syntax error) may
              examine the second digit, reserving the third digit for the finest
              gradation of information (e.g., RNTO command without a preceding

        And Section 6 presents some simple state machines for commands, using
        only the first digit of the code to drive them. So we can be lazy if
        we want to.

        It makes sense to me to have an error indication (first digit) and
        then a more specific error code (second digit), but it doesn't seem to
        me that we should really have to worry about "what kind of success"
        happened when there was no error, which is what the original question
        was about (4.2 returning a strange success code). So I think most user
        implementations can probably ignore the second and third digits in the
        case of success.

    OK, that takes care of the user end; user ends are allowed to be lazy.

        Of course, if there is a "standard" response (250) to send in the case of
        success, a server should probably send that instead of something else
        that's similar but not quite the same (200). Appendix II of RFC959
        says that the correct success response to a DELE is 250.

    Several (all?) Unix server implementations send 200. This is NOT the
    correct response, and I think a user program that does look at all three
    digits is allowed to consider this a protocol violation.

I disagree. The paragraph above says clearly that the basic response
semantics are implied by the first digit. It seems to me that the spec
should be revised to state that for success the later two digits are

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:05 GMT