IPP Mail Archive: IPP> Re: Should we add image/tiff ;application=faxbw and

IPP Mail Archive: IPP> Re: Should we add image/tiff ;application=faxbw and

IPP> Re: Should we add image/tiff ;application=faxbw and

James Rafferty (jrafferty@worldnet.att.net)
Wed, 24 Feb 1999 12:57:04 -0500

At 11:51 AM 2/21/99 -0800, Hastings, Tom N wrote:
>So lets consider the problem of color versus black and white for tiff:
>The Internet-Draft submitted to the IETF Secretariat for IPP/1.1 on 2/18
>includes 'image/tiff' as an example, but does not include the
>;application=faxbw or ;application=faxcolor parameters in the examples.
>There are 6 reasons to allow the ;application=faxbw or ;application=faxcolor
>parameter on the 'image/tiff' to be sent by the client when submitting a job
>as the value of the "document-format" attribute in the create job
I believe use of the application parameters should be allowed and in fact
are valuable, for some of the reasons Tom notes below and others I will
>1. The parameter is optional but has been registered. IPP can't disallow
>using MIME types with parameters, if the parameters have been registered
>with IANA. Correct?
This would not be good practice.
>2. There is an advantage to a server of seeing the tiff parameter in a
>create job operation for a server that is supporting both color and bw fax
>devices (fanout). Then the server will be able to know whether the job
>being submitted is faxbw or faxcolor without having to examine the TIFF
>content. Then the server can schedule the job on the proper device without
>looking into the TIFF content. Being document-format independent is a nice
>feature for a spooler that fans out to devices and other servers that may be
>document-format specific.
Yes, the parameter value is a "hint".
>(BTW, perhaps we goofed in IPP/1.0 and IPP/1.1 with the color boolean, only
>making "color-supported" a Printer Description attribute. Perhaps, it
>should have been a Job Template attribute: "color (boolean)" Job attribute
>and "color-default (boolean)" and "color-supported (1setOf boolean)" Printer
>attributes. Then the submitter could have indicated that the job being
>submitted was color or not for any document format. We could add "color" as
>a Job Template as an extension. That would cause "color-supported" to have
>two instances on the Printer object: one as a Job Template attribute with a
>'1setOf boolean' data type and the other as a Printer Description attribute
>with simply a 'boolean' data type. Hmmm....)
>3. The "document-format-supported" can also indicate the values supported
>with parameters. So a device that supports only bw, only color, or both bw
>and color would have the following values, respectively:
> "document-format-supported" = 'image/tiff; application=faxbw'
> "document-format-supported" = 'image/tiff; application=faxcolor'
> "document-format-supported" = 'image/tiff; application=faxbw',
>'image/tiff; application=faxcolor'
>which is more descriptive than just "document-format-supported" =
>'image/tiff' in combination with the "color-supported" boolean which can
>only be 'true' or 'false'.
If they also supported baseline TIFF, the parameter could be omitted for
that case.

