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