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/rfc3302.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc3302.txt (limited to 'doc/rfc/rfc3302.txt') diff --git a/doc/rfc/rfc3302.txt b/doc/rfc/rfc3302.txt new file mode 100644 index 0000000..8726452 --- /dev/null +++ b/doc/rfc/rfc3302.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group G. Parsons +Request for Comments: 3302 Nortel Networks +Obsoletes: 2302 J. Rafferty +Category: Standards Track Brooktrout Technology + September 2002 + + + 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 (2002). All Rights Reserved. + +Abstract + + This document describes the registration of the MIME sub-type + image/tiff. This document refines an earlier sub-type registration + in RFC 1528. + + This document obsoletes RFC 2302. + +1. Conventions used in this document + + 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 [REQ]. + +2. Overview + + This document describes the registration of the MIME sub-type + image/tiff. The baseline encoding of TIFF (Tag Image File Format) is + defined by [TIFF]. + +3. 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 . + + + + +Parsons & Rafferty Standards Track [Page 1] + +RFC 3302 image/tiff September 2002 + + +4. 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: + + 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: + http://partners.adobe.com/asn/developer/PDFS/TN/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. + +4.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. + +4.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. + + + + +Parsons & Rafferty Standards Track [Page 2] + +RFC 3302 image/tiff September 2002 + + + - TIFF allows the inclusion of an unlimited amount of private or + special-purpose information. + +5. MIME Definition + +5.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 redefines the + original image/tiff definition to refer to 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 6.2) to enable identification of + a specific subset of TIFF and TIFF extensions for the encoded image + data. + +5.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: + + 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. + + New values for the image/tiff application parameter must be approved + by the IESG prior to registration. As a result, the publication of a + description of parameter values in an RFC is required. + + Guidelines on writing IANA considerations for RFCs can be found in + RFC 2434. + + An application parameter is a hint to the receiver. It MUST NOT be + used as a blind request to execute some arbitrary program. + + + + +Parsons & Rafferty Standards Track [Page 3] + +RFC 3302 image/tiff September 2002 + + + Instead, it should be viewed rather as an indication of what sort of + application would be able to handle the content most appropriately. + +6. 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 + + 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 as hints + to the receiver. 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: + + This media type consists of binary data. The base64 encoding + should be used on transports that cannot accommodate binary + data directly. + + 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 the 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 + + + +Parsons & Rafferty Standards Track [Page 4] + +RFC 3302 image/tiff September 2002 + + + 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 as + defined to date. + + 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 + 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: + http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf + + Applications which use this media type: + + Imaging, fax, messaging and multi-media + + Additional information: + + Magic number(s): + II (little-endian): 49 49 2A 00 hex + MM (big-endian): 4D 4D 00 2A hex + File extension(s): .TIF + Macintosh File Type Code(s): TIFF + + + + + + +Parsons & Rafferty Standards Track [Page 5] + +RFC 3302 image/tiff September 2002 + + + Person & email address to contact for further information: + + Glenn W. Parsons + gparsons@nortelnetworks.com + + James Rafferty + jraff@brooktrout.com + + Intended usage: COMMON + + Change controller: James Rafferty + +6. 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 the 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 + as defined to date. + +7. Changes from RFC 2302 + + * Correction of magic number + * Improvements of the security considerations + * Change of change controller + * Various editorials to improve clarity + +8. References + +8.1 Normative References + + [REQ] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + + +Parsons & Rafferty Standards Track [Page 6] + +RFC 3302 image/tiff September 2002 + + + [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", BCP + 13, RFC 2048, November 1996. + + [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - + Final, June 3, 1992. + +8.2 Non-Normative References + + [TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File + Format (TIFF) -image/tiff MIME Sub-type Registration", RFC + 2302, March 1998. + + [TPC.INT] Malamud, C. and M. Rose, "Principles of Operation for the + TPC.INT Subdomain: Remote Printing -- Technical + Procedures", RFC 1528, October 1993. + +9. Authors' Addresses + + Glenn W. Parsons + Nortel Networks + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7 + Canada + + Phone: +1-613-763-7582 + Fax: +1-613-763-2697 + EMail: gparsons@nortelnetworks.com + + + James Rafferty + Brooktrout Technology + 410 First Avenue + Needham, MA 02494 + USA + + Phone: +1-781-433-9462 + Fax: +1-781-433-9268 + EMail: jraff@brooktrout.com + + + + + + + + +Parsons & Rafferty Standards Track [Page 7] + +RFC 3302 image/tiff September 2002 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Parsons & Rafferty Standards Track [Page 8] + -- cgit v1.2.3