Editor's note: These minutes have not been edited. Draft Minutes for the FTP Extensions Working Group 37th IETF, San Jose, December 10, 1996 Reported by: Bill Curtin (curtinw@ftm.disa.mil) with thanks to Keith Lamond for contributing his notes from the meeting. Chair: Paul Hethmon 1. Paul opened the meeting by welcoming everyone and giving a brief overview of the FTPEXT working group. Topics discussed at the meeting included the I18N draft, the MLST draft, Secure Socket Layer for FTP, Checkpoint / Restart, IPV6 draft, URLs, and rewrite of RFC 959. 2. I18N DRAFT. The major mail list discussion points concerning draft-ietf- ftpext-intl-ftp-00.txt were presented. The mail list comments were categorized as general, document structure, references to IAB character set workshop, control characters in pathnames, display issues, and bidirectionality. - General comments included mostly editorial changes such as replacing references of "filename" to "pathname" where appropriate, using the term "encoding" instead of "character set" when referring to UTF-8, changing "unknown UTF-8 glyphs" to "characters which can not be displayed", clarify temporary error in the pseudo code, and label pseudo code as an example. In addition the general comments included a discussion on the translation examples, the use of Hebrew characters in examples because of the issue of Bi- directional display, references to the obsolete UTF-2 when describing UTF-8, and the efficiency of the `C' code examples. The author noted that most of the comments were reasonable but believed that the Hebrew character examples alerted implementors of the potential need to support bi- directional character display, that reference to UTF-2 helped tie UTF-8 to UTF-2, noted that the `C' code examples closely reflected the algorithm described in ISO 10646, and that further mail list discussion may be needed on these topics. - Comments on the structure of the draft included shortening the document, mentioning the removal of the 7 bit restriction up front, adding a section on backward compatibility, and changing the structure to: General I18N Conformance Server/Client strategies Appendix (containing the examples and `C' code). The author thought that they were all good comments. - A suggestion was made, on the mail list, to reference the draft-weider-iab-char-wrkshop-00.txt in the FTP I18N draft. This ID details the conclusions of the IAB workshop which addressed the use of character sets on the Internet. It recommends that the FTP protocol use a single character set and UTF-8 for transfer, with a fallback position of ASCII. The author pointed out that it also recommended a "negotiated facility" and the ability for clients and servers to negotiate languages for welcome banners, and that the general topic of character set and language content negotiation had been discussed and rejected on the mail list. - The issue of how to support , , and within a pathname was presented. It was noted by the author that although one of the suggestions were to use UTF-8 to solve this problem, that he did not believe that this was an internationalization problem. He also noted that the suggestion to use , as described in RFC 854 (TELNET) might not solve the problem. The two suggestions which seemed to have support on the mail list to address the embedded space problem were to use a telnet like encoding i.e. or to only allow 1 space preceding a pathname. The latter suggestion, while eliminating the need for special encoding, may run the risk of breaking existing implementations. - Comments on display suggested that not all clients supported display, that the draft needed to note that clients were not responsible for displaying all of the ISO 10646 character set, and that a section might be needed in the draft to suggest to clients what to do if they cannot display a character. There is a question concerning whether or not the latter suggestion is really a quality of implementation issue and need not be addressed by the draft. - Comments on Bi-directional display (BIDI) were that the draft did not go into enough detail to adequately address this issue and that the draft should either go into great detail, leave it out, or to use algorithm described in the UNICODE standard. The author's feeling was that the intent of mentioning it in the draft was to alert implementors of the potential problem. It was also pointed out that a string may be display-wise equivalent but not bit-wise equivalent. A discussion followed the presentation. The general topics were how to address the problem of unsupported characters, the `C' code examples, detail of the draft, and content encoding. The question was raised about what a client should do when confronted with a character that it can not display. While it was pointed out by Harald Alvestran that it is unacceptable for a client to discard characters that it can not display, it was felt that because each client has different display characteristics that the decision on how to display them should be left to the implementor. The group felt that the appropriate place for the `C' code examples was in the appendix and that it would be better if the code lined up with the rest of the document. A comment was raised about using UTF-8 on the content of files. Paul noted that this had been discussed on the mail list and felt that any attempt to solve this would have to wait until after the group's other work was done. Paul also noted that this could be harder than any of the group's other work. It was mentioned, in response to the author's earlier comment of balancing enough detail vice references to other documents, that having access to information in FREE RFCs was preferable to having to buy standards from ISO or UNICODE. Paul pointed out that in order to get many of the details it may still be necessary to purchase the base documents. 3. MLST draft. Paul Hethmon presented draft-hethmon-mlst-command-ftp-00.txt concerning a common LIST format to be used by all FTP clients and servers and support for FTP extensions. The main points of discussion during this session were support for a FEAT (Feature) command, the MLST specification, and the associated facts. Paul described the need for the FEAT command to allow clients to retrieve commands which were extensions to RFC 959. He mentioned that support for this command would alleviate the need for the client to send commands, by trial and error, to determine what extensions the server could support. Paul noted that the client could choose to cache these extensions to eliminate the need to send this command each time it connected to frequently used servers. A suggestion was made that a server might use the opening banner to broadcast what extensions it could support, however, it was felt that the opening banner was already too large and that this approach might cause problems for graphical clients. During this discussion it was noted that it was good policy to minimize the number of commands sent to a server and the number of roundtrips required. Keith Moore responded that this could be done by applying piggybacking techniques for commands and responses. Paul then described the MLST specification and the associated facts (size, mtime, ctime, type, uid, perm, scharset). Paul noted that the response to the MLST command was always performed over the control connection and that, unlike LIST and NLST, no data connection was established. It was mentioned by the group that there may be a need to cancel the response and this would only be possible if the response was over the data connection. Paul noted that the next version of the draft would use the control connection as the default but allow use of the data connection as an option. The issue of whether MLST should optionally return fact information was discussed. It was expressed that in some circumstances clients and servers may not want to exchange all of the fact information. Some suggestions on how to return partial fact information were to use the FEAT command, to specify another command to negotiate responses from MLST, or for the client to ask for what it wants and the server send what it can support. Keith noted that TELNET has already gone down the conversational negotiation path and does not suggest that FTP do the same. John Klensin suggested that whatever solution is used there will need to be much stronger conformance rules than exist in the current FTP protocol and must explicitly state how the list of facts are returned by the MLST command. It was also suggested that there may need to be a way to define the end of the MLST command and that we may want to distinguish between facts that were omitted because the server did not send them and those which were omitted because they were not available for the file. It was suggested that the discussion be continued on the mail list. A suggestion was made to name the facts so that they would not be misinterpreted (e.g. ctime, UID, ...). The suggested fact names were size, create, modify, and unique. There was a suggestion that a formal way to specify fact extensions was needed in the draft. It was pointed out that size could not be returned accurately by all operating systems. The question of whether there needs to be an exact size and approximate size fact was raised. The question of how the size fact should handle compressed and uncompressed files was also raised. It was noted that both ctime and mtime were expressed as a 32 bit integer with a negative number expressing time prior to 1970. It was noted that not all clients may be able to support this and that there would be wrap around problem. It was suggested to express time as an ASCII string of YYYYMMDDHHMMSS.ss format. The topic of how to handle spaces inside of unique IDs was discussed. A suggestion was to use quoted strings. Keith suggested that counted strings might be better. He pointed out that they are easy to parse. The discussion on the perm (permission) fact suggested that this might be hard to define. It was noted that it was important to have the ability to change and retrieve from directories but not display them. Keith suggested that parameters should be specified to express how they will work with FTP commands (e.g. CWD, RETR, LIST, ..). A suggestion was made for the server to send back all commands that could be supported or to group commands into common sets. The discussion on the scharset fact noted that there was little support for this feature on the mail list but there was some suggestion that what was needed was a language specification. Paul noted that the scharset fact could by done by extension and could be optional. The scharset discussion spawned a discussion on file content. There was a statement that determining what the file content is by the filename extension was a bad idea and there should be a statement in the draft which states that filenames should not be used to derive content type. Keith warned against HTTP like content negotiation. A suggestion of a Media fact was made. It was suggested that perhaps the server could supply how it determined file content e.g. table, extension, etc. 4. Secure Socket Layer (SSL) draft. A FTP over SSL draft will soon be sent to the mail list. It was suggested that if the control connection was encrypted then the data connection should also be encrypted. It was noted that if the data is already encrypted that this would be additional unneeded overhead and that the connections should be handled independently. The group observed that there was a need to for a simple authentication scheme to avoid sending passwords in the clear. 5. Checkpoint / Restart There was some discussion about the size fact and the support for checkpoint / restart for image mode. David Borman said that he had written a paper documenting the Berkley implementation and promised to place it to the mail list. 6. FTP over IPv6. During the discussion of this draft it was noted that addresses could change during session and that people will not want to type in 16 byte IPv6 addresses. 7. FTP URLs. A brief discussion concerning FTP URLs raised the points that it was not a protocol problem but an implementation problem, and that there would probably be a working group forming to register URLs. The group consensus was that URLs should not be addressed by the FTPEXT working group. 8. RFC 959 Rewrite The question was raised if the working group needed to revisit RFC 959 to make it current and to deprecate unused features such as block mode and EBCDIC. Keith Moore stated that was a possibility but only after the working group finished the current work on its charter. A suggestion was made to develop an informational RFC on common implementation practices. It was felt that such an RFC could be written by an individual and that it did not have to be a working group item. Paul Hethmon phethmon@hethmon.com -- phethmon@utk.edu ------------------------------------------------------------ Inet.Mail Internet Mail Server ------------------------------------------------------------ www.hethmon.com -- ftp.hethmon.com ------------------------------------------------------------