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

["Carl Kugler" <[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.

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