I agree with you rules below with the following suggestions and additions.
This reply got longer than I initially expected.
First, we need to define the terms "supported", "implements", and "default"
more carefully.
The text should indicate that a value is "supported" for an attribute
"XXX" if it is member of the set of values for the Printer attribute
"supportedXXX". If a value is not supported, that does not make a
statement about whether the Printer implements the value. That is,
a Printer may implement values that someone (e.g. an administrator)
has decided a Printer will not support.
NOTE: the model group is still debating the name of "supportedXXX",
versus "XXXsupported" versus "XXX-supported", etc.
A printer implements an attribute if that attribute is in the list of
attributes that the Printer knows about. A Printer may have behavior
that corresponds to the value of some attribute, but if the Printer
doesn't know about the attribute name, it doesn't implement it. For
example, if a printer prints one-sided only but does not know about the
attribute "sides", it does not implement "sides" even though it prints
one-sided jobs. I would hope that most Printers would implement "sides",
even for one-sided Printer, but the same reasoning applies to the
attribute "foo".
If a printer implements an attribute, but that attribute contains
no values (e.g. an Administrator didn't initialize it), what does
the Printer return as its value? "unknown", empty set, or does
every attribute has at least some reasonable value that can never
be empty (for IPP attributes, the model document defines such
a default value)?
The text should also define what the Printer's default value is. For
attribute "XXX" the Printer's "defaultXXX" attribute contains the
default value. If the printer doesn't implement "defaultXXX", the
default value is the first value of "supportedXXX". If neither
"supportedXXX" nor "defaultXXX" are defined, the printer does not
implement the attribute, so the explicit default is moot.
Your text also omits a whole set of rules, namely what happens during
job submission when the job doesn't contain an attribute. The missing
rules are:
o shall use the Printer's default attribute value in the print operation
if the Printer implements an attribute which the job does not specify.
If a client queries the job, subsequently, such attributes shall
be included with the job, as if the client had included them with
the original job submission.
o shall use the default behavior (according to the IPP model document)
for the attribute in the print operation if the Printer doesn't
implement the attribute and the job does not specify the attribute
and the IPP model document does specify the attribute. If a client
queries the job, subsequently, such attributes shall not be included
with the job.
o shall use the default behavior (according to the Printer)
for the attribute in the print operation if the Printer doesn't
implement the attribute and the job does not specify the attribute
and the IPP model document does not specify the attribute. If a client
queries the job, subsequently, such attributes shall not be included
with the job.
Comments about the text:
>> In response to a Print request, if a job or document attribute is
> supplied and the best-effort attribute is set to
> substitute-as-needed, an IPP Printer
>Change the following to active voice:
>> o shall use the supplied attribute value in the print operation
> if the attribute is implemented in the Printer and the
> specified value is supported.
o shall use the supplied attribute value in the print operation
if the Printer implements the specified attribute and supports
the specified value.
>> o shall change the attribute value to the default value for the
> supplied attribute if the attribute is implemented but the
> supplied value is not supported. A return code will indicate
> that the job was accepted with attribute substitution. A
> subsequent query of the supplied attribute should return the
> substituted value.
ISSUE: what is the rule if the attribute's default value is "unknown"?
It that the same as the attribute not being implemented.
o shall change the attribute value to the default value for the
supplied attribute if the Printer implements the specified
attribute but does not support the specified value. A return
code shall indicate that the Printer accepted the job
with attribute substitution. A subsequent query of the
aforementioned attribute should return the substituted value.
>> o shall ignore the attribute if the attribute is not
> implemented. A return code will indicate that the job was
> accepted with some attributes ignored. The Printer shall not
> add the unimplemented attributes to the created job object. A
> subsesquent Get-attributes operation will not return the
> ignored unimplemented attributes.
ISSUE: what sort of return code is used when several of the return
code clauses get invoked?
o shall ignore the attribute if the Printer does not implement
it. ...
Note: an alternative approach to the above case, is for the job to
keep the attribute with a value of "unsupported". This makes
it easier for a client to query a job and see the attributes
that were ignored.
>> In response to a Print request, if the best-effort attribute is
> set to do-not-substitute, an IPP Printer
Change these to active voice too:
>>> o shall reject the print job if the attribute is implemented but
> the supplied value is not. A return code will indicate that
> the job was rejected because a supplied attribute value is
> unsupported.
Keep the language of "supported" for values rather than the implicit
"implemented" here. Suggested wording:
o shall reject the print job if the Printer implements the
specified attribute but does not support the specified value.
>>
>>> In response to a Query, an IPP client may ignore any attributes
> that it does not implement.
>
We probably shouldn't prescribe the behavior of a client. What we
should say is:
A Query may return attributes and values which a client does not
implement.
This warns the implementor to be ready to receive unexpected attributes
and value, but leaves the implementer free to handle such attributes
and values in whatever way the implementor chooses. This does not
prohibit bad solutions, such as abnormal termination of the client.