IPP> MOD - Editorial comments on Model

IPP> MOD - Editorial comments on Model

IPP> MOD - Editorial comments on Model

Tom Hastings hastings at cp10.es.xerox.com
Mon Jul 14 14:17:20 EDT 1997


Carl-Uno,


The Job Monitoring MIB is ahead of IPP, so your concern that one
would hold up the other is not a problem.


Furthermore, if there are additional values that are added to, say IPP,
for printer resolution that didn't make Job Mon MIB, there is no
problem.  These are type 2 enums that can be added to anytime and have
all the validity as if they were in the standard.


Our plan is to complete the next JMP draft this week and that will be the
one that we forward to IESG this month.


I also want to make sure that IPP people are happy with making
these 5 attribute values enums, instead of keywords.  If any of them
change back to keywords, then the Job Monitoring MIB would want to
change them to be OCTET STRING, instead of Integer32 as well.


So its important to both JMP and IPP to reach agreement on these five
attributes and their data types.


Tom


At 09:23 07/13/97 PDT, Carl-Uno Manros wrote:
>At 03:17 AM 7/12/97 PDT, you 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
>
>
>
>



More information about the Ipp mailing list