Subject: IPP> MOD - ISSUE: is "best-effort" job template attribute useful?

From: Tom Hastings <[email-masked]>
Date: Sat, 21 Jun 1997 10:09:15 PDT

I still question the value of having a single job template attribute
that specifies "best-effort" (or more aptly named: "attribute-precedance"
or something.) that applies to ALL attributes supplied by the client.

My understanding of the xxx-supported attributes is that a Printer
SHALL return the values that the Printer supports in the protocol.

For each xxx attribute, there are 3 alternatives for a conforming
Printer:

  a. only supports the values in the protocol, not in the PDL
  b. supports the values in both the protocol and the PDL, but if both
     are supplied, the PDL takes precedance.
  c. supports the values in both the protocol and the PDL, but if both
     are supplied, the protocol takes precedance.

If a printer supports an attribute value only in the PDL, the Printer
SHALL NOT return that value in the "xxx-supported" attribute.

As we have agreed most current implementations do not
support the protocol overriding what is in the PDL, yet we agree that is
what we want to get to long term.  I suspect that vendors are going to 
implement overriding gradually, a few attributes at a time, not all or 
nothing.  TRUE?  And different vendors will support overriding for different
attributes.

Therefore, having a *single* attribute that allows the client to choose between:

  a. ALL attributes that the client supplies MUST override the PDL, else the 
     Printer MUST reject the job OR

  b. its ok if SOME or ALL of the attributes that the client supplies do not
     override the PDL, in case the attribute is also in the PDL

Instead, I propose that we follow the same strategy that got us to delete
the compulsory/non-compulsory concept, namely that the client has to get
it right and specify only attributes that override the PDL or the Printer
shall reject the job.  

a. So delete the "best-effort" job template attribute.  

b. Instead, let the Printer attributes specify what the Printer supports 
in the protocol and in the PDL and with what precedance.  Therefor,
introduce a parallel set of Printer attributes to the "xxx-supported"
attributes called "xxx-precedance".  Each "xxx-precedance" Printer
attribute is single-valued.  The values are:

   'ipp-only'
       the corresponding "xxx" job attribute is supported in the IPP protocol 
       only [This value isn't strictly necessary, but might be informative]
   'ipp-over-pdl'
       the corresponding "xxx" job attribute is supported in both the IPP 
       protocol and in the PDL, but if supplied in both, the IPP protocol 
       takes precedance
   'pdl-over-ipp'
       the corresponding "xxx" job attribute is supported in both the IPP 
       protocol and in the PDL, but if supplied in both, the PDL takes 
       precedance

[We definitely don't want a 'pdl-only' value, since the purpose of
"xxx-supported" is to show what is possible for a client to supply in 
the protocol]

While this proposal adds more Printer attributes, they only go in the IPP spec
as a column in the job template table, replacing the column that we deleted
on availablilty.  Also these attributes are specified only in Get-Attributes
for a Printer, not in Create-Job/Print-Job, so we are simplifying the
job submission part of IPP.

If we want to allow the client to specify an attribute to be used,
in case the PDL doesn't specify, we could add an "xxx-default" column
to the job template table that a client could supply.  If we do that,
we could even change the names of the "xxx" Printer attribute to "xxx-default",
since they would have the same semantics, namely, the value is applied only
if the PDL does not supply a value.

Comments?

Tom