From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2302.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc2302.txt (limited to 'doc/rfc/rfc2302.txt') diff --git a/doc/rfc/rfc2302.txt b/doc/rfc/rfc2302.txt new file mode 100644 index 0000000..e35b775 --- /dev/null +++ b/doc/rfc/rfc2302.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group G. Parsons +Request for Comments: 2302 Northern Telecom +Category: Standards Track J. Rafferty + Human Communications + S. Zilles + Adobe Systems, Inc. + March 1998 + + + Tag Image File Format (TIFF) - image/tiff + MIME Sub-type Registration + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Overview + + This document describes the registration of the MIME sub-type + image/tiff. The baseline encoding is defined by [TIFF]. + +Internet Fax Working Group + + This document is a product of the IETF Internet Fax Working Group. + All comments on this document should be forwarded to the email + distribution list at . + +1. Abstract + + This document describes the registration of the MIME sub-type + image/tiff. The baseline encoding is defined by [TIFF]. This + document refines an earlier sub-type registration in RFC 1528 + [TPC.INT]. + +2. TIFF Definition + + TIFF (Tag Image File Format) Revision 6.0 is defined in detail by + Adobe in [TIFF]. The documentation can be obtained from Adobe at: + + + + +Parsons, et. al. Standards Track [Page 1] + +RFC 2302 TIFF March 1998 + + + Adobe Developers Association + Adobe Systems Incorporated + 345 Park Avenue + San Jose, CA 95110-2704 + + Phone: +1-408-536-6000 + Fax: +1-408-537-6000 + + A copy of this specification can also be found in: + ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdffiles/ + tiff6.pdf + + While a brief scope and feature description is provided in this + section as background information, the reader is directed to the + original TIFF specification [TIFF] to obtain complete feature and + technical details. + + 2.1 TIFF Scope + + TIFF describes image data that typically comes from scanners, frame + grabbers, and paint- and photo-retouching programs. TIFF is not a + printer language or page description language. The purpose of TIFF is + to describe and store raster image data. A primary goal of TIFF is + to provide a rich environment within which applications can exchange + image data. This richness is required to take advantage of the + varying capabilities of scanners and other imaging devices. Though + TIFF is a rich format, it can easily be used for simple scanners and + applications as well because the number of required fields is small. + +2.2 TIFF Features + + Some of the features of TIFF (from [TIFF]) are: + + - TIFF is capable of describing bilevel, grayscale, palette-color, + and full-color image data in several color spaces. + + - TIFF includes a number of compression schemes that allow + developers to choose the best space or time tradeoff for their + applications. + + - TIFF is designed to be extensible and to evolve gracefully as new + needs arise. + + - TIFF allows the inclusion of an unlimited amount of private or + special-purpose information. + + + + + + +Parsons, et. al. Standards Track [Page 2] + +RFC 2302 TIFF March 1998 + + +3. MIME Definition + +3.1 image/tiff + + The image/tiff content-type was previously defined in RFC 1528 as + containing TIFF 6.0 encoded image data, with specific reference made + to a subset known as TIFF Class F. This document re-defines the + original image/tiff definition to refer to all of the profiles and + extensions that build on TIFF 6.0 [TIFF] encoded image data, + consistent with existing practice for TIFF aware Internet + applications. This definition is further enhanced by introducing the + new "application parameter" (section 3.2) to enable identification of + a specific subset of TIFF and TIFF extensions for the encoded image + data. + +3.2 Application parameter + + There are cases where it may be useful to identify the application + applicable to the content of an image/tiff body. Typically, this + would be used to assist the recipient in dispatching a suitable + rendering package to handle the display or processing of the image + file. As a result, an optional "application" parameter is defined + for image/tiff to identify a particular application's subset of TIFF + and TIFF extensions for the encoded image data, if it is known. No + values are defined in this document. + + Example using a fictional value 'foo': + + Content-type: image/tiff; application=foo + + There is no default value for application, as the absence of the + application parameter indicates that the encoded TIFF image is + Baseline TIFF or that it is not necessary to identify the + application. It is up to the recipient's implementation to + determine the application (if necessary) and render the image to the + user. + +4. IANA Registration + + To: ietf-types@iana.org + Subject: Registration of Standard MIME media type image/tiff + + MIME media type name: image + + MIME subtype name: tiff + + Required parameters: none + + + + +Parsons, et. al. Standards Track [Page 3] + +RFC 2302 TIFF March 1998 + + + Optional parameters: application + + There is no format specified for the value of this parameter + in addition to that specified by [MIME1]. Various + applications of TIFF may define values as required. New + values should be defined in standards track RFCs and the + values should be registered with IANA, using the + registration form included in Appendix A. There is no + default value for application, as the absence of the + application parameter indicates that the encoded TIFF image + is Baseline TIFF or that it is not necessary to identify the + application. It is up to the implementation to determine + the application (if necessary) and render the image to the + user. + + Encoding considerations: Binary or Base-64 generally preferred + + Security considerations: + + TIFF utilizes a structure which can store image data and + attributes of this image data. The fields defined in the + TIFF specification are of a descriptive nature and provide + information that is useful to facilitate viewing and + rendering of images by a recipient. As such, the fields + currently defined in the TIFF specification do not in + themselves create additional security risks, since the + fields are not used to induce any particular behavior by + the recipient application. + + TIFF has an extensible structure, so that it is + theoretically possible that fields could be defined in the + future which could be used to induce particular actions on + the part of the recipient, thus presenting additional + security risks, but this type of capability is not + supported in the referenced TIFF specification. Indeed, the + definition of fields which would include such processing + instructions is inconsistent with the goals and spirit of + the TIFF specification. + + Interoperability considerations: + + The ability of implementations to handle all the defined + applications (or profiles within applications) of TIFF may + not be ubiquitous. As a result, implementations may decode + and attempt to display the encoded TIFF image data only to + determine that the image cannot be rendered. The presence + of the application parameter may aid in allowing this + determination before dispatching for rendering. However, it + + + +Parsons, et. al. Standards Track [Page 4] + +RFC 2302 TIFF March 1998 + + + should be noted that the parameter value is not intended to + convey levels of capabilities for a particular application. + + Published specification: + + TIFF (Tag Image File Format) is defined in: + TIFF (TM) Revision 6.0 - Final - June 3, 1992 + + Adobe Developers Association + Adobe Systems Incorporated + 345 Park Avenue + San Jose, CA 95110-2704 + + Phone: +1-408-536-6000 + Fax: +1-408-537-6000 + + A copy of this specification can be found in: + ftp://ftp.adobe.com/pub/adobe/devrelations/devtechnotes/pdff + iles/tiff6.pdf + + Applications which use this media type: + + Imaging, fax, messaging and multi-media + + Additional information: + + Magic number(s): + II (little-endian): 49 49 42 00 hex + MM (big-endian): 4D 4D 00 42 hex + File extension(s): .TIF + Macintosh File Type Code(s): TIFF + + Person & email address to contact for further information: + + Glenn W. Parsons + Glenn.Parsons@Nortel.ca + + James Rafferty + Jrafferty@worldnet.att.net + + Stephen Zilles + szilles@adobe.com + + Intended usage: COMMON + + Change controller: Stephen Zilles + + + + + +Parsons, et. al. Standards Track [Page 5] + +RFC 2302 TIFF March 1998 + + +5. Authors' Addresses + + Glenn W. Parsons + Northern Telecom + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7 + Canada + Phone: +1-613-763-7582 + Fax: +1-613-763-2697 + Email: Glenn.Parsons@Nortel.ca + + James Rafferty + Human Communications + 12 Kevin Drive + Danbury, CT 06811-2901 + USA + Phone: +1-203-746-4367 + Fax: +1-203-746-4367 + Email: Jrafferty@worldnet.att.net + + Stephen Zilles + Adobe Systems Inc. + Mailstop W14 + 345 Park Avenue + San Jose, CA 95110-2704 + USA + Voice: +1-408-536-4766 + Fax: +1-408-536-4042 + Email: szilles@adobe.com + +6. References + + [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + [MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Four: Registration Procedures", RFC 2048, + November 1996. + [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final, + June 3, 1992. + [TPC.INT] Malamud, C. and M. Rose, "Principles of Operation for the + TPC.INT Subdomain: Remote Printing -- Technical Procedures", + RFC 1528, October 1993. + [TIFFPLUS] McIntyre, L., Zilles, S., Buckley, R., Venable, D., + Parsons, G., and J. Rafferty, "File Format for Internet Fax", + RFC 2301, March 1998. + [TIFF] Parsons, G., and J. Rafferty, "Tag Image File Format + TIFF) -- R Profile for Facsimile, RFC 2306, March 1998. + + + +Parsons, et. al. Standards Track [Page 6] + +RFC 2302 TIFF March 1998 + + +Appendix A: IANA Registration form for new values of Application +Parameter + + To: IANA@isi.edu Subject: Registration of new values for the + Application parameter + of image/tiff + + MIME type name: + + image/tiff + + Optional Parameter: + + Application + + New Value(s): + + Application=foo + + Description of Use: + + foo - ("foo" is a fictional new value used in this message as an + example, it is to be replaced with the new value being + registered. Include a short description of the use of the + new value here. This must include reference to a standards + track RFC for the complete description; the use of the + value must be defined completely enough for independent + implementation. ) + + Security Considerations: + + (Any additional security considerations that may be introduced by use + of the new parameter should be defined here or in the referenced + standards track RFC.) + + Person & email address to contact for further information: + + (fill in contact information) + + INFORMATION TO THE SUBMITTER: + + The accepted registrations will be listed in the "Assigned Numbers" + series of RFCs. The information in the registration form is freely + distributable. + + + + + + + +Parsons, et. al. Standards Track [Page 7] + +RFC 2302 TIFF March 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Parsons, et. al. Standards Track [Page 8] + -- cgit v1.2.3