Yes, you have accurately summed up the "best-effort" semantics which
I have proposed calling it "may-ignore-attributes", except for
your item 1.
The client isn't quite asking the printer to do its best. Rather it is
saying "do what you understand and ignore what you don't, but I want
output". HTTP has a similar philosophy. This seems like good behavior
for work-group printers. The higher standard of "do exactly what I
asked or print nothing" is more suitable for production printing.
Bob Herriot
> From jkm at underscore.com Sat Jul 19 17:15:22 1997
>> 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 -----
>> From ipp-owner at pwg.org Fri Jul 18 23:01 EDT 1997
> 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 -----
>>