IPP>MOD Issue with best-effort

IPP>MOD Issue with best-effort

IPP>MOD Issue with best-effort

Robert Herriot Robert.Herriot at Eng.Sun.COM
Mon Jul 21 17:20:56 EDT 1997


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



More information about the Ipp mailing list