idnits 2.17.1 draft-ietf-fax-tiff-reg-05.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-26) 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 6 months document validity. ** 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 == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 105 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([TIFF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 314 has weird spacing: '... of the value...' -- 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 (February 13, 1998) is 9569 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) == Unused Reference: 'MIME4' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'TIFFPLUS' is defined on line 286, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2048 (ref. 'MIME4') (Obsoleted by RFC 4288, RFC 4289) -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFFPLUS' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Glenn Parsons 3 Internet Draft James Rafferty 4 Expires in six months Stephen Zilles 5 February 13, 1998 7 Tag Image File Format (TIFF) - image/tiff 8 MIME Sub-type Registration 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet Drafts as reference material or to 22 cite them other than as a "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Overview 32 This document describes the registration of the MIME sub-type 33 image/tiff. The baseline encoding is defined by [TIFF]. 35 Internet Fax Working Group 37 This document is a product of the IETF Internet Fax Working Group. 38 All comments on this document should be forwarded to the email 39 distribution list at . 41 1. Abstract 43 This document describes the registration of the MIME sub-type 44 image/tiff. The baseline encoding is defined by [TIFF]. This 45 document refines an earlier sub-type registration in RFC 1528 46 [TPC.INT]. 48 2. TIFF Definition 50 TIFF (Tag Image File Format) Revision 6.0 is defined in detail by 51 Adobe in [TIFF]. The documentation can be obtained from Adobe at: 53 Adobe Developers Association 54 Adobe Systems Incorporated 55 345 Park Avenue 56 San Jose, CA 95110-2704 58 Phone: +1-408-536-6000 59 Fax: +1-408-537-6000 61 A copy of this specification can also be found in: 62 ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/ 63 tiff6.pdf 65 While a brief scope and feature description is provided in this 66 section as background information, the reader is directed to the 67 original TIFF specification [TIFF] to obtain complete feature and 68 technical details. 70 2.1 TIFF Scope 72 TIFF describes image data that typically comes from scanners, frame 73 grabbers, and paint- and photo-retouching programs. TIFF is not a 74 printer language or page description language. The purpose of TIFF 75 is to describe and store raster image data. A primary goal of TIFF 76 is to provide a rich environment within which applications can 77 exchange image data. This richness is required to take advantage of 78 the varying capabilities of scanners and other imaging devices. 79 Though TIFF is a rich format, it can easily be used for simple 80 scanners and applications as well because the number of required 81 fields is small. 83 2.2 TIFF Features 85 Some of the features of TIFF (from [TIFF]) are: 87 - TIFF is capable of describing bilevel, grayscale, palette-color, 88 and full-color image data in several color spaces. 90 - TIFF includes a number of compression schemes that allow 91 developers to choose the best space or time tradeoff for their 92 applications. 94 - TIFF is designed to be extensible and to evolve gracefully as new 95 needs arise. 97 - TIFF allows the inclusion of an unlimited amount of private or 98 special-purpose information. 100 3. MIME Definition 102 3.1 image/tiff 104 The image/tiff content-type was previously defined in RFC 1528 as 105 containing TIFF 6.0 encoded image data, with specific reference 106 made to a subset known as TIFF Class F. This document re-defines 107 the original image/tiff definition to refer to all of the profiles 108 and extensions that build on TIFF 6.0 [TIFF] encoded image data, 109 consistent with existing practice for TIFF aware Internet 110 applications. This definition is further enhanced by introducing 111 the new "application parameter" (section 3.2) to enable 112 identification of a specific subset of TIFF and TIFF extensions 113 for the encoded image data. 115 3.2 Application parameter 117 There are cases where it may be useful to identify the application 118 applicable to the content of an image/tiff body. Typically, this 119 would be used to assist the recipient in dispatching a suitable 120 rendering package to handle the display or processing of the image 121 file. As a result, an optional "application" parameter is defined 122 for image/tiff to identify a particular application's subset of 123 TIFF and TIFF extensions for the encoded image data, if it is 124 known. No values are defined in this document. 126 Example: 128 Content-type: image/tiff; application=foo 130 There is no default value for application, as the absence of the 131 application parameter indicates that the encoded TIFF image is 132 Baseline TIFF or that it is not necessary to identify the 133 application. It is up to the recipient's implementation to 134 determine the application (if necessary) and render the image to 135 the user. 137 4. IANA Registration 139 To: ietf-types@iana.org 140 Subject: Registration of Standard MIME media type image/tiff 142 MIME media type name: image 144 MIME subtype name: tiff 146 Required parameters: none 148 Optional parameters: application 150 There is no format specified for the value of this parameter 151 in addition to that specified by [MIME1]. Various 152 applications of TIFF may define values as required. . New 153 values should be defined in standards track RFCs and the 154 values should be registered with IANA, using the 155 registration form included in Appendix A. There is no 156 default value for application, as the absence of the 157 application parameter indicates that the encoded TIFF image 158 is Baseline TIFF or that it is not necessary to identify the 159 application. It is up to the implementation to determine 160 the application (if necessary) and render the image to the 161 user. 163 Encoding considerations: Binary or Base-64 generally preferred 165 Security considerations: 167 TIFF utilizes a structure which can store image data and 168 attributes of this image data. The fields defined in the 169 TIFF specification are of a descriptive nature and provide 170 information that is useful to facilitate viewing and 171 rendering of images by a recipient. As such, the fields 172 currently defined in the TIFF specification do not in 173 themselves create additional security risks, since the 174 fields are not used to induce any particular behavior by 175 the recipient application. 177 TIFF has an extensible structure, so that it is 178 theoretically possible that fields could be defined in the 179 future which could be used to induce particular actions on 180 the part of the recipient, thus presenting additional 181 security risks, but this type of capability is not 182 supported in the referenced TIFF specification. Indeed, the 183 definition of fields which would include such processing 184 instructions is inconsistent with the goals and spirit of 185 the TIFF specification. 187 Interoperability considerations: 189 The ability of implementations to handle all the defined 190 applications (or profiles within applications) of TIFF may 191 not be ubiquitous. As a result, implementations may decode 192 and attempt to display the encoded TIFF image data only to 193 determine that the image cannot be rendered. The presence 194 of the application parameter may aid in allowing this 195 determination before dispatching for rendering. However, it 196 should be noted that the parameter value is not intended to 197 convey levels of capabilities for a particular application. 199 Published specification: 201 TIFF (Tag Image File Format) is defined in: 202 TIFF (TM) Revision 6.0 - Final - June 3, 1992 204 Adobe Developers Association 205 Adobe Systems Incorporated 206 345 Park Avenue 207 San Jose, CA 95110-2704 209 Phone: +1-408-536-6000 210 Fax: +1-408-537-6000 212 A copy of this specification can be found in: 213 ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdff 214 iles/tiff6.pdf 216 Applications which use this media type: 218 Imaging, fax, messaging and multi-media 220 Additional information: 222 Magic number(s): 223 II (little-endian): 49 49 42 00 hex 224 MM (big-endian): 4D 4D 00 42 hex 225 File extension(s): .TIF 226 Macintosh File Type Code(s): TIFF 228 Person & email address to contact for further information: 230 Glenn W. Parsons 231 Glenn.Parsons@Nortel.ca 233 James Rafferty 234 Jrafferty@worldnet.att.net 236 Stephen Zilles 237 szilles@adobe.com 239 Intended usage: COMMON 241 Change controller: Stephen Zilles 243 5. Authors' Addresses 245 Glenn W. Parsons 246 Northern Telecom 247 P.O. Box 3511, Station C 248 Ottawa, ON K1Y 4H7 249 Canada 250 Phone: +1-613-763-7582 251 Fax: +1-613-763-2697 252 Email: Glenn.Parsons@Nortel.ca 254 James Rafferty 255 Human Communications 256 12 Kevin Drive 257 Danbury, CT 06811-2901 258 USA 259 Phone: +1-203-746-4367 260 Fax: +1-203-746-4367 261 Email: Jrafferty@worldnet.att.net 263 Stephen Zilles 264 Adobe Systems Inc. 265 Mailstop W14 266 345 Park Avenue 267 San Jose, CA 95110-2704 268 USA 269 Voice: +1-408-536-4766 270 Fax: +1-408-536-4042 271 Email: szilles@adobe.com 273 6. References 275 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail 276 Extensions (MIME) Part One: Format of Internet Message Bodies", 277 RFC 2045, Innosoft, First Virtual, Nov 1996 278 [MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail 279 Extensions (MIME) Part Four: Registration Procedures", RFC 280 2048, Innosoft, First Virtual, Nov 1996. 281 [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final, 282 June 3, 1992. 283 [TPC.INT] C. Malamud, M. Rose, "Principles of Operation for the 284 TPC.INT Subdomain: Remote Printing -- Technical Procedures", 285 RFC 1528, 10/06/1993 286 [TIFFPLUS] McIntyre, L., Zilles, S., Buckley, R., Venable, D., 287 Parsons, G., and J. Rafferty, "File Format for Internet 288 Fax", Work in Progress, February 1998. 289 [TIFF] Parsons, G., and J. Rafferty, "Tag Image File Format 290 (TIFF) -- Application F", Work in Progress, February 1998 292 Appendix A: IANA Registration form for new values of Application Parameter 294 To: IANA@isi.edu 295 Subject: Registration of new values for the Application parameter 296 of image/tiff 298 MIME type name: 300 image/tiff 302 Optional Parameter: 304 Application 306 New Value(s): 308 Application=foo 310 Description of Use: 312 foo - (include short description of the use of the new value here. 313 This must include reference to a standards track RFC for the 314 complete description; the use of the value must be defined 315 completely enough for independent implementation. ) 317 Security Considerations: 319 (Any additional security considerations that may be introduced by 320 use of the new parameter should be defined here or in the 321 referenced standards track RFC.) 323 Person & email address to contact for further information: 325 (fill in contact information) 327 INFORMATION TO THE SUBMITTER: 329 The accepted registrations will be listed in the "Assigned Numbers" 330 series of RFCs. The information in the registration form is freely 331 distributable.