Bob,
Sometimes I get lost in a sea of words, at which point I drown
before I fully grasp the point.
Regarding "best-effort", are the following statements consistent
with what you and Scott are proposing?
1) Conceptually, "best-effort" is the way for a client to tell the
IPP server to print the document(s) "the best way that it can",
given the specified job attributes.
2) When the client indicates "best-effort", the server is free to
ignore any attribute it either does not recognize, or is invalid
in some way.
3) When the client indicates "best-effort", the server is free to
ignore any attribute having a value that is invalid in some way.
4) The "best-effort" parameter is used only during job submission;
that is, it may only appear within a Print-Job, Print-URI,
Create-Job or Validate-Job operation.
5) The "best-effort" parameter is always an optional parameter;
if absent in the operation, the implied value is "false".
Do these statements accurately sum up the proposal, or is something
missing or incorrect?
...jay
----- Begin Included Message -----
Date: Fri, 18 Jul 1997 19:34:58 -0700
From: Robert.Herriot at Eng.Sun.COM (Robert Herriot)
To: ipp at pwg.org
Subject: IPP>MOD Issue with best-effort
Scott and I have discussed the best-effort job attribute and we both
agree that this doesn't fit as a Job- Template attribute. The printer
attribute best-effort-supported doesn't fit the job template model very
well.
I suggest that it become an optional parameter to Print-Job, Print-URI,
Create-Job, and Validate-Job and that it be renamed to
`may-ignore-attributes' to reflect its new meaning.
If it is omitted in these operations, it has a value of false. All
implementations must support both values of this parameter. It seems
to me that this is not much of a requirement because very
implementation has to check if it supports an attribute and each value.
If the answer is yes, the value of may-ignore-attributes doesn't
matter. If it is no and may-ignore-attributes is false, the job is
rejected and the offending attribute returned in the response ( the
current required mechanism). If it is no and may-ignore-attributes is
true, I propose that the Printer ignore the attribute not to add it to
the job, which means the default behavior takes hold (the new
very-simple mechanism).
There should be an OPTIONAL job attribute may-ignore-attributes which
is set by the parameter may- ignore-attributes. This attribute is
MANDATORY if Create-Job is supported because Send-Document and Send-URI
use the value set by Create-Job. Otherwise, I wouldn't expect it to be
implemented. It would be useful in a future resubmit-job operation
The following is the change in wording that I propose for rules 3 and 4
in section 3.1.2.1 Print-Job Request:
3. The client supplies a Job Template attribute and either the
attribute is not supported by the Printer or the attribute value is not
among the values supported by the Printer: The value of the
"may-ignore- attributes" parameter determines the Printer's behavior.
3a. The client supplies no "may-ignore-attributes" parameter, or
supplies a "may-ignore- attributes" parameter of 'false': the
Printer SHALL reject the Job. It SHALL return the 'client-
error-attribute-unsupported" error code and the unsupported attribute
in the "unsupported attributes " output parameter. If it is the
attribute value that is unsupported, the attribute in the unsupported
attributes output parameter SHALL be exactly as received in the
request. If it is the attribute itself that is unsupported, the
attribute in the `unsupported attributes' output parameter SHALL have
the name as received in the request, but its value SHALL be
"unsupported". If a job contains more than one unsupported attribute or
attribute value that cause a job to be rejected, a Printer may return
all of them, some of them, or only one of them in the `unsupported
attributes' output parameter. Note: in the Send-Document or Send-URI
operation, the document and not the job is rejected, and if the
last-document flag is true, it is treated as if it were false so that
the client can resubmit the document.
3b. The client supplies a "may-ignore-attributes" of 'true': the
Printer SHALL continue accepting the Job but ignore the attribute and
not associate it with the new Job object. The Printer's default value
effectively becomes the value of this attribute (see rule 4 below). In
this case, if everything else is ok, the Printer SHALL return a
"successful-attributes-ignored" status code along an optional complete
list of ignored attributes in the `unsupported attributes' output
parameter.
Job-name
Job-name, like best-effort, doesn't fit in the job-template section.
For example, it alone is mandatory and it alone has no xxx-supported
attribute. It also has special rules for setting its value because it
has no default.
I suggest that it become a parameter to Print-Job, Print-URI,
Create-Job and Validate-Job and become a job-description attribute
where there are several mandatory attributes. The description for the
job attribute can contain all the rules for how a printer sets its
value, i.e. from the parameter, or the document-name or from an
implementation defined value, in that order of precedence.
----- End Included Message -----