>On the other hand, maybe faxbw is always supported, if faxcolor is
>supported.
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
>3.2.5.1 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
>well.
>
>
>
>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
>4.1.9:
>
> '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.
>to:
>
>'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
>registry
>'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
*------------------------------------------------*
James Rafferty
President, Human Communications LLC
12 Kevin Drive
Danbury, CT 06811-2901
USA
Voice/Fax: +1-203-746-4367
Email/Internet Fax: JRafferty@worldnet.att.net
J_Rafferty_HC@compuserve.com
jrafferty@humancomm.com
HC Web Site: http://www.humancomm.com
*---------------------------------------------------