My objection was the addition of a new attribute to provide the
"aaplication=xxxx". My point was that the profile provides more
information than faxbw or faxcolor. But, certainly the additional
information can be included in the "document-format" attribute.
The TIFF profiles are more complex that simply B&W or color. You may want
to check RFC 2301, page #6 for a summary of the profiles and then reword
your examples.
Ron Bergman
Dataproducts Corp.
On Sun, 21 Feb 1999, Hastings, Tom N wrote:
> Ron,
>
> 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.
> >
> >
>