Re: Last Call: Feature negotiation mechanism for the File Transfer Protocol to Proposed Standard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: Feature negotiation mechanism for the File Transfer Protocol to Proposed Standard



Robert Elz writes:
  [ about changing " " to "211-" in a proposed FTP extension ]
> That's certainly just a cosmetic change,

I'm continually amazed at how little attention the IETF pays to these
basic protocol engineering issues.

In the real world, Qualcomm has just released a version of Eudora Pro
that's incompatible with thousands of non-sendmail SMTP servers around
the world. It fails whenever it tries to send a styled message, because
it incorrectly terminates SMTP lines with \n instead of \r\n. Oops.

Exercise for the reader: How could SMTP have been engineered so that
Qualcomm would not have fallen into this trap? (For some hints, see
http://pobox.com/~djb/proto/design.html. For a complete answer, see
http://pobox.com/~djb/proto/qmtp.txt.)

Back to the proposed extension. I object to FEAT on the grounds that its
response format is much more complicated than it needs to be. The format
should be redesigned to make client parsing as easy as possible. In
particular, the initial text should be scrapped, and the current "\r\n "
separator should be replaced by a single-byte terminator such as "/".

---Dan

P.S. I'm sending this to ftp-wg at hethmon.com and ietf at ietf.org. Thanks to
the misguided ftp-wg MLM, ftp-wg subscribers probably won't see the
complete To line.



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.