Subject: IPP> MOD> "document-format-supported"

From: "Carl Kugler" <[email-masked]>
Date: 8 Jun 1998 23:09:33 -0000

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

---

From: Robert Herriot <[email-masked]>
Date: Tue, 09 Jun 1998 12:26:36 -0700

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.

Bob Herriot

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

---

From: "Carl Kugler" <[email-masked]>
Date: 9 Jun 1998 21:47:23 -0000

> --=====================_3129239==_.ALT
> Content-Type: text/plain; charset="us-ascii"
> 
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?

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

---

From: Tom Hastings <[email-masked]>
Date: 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

>> document-formats the printer supports. The document-format attribute
should 
>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?

---

From: "Carl Kugler" <[email-masked]>
Date: 10 Jun 1998 21:28:11 -0000

> Table in Section 4.2) MAY depend on the value of the document-format.

Glad we agree on all this.

> create operation attribute   corresponding Printer attributes     vary?

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

---

From: "Carl Kugler" <[email-masked]>
Date: 17 Jul 1998 23:11:39 -0000

It looks like the problem discusssed in Re: MOD> "document-format-supported" [MOD needs clarification], http://www.findmail.com/list/ipp/showthread.html?num=3864 was addressed in the new MOD, ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipp-model-10.txt June 30, 1998.  The new words say:

    "If the Printer object does distinguish between different sets of supported values for each different document format specified by the client, this specialization applies only to the following Printer object attributes: 

- Printer attributes that are Job Template attributes ("xxx-default" "xxx-supported", and "xxx-ready" in the Table in Section 4.2),
- "pdl-override-supported",
- "compression-supported",
- "job-k-octets-supported",
- "job-impressions-supported,
- "job-media-sheets-supported"
- "printer-driver-installer",
- "color-supported", and
- "reference-uri-schemes-supported"

    "The values of all other Printer object attributes (including "document-format-supported") remain invariant with respect to the client supplied document format (except for new Printer description attribute as registered according to section 6.2).

While this new wording gets around the problem, I think it presents a poor model.  It blatantly violates Second Normal Form, in that some Printer attributes depend on the (Printer identifier, document-format) tuple, while others depend only on the Printer identifier.  The model says that all these attributes, including those that vary with document-format (e.g., number-up), are attributes of the Printer class of objects.  But the implication is that each real-wold printer maps to a whole set of Printer object instances, selected by document-format.  Attributes (e.g. printer-name) which don't vary with document-format are redundantly stored in each instance.  Updates to attributes that don't vary with document-format (e.g. printer-state) require visiting all the instances.

A better model would split the existing Printer into two classes of objects:  1) a new, reduced Printer, and 2)something else that could be called "Interpreter".  Then the attributes can be normalized between these two new classes.  Attributes that don't vary with document-format are assigned to the Printer.  Each real-world printer maps to one instance of Printer.  Attributes that do vary with document-format are assigned to Interpreter.  Each Printer instance contains one or more Interpreter instances, selected by document-format.  

I know that IPP doesn't claim to be truly object-oriented.  But I think considerations like this are important for a few reasons:

  - IPP looks object-oriented, with terms like Object, and attribute, and Operation bandied about.  It will lead to confusion if the IPP model is anti-object-oriented.  Let's not call Printer an object if it represents something other than what an object is commonly understood to be.  

  - Many implementors are likely to use OO methods. (How about a poll of current implementors?)  It would sure be nice if the IPP model could map easily to an OO design and implementation.

  - Although an implementor's design could split up these classes internally and still meet the existing spec, there is some value in having the implemenation, the design, and the model trace cleanly back to the real world.

    -Carl

-----
Original Message: http://www.findmail.com/list/ipp/?start=3867
Start a FREE email list at http://www.FindMail.com/