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

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

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

Tom Hastings (hastings@cp10.es.xerox.com)
Wed, 10 Jun 1998 13:17:05 PDT

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.

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.

Suggested text to be the clarification

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--
>>
>>
>>
>
>
>