I'm confused and concerned about what the MIME Content Type 'image/tiff'
means and implies.
There is the IANA Registration from 1993 and there is RFC 2301 File Format
for Internet Fax. RFC 2301 seems to define a lot more than the original
'image/tiff'. Worse, the IANA registration entry does not cite RFC 2301.
IPP uses MIME Content Types (MIME Media Types?) to indicate the format of a
document in a create job request (the "document-format" Job object
attribute) and for an IPP Printer to indicate what document formats it is
capable of printing (the "document-format-supported" Printer object
Should the IPP mimeMediaType value in [ipp-mod] section 4.1.9 be listed as:
'image/tiff': Tag Image Format - see IANA MIME Media Type registry
'image/tiff': Tag Image Format - see File Format for Internet Fax
'image/tiff': Tag Image Format - see IANA MIME Media Type registry
The IANA Registration for image/tiff MIME Media Type is:
>From mrose at dbc.mtview.ca.us Sat Jul 31 20:04:51 1993
To: iana at ISI.EDU
Subject: Registration of new MIME content-type/subtype
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 31 Jul 1993 20:04:00 -0700
From: Marshall Rose <mrose at dbc.mtview.ca.us>
MIME type name: image
MIME subtype name: tiff
Required parameters: none
Optional parameters: none
Encoding considerations: base64
Security considerations: none
Published specification: TIFF class F, as defined in:
Tag Image File Format (TIFF) revision 6.0
Developer's Desk Aldus Corporation
411 First Ave. South Suite
200 Seattle, WA 98104
Tile Format for Internet Fax
Person & email address to contact for further information:
Glenn Parsons <Glenn.Parsons at Nortel.ca>
On the other hand a March 1998 RFC entitled "File Format For Internet FAX"
formally defines TIFF/FX as minimal, extended and lossless JBIG modes
(Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and
Mixed Raster Content modes (Profiles C, L, M) for color and grayscale fax.
These modes or profiles correspond to the content of the applicable ITU-T
Recommendations. Files formatted according to this specification use the
image/tiff MIME Content Type.
So if an IPP Printer's "document-format-supported" attribute includes the
MIME Content Type (or is it MIME Media Type?) with a value of 'image/tiff',
does that mean that the IPP Printer supports all of the above
representations? If so, how come the IANA registered MIME media type
doesn't mention RFC 2301?
ISSUE: Should IPP refer to the IANA registration of 'image/tiff' or to RFC
2301 as the definition of what the 'image/tiff' value means in the
"document-format" attribute that a client can supply in a create job request
and that a Printer object uses to indicate the document formats that it is
capable of accepting and printing?
Here is the Abstract for RFC 2301:
Network Working Group L. McIntyre
Request for Comments: 2301 Xerox Corporation
Category: Standards Track S. Zilles
Adobe Systems, Inc.
File Format for Internet Fax
This document describes the TIFF (Tag Image File Format)
representation of image data specified by the ITU-T Recommendations
for black-and-white and color facsimile. This file format
specification is commonly known as TIFF-FX. It formally defines
minimal, extended and lossless JBIG modes (Profiles S, F, J) for
black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster
Content modes (Profiles C, L, M) for color and grayscale fax. These
modes or profiles correspond to the content of the applicable ITU-T
Recommendations. Files formatted according to this specification use
the image/tiff MIME Content Type.
Return-Path: <owner-ipp at pwg.org>
Received: by pwg.org (SMI-8.6/SMI-SVR4)
id OAA01838; Thu, 18 Feb 1999 14:47:10 -0500
Received: from lysithea.eastgw.xerox.com by pwg.org (SMI-8.6/SMI-SVR4)
id OAA01834; Thu, 18 Feb 1999 14:47:06 -0500
Received: from norman.cp10.es.xerox.com (norman.cp10.es.xerox.com [22.214.171.124])
by lysithea.eastgw.xerox.com (8.9.1a/8.9.1) with ESMTP id OAA16113
for <ipp at pwg.org>; Thu, 18 Feb 1999 14:47:32 -0500 (EST)
Received: from x-crt-es-ms1.es.cp10.es.xerox.com (x-crt-es-ms1.cp10.es.xerox.com [126.96.36.199])
by norman.cp10.es.xerox.com (8.8.5/8.8.5) with ESMTP id LAA03753
for <ipp at pwg.org>; Thu, 18 Feb 1999 11:48:54 -0800 (PST)
Received: by x-crt-es-ms1.cp10.es.xerox.com with Internet Mail Service (5.5.2232.9)
id <1JRFT8SH>; Thu, 18 Feb 1999 11:47:23 -0800
Message-ID: <918C79AB552BD211A2BD00805F15CE85BCDDF1 at x-crt-es-ms1.cp10.es.xerox.com>
From: "Manros, Carl-Uno B" <cmanros at cp10.es.xerox.com>
To: "Masinter, Larry <masinter at parc.xerox.com>" <masinter at parc.xerox.com>,
"Hastings, Tom N" <hastings at cp10.es.xerox.com>, ipp <ipp at pwg.org>
Subject: RE: IPP> MOD - Ok to add 'image/tiff' and 'application/pdf' to IP
P/1.1 Model document format list?
Date: Thu, 18 Feb 1999 11:47:20 -0800
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: owner-ipp at pwg.org
I think we have a disconnect in this discussion, or else I don't know what
you are talking about - wouldn't be the first time :-)
The document-format parameter in the current IPP spec is just an indicator
of the overall capability, it never tried to give you all the details about
particular MIME parameters. If you want to discuss this as a fully fledged
solution to meet requirements for IFAX over IPP, please move that discussion
to the new ifx at pwg.org DL.
I don't want to introduce new complex features in IPP/1.1 to meet the IFAX
requirements, they should be left for a separate discussion on the ifx DL.
However, if we come up with some REAL simple solution like adding a new
attribute which gives the tiff-profile as complementary information I am all
for adding it to IPP/1.1.
> -----Original Message-----
> From: Larry Masinter [mailto:masinter at parc.xerox.com]
> Sent: Wednesday, February 17, 1999 6:41 PM
> To: Hastings, Tom N; ipp
> Subject: RE: IPP> MOD - Ok to add 'image/tiff' and
> 'application/pdf' to
> IPP/1.1 Model document format list?
>>> I suggest that IPP/1.1 change, with regard to MIME types, from:
>> # The value MAY include a charset parameter, depending on the
> # specification of the Media Type in the IANA Registry [IANA-MT].
>> # The value MAY include any number of parameters, depending
> # on the specification of the Media Type in the IANA Registry
>> Many media type registrations have both required and optional
> parameters. A MIME type which requires a parameter is meaningless
> without the parameter, and there are many other parameters other
> than 'charset'.
>> It is also true that most 'text' types allow a 'charset' parameter,
> and you can point this out if you want; the current wording, though,
> seems to imply that parameters other than 'charset' are not allowed,
> which would be wrong.