I question whether the enum data type is the best choice for
"printer-resolution". It would seem better to leave these values as
keywords, since that would make it easier to manage, debug, and introduce
new values promptly. There doesn't appear to be a localization issue here.
The only issue I see would be the case where inches must be converted to
mm, e.g., for fax purposes; but the situation here is the same whether the
"printer-resolution" datatype is an enum or a keyword.
Stan . . .
At 10:06 AM 7/13/97 PDT, Carl-Uno Manros wrote:
>At 03:17 AM 7/12/97 PDT, Tom wrote:
>>Scott,
>>>>I edited with revisions ipp-model-970623-rev.doc (after accepting revisions)
>>>>and put back in:
>>ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/>>-rw-r--r-- 1 pwg pwg 311296 Jul 12 10:09
ipp-model-970623-th.doc
>>>>I've included the new enum data type and the enums values for the
>>five attributes that we agreed to be enums instead of keywords
>>and which aligns with the Job Monitoring MIB:
>>>> "finishings"
>> "print-quality"
>> "printer-resolution"
>> "job-state"
>> "document-format"
>>>>I also copied in the "job-state" and "job-state-reasons" that we agreed
>>to jointly between the JMP and IPP.
>>>>NOTE: that going back to Printer MIB document-format enums means that
>>PDF needs to get registered. Would be nice to include PDF in the
>>Printer MIB textual-conventions that is due this week.
>>>>Tom
>>>>Tom,
>>are we sure that we know what we are doing here? The recommended solution
from
>Nashua to use "enums" where they were already defined in other standards
sounded
>good at the time, but does the Job Monitoring MIB really fall into that
category
> - YET?
>>I do not want the progression of IPP to be dependent and possibly delayed
by the
>Job Monitoring MIB project. Are we convincened that the Job Monitoring work
>will
>proceed with at least the same speeed as IPP?
>>Carl-Uno
>>>>