I agree that version number should not be included in the MIME media type
(as a parameter). Its best if the content indicates the version number. On
the other hand, it would be nice some how if a client could query an IPP
Printer to find out what version of each document format was being
supported. So I leave the version number problem as a future extension to
IPP, perhaps using the 'collection' attribute syntax....
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
operations:
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?
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.
(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'.
On the other hand, maybe faxbw is always supported, if faxcolor is
supported.
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.
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
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, lets continue the discussion on tiff profile extensions only on the
ifx DL, not on the IPP DL, if there is consensus not to add any more about
tiff profiles to IPP/1.1 at this time. Ok?
Tom
>-----Original Message-----
>From: Ron Bergman [mailto:rbergma@dpc.com]
>Sent: Wednesday, February 17, 1999 14:50
>To: Hastings, Tom N
>Cc: Richard Shockey; ipp; ifx@pwg.org
>Subject: RE: IPP> MOD - Ok to add 'image/tiff' and 'application/pdf' to
>IP P/1.1 Model document format list?
>
>
>
>On Wed, 17 Feb 1999, Hastings, Tom N wrote:
>
>...snip...snip...
>> Does the submitter (client software) have to identify the
>profile being used
>> in what is being submitted to the IPP Printer, or is it
>sufficient for the
>> IPP Printer to indicate the profile or profiles that it will
>accept and
>> image correctly for documents submitted with the
>document-format attribute
>> indicating 'image/tiff'? If the latter is sufficient, we
>could just add a
>> Printer Description attribute, say, tiff-profiles-supported,
>in which the
>> printer lists the tiff profiles that it supports. Such an
>attribute would
>> not be submitted with the document, but would be queriable using
>> Get-Printer-Attributes.
>>
>> If the submitter has to identify the profile being passed,
>then we would
>> need to add a new Job Template attribute (or may a new
>Operation attribute?)
>> that indicates the "tiff-profile" being submitted. This
>attribute would
>> only be submitted when the "document-format" attribute also
>being submitted
>> was 'image/tiff'.
>>
>> Comments?
>>
>> Tom
>>
>Tom,
>
>For printer capability discovery:
>
>I support just "image/tiff" for the
>"document-format-supported" attribute
>and then include "tiff-profiles-supported" as an additional attribute.
>"image/tiff" indicates that at least profile S is supported
>and if this is
>satisfactory, the client has all the information necessary.
>If the client
>wishes to use a more advanced profile of TIFF, either two
>requests can be
>submitted or he can request both attributes in one request.
>
>For job submission:
>
>Do we need to treat job submission for TIFF any differently than other
>PDLs? For PCL, a version number of PCL is not included as an
>Operation or
>Job Template attribute. This situation with TIFF should be
>treated as if
>this was a real fax. That is, the client should only send a
>TIFF profile
>that it is sure the target printer will properly process. If
>the client
>has the ability to discover the supported profiles, it should not be
>needed to be supplied in the job submission.
>
>
> Ron Bergman
> Dataproducts Corp.
>
>