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

[Tom Hastings <[e-mail]>]

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