Here are my comments on the attributes table that Scott posted.
It will help us a lot in updating the document to use this table as
a work sheet.
Thanks for doing.
Tom
At 13:01 05/06/97 PDT, Scott Isaacson wrote:
>I posted the following:
>>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.doc>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.pdf>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/atts-rev-4.txt>>This shows the relationship between Job attributes, Printer default
>attributes,
>supported, and the new proposed "capable" attributes.
>>Take a look and we will discuss on Friday.
>>Scott
1. Clarify that Opt/Man means optional/mandatory for the Printer to
implement (not the requester to implement, not for the requester to supply
in a request.
2. I think we need the Opt/Man for every box in the table, not just for rows.
Since most are optional for Printer conformance, just add an * to each cell
that is mandatory for a Printer to implement.
3. If the job-name is not queriable then how can the client find out if
the Printer implements job-name? I suggest that the default value of a
text attribute be either the empty string, or a string with just an "*" in
it. We need to pick one of those forms and specify default text that way.
4. A lot of 1setOf got changed to setOf. I'm still trying to sell you all
on the idea that we not have setOf at all where an attribute can have no
value or only for the very few attributes whose values are registered by
some other source, for which we can't get a distinguished 'none' value.
Reasons for opposing emtpy attribute values in the client to Printer or
in responses from the Printer to the Client:
a. Most attributes have a distinguished value for none already, so have a
second way, namely an attribute with no value, is more complex and will
likely lead to inoperatibility problems where some implementation send one
form, some send the other, and all implemementations have to accept both
forms, in order to achieve interoperability.
b. Its very confusing to users to see or specify an attribute with no values.
Only programmers and mathematicians are comformatble with empty sets.
c. When advertizing the xxx-supported, we would need a way to indicate whether
an empty value is supported or not! Ugh. It so much simpler for the
xxx-supported to include the explicity 'none' value as one of the values
that are supported, if that is a legal value and to omit the 'none' value
from the xxx-supported attribute if 'none' is not supported.
d. If a Printer doesn't implement an attribute at all or doesn't implement
an attribute for a particular document-format, the Printer just omits
returning that attribute at all on a GetAttributes operation.
So the only attribute that I think there might be a case for setOf, instead
of 1setOf, is notification-addresses, where URLs are the values.
5. I suggest that medium be changed from type 2 keyword to type 4 keyword.
The IPP standard can still have the long list of standard values for
type 4 keywords.
6. Need to add Opt/Man for the other tables. If add * to each cell,
then fine.
7. For consistency with the rest of the attributes in the second table, how
about adding "job-" to "submission-time" and "completion-time"?
8. document-URL - need way to find out what schemes are supported for
documents.