Subject: IPP> MOD - New enum data type and attributes text

From: Tom Hastings <[email-masked]>
Date: Mon, 14 Jul 1997 01:15:45 PDT

I've posted the subset of the IPP Model document that deals with the
new enum data type and the 5 attributes that are changed from
type keyword to type enum:

ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/
-rw-r--r--   1 pwg      pwg        43520 Jul 14 08:07 ipp-enum.doc
-rw-r--r--   1 pwg      pwg        45379 Jul 14 08:07 ipp-enum.pdf

This makes it easier for PWG people to review just that part which
is new concerning enums as agreed to at Nashua affecting these attributes:

  "finishings"
  "print-quality"
  "printer-resolution"
  "job-state"
  "document-format"

Send any comments ASAP, as Scott is incorporating this into the Model
document.

Thanks,
Tom

>Date: Sat, 12 Jul 1997 03:17:20 -0700
>To: scott
>From: Tom Hastings <[email-masked]>
>Subject: MOD - Editorial comments on Model
>Cc: ipp, jmp
>
>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
>

---

From: [email-masked] (Robert Herriot)
Date: Mon, 14 Jul 1997 13:56:58 -0700

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

Just my 2 cents.

Bob Herriot

---

From: Tom Hastings <[email-masked]>
Date: Mon, 14 Jul 1997 15:59:58 PDT

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

>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