Internet DRAFT - draft-costanzo-fs-mime
draft-costanzo-fs-mime
INTERNET-DRAFT A. Costanzo
draft-costanzo-fs-mime-00.txt AKC Computer Services Corp.
Expires: March 1st, 1999 August 24, 1998
Creating File System Object Attachments
with MIME
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc.-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast, or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited.
2. Abstract
This memo defines a new top level type for MIME and its subtypes
and mappings to file types.
The intent of this draft is to both define a new comprehensive top
level type and define a method and usage for one of the to be defined
subtypes. This new subtype in itself is a media type. The purpose of
which provides a mechanism to move a structured set of files system
object structures (directories and/or files) as a MIME attachment
from one environment to another while preserving common elements.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
3. Introduction
In creating the conceptual aspects of this draft it was realized that
a new top level media type needed to be defined.
Costanzo [Page 1]
EXPIRES IN SIX MONTHS August 24, 1998
Initial thoughts were to create a subtype in the Application top
level type. This however seemed not only insufficient but inapplicable
as well, since the type to be defined was in fact a media type.
Consideration was given to the creation of new top level media
type for the specific objects in question, as to define these
object types.
MIME's requirement for top level media types to have subtypes
precluded this concept. The media type that was to be defined
was in itself, self contained and had no such requirement for
subtype definition. This in itself presented a dilemma.
How could this media type structure be defined within MIME?
There is in effect a large set of well defined types in a single
name space that desperately need to be registered. This name space
is "FILE".
This top level media type contains some abstract subtypes that have no
definitive mapping, whereas others are quite definitive but do not fall
well into any current MIME TYPE/subtype. An example of the former being
"filename.txt" and an example of the latter being "filename.avi".
Defining this top level media type resolves the problem of this draft's
subtype in question, "FS". FS as defined in this draft, is a media
subtype object of the top level type "FILE".
This first draft makes absolutely no attempt to define all the subtypes
in FILE. Nor does it attempt to deal with any abstract types as of yet.
Let it currently be sufficient to say that FS is a media subtype
of an newly defined top level type know as "FILE".
The FILE media type is not an attempt to circumvent usage of the other
top level MIME types. FILE is in effect supplemental in nature.
Types may or may not exist in the other top level types and also exist
in FILE.
This draft therefore specifies and defines a specific subtype for FILE,
namely FS and its file type mappings.
The FS (File System) media type specifies a mail part consisting of a
file system objects structure.
4. The FILE/FS Media Type
4.1 Overview
The Media Type FS specifies a section or part consisting of a file
system media type object. File system media types provide a standard,
transportable delivery system from many different operating systems.
Costanzo [Page 2]
EXPIRES IN SIX MONTHS August 24, 1998
The intent is to move a structured set of files from one environment
to another while preserving common elements. At the same time, files
can be moved within a single environment while preserving all
attributes.
4.2 Definition of the FS Media Type
A FS media type object is a file system object that contains a
representation of a file system object or objects.
FS media type objects are actually compressed file system object
structures. They may be considered as a representation of a file,
file structure, directory, directory and its contents and any other
file system object that may be supported by a particular disk format.
The structure may be thought of as a file archive that would be
generated by a program like pkZip or ARJ - the difference being that
the actual structure is stored in a format that will survive mail
transport without any further modification or transfer encoding
being applied.
4.3 MIME FS Media Type to File Name Mappings
The MIME FS media type always maps to a file with an extension or
file hook of `.fs'. Implementors must use the `.fs' file extension.
Mail agents that create a FS media type object by some internal
functionality, such as drag and drop, should use the file name
`default.fs' or some other temporary file name ending with the
required `.fs' file hook.
4.4 Content-Type-Encoding
FS Media type objects have already been encoded and compressed using
an encoding algorithm, with the exception of control elements known as
"sections". The Content-Type-Encoding for this media type therefore
must always be "none". A mailer must not do any additional encoding
to a part containing a FS Media type object.
In other words Content-Type-Encoding must be ignored or the FS object
will no longer be in a valid format.
4.5 Character Set
FS Media type objects are in UTF-8 character set. [2] [3]
This character set must be used.
Costanzo [Page 3]
EXPIRES IN SIX MONTHS August 24, 1998
4.6 Partial or Split Message Parts and Message Boundaries
A single FS media type object must be completely contained in a
specific message part and must not be split over multiple parts
in any fashion. Only one FS media object may be contained in a
message part or boundary.
If it is desirous to have a split FS object, at least one instance
of the complete object must be contained within a message
part.
4.7 Content Disposition
Content Disposition of a FS Media Type object must always be set to
`attachment'.
4.8 An example of an FS Media Type Object sent via a MIME program:
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0099_01BDC836.52F1A800"
This is a multi-part message in MIME format.
------=_NextPart_000_0099_01BDC836.52F1A800
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Hi! I'm sending you my windows directory, it's attached.
-----------------------------------------------------
And Remember --- No Matter Where You Go, There You Are...
------=_NextPart_000_0099_01BDC836.52F1A800
Content-Type: FILE/fs;
charset="utf-8"
name="default.fs"
Content-Disposition: attachment;
filename="default.fs"
[ directory windows
created 27 Mar 1996 12:17:20.09
modified 1 Aug 1998 11:31:04.00
[file window~1
display "windows Long Filename"
created 1 Aug 1998 11:31:05.09
modified 1 Aug 1998 11:31:05.09
type FLAT
[ data LZJU90
* LZJU90
...
]]]
Costanzo [Page 4]
EXPIRES IN SIX MONTHS August 24, 1998
------=_NextPart_000_0099_01BDC836.52F1A800--
5. Creating FS Media Types
As mentioned previously, FS media type objects are actually
compressed file system object structures stored as a compressed file.
They may be considered as a representation of a file, file structure,
directory, directory and its contents and any other file system object
that may be supported by a particular disk format. The structure may
be thought of as a file archive that would be generated by a programs
like pkZip, ARJ or Gzip, the difference being that the actual structure
is stored in a format that will survive mail transport.
The FS media type may be created by a standalone encoder / decoder or
any mail program such as Microsoft Outlook Express. FS encoding
creates these type objects. See section 5.2.
Programs and mailers have been using a version of the FS since the mid
1980's. FS was previously defined in RFC 1505 [1]. It is redefined
in this Draft.
When using a standalone FS encoder program it would be possible
to insert the raw data created by the encoder into a mail message,
send it to someone with a decoder and successfully reconstruct the
file system object(s).
MIME mail users must first use a file archive program like Gzip
or manually attach file after file to their email. Even more complex
is when it is desirous to send complex directory structures.
FS encoding solves this by allowing an FS object to be attached
directly to an electronic mail messages.
5.2 Creating a FS Object using FS Encoding
5.2.1 Overview
As previously stated, the intent is to move a structured set of
files from one environment to another while preserving common
elements. At the same time, files can be moved within a single
environment while preserving all attributes.
The representations consist of a series of nested sections, with
attributes defined at the appropriate levels. Each section begins
with an open bracket "[" followed by a directive keyword and ends
with a close bracket "]". Attributes are lines, beginning with a
keyword. Lines which begin with a LWSP (linear white space)
character are continuation lines.
Costanzo [Page 5]
EXPIRES IN SIX MONTHS August 24, 1998
Any string-type directive or attribute may be a simple string not
starting with a quotation mark ( " ) and not containing special
characters (e.g. newline) or LWSP (space and tab). The string name
begins with the first non-LWSP character on the line following the
attribute or directive keyword and ends with the last non-LWSP
character.
Otherwise, the character string name is enclosed in quotes. The
string itself contains characters in ISO-10646-UTF-8 but is quoted
and escaped at octet level (as elsewhere in RFC822). The strings
begin and end with a quotation mark ( " ). Octets equal to quote in
the string are escaped, as are octets equal to the escape characters
(\" and \\). The escaped octets may be part of a UTF multi-octet
character. Octets that are not printable are escaped with \nnn octal
representation. When an escape (\) occurs at the end of a line, the
escape, the end of the line, and the first character of the next
line, which must be one of the LWSP characters, are removed
(ignored).
[ file Simple-File.Name
[ file " Long file name starting with spaces and having a couple\
[sic] of nasties in it like this newline\012near the end."
Note that in the above example, there is one space (not two) between
"couple" and "[sic]". The encoder may choose to use the nnn sequence
for any character that might cause trouble.
5.3 Sections
A section starts with an open bracket, followed by a keyword that
defines the type of section.
The section keywords are:
directory
entry
file
segment
data
The encoding may start with either a file, directory or entry. A
directory section may contain zero or more file, entry, and directory
sections. A file section contains a data section or zero or more
segment sections. A segment section contains a data section or zero
or more segment sections.
Costanzo [Page 6]
EXPIRES IN SIX MONTHS August 24, 1998
5.3.1 Directory
This indicates the start of a directory. There is one parameter, the
entry name of the directory:
[ directory foo
...
]
5.3.2 Entry
The entry keyword represents an entry in a directory that is not a
file or a sub-directory. Examples of entries are soft links in Unix,
Microsoft Windows shortcuts or access categories in Primos.
A Primos access category might look like this:
[ entry SYS.ACAT
type ACAT
created 27 Jan 1987 15:31:04.00
acl SYADMIN:* ARIEL:DALURWX $REST:
]
5.3.3 File
The file keyword is followed by the entry name of the file. The
section then continues with attributes, possibly segments, and then
data.
[ file MY.FILE
created 27 Feb 1987 12:10:20.07
modified 27 Mar 1987 16:17:03.02
type DAM
[ data LZJU90
* LZJU90
...
]]
5.3.4 Segment
This is used to define segments of a file. It should only be used
when encoding files that are actually segmented. The optional
parameter is the number or name of the segment.
When encoding Macintosh files, the two forks of the file are treated
as segments:
Costanzo [Page 7]
EXPIRES IN SIX MONTHS August 24, 1998
[ file A.MAC.FILE
display "A Mac File"
type MAC
comment "I created this myself"
...
[ segment resource
[ data ...
...
]]
[ segment data
[ data ...
...
]]]
5.3.5 Data
The data section contains the encoded data of the file. The encoding
method shown is defined in a separate Internet Draft. The data section
must be last within the containing section.
5.4 Attributes
Attributes may occur within file, entry, directory, and segment
sections. Attributes must occur before sub-sections.
The attribute directives are:
display
type
created
modified
accessed
owner
group
acl
password
block
record
application
5.4.1 Display
This indicates the display name of the object. Some systems, such as
the Macintosh, use a different form of the name for matching or
uniqueness. Microsoft Windows 95/98 use the attribute to maintain the
long filename.
Costanzo [Page 8]
EXPIRES IN SIX MONTHS August 24, 1998
5.4.2 Comment
This contains an arbitrary comment on the object. The Macintosh
stores this attribute with the file.
5.4.3 Type
The type of an object is usually of interest only to the operating
system that the object was created on.
Types are:
ACAT access category (Primos)
CAM contiguous access method (Primos)
DAM direct access method (Primos)
FIXED fixed length records (VMS)
FLAT `flat file', sequence of bytes (Unix, DOS, default)
ISAM indexed-sequential access method (VMS)
LINK soft link (Unix), Microsoft Windows shortcut
MAC Macintosh file
SAM sequential access method (Primos)
SEGSAM segmented direct access method (Primos)
SEGDAM segmented sequential access method (Primos)
TEXT lines of ISO-10646-UTF-8 text ending with CR/LF
VAR variable length records (VMS)
5.2.4 Created
Indicates the creation date of the file. Dates are in the format
defined in section 5.3.
5.2.5 Modified
Indicates the date and time the file was last modified or closed
after being open for write.
5.2.6 Accessed
Indicates the date and time the file was last accessed on the
original file system.
5.2.7 Owner
The owner directive gives the name or numerical ID of the owner or
creator of the file.
Costanzo [Page 9]
EXPIRES IN SIX MONTHS August 24, 1998
5.2.8 Group
The group directive gives the name(s) or numerical IDs of the group
or groups to which the file belongs.
5.2.9 ACL
This directive specifies the access control list attribute of an
object (the ACL attribute may occur more than once within an object).
The list consist of a series of pairs of IDs and access codes in the
format:
user-ID:access-list
There are four reserved IDs:
$OWNER the owner or creator
$GROUP a member of the group or groups
$SYSTEM a system administrator
$REST everyone else
The access list is zero or more single letters:
A add (create file)
D delete
L list (read directory)
P change protection
R read
U use
W write
X execute
* all possible access
5.2.10 Password
The password attribute gives the access password for this object.
Since the content of the object follows (being the raison d'etre of
the encoding), the appearance of the password in plain text is not
considered a security problem. If the password is actually set by
the decoder on a created object, the security (or lack) is the
responsibility of the application domain controlling the decoder as
is true of ACL and other protections.
5.2.11 Block
The block attribute gives the block size of the file as a decimal
number of bytes.
Costanzo [Page 10]
EXPIRES IN SIX MONTHS August 24, 1998
5.2.12 Record
The record attribute gives the record size of the file as a decimal
number of bytes.
5.2.13 Application
This specifies the application that the file was created with or
belongs to. This is of particular interest for Macintosh files.
5.3 Date Field
Various attributes have a date and time subsequent to and associated
with them.
5.3.1 Syntax
The syntax of the date field is a combination of date, time, and
timezone:
DD Mon YYYY HH:MM:SS.FFFFFF [+-]HHMMSS
Date := DD Mon YYYY 1 or 2 Digits " " 3 Alpha " " 4 Digits
DD := Day e.g. "08", " 8", "8"
Mon := Month "Jan" | "Feb" | "Mar" | "Apr" |
"May" | "Jun" | "Jul" | "Aug" |
"Sep" | "Oct" | "Nov" | "Dec"
YYYY := Year
Time := HH:MM:SS.FFFFFF 2 Digits ":" 2 Digits [ ":" 2 Digits
["." 1 to 6 Digits ] ]
e.g. 00:00:00, 23:59:59.999999
HH := Hours 00 to 23
MM := Minutes 00 to 59
SS := Seconds 00 to 60 (60 only during a leap second)
FFFFF:= Fraction
Zone := [+-]HHMMSS "+" | "-" 2 Digits [ 2 Digits
[ 2 Digits ] ]
HH := Local Hour Offset
MM := Local Minutes Offset
SS := Local Seconds Offset
5.3.2 Semantics
The date information is that which the file system has stored in
regard to the file system object. Date information is stored
differently and with varying degrees of precision by different
computer file systems. An encoder must include as much date
information as it has available concerning the file system object.
Costanzo [Page 11]
EXPIRES IN SIX MONTHS August 24, 1998
A decoder which receives an object encoded with a date field containing
greater precision than its own must disregard the excessive
information. Zone is Co-ordinated Universal Time "UTC" (formerly
called "Greenwich Mean Time"). The field specifies the time zone of
the file system object as an offset from Universal Time. It is
expressed as a signed [+-] two, four or six digit number.
A file that was created April 15, 1993 at 8:05 p.m. in Roselle Park,
New Jersey, U.S.A. might have a date field which looks like:
15 Apr 1993 20:05:22.12 -0500
5.0 Notes to Implementors
This section of this draft no way attempts to specify any type of
standard. It is merely here as a reference to implementors. NONE
of the following section is required to implement the FS media type.
5.1 Inter-operablility with non-MIME mail systems and stand alone
Encoders/Decoders
Standalone FS encoder and decoding programs will be able to
decode a FS object sent via electronic mail regardless if that mailer
is MIME compliant. The mailer only need be able to support the UTF-8
character set. The mail section with the FS object will need to be
cut from the messages beginning at the first section control element.
Mail messages from a MIME compliant mailers will be successfully
translated by non-MIME mailers directly without the need of a
standalone decoder that uses an encoding header field but only if the
MIME implementation includes the field as well in the mail message,
otherwise a standalone encoder/decoder will need to be used.
6. Security Consideration
The security (or lack) is responsibility of the application domain
controlling the decoder of a FS media type object.
Costanzo [Page 12]
Expires March 1st, 1999 August 24, 1998
7. References
[1] Costanzo, A. Robinson, D. and R. Ullmann, "Encoding Header Field
for Internet Messages", RFC 1505, AKC Consulting, Prime Computer,
Inc., August 1993.
[2] International Organization for Standardization, Information
Technology -- Universal Coded Character Set (UCS). ISO/IEC
10646-1:1993, June 1993.
[3] International Organization for Standardization, Information
Technology -- Universal Coded Character Set (UCS). ISO/IEC
10646-1: 1993/AMD.2: 1996 (E)
8. Epilogue
It should be noted that the author of this Draft did not participate
in the initial design of FS. Intentions exist to create a plug-in
implementation for various MIME compliant mailers. The plug-in will
allow the transfer of file system directory structures.
A definition of the encoding mentioned in this draft may be found
in a separate draft titled: "Definition of the LZJU90 MIME Content
Transfer Encoding Type".
The author is attempting to solicit comments, suggestions and
recommendations from the Internet community in general.
You may join the File System Attachment discussion list by sending
email to: "fsa-request@donet.com", the body of the message must
consist of the word: "subscribe".
9. Acknowledgments
The author would like to thank Robert Jung and David Robinson and
Robert Ullmann for their past contributions to this work as well as
all of the people who have made suggestions to this current project.
10. Authors' Addresses
Al Costanzo
AKC Computer Services Corp.
P.O. Box 4031
Roselle Park, NJ 07204-0531
Phone: +1 908 298 9000
Email: AL@AKC.COM
Costanzo [Page 13]
