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]