idnits 2.17.1 draft-ietf-acap-mediatype-00.txt: 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-16) 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 Introduction section. ** 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 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([MIME-IMT], [MAILCAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 1997) is 9772 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) == Missing Reference: 'ACAP' is mentioned on line 113, but not defined == Unused Reference: 'BASIC-URL' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'IMAP4' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'REL-URL' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'UTF8' is defined on line 435, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1738 (ref. 'BASIC-URL') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 822 (ref. 'IMAIL') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Downref: Normative reference to an Informational RFC: RFC 1524 (ref. 'MAILCAP') ** Obsolete normative reference: RFC 2048 (ref. 'MIME-REG') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 1808 (ref. 'REL-URL') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2044 (ref. 'UTF8') (Obsoleted by RFC 2279) Summary: 17 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: ACAP Media Type Dataset Class Innosoft 4 Document: draft-ietf-acap-mediatype-00.txt July 1997 5 Expires in six months 7 ACAP Media Type Dataset Class 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 With the definition of standardized media types in MIME [MIME-IMT] 31 it has become necessary to keep mapping tables which translate 32 between the standard media type names, commonly used file name 33 extensions, any platform specific typing mechanism, and helper 34 applications to view, compose, edit or print media types. 35 Supplying a set of site defaults is useful so that users won't have 36 to configure well-known types. The mailcap mechanism [MAILCAP] 37 provides some of this functionality in a homogenous environment 38 with a shared filesystem, and the Macintosh program "Internet 39 Config" has had success in consolidating these tables for multiple 40 applications on a single machine. But neither of these addresses 41 the problems of multi-platform users or a heterogenous environment. 43 ACAP provides precisely the right facilities for this need. ACAP's 44 dataset structure is extensible, and ACAP's inheritance feature is 45 ideal for enterprise default settings with per-user customization. 47 Table of Contents 49 Status of this memo ............................................... i 50 Abstract .......................................................... i 51 0. Open Issues .................................................. 1 52 1. Conventions used in this document ............................ 1 53 2. ACAP Media Type Dataset Class ................................ 1 54 2.1. ACAP Media Type Dataset Class Prefix ......................... 1 55 2.3. ACAP Media Type Dataset Hierarchy ............................ 1 56 3. Recommended ACAP Media Type Attributes ....................... 1 57 3.1. Basic Attributes ............................................. 1 58 3.2. System independent attributes ................................ 2 59 3.3. MacOS related attributes ..................................... 4 60 3.4. Unix Related Attributes ...................................... 5 61 3.5. Windows 95/NT Related Attributes ............................. 7 62 3.5. Windows 3.1 Related Attributes ............................... 7 63 5. Examples ..................................................... 8 64 6. Security Considerations ...................................... 8 65 7. References ................................................... 8 66 8. Author's Address ............................................. 9 67 Appendix .......................................................... 10 68 A. Attribute Index .............................................. 10 69 0. Open Issues 71 1) Can someone else do the Windows sections? I'm not familiar with 72 the platforms. 74 1. Conventions used in this document 76 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 77 NOT", "OPTIONAL", and "MAY" in this document are to be interpreted 78 as described in "Key words for use in RFCs to Indicate Requirement 79 Levels" [KEYWORDS]. 81 The attribute syntax specifications use the Augmented Backus-Naur 82 Form (ABNF) notation as specified in [IMAIL]. 84 2. ACAP Media Type Dataset Class 86 2.1. ACAP Media Type Dataset Class Prefix 88 Datasets whose names begin with "/mediatype" are assumed to contain 89 mediatype entries as defined in this specification. 91 2.3. ACAP Media Type Dataset Hierarchy 93 Each user may have a set of named media type profiles for use on 94 different hosts. The default is "default" and is referenced with 95 the path "/mediatype/user//default/". Inheritance is 96 likely to be useful both for inheriting site or group defaults as 97 well as for inheriting the default configuration when using 98 different hosts. 100 3. Recommended ACAP Media Type Attributes 102 A mediatype entry MUST have an "entry" attribute. All other 103 attributes are OPTIONAL. 105 The ABNF defines the content of the attribute values prior to their 106 encoding as an ACAP string. Clients MUST conform to the syntax 107 when generating these attributes, but MUST NOT assume that the 108 attribute values will conform to this syntax on access. Servers 109 MUST NOT enforce the syntax. 111 3.1. Basic Attributes 113 These attributes are defined in ACAP [ACAP] and have meaning in all 114 dataset classes. The section describes how they are used in an 115 mediatype dataset. 117 entry 118 The "entry" attribute is used to hold a descriptive name of 119 the media type. This name is used for inheritance, so when 120 customizing a media type which has an entry in an inherited 121 dataset, the entry name needs to remain the same. 123 subdataset 124 The "subdataset" attribute indicates there is another media 125 type dataset underneath this entry. 127 3.2. System independent attributes 129 These attributes are likely to have meaning for all ACAP clients. 131 mediatype.common.type 132 This is a multi-valued attribute which contains the MIME media 133 type(s) [MIME-IMT] of the entry. It may include type 134 parameters (such parameters should be canonicalized by 135 removing unnecessary quoting and converting to lower case to 136 simplify lookups). New MIME media types are registered 137 according to the MIME registration procedures [MIME-REG]. 139 The terminals type, subtype and parameter are defined in MIME 140 Internet Message Bodies [MIME-IMB]. Free insertion of 141 linear-white-space is not permitted in this grammar. 143 A subtype of "*" indicates a catch-all entry for a type. 144 Clients SHOULD check for a catch-all entry after checking for 145 a regular entry. 147 mtype-typenam = type "/" mtype-subtype *(";" SPACE parameter) 149 mtype-subtype = subtype / "*" 151 mediatype.common.extension 152 This is a multi-valued attribute which contains the file name 153 extension(s) that are commonly associated with this media 154 type. For example, with JPEG files (image/jpeg), a number of 155 extensions have been observed: "jpg", "jpeg", "jfif", "jpe", 156 and "jfi". Extensions should be converted to lower case to 157 simplify searching. 159 mtype-ext = 1*ATOM-CHAR 161 mediatype.common.magicNumber.bin 162 This contains the magic number(s) of the media type. A magic 163 number is a set of octets at the beginning of the file which 164 are always the same for that media type. For example, all 165 image/gif objects begin with the four-octet sequence (71, 73, 166 70, 56 or "GIF8"). As this is a binary field, it may contain 167 any octet value including 0. This can be used to attempt to 168 locate a type for an untyped file. 170 mtype-magic = 1*OCTET 172 mediatype.common.textualNewlines 173 If this is "1" it indicates that the media type is line 174 oriented and subject to newline canonicalization. If this is 175 "0" it indicates newlines should be preserved. If NIL, the 176 client should default this to "0" for non-text types and "1" 177 for text types. 179 mtype-text = "0" / "1" 181 mediatype.common.description 182 This is a longer textual description of the mediatype. 184 mtype-desc = *UTF8-CHAR 186 mediatype.common.securityRisk 187 This contains a token indicating an estimate of the security 188 risks of the media type. This is likely to be set by a site 189 administrator. Applications SHOULD consult the security risk 190 field before taking action on an attachment and SHOULD NOT 191 launch applications other than "probably-safe" ones without 192 querying the user. 194 The levels are "probably-safe", meaning there aren't any known 195 or suspected problems and the media type is not extensible. 196 audio/basic falls in this category. "probably-safe-but- 197 extensible" meaning there aren't any known or suspected 198 problems but the media type is extensible and an extension may 199 result in security problems. image/jpeg falls into this 200 category. "caution" means the media type can cause damage in 201 limited circumstances. text/plain falls in this category 202 since if they are displayed on a powerful terminal embedded 203 escape sequences could reprogram the keyboard or otherwise 204 generate dangerous simulated user input. "caution-extensible" 205 means the media type is at the caution level, but could be 206 extended to add further damage. text/enriched falls into this 207 category. "danger" indicates the type has dangerous functions 208 which can be used to destroy data and must be executed in a 209 safe environment or the sender must be trusted. 210 application/postscript falls into this category due to it's 211 file operators. text/html falls into this category due to the 212 numerous security problems it continues to have from 213 proprietary extensions. Finally, "embedded" means the type is 214 an encapsulating type which inherits risks from the type 215 embedded within it. application/applefile falls into this 216 category. 218 When this is NIL, clients SHOULD assume "unknown". 220 mtype-risk = "probably-safe" / "probably-safe-but-extensible" / 221 "caution" / "caution-but-extensible" / "danger" / 222 "embedded" / "unknown" 224 3.3. MacOS related attributes 226 These are attributes which apply to MacOS systems. 228 mediatype.macOS.type.bin 229 This contains the 4-octet MacOS type code for this media type. 231 mtype-mactype = 4OCTET 233 mediatype.macOS.creator.bin 234 This contains the 4-octet MacOS creator code which the user 235 prefers for use with documents of this type. 237 mtype-maccreat = 4OCTET 239 mediatype.macOS.postProcess.bin 240 This contains the 4-octet MacOS creator code of an application 241 which the user wishes to use when post-processing documents of 242 this type. If NIL, then no post-processing is required. This 243 is primarily used for encapsulating formats such as 244 application/applefile. 246 mtype-macpost = 4OCTET 248 mediatype.macOS.creatorName 249 This contains the filename of the application whose creator 250 code is stored in mediatype.MacOS.creator.bin. This value 251 MUST be UTF-8 and not in a MacOS internal character set. 253 mtype-maccname = 1*UTF8-CHAR 255 mediatype.macOS.postProcessName 256 This contains the filename of the application whose creator 257 code is stored in mediatype.MacOS.postProcess.bin. This value 258 MUST be UTF-8 and not in a MacOS internal character set. 260 mtype-macpname = 1*UTF8-CHAR 262 mediatype.macOS.alwaysUseHelper 263 If this is non-NIL, it states a user preference to use the 264 specified helper application rather than any internal viewer 265 contained in the dispatching application. 267 mtype-macalways = "1" 269 3.4. Unix Related Attributes 271 These attributes are used to launch unix helper applications 272 similar to the mailcap [MAILCAP] mechanism. 274 When a client executes a Unix command line helpers it runs under 275 the Bourne shell (usually by using the system() function call). 276 Prior to execution, the client SHOULD perform the following 277 substitutions into the command line: the string "%s" is replaced by 278 a temporary file name for the body part or MIME part (if %s is 279 absent, the body part or MIME part is passed through standard 280 input). The string "%t" is replaced by the media type and subtype, 281 the string "%{}" is replaced by the media type parameter 282 with name . The character "%" is quoted with "\%". By 283 default, multi-part types are left intact with MIME headers prior 284 to dispatching. A dispatching application MAY support the %n and 285 %F options of mailcap [MAILCAP] for backwards compatibility. 287 mediatype.unix.viewer 288 This contains a command to execute a viewer for the media 289 type. 291 mtype-unixview = *UTF8-CHAR 293 mediatype.unix.viewerMIME 294 If this is non-NIL it indicates that the viewer uses MIME 295 entities (with complete headers) rather than body parts. 297 mtype-unixvmime = "1" 299 mediatype.unix.composer 300 This contains a command to execute a program to compose a new 301 body part of the specified media type. If not set, it is 302 assumed to be the same as mediatype.unix.editor. 304 mtype-unixcomp = *UTF8-CHAR 306 mediatype.unix.composerMIME 307 If this is non-NIL it indicates that the composer uses MIME 308 entities (with complete headers) rather than body parts. 310 mtype-unixcmime = "1" 312 mediatype.unix.editor 313 This contains a command to execute a program to edit body 314 parts of the specified media type. If not set, it is assumed 315 to be the same as mediatype.unix.viewer. 317 mtype-unixedit = *UTF8-CHAR 319 mediatype.unix.editorMIME 320 If this is non-NIL it indicates that the editor uses MIME 321 entities (with complete headers) rather than body parts. 323 mtype-unixemime = "1" 325 mediatype.unix.print 326 This contains a command to print a body part of the specified 327 type. 329 mtype-unixprint = *UTF8-CHAR 331 mediatype.unix.printMIME 332 If this is non-NIL it indicates that the print command uses 333 MIME entities (with complete headers) rather than body parts. 335 mtype-unixpmime = "1" 337 mediatype.unix.output 338 This indicates any output assistance which the viewer command 339 needs. The "terminal" option indicates an interactive 340 terminal is needed and the dispatcher should create a terminal 341 window or the equivalent. The "pager" option indicates the 342 output may be more than 24 lines and the viewer does not have 343 a built-in pager. 345 mtype-unixout = "terminal" / "pager" 347 mediatype.unix.alwaysUseHelper 348 If this is non-NIL, it states a user preference to use the 349 specified helper application rather than any internal viewer 350 contained in the dispatching application. 352 mtype-unixalways = "1" 354 3.5. Windows 95/NT Related Attributes 356 mediatype.win32.viewer 358 mediatype.win32.editor 360 mediatype.win32.alwaysUseHelper 362 3.5. Windows 3.1 Related Attributes 364 These attributes are specific to Windows 3.1 machines. If these 365 are not present, then the mediatype.win32.* attributes may be used 366 instead. 368 mediatype.win31.viewer 370 mediatype.win31.editor 371 mediatype.win31.alwaysUseHelper 373 5. Examples 375 TODO 377 6. Security Considerations 379 Security considerations for launching helper applications for media 380 types are discussed in the section for the 381 mediatype.common.securityRisk attribute. 383 7. References 385 [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource 386 Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of 387 Minnesota, December 1994. 389 391 [IMAIL] Crocker, D., "Standard for the Format of ARPA Internet Text 392 Messages", STD 11, RFC 822, University of Delaware, August 1982. 394 396 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 397 4rev1", RFC 2060, University of Washington, December 1996. 399 401 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 402 Requirement Levels", RFC 2119, Harvard University, March 1997. 404 406 [MAILCAP] Borenstein, "A User Agent Configuration Mechanism For 407 Multimedia Mail Format Information", RFC 1524, Bellcore, September 408 1993. 410 412 [MIME-IMB] Freed, Borenstein, "Multipurpose Internet Mail 413 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 414 2045, Innosoft, First Virtual, November 1996. 416 418 [MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail 419 Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First 420 Virtual, November 1996. 422 424 [MIME-REG] Freed, Klensin, Postel, "Multipurpose Internet Mail 425 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 426 Innosoft, MCI, ISI, November 1996. 428 430 [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808, 431 UC Irvine, June 1995. 433 435 [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and 436 ISO 10646", RFC 2044, Alis Technologies, October 1996. 438 440 8. Author's Address 442 Chris Newman 443 Innosoft International, Inc. 444 1050 Lakes Drive 445 West Covina, CA 91790 USA 447 Email: chris.newman@innosoft.com 449 Appendix 451 A. Attribute Index 453 entry ...................................................... 2 454 mediatype.common.description ............................... 3 455 mediatype.common.extension ................................. 2 456 mediatype.common.magicNumber.bin ........................... 3 457 mediatype.common.securityRisk .............................. 3 458 mediatype.common.textualNewlines ........................... 3 459 mediatype.common.type ...................................... 2 460 mediatype.macOS.alwaysUseHelper ............................ 5 461 mediatype.macOS.creator.bin ................................ 4 462 mediatype.macOS.creatorName ................................ 5 463 mediatype.macOS.postProcess.bin ............................ 4 464 mediatype.macOS.postProcessName ............................ 5 465 mediatype.macOS.type.bin ................................... 4 466 mediatype.unix.alwaysUseHelper ............................. 7 467 mediatype.unix.composer .................................... 6 468 mediatype.unix.composerMIME ................................ 6 469 mediatype.unix.editor ...................................... 6 470 mediatype.unix.editorMIME .................................. 6 471 mediatype.unix.output ...................................... 7 472 mediatype.unix.print ....................................... 6 473 mediatype.unix.printMIME ................................... 6 474 mediatype.unix.viewer ...................................... 5 475 mediatype.unix.viewerMIME .................................. 6 476 mediatype.win31.alwaysUseHelper ............................ 8 477 mediatype.win31.editor ..................................... 7 478 mediatype.win31.viewer ..................................... 7 479 mediatype.win32.alwaysUseHelper ............................ 7 480 mediatype.win32.editor ..................................... 7 481 mediatype.win32.viewer ..................................... 7 482 subdataset ................................................. 2