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