Roger,
Thanks for the complete review of the doc. Some of my comments:
>>> <rdebry at us.ibm.com> 02/17/97 11:08am >>>
> Section 4.1.1.2 Print Response:
> If the response to a print request always includes Job Status and
> Printer State, then I would propose not including other requested
> attributes in the print request. In the requirements scenarios, job status
> and printer state were the only two attrinbutes I ever specified in the
> request.
Sounds like we all agree that we can do without "requested attributes". I
have created a new issue on the Model issues list for the notion of Job
and Printer state and state reasons being returned in the print response.
>>> <rdebry at us.ibm.com> 02/17/97 11:08am >>>
> Section 5.2.2.1 Job-sheets
> Where ever we have type3enums, would it be worth mentioning in the
> text that additional attribute values may be defined for those of us who
> can never remember what a type3enum means?
I can never remember either, but we do define it clearly right at the
begining of 5.1. I am sure we do not want to define it over an over
again.
>>> <rdebry at us.ibm.com> 02/17/97 11:08am >>>
> 5.2.4.1 job-priority
> I'd like to see more values here. I can't map IPP to existing operating
> system, like MVS, which allow more priorities. MVS users would like to
> see the same service on the web that they see in today's operation.
You can always have a mapping - might not be very good, but you can
always do it. Supposing one system A, has some priorities. IPP has 3. If
A has less than 3, just map to some set of IPP values. If A has more than
3, map multiple values from A to one value in IPP.
If: Set A {none} Set IPP {low, med, high}
Mapping 1: none -> low
Mapping 2: none -> high
If: Set A {1, 2} Set IPP {low, med, high}
Mapping 1: 1 -> low, 2 -> high
Mapping 2: 1 -> med, 2 -> high
If: Set A {1, 2, 3, ..., 100} Set IPP {low, med, high}
Mapping 1: 1,2,..., 33 -> low, 34-67 -> med, 68-100 -> high
I do not want the IPP Model to turn into a smallest common subset or
union of all printing systems. I want it to be a "reasonable" view for all
printing subsystems. I don't even think the right words are greatest
common subset (since one trivial printing system brings the whole thing
down into the mud). We, as participating companies, all have different
markets with different types of customers, however, from the Novell
perspective, we have found that 100 different values are TOO many. I
am sure that we can satisfy over 95% of electronic distributed printing
with only 3 values.
Scott Isaacson