idnits 2.17.1 draft-costanzo-fs-mime-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...fts are worki...' == Line 11 has weird spacing: '...ments of the ...' == Line 12 has weird spacing: '...t other group...' == Line 16 has weird spacing: '...and may be ...' == Line 20 has weird spacing: '...atus of any ...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 24, 1998) is 9370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 1505 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Costanzo 2 draft-costanzo-fs-mime-00.txt AKC Computer Services Corp. 3 Expires: March 1st, 1999 August 24, 1998 5 Creating File System Object Attachments 6 with MIME 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working doc.- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast, or ftp.isi.edu 24 (US West Coast). 26 Distribution of this memo is unlimited. 28 2. Abstract 30 This memo defines a new top level type for MIME and its subtypes 31 and mappings to file types. 33 The intent of this draft is to both define a new comprehensive top 34 level type and define a method and usage for one of the to be defined 35 subtypes. This new subtype in itself is a media type. The purpose of 36 which provides a mechanism to move a structured set of files system 37 object structures (directories and/or files) as a MIME attachment 38 from one environment to another while preserving common elements. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 42 document are to be interpreted as described in RFC-2119. 44 3. Introduction 46 In creating the conceptual aspects of this draft it was realized that 47 a new top level media type needed to be defined. 49 Costanzo [Page 1] 50 EXPIRES IN SIX MONTHS August 24, 1998 52 Initial thoughts were to create a subtype in the Application top 53 level type. This however seemed not only insufficient but inapplicable 54 as well, since the type to be defined was in fact a media type. 56 Consideration was given to the creation of new top level media 57 type for the specific objects in question, as to define these 58 object types. 60 MIME's requirement for top level media types to have subtypes 61 precluded this concept. The media type that was to be defined 62 was in itself, self contained and had no such requirement for 63 subtype definition. This in itself presented a dilemma. 64 How could this media type structure be defined within MIME? 66 There is in effect a large set of well defined types in a single 67 name space that desperately need to be registered. This name space 68 is "FILE". 70 This top level media type contains some abstract subtypes that have no 71 definitive mapping, whereas others are quite definitive but do not fall 72 well into any current MIME TYPE/subtype. An example of the former being 73 "filename.txt" and an example of the latter being "filename.avi". 75 Defining this top level media type resolves the problem of this draft's 76 subtype in question, "FS". FS as defined in this draft, is a media 77 subtype object of the top level type "FILE". 79 This first draft makes absolutely no attempt to define all the subtypes 80 in FILE. Nor does it attempt to deal with any abstract types as of yet. 81 Let it currently be sufficient to say that FS is a media subtype 82 of an newly defined top level type know as "FILE". 84 The FILE media type is not an attempt to circumvent usage of the other 85 top level MIME types. FILE is in effect supplemental in nature. 86 Types may or may not exist in the other top level types and also exist 87 in FILE. 89 This draft therefore specifies and defines a specific subtype for FILE, 90 namely FS and its file type mappings. 92 The FS (File System) media type specifies a mail part consisting of a 93 file system objects structure. 95 4. The FILE/FS Media Type 97 4.1 Overview 99 The Media Type FS specifies a section or part consisting of a file 100 system media type object. File system media types provide a standard, 101 transportable delivery system from many different operating systems. 103 Costanzo [Page 2] 104 EXPIRES IN SIX MONTHS August 24, 1998 106 The intent is to move a structured set of files from one environment 107 to another while preserving common elements. At the same time, files 108 can be moved within a single environment while preserving all 109 attributes. 111 4.2 Definition of the FS Media Type 113 A FS media type object is a file system object that contains a 114 representation of a file system object or objects. 116 FS media type objects are actually compressed file system object 117 structures. They may be considered as a representation of a file, 118 file structure, directory, directory and its contents and any other 119 file system object that may be supported by a particular disk format. 120 The structure may be thought of as a file archive that would be 121 generated by a program like pkZip or ARJ - the difference being that 122 the actual structure is stored in a format that will survive mail 123 transport without any further modification or transfer encoding 124 being applied. 126 4.3 MIME FS Media Type to File Name Mappings 128 The MIME FS media type always maps to a file with an extension or 129 file hook of `.fs'. Implementors must use the `.fs' file extension. 130 Mail agents that create a FS media type object by some internal 131 functionality, such as drag and drop, should use the file name 132 `default.fs' or some other temporary file name ending with the 133 required `.fs' file hook. 135 4.4 Content-Type-Encoding 137 FS Media type objects have already been encoded and compressed using 138 an encoding algorithm, with the exception of control elements known as 139 "sections". The Content-Type-Encoding for this media type therefore 140 must always be "none". A mailer must not do any additional encoding 141 to a part containing a FS Media type object. 143 In other words Content-Type-Encoding must be ignored or the FS object 144 will no longer be in a valid format. 146 4.5 Character Set 148 FS Media type objects are in UTF-8 character set. [2] [3] 149 This character set must be used. 151 Costanzo [Page 3] 152 EXPIRES IN SIX MONTHS August 24, 1998 154 4.6 Partial or Split Message Parts and Message Boundaries 156 A single FS media type object must be completely contained in a 157 specific message part and must not be split over multiple parts 158 in any fashion. Only one FS media object may be contained in a 159 message part or boundary. 161 If it is desirous to have a split FS object, at least one instance 162 of the complete object must be contained within a message 163 part. 165 4.7 Content Disposition 167 Content Disposition of a FS Media Type object must always be set to 168 `attachment'. 170 4.8 An example of an FS Media Type Object sent via a MIME program: 172 Content-Type: multipart/mixed; 173 boundary="----=_NextPart_000_0099_01BDC836.52F1A800" 175 This is a multi-part message in MIME format. 177 ------=_NextPart_000_0099_01BDC836.52F1A800 178 Content-Type: text/plain; 179 charset="utf-8" 180 Content-Transfer-Encoding: 7bit 182 Hi! I'm sending you my windows directory, it's attached. 183 ----------------------------------------------------- 185 And Remember --- No Matter Where You Go, There You Are... 187 ------=_NextPart_000_0099_01BDC836.52F1A800 188 Content-Type: FILE/fs; 189 charset="utf-8" 190 name="default.fs" 191 Content-Disposition: attachment; 192 filename="default.fs" 193 [ directory windows 194 created 27 Mar 1996 12:17:20.09 195 modified 1 Aug 1998 11:31:04.00 196 [file window~1 197 display "windows Long Filename" 198 created 1 Aug 1998 11:31:05.09 199 modified 1 Aug 1998 11:31:05.09 200 type FLAT 201 [ data LZJU90 202 * LZJU90 203 ... 204 ]]] 206 Costanzo [Page 4] 207 EXPIRES IN SIX MONTHS August 24, 1998 209 ------=_NextPart_000_0099_01BDC836.52F1A800-- 211 5. Creating FS Media Types 213 As mentioned previously, FS media type objects are actually 214 compressed file system object structures stored as a compressed file. 216 They may be considered as a representation of a file, file structure, 217 directory, directory and its contents and any other file system object 218 that may be supported by a particular disk format. The structure may 219 be thought of as a file archive that would be generated by a programs 220 like pkZip, ARJ or Gzip, the difference being that the actual structure 221 is stored in a format that will survive mail transport. 223 The FS media type may be created by a standalone encoder / decoder or 224 any mail program such as Microsoft Outlook Express. FS encoding 225 creates these type objects. See section 5.2. 227 Programs and mailers have been using a version of the FS since the mid 228 1980's. FS was previously defined in RFC 1505 [1]. It is redefined 229 in this Draft. 231 When using a standalone FS encoder program it would be possible 232 to insert the raw data created by the encoder into a mail message, 233 send it to someone with a decoder and successfully reconstruct the 234 file system object(s). 236 MIME mail users must first use a file archive program like Gzip 237 or manually attach file after file to their email. Even more complex 238 is when it is desirous to send complex directory structures. 240 FS encoding solves this by allowing an FS object to be attached 241 directly to an electronic mail messages. 243 5.2 Creating a FS Object using FS Encoding 245 5.2.1 Overview 247 As previously stated, the intent is to move a structured set of 248 files from one environment to another while preserving common 249 elements. At the same time, files can be moved within a single 250 environment while preserving all attributes. 252 The representations consist of a series of nested sections, with 253 attributes defined at the appropriate levels. Each section begins 254 with an open bracket "[" followed by a directive keyword and ends 255 with a close bracket "]". Attributes are lines, beginning with a 256 keyword. Lines which begin with a LWSP (linear white space) 257 character are continuation lines. 259 Costanzo [Page 5] 260 EXPIRES IN SIX MONTHS August 24, 1998 262 Any string-type directive or attribute may be a simple string not 263 starting with a quotation mark ( " ) and not containing special 264 characters (e.g. newline) or LWSP (space and tab). The string name 265 begins with the first non-LWSP character on the line following the 266 attribute or directive keyword and ends with the last non-LWSP 267 character. 269 Otherwise, the character string name is enclosed in quotes. The 270 string itself contains characters in ISO-10646-UTF-8 but is quoted 271 and escaped at octet level (as elsewhere in RFC822). The strings 272 begin and end with a quotation mark ( " ). Octets equal to quote in 273 the string are escaped, as are octets equal to the escape characters 274 (\" and \\). The escaped octets may be part of a UTF multi-octet 275 character. Octets that are not printable are escaped with \nnn octal 276 representation. When an escape (\) occurs at the end of a line, the 277 escape, the end of the line, and the first character of the next 278 line, which must be one of the LWSP characters, are removed 279 (ignored). 281 [ file Simple-File.Name 283 [ file " Long file name starting with spaces and having a couple\ 284 [sic] of nasties in it like this newline\012near the end." 286 Note that in the above example, there is one space (not two) between 287 "couple" and "[sic]". The encoder may choose to use the nnn sequence 288 for any character that might cause trouble. 290 5.3 Sections 292 A section starts with an open bracket, followed by a keyword that 293 defines the type of section. 295 The section keywords are: 297 directory 298 entry 299 file 300 segment 301 data 303 The encoding may start with either a file, directory or entry. A 304 directory section may contain zero or more file, entry, and directory 305 sections. A file section contains a data section or zero or more 306 segment sections. A segment section contains a data section or zero 307 or more segment sections. 309 Costanzo [Page 6] 310 EXPIRES IN SIX MONTHS August 24, 1998 312 5.3.1 Directory 314 This indicates the start of a directory. There is one parameter, the 315 entry name of the directory: 317 [ directory foo 318 ... 319 ] 321 5.3.2 Entry 323 The entry keyword represents an entry in a directory that is not a 324 file or a sub-directory. Examples of entries are soft links in Unix, 325 Microsoft Windows shortcuts or access categories in Primos. 326 A Primos access category might look like this: 328 [ entry SYS.ACAT 329 type ACAT 330 created 27 Jan 1987 15:31:04.00 331 acl SYADMIN:* ARIEL:DALURWX $REST: 332 ] 334 5.3.3 File 336 The file keyword is followed by the entry name of the file. The 337 section then continues with attributes, possibly segments, and then 338 data. 340 [ file MY.FILE 341 created 27 Feb 1987 12:10:20.07 342 modified 27 Mar 1987 16:17:03.02 343 type DAM 344 [ data LZJU90 345 * LZJU90 346 ... 347 ]] 349 5.3.4 Segment 351 This is used to define segments of a file. It should only be used 352 when encoding files that are actually segmented. The optional 353 parameter is the number or name of the segment. 355 When encoding Macintosh files, the two forks of the file are treated 356 as segments: 358 Costanzo [Page 7] 359 EXPIRES IN SIX MONTHS August 24, 1998 361 [ file A.MAC.FILE 362 display "A Mac File" 363 type MAC 364 comment "I created this myself" 365 ... 366 [ segment resource 367 [ data ... 368 ... 369 ]] 370 [ segment data 371 [ data ... 372 ... 373 ]]] 375 5.3.5 Data 377 The data section contains the encoded data of the file. The encoding 378 method shown is defined in a separate Internet Draft. The data section 379 must be last within the containing section. 381 5.4 Attributes 383 Attributes may occur within file, entry, directory, and segment 384 sections. Attributes must occur before sub-sections. 386 The attribute directives are: 388 display 389 type 390 created 391 modified 392 accessed 393 owner 394 group 395 acl 396 password 397 block 398 record 399 application 401 5.4.1 Display 403 This indicates the display name of the object. Some systems, such as 404 the Macintosh, use a different form of the name for matching or 405 uniqueness. Microsoft Windows 95/98 use the attribute to maintain the 406 long filename. 408 Costanzo [Page 8] 409 EXPIRES IN SIX MONTHS August 24, 1998 411 5.4.2 Comment 413 This contains an arbitrary comment on the object. The Macintosh 414 stores this attribute with the file. 416 5.4.3 Type 418 The type of an object is usually of interest only to the operating 419 system that the object was created on. 421 Types are: 423 ACAT access category (Primos) 424 CAM contiguous access method (Primos) 425 DAM direct access method (Primos) 426 FIXED fixed length records (VMS) 427 FLAT `flat file', sequence of bytes (Unix, DOS, default) 428 ISAM indexed-sequential access method (VMS) 429 LINK soft link (Unix), Microsoft Windows shortcut 430 MAC Macintosh file 431 SAM sequential access method (Primos) 432 SEGSAM segmented direct access method (Primos) 433 SEGDAM segmented sequential access method (Primos) 434 TEXT lines of ISO-10646-UTF-8 text ending with CR/LF 435 VAR variable length records (VMS) 437 5.2.4 Created 439 Indicates the creation date of the file. Dates are in the format 440 defined in section 5.3. 442 5.2.5 Modified 444 Indicates the date and time the file was last modified or closed 445 after being open for write. 447 5.2.6 Accessed 449 Indicates the date and time the file was last accessed on the 450 original file system. 452 5.2.7 Owner 454 The owner directive gives the name or numerical ID of the owner or 455 creator of the file. 457 Costanzo [Page 9] 458 EXPIRES IN SIX MONTHS August 24, 1998 460 5.2.8 Group 462 The group directive gives the name(s) or numerical IDs of the group 463 or groups to which the file belongs. 465 5.2.9 ACL 467 This directive specifies the access control list attribute of an 468 object (the ACL attribute may occur more than once within an object). 469 The list consist of a series of pairs of IDs and access codes in the 470 format: 472 user-ID:access-list 474 There are four reserved IDs: 476 $OWNER the owner or creator 477 $GROUP a member of the group or groups 478 $SYSTEM a system administrator 479 $REST everyone else 481 The access list is zero or more single letters: 483 A add (create file) 484 D delete 485 L list (read directory) 486 P change protection 487 R read 488 U use 489 W write 490 X execute 491 * all possible access 493 5.2.10 Password 495 The password attribute gives the access password for this object. 496 Since the content of the object follows (being the raison d'etre of 497 the encoding), the appearance of the password in plain text is not 498 considered a security problem. If the password is actually set by 499 the decoder on a created object, the security (or lack) is the 500 responsibility of the application domain controlling the decoder as 501 is true of ACL and other protections. 503 5.2.11 Block 505 The block attribute gives the block size of the file as a decimal 506 number of bytes. 508 EXPIRES IN SIX MONTHS August 24, 1998 510 5.2.12 Record 512 The record attribute gives the record size of the file as a decimal 513 number of bytes. 515 5.2.13 Application 517 This specifies the application that the file was created with or 518 belongs to. This is of particular interest for Macintosh files. 520 5.3 Date Field 522 Various attributes have a date and time subsequent to and associated 523 with them. 525 5.3.1 Syntax 527 The syntax of the date field is a combination of date, time, and 528 timezone: 530 DD Mon YYYY HH:MM:SS.FFFFFF [+-]HHMMSS 532 Date := DD Mon YYYY 1 or 2 Digits " " 3 Alpha " " 4 Digits 533 DD := Day e.g. "08", " 8", "8" 534 Mon := Month "Jan" | "Feb" | "Mar" | "Apr" | 535 "May" | "Jun" | "Jul" | "Aug" | 536 "Sep" | "Oct" | "Nov" | "Dec" 537 YYYY := Year 538 Time := HH:MM:SS.FFFFFF 2 Digits ":" 2 Digits [ ":" 2 Digits 539 ["." 1 to 6 Digits ] ] 540 e.g. 00:00:00, 23:59:59.999999 541 HH := Hours 00 to 23 542 MM := Minutes 00 to 59 543 SS := Seconds 00 to 60 (60 only during a leap second) 544 FFFFF:= Fraction 545 Zone := [+-]HHMMSS "+" | "-" 2 Digits [ 2 Digits 546 [ 2 Digits ] ] 547 HH := Local Hour Offset 548 MM := Local Minutes Offset 549 SS := Local Seconds Offset 551 5.3.2 Semantics 553 The date information is that which the file system has stored in 554 regard to the file system object. Date information is stored 555 differently and with varying degrees of precision by different 556 computer file systems. An encoder must include as much date 557 information as it has available concerning the file system object. 559 EXPIRES IN SIX MONTHS August 24, 1998 561 A decoder which receives an object encoded with a date field containing 562 greater precision than its own must disregard the excessive 563 information. Zone is Co-ordinated Universal Time "UTC" (formerly 564 called "Greenwich Mean Time"). The field specifies the time zone of 565 the file system object as an offset from Universal Time. It is 566 expressed as a signed [+-] two, four or six digit number. 568 A file that was created April 15, 1993 at 8:05 p.m. in Roselle Park, 569 New Jersey, U.S.A. might have a date field which looks like: 571 15 Apr 1993 20:05:22.12 -0500 573 5.0 Notes to Implementors 575 This section of this draft no way attempts to specify any type of 576 standard. It is merely here as a reference to implementors. NONE 577 of the following section is required to implement the FS media type. 579 5.1 Inter-operablility with non-MIME mail systems and stand alone 580 Encoders/Decoders 582 Standalone FS encoder and decoding programs will be able to 583 decode a FS object sent via electronic mail regardless if that mailer 584 is MIME compliant. The mailer only need be able to support the UTF-8 585 character set. The mail section with the FS object will need to be 586 cut from the messages beginning at the first section control element. 588 Mail messages from a MIME compliant mailers will be successfully 589 translated by non-MIME mailers directly without the need of a 590 standalone decoder that uses an encoding header field but only if the 591 MIME implementation includes the field as well in the mail message, 592 otherwise a standalone encoder/decoder will need to be used. 594 6. Security Consideration 596 The security (or lack) is responsibility of the application domain 597 controlling the decoder of a FS media type object. 599 Expires March 1st, 1999 August 24, 1998 601 7. References 603 [1] Costanzo, A. Robinson, D. and R. Ullmann, "Encoding Header Field 604 for Internet Messages", RFC 1505, AKC Consulting, Prime Computer, 605 Inc., August 1993. 607 [2] International Organization for Standardization, Information 608 Technology -- Universal Coded Character Set (UCS). ISO/IEC 609 10646-1:1993, June 1993. 611 [3] International Organization for Standardization, Information 612 Technology -- Universal Coded Character Set (UCS). ISO/IEC 613 10646-1: 1993/AMD.2: 1996 (E) 615 8. Epilogue 617 It should be noted that the author of this Draft did not participate 618 in the initial design of FS. Intentions exist to create a plug-in 619 implementation for various MIME compliant mailers. The plug-in will 620 allow the transfer of file system directory structures. 622 A definition of the encoding mentioned in this draft may be found 623 in a separate draft titled: "Definition of the LZJU90 MIME Content 624 Transfer Encoding Type". 626 The author is attempting to solicit comments, suggestions and 627 recommendations from the Internet community in general. 629 You may join the File System Attachment discussion list by sending 630 email to: "fsa-request@donet.com", the body of the message must 631 consist of the word: "subscribe". 633 9. Acknowledgments 635 The author would like to thank Robert Jung and David Robinson and 636 Robert Ullmann for their past contributions to this work as well as 637 all of the people who have made suggestions to this current project. 639 10. Authors' Addresses 641 Al Costanzo 642 AKC Computer Services Corp. 643 P.O. Box 4031 644 Roselle Park, NJ 07204-0531 645 Phone: +1 908 298 9000 646 Email: AL@AKC.COM