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 <CR>, <LF>, and <SP> 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 <CR> <NUL>, as described in RFC 854
(TELNET) might not solve the <LF> 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. <SP><NUL> 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
------------------------------------------------------------