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
>
>
>
>