Subject: Re: IPP>MOD - best effort

From: [email-masked] (Robert Herriot)
Date: Tue, 22 Jul 1997 12:51:50 -0700

I think that the sum total of your arguments in favor of keeping
best-effort as a job-template parameter add up to an argument in favor
of the single best-effort parameter.  In each item below, you provide a
workable solution, but each one is increasingly difficult to implement,
especially the one that involves determining the value of best-effort
before processing other attributes.

But the bottom line question is, why do we need all of these
implementation options for best-effort when all implementations have to
deal with the issue of unsupported attributes and each of the two
"best-effort" options is trivial to implement. That is, when a Printer
encounters an unsupported attribute or value, it either rejects the job
(best-effort=false) or ignores the attribute (best-effort=true).

It seems like far more effort to implement, document and test the 3
best-effort job-template attributes (MANDATORY attributes with
values that are OPTIONAL), than to fully support both values of
a best-effort parameter.
 
[ There is an additional comment about substitution at the end of this
  email. ]

Bob Herriot

> From [email-masked] Tue Jul 22 06:26:08 1997
> 
>  Bob, You've clearly simplified things by
> getting rid of the "may-ignore ..." job
> attribute. But, I still believe that a
> "best-effort" job template attribute is better
> than a new parameter. To me, whether or not I want
> the job to print, regardless of attribute errors,
> is itself an attribute of the job. Let's keep
> attributes attributes!
> 
>    o there is a job attribute "best-effort" for specifying what the
>      client wants.
> 
>     <RKD> This is straightforward and consistent with it being
>     <RKD> a job template attribute. I see no problem here.
> 
>    o there is a printer default "best-effort" which says whether
>      the printer defaults it behavior to best-effort or not if a
>      client doesn't specify this attribute.
> 
>     <RKD> This is also simple and consistent.
> 
>    o there is a printer "best-effort-supported" attribute which is unlike
>      most xxx-supported attributes. It is not a set of possible
>      values, namely "true" and "false" values. Instead, it is either
>      "true" or "false"
> 
>     <RKD> As you have written it down here, the rules are
>     <RKD> not consistent with other job template atributes.
>     <RKD> However, it seems that this is an easy fix. If a
>     <RKD> Printer supports both "true" and "false" values,
>     <RKD> then the xxx-supported should in fact be a set of
>     <RKD> values, namely "true" and "false". This matches
>     <RKD> what you have written below. Furthermore, if the
>     <RKD> Printer only supports "false" then xxx-supported
>     <RKD> has only one value, and that is "false". This also
>     <RKD> matches what you have written below. Now I think
>     <RKD> xxx-supported for "best-effort" is consistent with
>     <RKD> other job template attributes.
> 
>          * "true" means that a client can specify either the value
>            "true" or "false" or and the printer default "best-effort"
>            can have the value of true or false"
>          * "false" means that a client can specify only the value of
>            "false" and the default "best-effort" can have only the
>            value of "false".
>          NOTE: it is believed that no implementation would support
>          a "best-effort" job attribute of "true" only.
> 
>     o this attribute has to be processed before others are processed
>       because it affects the processing of them, but it need not
>       be the first attribute.
> 
>     <RKD> It appears that you can fix this problem in two ways.
>     <RKD> Although it may require a little additional code to
>     <RKD> implement, it is surely possible for the Printer to
>     <RKD> handle the best-effort attribute in any place in the
>     <RKD> sequence of received attributes. If everyone thinks
>     <RKD> this is too hard, then you could mandate that if this
>     <RKD> attribute is used it MUST be the first in the list.
>     <RKD> Admittedly, this is a special rule for this attribute,
>     <RKD> but in effect that's all you've done by declaring it
>     <RKD> a parameter.
> 
>       o the "best-effort" substitution is somewhat undefined and
>       potentially complex.
> 
>     <RKD> Its not clear why you think this is somewhat undefined
>     <RKD> and potentially complex. Why is it different from any
>     <RKD> other attribute?

 RGH:  The model document uses the word "substitution" to (perhaps)
 RGH:  mean that the Printer picks some value that may be other than
 RGH:  the attribute's default value. For example, if a printer  
 RGH:  supports letter and B size paper with letter the default size, 
 RGH:  and if a client requests A3 paper, then B would be a good 
 RGH:  substitution using some undefined logic, and letter would 
 RGH:  be the simple substitution using the default.

---

From: Jim Walker <[email-masked]>
Date: Tue, 22 Jul 1997 15:19:35 -0500

One of the *negative* aspects of making best-effort a parameter of the
operation instead of an attribute is that it would not be a persistent
part of the job state.  For example, if best-effort is not an attribute,
I cannot query a job after it has been submitted, and find out whether
it was submitted with best-effort or not.  IMHO, this would be a bad
thing; I would prefer that it stay an attribute.

As for the xxx-supported feature of best-effort, I agree with Roger
that it seems very simple to align a best-effort job template attribute
with all of the other job template attributes.

Finally, in terms of the placement of the best-effort attribute, I do
not feel that it is burdensome to the implementation to allow it as an
attribute, and allow it to occur anywhere in the sequence of job
attributes.  If anyone has a concrete example to the contrary, I
would love to hear it.

...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX