At 13:56 07/14/97 PDT, Robert Herriot wrote:
>>For the most part, I think that it is good that we have changed
>some keywords to enums so that we line up with other standards.
>>I have a few observations.
>>It is a bit strange that IPP aligns for job-state, but not for
>job-state-reason, printer-state or printer-state-reasons. It would
>seem better if printer-state and job-state had the same type, either
>both enums or both keywords.
I agree. Lets change printer-state from keyword to enum.
NOTE: the Job Monitoring MIB doesn't have printer-state, so this
is only an IPP issue (that is why I didn't think of proposing
printer-state as an enum.
NOTE: also making printer-state an enum doesn't follow the rationale
that we use enums from other standards. But maybe this is just the
"exception that makes the rule".
NOTE: the Printer MIB printer state enum(s) are all messed up, so we
don't want to use them for sure in IPP.
>>I am also concerned about printer-resolution. I don't see the advantage
>of abitrary keywords over a value that gives the resolution explictly,
>either the keyword string we had or a pair integers with units. Both
>of these solutions allow a client and server to understand the values
>without some middleman registry.
NOTE: with keyword values, we still want/need a middleman registry, but
the advantage is that the actual value can be parsed. Also the value
can be displayed without localization problems, since they are decimal
digits.
Another argument in favor of NOT using enums for printer-resolution
is that there were some omissions in the values:
1. res400 was omitted (though 400x800 and 800x400 is included)
2. res200x100 was omitted (though 100x200 is included).
3. res1600 is used by scanners and should be added.
Talking with Scott, we agreed to put them in IPP and Job Monitoring MIB
together with the same values. Since neither have been published widely,
we put them into the proper enum sequence. After this however, new values
will go at the end. We also decided to leave a gap between the values
that are the same in both dimensions and the ones that are different.
So res100x200 will start at res100x200(100).
On the other hand, do implementors have to have an enum table internally
of legal values, since they can't parse out any arbitrary value, but only
certain values? So the advantage of enums is that the discrete values
are standardized. Software conversion from one to another resolution
is done with pair-wise algorithms.
We will leave it as an issue whether to go back to keywords for
"printer-resolution" or leave them as enums in this Internet-Draft
for IPP. If we can decide in time for IPP, we can fix the Job Monitoring
MIB to be keyword or enum.
Tom
>>Just my 2 cents.
>>Bob Herriot
>>>