IPP> Re: MOD - Confusion about image/tiff MIME Content Type

IPP> Re: MOD - Confusion about image/tiff MIME Content Type

IPP> Re: MOD - Confusion about image/tiff MIME Content Type

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Feb 18 18:46:05 EST 1999


Thanks.  So it looks like the IPP Model and Semantics 'mimeMediaType' value
of 'image/tiff' should point to the IANA Registry, not a particular RFC.  

For future work and an extension to IPP to be developed in the IFAX over IPP
WG, we will need to solve the Interoperability Considerations problem called
out below where there are different profiles for TIFF.


Here is the updated IANA Registry entry:

>From RFC 2302

   To: ietf-types at 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.  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

   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
      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:

   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 at Nortel.ca

      James Rafferty
      Jrafferty at worldnet.att.net

      Stephen Zilles
      szilles at adobe.com

      Intended usage: COMMON

      Change controller:  Stephen Zilles

>-----Original Message-----
>From: Keith Moore [mailto:moore at cs.utk.edu]
>Sent: Thursday, February 18, 1999 12:40
>To: Hastings, Tom N
>Cc: Larry Masinter; Lloyd McIntyre; Robert Buckley; Zilles, Steve;
>venable at wrc.xerox.com; Glenn.Parsons at nortel.ca;
>Jrafferty at worldnet.att.net; ipp; ifx at pwg.org; Keith Moore <
>Subject: IPP> Re: MOD - Confusion about image/tiff MIME Content Type 
>I think that the IANA registration for image/tiff was fixed yesterday
>to point to the newer document.

More information about the Ipp mailing list