Hi Ron,
There are no Sharp implementations of Printer MIB v2.
However there are numerous Sharp implementations of
Printer MIB v1. Changing either textual convention
or enumerated value names from Printer MIB v1 causes
those implementations to have to be rebuilt on the
embedded products (the old local symbols would no
longer compile) and seriously breaks client-side
printer browsing implementations (which both Sharp
and Xerox folks have delivered) - very simply, the
enumerated value names in the client-side GUI panels
are broken by being changed. The client-side browser
can EITHER present the new names (for either RFC 1759
or Printer MIB v2 speaking embedded systems) OR
present the old (RFC 1759) names.
Sharp implementors (like many implementors) actually
compile the Printer MIB ASN.1 to generate local labels
and data structures - the changed names break the code
written to the old local labels (which are either equal
to or algorithmically derived by the ASN.1 compiler
from the actual MIB labels).
This is neither religion nor philosophy - this is
running code (on both devices and clients) getting
broken.
Cheers,
- Ira McDonald (consulting architect at Sharp and Xerox)
High North Inc
-----Original Message-----
From: Ron Bergman [mailto:rbergma at hitachi-hkis.com]
Sent: Wednesday, March 22, 2000 8:43 AM
To: 'pmp at pwg.org'; Harry Lewis
Cc: Tom Hastings; Ira McDonald; pmp at pwg.org; don at lexmark.com
Subject: PMP> JMP> RFC 2790 - Host Resources MIB v2 - Let's move Printer
MIB v2
Harry,
We are now in the "hot seat" to get this document completed!
Other than a couple of editorial corrections, the only real
open issue is the name changes. I have not received any
response from Tom regarding the impact to Xerox, so I can
only assume that this is not an issue. (We had one vote
for and one vote against from Xerox.)
Ira stated that Sharp was against the new names, but I have
no statement that it actually breaks an implementation.
Since the current MIB draft was completed over three years
ago and the editor during the draft development was
employed by Sharp, it it hard to believe that these changes
would break an implementation by Sharp!
I agree that the name changes should not have been made,
especially the textual conventions. But I have revised
my implementations and going back would break my code!
Actually, if there was a strong consensus, I am willing
to again change my code.
I don't see any consensus, and for this issue to surface
three years after the draft was completed, makes it seem
more like a religious issue than a real technical problem.
The weak response on this subject indicates that the
majority of WPG members don't care.
As chairman of this project, I am closing this issue. We
must move forward and get this document published.
As to incorporation of the Finisher MIB, this will surely
cause a major problem with the IETF. We are going to
have enough to worry about due to the changing Area
Director. (My real concern with the Finisher MIB is the
attribute mechanism and the negative response it received
in the Job MIB.)
When do you estimate the editing changes can be incorporated
and the document submitted as an Internet-Draft? I can
assist in any editing changes if necessary.
Ron Bergman
Hitachi Koki Imaging Solutions
-- Original message from Ira
Tue, 21 Mar 2000 14:58:42 -0800
Hi folks,
RFC 2790 - Host Resources MIB v2 (March 2000)
- IETF Draft Standard status
This was posted last week (14 March 2000) but got past
me until it showed up in the RFC Index today.
So now it's time to get on with Printer MIB v2.
I urge that we fold the text of Finisher MIB into the
Printer MIB v2 text (after all it completes the model
in original Printer MIB, RFC 1759, March 1995) and
NOT publish Finisher MIB as a separate RFC.
I also urge that we press on as quickly as possible
with publishing a definitive text for Printer MIB v2
(with the approved additions from July 1999 for new
generic alerts and 'chIPP' specification) and move it
to PMP WG last call and send it onward for IESG last
call. More than one vendor has already shipped a
product with Printer MIB v2 new objects implemented.
Remember that since the bar is now *very* high for
advancement to Draft Standard, the Printer MIB v2
MUST be published at Proposed Standard and convincing
proof of interoperable implementations of EVERY object
and object group must be presented to the IESG and
publicly posted before we can request movement to
Draft Standard status.
Cheers,
- Ira McDonald, consulting architect at Sharp Labs America
High North Inc