IPP> Re: Should we add image/tiff ;application=faxbw and ;application=faxc olor as 2 additional examples to IPP/1.1?

IPP> Re: Should we add image/tiff ;application=faxbw and ;application=faxc olor as 2 additional examples to IPP/1.1?

IPP> Re: Should we add image/tiff ;application=faxbw and ;application=faxc olor as 2 additional examples to IPP/1.1?

Ron Bergman rbergma at dpc.com
Mon Feb 22 22:00:07 EST 1999


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
> 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 at dpc.com]
> >Sent: Wednesday, February 17, 1999 14:50
> >To: Hastings, Tom N
> >Cc: Richard Shockey; ipp; ifx at 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.
> >
> >

More information about the Ipp mailing list