This is only a rough draft - Megan 04/20/92 Minutes of the FTP Extensions BOF at IETF 23 Jordan Brown, 16 April 1992 The mail traffic and discussion at the meeting basically involved people's wish lists for the protocol. Topics included: . passing "auxiliary" information about files - dates, etc. . automatic authentication . encryption . on-the-fly compression . checkpointing/restart . language selection for messages . message digest calculation . atomic store (FTP your nuclear waste to...) . various protocol cleanups/clarifications . more sophisticated conversions - character set, app, etc. . should write both a spec and an "implementor's guide" . time conversion issues - time zones, DST, etc. There was consensus that a Working Group should be formed, and when a deafening silence resulted from a call for volunteers to chair it, I agreed to. (Volunteers are still solicited!) Russ Hobby offered to host the mailing list and archives. The initial mailing list is the BOF attendees. Mailing list: ietf-ftpext@ucdavis.edu Requests: ietf-ftpext-request@ucdavis.edu Archive: ucdavis.edu: /archive/ftpext-archive No date was set for the next meeting. Detailed comments: . passing "auxiliary" information about files - dates, etc. The goal would be to build an extensible mechanism allowing a client and server to pass "auxiliary" information about files. Extended versions of LIST, RETR, STOR, etc would pass this information, and a new command would be added to change it. Matching client and server should be able to pass all of the information their native system supports; non-matching pairs would pass as much as they have in common. A major open issue is whether the data should be passed in binary as type-length-value or in some printable-ASCII form. . automatic authentication There are two basic ways in which authentication data might be passed at present - using FTP commands or, relaxing the spec a bit, using TELNET options on the control connection. It was suggested that authentication and encryption are big complex issues on their own, and that they be split off from the rest of the items on the wish lists. . encryption There was interest in encryption of both the data and the control channel. Encryption is tightly tied to authentication, and the two should probably be treated as a unit. . on-the-fly compression Some servers already implement on-the-fly compression triggered by variations in the file name. The patent status of LZW is an issue which needs to be researched and resolved. . checkpointing/restart Some attendees sought official blessing for Rick Adams' stream mode restart capability (present in some BSD clients and servers). It was noted that it is unclear whether or not this mechanism truly works for NVT-ASCII mode transfers. It was clear that the restart marker for this mechanism should be measured in data-connection octets. Implementing such a restart mechanism might be tricky on systems where the local<->network translation is not strictly invertible. . language selection for messages Seems pretty self-explanatory; obviously no system will support all languages, but support for multiple languages seems reasonable. This issue will come up in other contexts (SMTP, etc); perhaps there should be a more global framework. . message digest calculation The goal is to allow automatic mirroring of archives without having to transfer all of the data. . atomic store The disposition of the file resulting from a failing STOR is unspecified; a new command would require that the file be deleted if the transfer was not completed successfully. . various protocol cleanups/clarifications RFC 1127 lists several response code cleanups and clarifications. Experience with newer servers which make more extensive use of multiline responses indicates that not all clients can handle them. The syntax for multiline responses is apparently not clear enough; there has been confusion. Note that FTP multiline responses are more liberal than SMTP multiline responses. . more sophisticated conversions - character set, app, etc. An extended version of NVT-ASCII mode would allow for transmission of non-USASCII characters; a mechanism would be needed to specify what character set is in use and what translations should be applied. This issue has already been addressed in Kermit and the lessons learned there should be applied. A still more sophisticated mechanism to automatically do application-level transformation (eg Microsoft Word to TeX) would certainly be useful, but is obviously a very complex topic. . should write both a spec and an "implementor's guide" It was mentioned that FTP has numerous common pitfalls, and an informational document pointing out these pitfalls and suggesting implementation schemes would help implementors and improve interoperability. . time conversion issues - time zones, DST, etc. Once FTP is passing around time information (file modification times, mostly), it becomes important to know what the times really mean, so that meaningful comparisons and conversions can be done. One obvious answer is to require that all times be expressed in GMT, but that is awkward for the large (and ever- increasing) number of machines which don't know what time zone they're in. One scheme for dealing with this would be to provide a command which gives the server's current time with respect to whatever TZ it finds convenient; the client can compare this with its current time to determine the offset to be applied to other times. This requires very loosely synchronized clocks - less than 15 minutes difference. It's not clear whether DST confuses this issue - a file stored under DST and later retrieved under ST might have its times mistranslated. (Portable computers make time issues a nightmare.)