I agree with these comments and have some minor comments on a few.
Some of my earlier comments are on the same areas, and these are not
repeated here.
Tom
>Return-Path: <ipp-owner at pwg.org>
>Date: Tue, 22 Apr 1997 16:02:29 PDT
>From: Robert.Herriot at eng.sun.com (Robert Herriot)
>To: ipp at pwg.org, rdebry at us.ibm.com>Subject: Re: IPP>MOD - Conformance
>X-Sun-Charset: US-ASCII
>Sender: ipp-owner at pwg.org>>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.
I agree. We need to put these terms in a terminology section.
I happen to like putting such a section up front, so that the reader
reads them first.
We also need to add "default behavior" to the terminology section.
>>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.
So we will talk about attributes being implemented, and values being
supported, but NOT attributes being supported and values being implemented,
correct?
Also I think we need to point out this subtle fact that an administrator
may restrict a Printer to not supporting a value that has actually been
implemented by the Printer.
>>NOTE: the model group is still debating the name of "supportedXXX",
>versus "XXXsupported" versus "XXX-supported", etc.
I happen to like XXX-supported, since I think of the "tag" as being
subordinate to the attribute. Also I like the syntax being the
same. Though I could support some other character between XXX and supported,
since - is also allowed inside XXX.
>>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".
I agree.
>>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)?
I'm a fan of not having empty attributes. Furthermore, I suggest that
the Printer shall prevent the administrator from setting an XXX-supported
attribute to no values. I suggest that we pick one of
for the model document for all the XXX-supported attributes:
1. The Printer shall supply a value, even if the administrator has not
set the XXX-supported attribute. In other words, the implementation shall
return one of the standard or registered values as a built-in default value
for each of the XXX-supported attributes, so that no XXX-supported attribute
shall be able to have no values.
2. The Printer shall supply the 'uninitialized' value, if the adminstrator
has not set the XXX-supported attribute.
I prefer 1, since it is simpler and means that the system does something
useful out of the box, in spite of the system administrator.
>>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.
I agree with Roger,
If we allow the first value to be the default, why not use just that
mechanism to specify the default and not have two ways for a Printer
to indicate the default value?
Alternatively, require the XXX-default and make no statement about the
first value. That will make it clearer about default values, though
it means more attributes, and complicates a client application. But I see
no advantage to have two ways, especially if it might reduce interoperability,
and complicates the spec and the implementation of clients and Printers.
I prefer the first alternative, since it is simpler and has less attributes.
>>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.
I agree with adding these rules.
>>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.
I'm a big fan of the active voice.
>>>> 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.
No. I suggest that we require that a conforming Printer shall not
have a default value of "unknown". Lets suppose that there is a hardware
device that allows the operator to set simplex vs. duples locally at the
console (and supports setting sides by the PDL), but that doesn't allow
the software to query the output device for the current setting. A conforming
Printer (front for this output device) shall support the sides attribute
and furthermore, the Printer shall have a default value for the sides
attribute. In order to implement such a default value, the Printer would have
to always send the default value for the sides attribute ahead of each
job to the output device. But that is the only way to get reproducible
results!
We need to explicitly forbid the unknown value for a default and explain
what a conforming Printer that is a front for the output device shall do
with such an output device.
>> 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.
I think the last line should be a shall, not a should.
>>>> 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?
If we are stuck with only one return code, we need some sort of precedance
for when there are more than one. I hope we can to better than only
having one.
>> 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.
Interesting idea. Lets list this as an issue.
>>>> 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.
Good.
>>>>>>>>>>>> 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.
I claim we need to write conformance requirements for clients as well
as Printers, and we can at least say something like:
a client shall not perform an abnormal termination upon receiving
an attribute or a value in a response from a Printer, that the client
did not implement or support.