IPP Mail Archive: Re: IPP> MOD> "document-format-supported" [MOD ne

Re: IPP> MOD> "document-format-supported" [MOD ne

Carl Kugler (kugler@us.ibm.com)
10 Jun 1998 21:28:11 -0000

> I agree with Bob that "document-formats-supported" must be invariant with
> respect to the "document-format" input parmeter that a client might supply
> in a Get-Printer-Attributes request.
>
> I agree with both Bob and Carl that the Model document needs clarification on
> which attributes returned in Get-Printer-Attributes MAY depend on
> the value of the "document-format" supplied as an input parameter and
> which SHALL NOT depend on the "document-format" supplied, i.e., MUST
> be invariant.
>
> I agree with Carl that all Printer attributes that are Job Template
> attributes in the Printer object (xxx-default and xxx-supported in the
> Table in Section 4.2) MAY depend on the value of the document-format.

Glad we agree on all this.

>
> Here is an analysis of the remaining Printer Description attributes:
>
> create operation attribute corresponding Printer attributes vary?
> -------------------------- -------------------------------- ----
> attributes-charset charset-configured shall not
> charset-supported shall not
> attributes-natural-language natural-language-configured shall not
> generated-natural-language-supported shall not
> printer-uri printer-uri-supported shall not
> uri-security-supported shall not
> requesting-user-name -
> job-name -
> ipp-attribute-fidelity pdl-override-supported MAY
> document-name -
> document-format document-format-default shall not
> document-format-supported shall not
> document-natural-language -
> compression compression-supported MAY
> job-k-octets job-k-octets-supported MAY
> job-impressions job-impressions-supported MAY
> job-media-sheets job-media-sheets-supported MAY
>
> - printer-driver-installer MAY
> - operations-suported shall not
> - printer-is-accepting-jobs shall not
> - queued-job-count shall not
> - color-supported MAY
> - reference-uri-schemes-supported MAY?
>
>
> An IPP Printer object SHALL NOT return different values for all other
> Printer Description attribute depending on the "document-format" supplied
> as an input parameter to the Get-Printer-Attributes operation:
> printer-name, printer-location, printer-info, printer-more-info,
> printer-make-and-model, printer-more-info-manufacturer, printer-state,
> printer-state-reasons, printer-message-from-operator, printer-up-time,
> printer-current-time, and multiple-operation-time-out.
>

Some of these could be debatable. For example, suppose the Postscript interpreter is down but the printer is still capable of printing text/plain jobs. Giving "printer-is-accepting-jobs" Printer scope wouldn't allow a client to discover that text/plain could still be accepted. I doubt this is significant, but I wanted to point it out.

>
>
> Suggested text to be the clarification
>

I have an alternative wording, which follows.
------------------------------------------------------------------
The following are Printer attributes (and are independent of "document-format"):

charset-configured
charset-supported
natural-language-configured
generated-natural-language-supported
printer-uri-supported
uri-security-supported
document-format-default
document-format-supported
operations-suported
printer-is-accepting-jobs
queued-job-count

printer-name
printer-location
printer-info
printer-more-info
printer-make-and-model
printer-more-info-manufacturer
printer-state
printer-state-reasons
printer-message-from-operator
printer-up-time
printer-current-time
multiple-operation-time-out

A Printer contains one or more Interpreters, selected by the "docment-format" Operation attribute. Multiple document-formats may be associated with one Interpreter. The following are Interpreter attributes:

pdl-override-supported
compression-supported
job-k-octets-supported
job-impressions-supported
job-media-sheets-supported
printer-driver-installer
color-supported
reference-uri-schemes-supported

Also, all Job Template xxx-default and xxx-supported attributes are Interpreter attributes.
------------------------------------------------------------------

> We could add the following to the Get-Printer-Attribute request
> under the "document-format" operation attribute description:
>
> All Printer attributes that are Job Template attributes in the Printer
> object (xxx-default and xxx-supported in the Table in Section 4.2) MAY
> depend on the value of the "document-format" supplied in the request.
>
> In addition, the following Printer attributes MAY depend on the value of
> the "document-format" supplied: pdl-override-supported,
> compression-supported, job-k-octets-supported, job-impressions-supported,
> job-media-sheets-supported, printer-driver-installer, color-supported,
> reference-uri-schemes-supported(?). An IPP Printer object SHALL NOT return
> different values for all other Printer Description attributes depending on
> the "document-format" supplied as an input parameter in the
> Get-Printer-Attributes request.
>
> When a new Printer attribute is registered (see section 6), part of its
> specification needs to contain the following sentence:
>
> The value of this attribute returned in a Get-Printer-Attributes
> response MAY depend on the "document-format" attribute supplied (see
> Section 3.2.5.1).
>
> If the specification does not, then its value SHALL NOT depend on the
> "document-format" supplied in the request.
>
> When a new Job Template attribute is registered, the value of the Printer
> attributes MAY vary with "document-format" supplied in the request
> without the specification having to indicate so.
>
>
>
> For the 7 or 8 Printer attributes indicated with MAY above, we might want to
> add a sentence to each description something like:
>
> The value of this attribute returned in a Get-Printer-Attributes
> response MAY depend on the "document-format" attribute supplied (see
> Section 3.2.5.1).
>
> Comments?
>
> Tom
>
>
> At 14:47 06/09/1998 PDT, Carl Kugler wrote:
> >> --=====================_3129239==_.ALT
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> The value of document-format-supported should be all document-formats
> >> supported and its value should not be affected by the document-format
> >> operation attribute. Otherwise, how does a client determine what
> >> document-formats the printer supports. The document-format attribute
> should
> >> affect other printer attributes returned. Perhaps the model document needs
> >> some clarification in this area.
> >>
> >Okay, that's reasonable. But your reading is a little like saying
> "application/vnd.hp-PCL" is a supported document-format value for
> "text/plain" Jobs.
> >
> >So what we have here is a Printer Description Attribute (PDA) which is
> invariant with respect to document-format. Are there other PDAs that
> should be considered invariant? printer-name? printer-state?
> printer-is-accepting-jobs? pdl-override-supported? color-supported? Or can
> these be considered attributes of a particular interpreter in a Printer?
> Maybe only Printer Job Template attributes are a function of document-format?
> >
> >>
> >> Bob Herriot
> >>
> >
> > -Carl
> >
> >>
> >>
> >> At 04:09 PM 6/8/98 , Carl Kugler wrote:
> >> >A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads me
> to the
> >> conclusion that the value of "document-format-supported" in a
> >> Get-Printer-Attributes Response will always be either:
> >> >
> >> >a) a parroting back of the "document-format" supplied in the Request
> >> >
> >> >or
> >> >
> >> >b) the Printer's "document-format-default"
> >> >
> >> >depending on whether or not the client supplied "document-format" in the
> >> Request. Am I reading this correctly?
> >> >
> >> > -Carl
> >> >
> >>
> >> --=====================_3129239==_.ALT
> >> Content-Type: text/html; charset="us-ascii"
> >>
> >> <html>
> >> <font size=3>The value of document-format-supported should be all
> >> document-formats <br>
> >> supported and its value should not be affected by the document-format
> >> <br>
> >> operation attribute. Otherwise, how does a client determine what <br>
> >> document-formats the printer supports. The document-format attribute
> >> should <br>
> >> affect other printer attributes returned. Perhaps the model document
> >> needs <br>
> >> some clarification in this area.<br>
> >> <br>
> >> <br>
> >> Bob Herriot<br>
> >> <br>
> >> <br>
> >> <br>
> >> At 04:09 PM 6/8/98 , Carl Kugler wrote:<br>
> >> &gt;A literal reading of 3.2.5.1, Get-Printer-Attributes Request, leads
> >> me to the conclusion that the value of
> >> &quot;document-format-supported&quot; in a Get-Printer-Attributes
> >> Response will always be either:<br>
> >> &gt;<br>
> >> &gt;a)&nbsp; a parroting back of the &quot;document-format&quot; supplied
> >> in the Request<br>
> >> &gt;<br>
> >> &gt;or<br>
> >> &gt;<br>
> >> &gt;b) the Printer's &quot;document-format-default&quot;<br>
> >> &gt;<br>
> >> &gt;depending on whether or not the client supplied
> >> &quot;document-format&quot; in the Request.&nbsp; Am I reading this
> >> correctly?<br>
> >> &gt;<br>
> >> &gt;&nbsp;&nbsp;&nbsp; -Carl<br>
> >> &gt; </font><br>
> >> </html>
> >>
> >> --=====================_3129239==_.ALT--
> >>
> >>
> >>
> >
> >
> >
>
>