CURRENT_MEETING_REPORT_ Reported by Urs Eppenberger/SWITCH Minutes of the Mail-based File Distribution BOF (MAILFTP) The MAILFTP BOF started with a brainstorming on problems in the area of file transfer which uses e-mail as the transport mechanism. See Table 1 below for a list of the identified issues. A number of tools and protocols were identified which address some of the problems listed. Since the MAILFTP BOF has been triggered by the need to synchronise RFC 1327 and RFC 1465 mapping and routing tables between gateways and mail relays, a list of the specific problems in this area were collected and are reflected in Table 2. Due to limited user need and expert time required, it was concluded that a working group is not needed to solve the open problems in a coherent way. Table 1 - Potential Problems to Solve o File size issues - Splitting - Joining o Automatic updating - Requesting/registering for updates - Automatic handling by recipient - Security o Transfer of entire file system hierarchies o Record structure and other per-file structure information o Application versus OS-specific formats o File properties - Name - Creation, read, modification date - ACLs - Etcetera o Gateway issues (e.g. X.400's FTBP, T.434) o Bulk distribution Table 2 - A Concrete Problem for the Distribution of RFC 1465 Routing Tables and RFC 1327 Mapping Tables o It should be possible to transfer full directory trees o An update mechanism should support the update of single files in that tree, including removing files o There might be many recipients which need the same information o The update should be automated between processes, not users; therefore some safety mechanisms and security mechanisms are needed Detailed Outline o Agenda - List potential problems - History - What do we solve / what is solved - Interest (user/experts) - How to proceed - Requirements (model/implementation) o Potential problems to solve - File size issues * Splitting * Joining - Automatic updating * Requesting/registering for updates * Automatic handling by recipient * Security - Transfer of entire file system hierarchies - Record structure and other per-file structure information - Application versus OS-specific formats - File properties * Name * Creation, read, modification date * ACLs * Etc. - Gateway issues (e.g. X.400's FTBP, T.434) - Bulk distribution o History (existing solutions) - Marko: MFS (used to distribute RFC 1327 tables) - Ned: application/vms-rms MIME content type - John: Uses MIME and UUENCODE, has software that runs on UNIX, DOS, Amiga, and Macintosh - Rick: SIFT (RFC 1440) - Jerome: LISTSERV - CCITT: T.434 (files via facsimile) o Definition of problem - Have a directory tree - Have file updates - Want to distribute the updates to synchronize the files - Should be automatic and (secure/safe) - Lots of recipients - Some of the updates involve removing files o rdist is one existing solution outside the mail domain o There are two classes of systems for this problem: ``push'' and ``pull'' rdist is ``push,'' package and CMU-depot are AFS-based ``pull'' systems. mirror is a ``pull'' system. o Sub-problem of how to represent directories of files. Tar is the only existing solution that works cross-platform. GNU tar has an extension for incremental updates which will remove files. o Marko's system has a plaintext password security mechanism. One could encode such a system in MIME (multipart/security) or even use a stronger system such as PEM. o Marko's system is based on the granularity of files. If one had large files, one might want to allow updating them by distributing differences instead of entirely new files. o Presentation on SIFT - Transitioning from NJE - Non-correspondence file transfer. SIFT is to mail as UPS is to letters - Separate inbox for files and mail - File attribute encoding o Comments on SIFT - now mail is the transport - Plain text mail is the correspondence - non-text MIME is the UPS - Separate inboxes can be handled inside of the mail domain. For example, at CMU, the local-part user+foo can deliver to the ``foo'' inbox belonging to ``user.'' o Insufficient community interest in mail-based synchronization of file trees to warrant further work. Attendees James Conklin jbc@bitnic.educom.edu David Crocker dcrocker@mordor.stanford.edu Urs Eppenberger eppenberger@switch.ch Roger Fajman raf@cu.nih.gov Patrik Faltstrom paf@nada.kth.se Ned Freed ned@innosoft.com Shawn Gillam shawn@timonware.com Terry Gray gray@cac.washington.edu Jeroen Houttuin houttuin@rare.nl Marko Kaittola Marko.Kaittola@funet.fi Lars-Johan Liman liman@ebone.net John Myers jgm+@cmu.edu Rick Troth troth@rice.edu