summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3950.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3950.txt')
-rw-r--r--doc/rfc/rfc3950.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3950.txt b/doc/rfc/rfc3950.txt
new file mode 100644
index 0000000..8f642a5
--- /dev/null
+++ b/doc/rfc/rfc3950.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group L. McIntyre
+Request for Comments: 3950 Consultant
+Obsoletes: 3250 G. Parsons
+Category: Standards Track Nortel Networks
+ J. Rafferty
+ Brooktrout Technology
+ February 2005
+
+
+ Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx
+ 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 (2005).
+
+Abstract
+
+ This document describes the registration of the MIME sub-type
+ image/tiff-fx. The encodings are defined by File Format for Internet
+ Fax and its extensions.
+
+1. Introduction
+
+ This document describes the registration of the MIME sub-type
+ image/tiff-fx. The encodings are defined by File Format for Internet
+ Fax [TIFF-FX] and its extensions.
+
+ This document is a product of the IETF Internet Fax Working Group.
+
+ 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 BCP 14, RFC 2119
+ [REQ].
+
+2. TIFF-FX Definition
+
+ Tag Image File Format Fax eXtended (TIFF-FX), is defined in detail by
+ RFC 3949, "File Format for Internet Fax" [TIFF-FX].
+
+
+
+
+McIntyre, et al. Standards Track [Page 1]
+
+RFC 3950 image/tiff-fx February 2005
+
+
+ While a brief scope and feature description is provided in this
+ section as background information, the reader is directed to the
+ original TIFF-FX specification (File Format for Internet Fax) to
+ obtain complete feature and technical details.
+
+2.1. TIFF-FX Scope
+
+ This document defines a TIFF-based file format specification for
+ enabling standardized messaging-based fax over the Internet. It
+ specifies the TIFF fields and field values required for compatibility
+ with the existing ITU-T Recommendations for Group 3 black-and-white,
+ grayscale and color facsimile. TIFF has historically been used for
+ handling fax image files in applications such as store-and-forward
+ messaging. Implementations that support this file format
+ specification for import/export may elect to support it as a native
+ format. This document recommends a TIFF file structure that is
+ compatible with low-memory and page-level streaming implementations.
+
+ Unless otherwise noted, the current TIFF specification [TIFF] and
+ selected TIFF Technical Notes [TTN1, TTN2] are the primary references
+ for describing TIFF and defining TIFF fields. This document is the
+ primary reference for defining TIFF field values for fax
+ applications.
+
+2.2. TIFF-FX Features
+
+ Some of the features of TIFF-FX are:
+
+ - TIFF-FX is capable of describing bilevel, grayscale, palette-
+ color, full-color and mixed content image data.
+
+ - TIFF-FX includes a number of compression schemes that allow
+ developers to choose the best space or time tradeoff for their
+ applications.
+
+ - TIFF-FX is designed to be extensible and to evolve gracefully as
+ new needs arise.
+
+3. MIME Definition
+
+ This document defines the image/tiff-fx MIME sub-type to refer to
+ TIFF-FX Profiles J, C, L and M encoded image data and any future
+ TIFF-FX extensions, or a subset. The image/tiff-fx content type MAY
+ be used when black-and-white image data is encoded using TIFF-FX
+ Profiles S or F, or a subset, however, the image/tiff content type
+ SHOULD be used.
+
+
+
+
+
+McIntyre, et al. Standards Track [Page 2]
+
+RFC 3950 image/tiff-fx February 2005
+
+
+4. IANA Registration
+
+ To: ietf-types@iana.org
+ Subject: Registration of Standard MIME media type image/tiff-fx
+
+ MIME media type name: image
+
+ MIME subtype name: tiff-fx
+
+ Required parameters: none
+
+ Optional parameters: none
+
+ 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-FX utilizes a structure which can store image data and
+ attributes of this image data. The fields defined in the TIFF-FX
+ 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-FX
+ 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-FX 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-FX
+ specification. Indeed, the definition of fields which would
+ include such processing instructions is inconsistent with the
+ goals and spirit of the TIFF-FX specification.
+
+ The MIME type and file extension defined by this document MUST NOT
+ be used to blindly select a processing program. It is up to the
+ implementation to determine the application (if necessary) and
+ render the image to the user.
+
+
+
+
+
+
+
+
+McIntyre, et al. Standards Track [Page 3]
+
+RFC 3950 image/tiff-fx February 2005
+
+
+ Interoperability considerations:
+
+ The ability of implementations to handle all the defined
+ applications (or profiles within applications) of TIFF-FX may not
+ be ubiquitous. As a result, implementations may decode and
+ attempt to display the encoded TIFF-FX image data only to
+ determine that the image cannot be rendered.
+
+ Published specification:
+
+ TIFF-FX (Tag Image File Format Fax eXtended) is defined in:
+
+ RFC 3949, "File Format for Internet Fax", February 2005, Buckley,
+ R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty.
+
+ 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): .TFX
+ Macintosh File Type Code(s): TFX
+
+ Person & email address to contact for further information:
+
+ Lloyd McIntyre
+ Lloyd_McIntyre@Dell.com
+
+ Glenn W. Parsons
+ gparsons@nortelnetworks.com
+
+ James Rafferty
+ jraff@brooktrout.com
+
+ Intended usage: COMMON
+
+ Change controller: Lloyd McIntyre
+
+
+
+
+
+
+
+
+
+
+McIntyre, et al. Standards Track [Page 4]
+
+RFC 3950 image/tiff-fx February 2005
+
+
+5. Security Considerations
+
+ TIFF-FX utilizes a structure which can store image data and
+ attributes of this image data. The fields defined in the TIFF-FX
+ 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-FX
+ 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-FX 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-FX specification. Indeed, the
+ definition of fields which would include such processing instructions
+ is inconsistent with the goals and spirit of the TIFF-FX
+ specification.
+
+ The MIME type and file extension defined by this document MUST NOT be
+ used to blindly select a processing program. It is up to the
+ implementation to determine the application (if necessary) and render
+ the image to the user.
+
+6. References
+
+6.1. Normative References
+
+ [TIFF-FX] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J.
+ Rafferty, "File Format for Internet Fax", RFC 3949,
+ February 2005.
+
+6.2. Informative References
+
+ [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 -
+ Final, June 3, 1992.
+
+ [REQ] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14, 1995,
+ http://partners.adobe.com/asn/developer/pdfs/tn/TIFFPM6.pdf
+
+ [TTN2] Adobe Photoshop TIFF Technical Notes, Replacement TIFF/JPEG
+ specification, March 22, 2002,
+ http://partners.adobe.com/asn/developer/pdfs/tn/
+ TIFFphotoshop.pdf
+
+
+
+McIntyre, et al. Standards Track [Page 5]
+
+RFC 3950 image/tiff-fx February 2005
+
+
+Annex A. List of edits to RFC 3250
+
+ +----+---------+-------------------------------------------------+
+ | No.| Section | Edit |
+ +----+---------+-------------------------------------------------+
+ | 1. | All | Updated references from RFC 2301 to |
+ | | | draft-ietf-fax-tiff-fx-13.txt |
+ +----+---------+-------------------------------------------------+
+ | 2. | 5 | MIME Definition - added a "SHOULD" statement to |
+ | | | stress that image/tiff is the preferred content |
+ | | | type when representing Profiles S and/or F. |
+ +----+---------+-------------------------------------------------+
+ | 3. | 7 | Revise security considerations. |
+ +----+---------+-------------------------------------------------+
+ | 4. | 3 | Merged sections 2 & 3 and renumbered. |
+ +----+---------+-------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McIntyre, et al. Standards Track [Page 6]
+
+RFC 3950 image/tiff-fx February 2005
+
+
+Authors' Addresses
+
+ Lloyd McIntyre
+ 10328 S. Stelling Road
+ Cupertino, CA 95014 USA
+
+ Phone: +1-408-725-1624
+ EMail: lloyd10328@pacbell.net or
+ Lloyd_McIntyre@Dell.com
+
+
+ Glenn W. Parsons
+ Nortel Networks
+ P.O. Box 3511, Station C
+ Ottawa, ON K1Y 4H7
+ Canada
+
+ Phone: +1-613-763-7582
+ Fax: +1-613-967-5060
+ EMail: gparsons@nortel.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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McIntyre, et al. Standards Track [Page 7]
+
+RFC 3950 image/tiff-fx February 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+McIntyre, et al. Standards Track [Page 8]
+