more FTP protocol violations


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


   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
      RNFR)."

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.

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.
                                        - john



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