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 >
Wrap
Text File
|
1994-02-08
|
5KB
|
175 lines
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