doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

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 <ietf-fax@imc.org>.
+
+
+
+
+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]
+