Subject: IPP> Review of Model Document - unsupported job template attribut

From: Roger K Debry <[email-masked]>
Date: Fri, 18 Jul 1997 11:48:56 -0400

In the latest (July 14th) version of the model document, lines 584-
 (PDF version w/o revision marks) - 594 read

"The client supplies a Job Template attribute and the attribute value
is not among the values supported by the Printer: This case depending
on the value of the "best-effort" attribute (see section 4.2.8), tIf the client
supplies a "best-effort" of 'false' (or supplies no "best-effort" attribute and
the printer's default behavior attribute is set to 'false') the Printer SHALL
reject the Job and return the 'client-error-attribute-unsupported" error
code and the unsupported attribute in the "unsupported attributes"
output parameter. If the client supplies a "best-effort" of 'true' (or
supplies no "best-effort" attribute and the Printer's default behavior
attribute is set to 'true') the printer SHALL accept the Job and
substitute supported values for all unsupported values supplied by
the client. In this case, if everything else is ok, the Printer returns a
"successful-ok" status code.  The client must query the newly create
Job object to find out if any of the requested values have been
modified."

1) When the job is rejected, shouldn't the error code say something
like 'client-error-attribute-value-unsupported'? Otherwise it is not
clear that the attribute itself is supported, but the supplied value is not.

2) Should the unsupported values be returned as parameters's?

3) As the text currently reads, when substitution occurs, the Printer
may choose any supported attribute value that it chooses. Is this
is what is intended? I would prefer that the default value be used
and the text reflect the same processing as in case 5 (the value
is not assigned at job creation, but at job processing time).

4) At one time, I thought we had a status code the said something
like "ok-values substituted" for the case where "best-effort" was
set to true. This alerts the end user that the ouput may not appear
exactly as intended, but is printing anyway.

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: [email-masked] (Robert Herriot)
Date: Fri, 18 Jul 1997 12:56:02 -0700

> From [email-masked] Fri Jul 18 08:58:03 1997
> 
> 

We have one status-code for both 'attribute not supported' and 'attribute value
not supported' because a job could be rejected because both problems exist.
The collection of unsupported attributes returned specify that it is
the attribute that is unsupported by returning the attribute in the
response with a value of "unsupported". Note an implementation that
rejects a job may return only the first attribute found, or all attributes
found or something in between.

> is not assigned at job creation, but at job processing time).

In an email about simplifying "best-effort" that I will send shortly I
will propose that the Printer simply ignore (treat as if not included
in the request) any 'attribute not supported' and 'attribute value not
supported'.  That effectively means the job gets the default value.
This makes the solution very simple to implement.
  
> exactly as intended, but is printing anyway.

That might be useful information.  The Printer could also return an OK
status-code with a list of the unsupported attributes as well to give
more detail.

Bob Herriot