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 rdebry at us.ibm.com 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.
>>