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?