As per Relevance of the word registration, we have this rfc below:
Network Working Group G.
Request for Comments: 2302 Northern
Category: Standards Track J.
Human
S.
Adobe Systems, Inc
March 1998
Tag Image File Format (TIFF) - image/
MIME Sub-type
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes the registration of the MIME sub-
image/tiff. The baseline encoding is defined by [TIFF].
Internet Fax Working
This document is a product of the IETF Internet Fax Working Group
All comments on this document should be forwarded to the
distribution list at .
1.
This document describes the registration of the MIME sub-
image/tiff. The baseline encoding is defined by [TIFF].
document refines an earlier sub-type registration in RFC 1528
[TPC.INT].
2. TIFF
TIFF (Tag Image File Format) Revision 6.0 is defined in detail
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
Adobe Systems
345 Park
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.
While a brief scope and feature description is provided in
section as background information, the reader is directed to
original TIFF specification [TIFF] to obtain complete feature
technical details
2.1 TIFF
TIFF describes image data that typically comes from scanners,
grabbers, and paint- and photo-retouching programs. TIFF is not
printer language or page description language. The purpose of TIFF
to describe and store raster image data. A primary goal of TIFF
to provide a rich environment within which applications can
image data. This richness is required to take advantage of
varying capabilities of scanners and other imaging devices.
TIFF is a rich format, it can easily be used for simple scanners
applications as well because the number of required fields is small
2.2 TIFF
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
developers to choose the best space or time tradeoff for
applications
- TIFF is designed to be extensible and to evolve gracefully as
needs arise
- TIFF allows the inclusion of an unlimited amount of private
special-purpose information
Parsons, et. al. Standards Track [Page 2]
RFC 2302 TIFF March 1998
3. MIME
3.1 image/
The image/tiff content-type was previously defined in RFC 1528
containing TIFF 6.0 encoded image data, with specific reference
to a subset known as TIFF Class F. This document re-defines
original image/tiff definition to refer to all of the profiles
extensions that build on TIFF 6.0 [TIFF] encoded image data
consistent with existing practice for TIFF aware
applications. This definition is further enhanced by introducing
new "application parameter" (section 3.2) to enable identification
a specific subset of TIFF and TIFF extensions for the encoded
data
3.2 Application
There are cases where it may be useful to identify the
applicable to the content of an image/tiff body. Typically,
would be used to assist the recipient in dispatching a
rendering package to handle the display or processing of the
file. As a result, an optional "application" parameter is
for image/tiff to identify a particular application's subset of
and TIFF extensions for the encoded image data, if it is known.
values are defined in this document
Example using a fictional value 'foo':
Content-type: image/tiff; application=
There is no default value for application, as the absence of
application parameter indicates that the encoded TIFF image
Baseline TIFF or that it is not necessary to identify
application. It is up to the recipient's implementation
determine the application (if necessary) and render the image to
user
4. IANA
To: ietf-types@iana.
Subject: Registration of Standard MIME media type image/
MIME media type name:
MIME subtype name:
Required parameters:
Parsons, et. al. Standards Track [Page 3]
RFC 2302 TIFF March 1998
Optional parameters:
There is no format specified for the value of this
in addition to that specified by [MIME1].
applications of TIFF may define values as required.
values should be defined in standards track RFCs and
values should be registered with IANA, using
registration form included in Appendix A. There is
default value for application, as the absence of
application parameter indicates that the encoded TIFF
is Baseline TIFF or that it is not necessary to identify
application. It is up to the implementation to
the application (if necessary) and render the image to
user
Encoding considerations: Binary or Base-64 generally
Security considerations
TIFF utilizes a structure which can store image data
attributes of this image data. The fields defined in
TIFF specification are of a descriptive nature and
information that is useful to facilitate viewing
rendering of images by a recipient. As such, the
currently defined in the TIFF specification do not
themselves create additional security risks, since
fields are not used to induce any particular behavior
the recipient application
TIFF has an extensible structure, so that it
theoretically possible that fields could be defined in
future which could be used to induce particular actions
the part of the recipient, thus presenting
security risks, but this type of capability is
supported in the referenced TIFF specification. Indeed,
definition of fields which would include such
instructions is inconsistent with the goals and spirit
the TIFF specification
Interoperability considerations
The ability of implementations to handle all the
applications (or profiles within applications) of TIFF
not be ubiquitous. As a result, implementations may
and attempt to display the encoded TIFF image data only
determine that the image cannot be rendered. The
of the application parameter may aid in allowing
determination before dispatching for rendering. However,
Parsons, et. al. Standards Track [Page 4]
RFC 2302 TIFF March 1998
should be noted that the parameter value is not intended
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
Adobe Systems
345 Park
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/
iles/tiff6.
Applications which use this media type
Imaging, fax, messaging and multi-
Additional information
Magic number(s):
II (little-endian): 49 49 42 00
MM (big-endian): 4D 4D 00 42
File extension(s): .
Macintosh File Type Code(s):
Person & email address to contact for further information
Glenn W.
Glenn.Parsons@Nortel.
James
Jrafferty@worldnet.att.
Stephen
szilles@adobe.
Intended usage:
Change controller: Stephen
Parsons, et. al. Standards Track [Page 5]
RFC 2302 TIFF March 1998
5. Authors'
Glenn W.
Northern
P.O. Box 3511, Station
Ottawa, ON K1Y 4H
Phone: +1-613-763-7582
Fax: +1-613-763-2697
Email: Glenn.Parsons@Nortel.
James
Human
12 Kevin
Danbury, CT 06811-2901
Phone: +1-203-746-4367
Fax: +1-203-746-4367
Email: Jrafferty@worldnet.att.
Stephen
Adobe Systems Inc
Mailstop W14
345 Park
San Jose, CA 95110-2704
Voice: +1-408-536-4766
Fax: +1-408-536-4042
Email: szilles@adobe.
6.
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[MIME4] Freed, N. and N. Borenstein, "Multipurpose Internet
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
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
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
To: IANA@isi.edu Subject: Registration of new values for
Application
of image/
MIME type name
image/
Optional Parameter
New Value(s):
Application=
Description of Use
foo - (Ûfooš is a fictional new value used in this message as
example, it is to be replaced with the new value
registered. Include a short description of the use of
new value here. This must include reference to a
track RFC for the complete description; the use of
value must be defined completely enough for
implementation. )
Security Considerations
(Any additional security considerations that may be introduced by
of the new parameter should be defined here or in the
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
distributable
Parsons, et. al. Standards Track [Page 7]
RFC 2302 TIFF March 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Parsons, et. al. Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
