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.
On Wed, 5 Feb 1997, Harry Lewis <harryl@VNET.IBM.COM> wrote:
> 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
>