summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2302.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2302.txt')
-rw-r--r--doc/rfc/rfc2302.txt451
1 files changed, 451 insertions, 0 deletions
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 <ietf-fax@imc.org>.
+
+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]
+