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
>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',
>>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
>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',
>>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;
>>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
>18.104.22.168 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
>'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.
President, Human Communications LLC
12 Kevin Drive
Danbury, CT 06811-2901
Email/Internet Fax: JRafferty at worldnet.att.netJ_Rafferty_HC at compuserve.comjrafferty at humancomm.com
HC Web Site: http://www.humancomm.com