>On the other hand, maybe faxbw is always supported, if faxcolor is
Yes, that is true.
>An IPP system that wanted to insist that the client supply the parameter
>could configure the Printer's "document-format-supported" attributes as:
> "document-format-supported" = 'image/tiff; application=faxbw',
>'image/tiff; application=faxcolor'
>i.e., not include the 'image/tiff' without a parameter. On the other hand,
>an IPP Printer that does not require the client to include the parameter
>would be configured with 3 values:
> "document-format-supported" = 'image/tiff', 'image/tiff;
>application=faxbw', 'image/tiff;
> application=faxcolor'
>4. The "color-supported" Printer Description boolean attribute only
>indicates that at least one document format supports color, but does not
>indicate which ones do. So including the color parameter in the
>"document-format-supported" Printer Description attribute makes it clear
>whether the tiff supports color or not, independent of the other document
>formats that may or may not support color.
>True, that if a client submits a "document-format" attribute in the
>Get-Printer-Attributes request, the "color-supported" value returned MAY
>depend on the document format submitted. But returning Printer Description
>attribute values that depend on the "document-format" attribute submitted in
>the Get-Printer-Attributes is only an IMPLEMENTATION OPTION. See section
> of the IPP/1.0 and IPP/1.1 Model and Semantics documents, which does
>list "color-supported" as one of the attributes that MAY be specialized for
>each document-format requested.
>5. We want the value that a submitter submits as the value of the
>"document-format" to be matched with the values of the Printer's
>"document-format-supported" for purposes of job validation, so if either
>attribute allows the parameter, then the other attribute must also.
>6. I think that knowing whether color tiff is supported or not is a useful
>thing to have in the SLP Directory entry as well, so the tiff parameter from
>"document-format-supported" values could be included in directory entries as
>Since the two above parameters (;application=faxbw and
>;application=faxcolor) have already been registered (supposed to have been
>registered in March of 1998 when RFC 2301 was published), I suggest we add
>them to IPP/1.1 now.
They are now in the IANA registry.
>So I'm suggesting that we add the following two example tiff values (making
>a total of 3 tiff example values) to IPP/1.1 Model and Semantics section
> 'image/tiff; application=faxbw': Tag Image Format - black and white
>profile or subset of TIFF for Facsimile. see IANA MIME Media Type registry
> 'image/tiff; application=faxcolor': Tag Image Format - color profile or
>subset of TIFF for Facsimile. see IANA MIME Media Type registry
Yes, I believe these should be added. A key reason is that the presence
of the parameter is a clear indication that the file content follows the
RFC 2301 rules for TIFF for facsimile; in its absence, the default
assumption of baseline TIFF is problematic when the file IS actually
compatible with one of the RFC 2301 profiles.
>'text/html': An HTML document
>'text/plain': A plain text document in US-ASCII (RFC 2046 indicates that in
>the absence of the charset parameter MUST mean US-ASCII rather than simply
>unspecified) [RFC2046].
>'text/plain; charset=US-ASCII': A plain text document in US-ASCII [52, 56].

>'text/plain; charset=ISO-8859-1': A plain text document in ISO 8859-1
>(Latin 1) [ISO8859-1].
>'text/plain; charset=utf-8': A plain text document in ISO 10646 represented
>as UTF-8 [RFC2279]
>'application/postscript': A PostScript document [RFC2046]
>'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape sequence
>embedded in the document data)
>'image/tiff': Tag Image Format - see IANA MIME Media Type registry
>'application/pdf': Portable Document Format - see IANA MIME Media Type
>'application/octet-stream': (REQUIRED) Auto-sense - see below
>As far as adding "tiff-profiles-supported" as Printer Description attributes
>to IPP/1.1, I suggest that we put such extensions into any separate IFAX
>over IPP specification, rather than trying to rush it into IPP/1.1. We need
>to have the time to work out the other negotiation, job validation, and
>discovery issues first. Also whether the client MUST NOT, MAY, SHOULD, or
>MUST indicate in an IPP submission attribute which tiff profile(s) are
>included in the submission, i.e., whether we should make "tiff-profile" a
>Job Template attribute, so we add both a "tiff-profile" Job attribute and a
>"tiff-profile-supported" Printer attributes. We have to have a separate
>document for IFAX over IPP anyway, since that separate document will REQUIRE
>'image/tiff' as a supported value, while IPP/1.1 does NOT require any
>particular document format to be supported, except
>'application/octet-stream' (auto sense). Ok?
In fact, the IFAX over IPP should have image/tiff with the application
parameter as the Requirement, since the format here IS NOT baseline TIFF.

Conceptually, the support of the media type (image/tiff; application=foo)
is a good starting point for describing the level of support and other
attributes (ssuch as TIFF profiles supported) can refine this.

James Rafferty
President, Human Communications LLC
12 Kevin Drive
Danbury, CT 06811-2901
Voice/Fax: +1-203-746-4367
Email/Internet Fax: JRafferty@worldnet.att.net

HC Web Site: http://www.humancomm.com