Subject: PMP> hrPrtDetectedErrorState

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Wed, 5 Feb 97 22:17:25 MST

An area of difficulty, confirmed during the Stardst interoperability
testing, has to do with mapping printer conditions into the current
set of hrDeviceStatus, hrPrinterStatus and hrPrtDetectedErrorState.

Below is an excerpt of my previous posting, slightly modified for
brevity, wherein I propose extending the hrPrtDetectedErrorState
definitions to improve our condition.

>Date: Thu, 12 Dec 96 16:52:59 MST
>From: "Harry Lewis <[email-masked]>" <[email-masked]>
>To: [email-masked]
>Subject: PWG> hrPrtDetectedErrorState
>
>... preamble                                                            r
>
>Here are my initial recommendations for new (hrPrtDetectedErrorState)
>bit definitions:
>
>  Tray Open
>  Output Full
>  Toner Cartridge Missing                               (bit)           )
>
>Currently, our implementation maps Tray Open to       Low Paper
>                                 Output Full          Service Requested
>                     Toner Cartridge Missing          No Toner
>
>I have to imagine that other implementation work in a similar fashion and I'll
>bet interoperability testing would demonstrate differences in how we all do
>it!

There is nothing in this proposal that says I have defined the ultimate
set of mappings or achieved world peace. These are only derived from
real experience and only address our immediate needs.

At Stardust, I proposed this again, but the notion was rejected on the
basis of two main themes:

1. Since there has been ambiguity in this area in the past, it may
   be less likely for software to ever be written as though it can
   "trust" printer responses regarding these attributes.

2. If we try to define more "bits" we will inevitably fall short of
   perfection and therefor will be right back where we are today,
   finding some ambiguity somewhere, so why even try.

I'm restating my proposal clearly, one more time, in this context,
because, I am missing the point of why, if we're going to embark
on "standard mappings" wherein implementations may need to adjust,
we are so shy to take the opportunity to attempt to resolve known
ambiguity in a more deterministic fashion.

 Harry Lewis - IBM Printing Systems

---

From: JK Martin <[email-masked]>
Date: Thu, 06 Feb 1997 19:49:45 -0500

Harry,

I have no problem (now) with the notion of extending the octet string
definition of hrPrtDetectedErrorState, given you fine explanation of
the situation at the interop test earlier this week.

However, are you suggesting that this become part of the "changes"
made to RFC1759 as it moves from Proposed to Draft, or would this
be part of Printer MIB II (the sequel)?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Chris Wellens <[email-masked]>
Date: Fri, 7 Feb 1997 05:13:30 -0800 (PST)

Harry,

I had a different recollection of the Stardust testing and discussion
from what you have presented.   The testing revealed serious problems
with hrPrtDetectedErrorState, and a number of other areas (Lloyd
and I are still compiling all the results).

On Wednesday, we stepped through the results of one set of tests
just to see where we were, and our discussion led to
hrPrtDetectedErrorState.  I heard two proposals for handling it:

(1) Ignore it (ultimately this would mean rendering
it "obsolete" or "historic" -- I will have to check the rules.)

(2)  Do explicit mappings to precisely define it (your
proposal).

At the time, I made a comment that I saw the latter as extremely
difficult. Then at least two suggestions were made as to how it
could work.  I assumed that you would be taking these
comments and suggestions and writing up a proposal and new
language for how to fix it.  

If you come up with a proposal and we have rough consensus on accepting
it, we would certainly add this to our list of changes to both RFC 1759
and RFC 1514 that are necessary based on the results of our
interoperability testing.

I would like to thank you and all the companies and individuals
who worked very hard for three days going through all the
testing.  The difficult, tedious part is now behind us.  Our
next step is to study the results and propose the solutions.

Please don't get discouraged; I am counting on your proposal.