home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93nov / mailftp-minutes-93nov.txt < prev    next >
Text File  |  1994-02-08  |  5KB  |  175 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Urs Eppenberger/SWITCH
  5.  
  6. Minutes of the Mail-based File Distribution BOF (MAILFTP)
  7.  
  8. The MAILFTP BOF started with a brainstorming on problems in the area of
  9. file transfer which uses e-mail as the transport mechanism.  See Table 1
  10. below for a list of the identified issues.  A number of tools and
  11. protocols were identified which address some of the problems listed.
  12.  
  13. Since the MAILFTP BOF has been triggered by the need to synchronise
  14. RFC 1327 and RFC 1465 mapping and routing tables between gateways and
  15. mail relays, a list of the specific problems in this area were collected
  16. and are reflected in Table 2.
  17.  
  18. Due to limited user need and expert time required, it was concluded that
  19. a working group is not needed to solve the open problems in a coherent
  20. way.
  21.  
  22.  
  23. Table 1 - Potential Problems to Solve
  24.  
  25.    o File size issues
  26.  
  27.       -  Splitting
  28.       -  Joining
  29.  
  30.    o Automatic updating
  31.  
  32.       -  Requesting/registering for updates
  33.       -  Automatic handling by recipient
  34.       -  Security
  35.  
  36.    o Transfer of entire file system hierarchies
  37.    o Record structure and other per-file structure information
  38.    o Application versus OS-specific formats
  39.    o File properties
  40.  
  41.       -  Name
  42.       -  Creation, read, modification date
  43.       -  ACLs
  44.       -  Etcetera
  45.  
  46.    o Gateway issues (e.g.  X.400's FTBP, T.434)
  47.    o Bulk distribution
  48.  
  49.  
  50. Table 2 - A Concrete Problem for the Distribution of RFC 1465 Routing
  51. Tables and RFC 1327 Mapping Tables
  52.  
  53.    o It should be possible to transfer full directory trees
  54.  
  55.    o An update mechanism should support the update of single files in
  56.      that tree, including removing files
  57.  
  58.    o There might be many recipients which need the same information
  59.  
  60.    o The update should be automated between processes, not users;
  61.      therefore some safety mechanisms and security mechanisms are needed
  62.  
  63.  
  64.  
  65. Detailed Outline
  66.  
  67.    o Agenda
  68.  
  69.       -  List potential problems
  70.       -  History
  71.       -  What do we solve / what is solved
  72.       -  Interest (user/experts)
  73.       -  How to proceed
  74.       -  Requirements (model/implementation)
  75.  
  76.  
  77.    o Potential problems to solve
  78.  
  79.       -  File size issues
  80.           * Splitting
  81.           * Joining
  82.       -  Automatic updating
  83.           * Requesting/registering for updates
  84.           * Automatic handling by recipient
  85.           * Security
  86.       -  Transfer of entire file system hierarchies
  87.       -  Record structure and other per-file structure information
  88.       -  Application versus OS-specific formats
  89.       -  File properties
  90.           * Name
  91.           * Creation, read, modification date
  92.           * ACLs
  93.           * Etc.
  94.       -  Gateway issues (e.g.  X.400's FTBP, T.434)
  95.       -  Bulk distribution
  96.  
  97.  
  98.    o History (existing solutions)
  99.  
  100.       -  Marko:  MFS (used to distribute RFC 1327 tables)
  101.       -  Ned:  application/vms-rms MIME content type
  102.       -  John:  Uses MIME and UUENCODE, has software that runs on UNIX,
  103.          DOS, Amiga, and Macintosh
  104.       -  Rick:  SIFT (RFC 1440)
  105.       -  Jerome:  LISTSERV
  106.       -  CCITT: T.434 (files via facsimile)
  107.  
  108.  
  109.    o Definition of problem
  110.  
  111.       -  Have a directory tree
  112.       -  Have file updates
  113.       -  Want to distribute the updates to synchronize the files
  114.       -  Should be automatic and (secure/safe)
  115.       -  Lots of recipients
  116.       -  Some of the updates involve removing files
  117.  
  118.  
  119.    o rdist is one existing solution outside the mail domain
  120.  
  121.    o There are two classes of systems for this problem:  ``push'' and
  122.      ``pull'' rdist is ``push,'' package and CMU-depot are AFS-based
  123.      ``pull'' systems.  mirror is a ``pull'' system.
  124.  
  125.    o Sub-problem of how to represent directories of files.  Tar is the
  126.      only existing solution that works cross-platform.  GNU tar has an
  127.      extension for incremental updates which will remove files.
  128.  
  129.    o Marko's system has a plaintext password security mechanism.  One
  130.      could encode such a system in MIME (multipart/security) or even use
  131.      a stronger system such as PEM.
  132.  
  133.    o Marko's system is based on the granularity of files.  If one had
  134.      large files, one might want to allow updating them by distributing
  135.      differences instead of entirely new files.
  136.  
  137.    o Presentation on SIFT
  138.  
  139.       -  Transitioning from NJE
  140.       -  Non-correspondence file transfer.  SIFT is to mail as UPS is to
  141.          letters
  142.       -  Separate inbox for files and mail
  143.       -  File attribute encoding
  144.  
  145.  
  146.    o Comments on SIFT - now mail is the transport
  147.  
  148.       -  Plain text mail is the correspondence
  149.       -  non-text MIME is the UPS
  150.       -  Separate inboxes can be handled inside of the mail domain.  For
  151.          example, at CMU, the local-part user+foo can deliver to the
  152.          ``foo'' inbox belonging to ``user.''
  153.  
  154.  
  155.    o Insufficient community interest in mail-based synchronization of
  156.      file trees to warrant further work.
  157.  
  158.  
  159. Attendees
  160.  
  161. James Conklin            jbc@bitnic.educom.edu
  162. David Crocker            dcrocker@mordor.stanford.edu
  163. Urs Eppenberger          eppenberger@switch.ch
  164. Roger Fajman             raf@cu.nih.gov
  165. Patrik Faltstrom         paf@nada.kth.se
  166. Ned Freed                ned@innosoft.com
  167. Shawn Gillam             shawn@timonware.com
  168. Terry Gray               gray@cac.washington.edu
  169. Jeroen Houttuin          houttuin@rare.nl
  170. Marko Kaittola           Marko.Kaittola@funet.fi
  171. Lars-Johan Liman         liman@ebone.net
  172. John Myers               jgm+@cmu.edu
  173. Rick Troth               troth@rice.edu
  174.  
  175.