I have made several comments below.
> From rdebry at us.ibm.com Thu Mar 27 13:29:17 1997
>> I have found the section on conformance, as it relates to attributes,
> to be confusing. I've tried to reason out what I think conformance
> means. If this sounds reasonable then perhaps we can use some
> of the following text to clarify conformance in section 1.1 of the
> model document. Please let me know your thoughts on the
> following. What I've suggested may not be correct, but I think we
> have to be this specific.
>> Attributes are conditionally mandatory. This means the following:
> (The attribute sides will be used as an example)
I would prefer that a certain set of common attributes be mandatory so
that we have don't have to deal with some of the complexity you
describe for these common attributes. I expect that we might want some
sort of common look and feel for the common stuff and it is hard to
support that if a client cannot depend on anything. I think that we are
taking generality too far when we can assume nothing about the world.
>> If a Printer does not provide a feature that a given attribute
> controls, then
>> In response to a general query (all or an attribute group) the
> Printer should respond with any attributes it does not
> support. For example, if jobTemplate is specified in a Get
> Attributes request, and the Printer only supports simplex
> printing, then it should return the attribute keyword sides
> with the attribute value 1-sided. However, it need not
> send back anything for sides.
I think that I have a different notion of 'support'. If the printer
knows about 'sides' but only supports '1-sided', then I believe that
the printer supports the attribute 'sides'. In this case, I believe
that the printer SHALL always return 'sides' in the case.
>> In response to a specific query for an unsupported attribute,
> the Printer should return the attribute keyword with an
> appropriate value. For example, if Sides is requested in a
> Get attributes request, and the Printer only supports simplex
> printing, then it should respond with sides = 1-sided. However,
> it may respond with sides = null value, since if it is really
> unsupported it will not know what value to respond with.
I have the same comment again. In addition, we need to be careful
about adding a "null" value to mean that the attribute is unsupported.
I would prefer that the server either return no attribute 'sides', or
have some special result attribute that contains a list of attributes
'requested but not returned'.
>> In response to a print request including a non-supported
> attribute, the Printer must recognize the attribute as one
> that it does not support (this would have to include syntax
> errors or private extensions not supported) and honor the
> print request ONLY if the best-effort attribute is set to
> substitute-as-needed (this implies that best-effort is either
> a mandatory attribute, or always defaults to do-not-
> substitute). In our example, a duplex job sent to a simplex
> printer would not print unless substitute-as-needed is
> indicated.
There are two issues here: a) the value is not supported and b) the
attribute is not supported.
If the value is not supported and best effort is requested, then we
need to define what best-effort means. Does the printer uses the
attribute's default value, or does it recognize some values and pick a
better one. Note: unsupported does not mean for all cases that the
printer is unaware of the meaning of a value. For simplicity, I would
prefer that the Printer use the attribute's default. Note, that
a syntax error may be recognizable as different from an unknown value
in this case.
If the attribute is not supported and best effort is requested, then
best effort means that the printer ignores the attribute. If an attribute
is unsupported, the Printer probably doesn't even know what it means
or what its syntax is.
>> When a print request is rejected because of an
> unsupported attribute, the Printer must be able to indicate
> which attribute(s) in the request were not supported and
> therefore caused the failure. In our example, if a duplex job
> is sent to a simplex printer, and the print request is rejected, the
> response must say sides=duplex not supported.
>> In response to a general query, a client should provide end
> users with some mechanism to see and select all attributes
> returned by the Printer. However, a client need not provide
> the end user with visibility of any attributes.
It doesn't seem like a protocol document should address what end-users
see.
>> When submitting a print request, the client need not explicity
> specify any attributes, thus taking the Printer defaults.
> For example, it might always default sides to be either
> 1-sided or take the Printer default. From this point of view,
> it is probably correct to say that a client need not support
> any attributes. This is contradictory to the current model doc.
>The sentence 'it might always default sides to be either 1-sided or take the
Printer default.' suggests two defaulting mechanisms. There is only
one, namely on the Printer side. The IPP documents don't specify how a
client decides to set or not to set attributes.
I'm not sure if the IPP documents are contradictory. A client can be
totally ignorant of attribute if it never performs a GetAttributes or
GetJobs.