Sorry, but I believe we're wasting valuable time here.
> I must leave the PWG meetings on Thursday at noon therefore
> having a PMP session on Thursday afternoon will not work.
> Regardless, I think this is the type of issue that is best
> worked out over the mailing list anyway.
If you must leave the PWG meetings by noon--and you won't let
anyone else act on your behalf as Chairman--then why don't we
move the PWG Wednesday schedule to:
8:00 - 10:00: PMP
10:30 - 3:00: IPP
3:30 - 5:30: Sense
That way you can make it, and the IPP-only attendees get to
sleep in a bit.
Carl-Uno: do you have any problems with this slight change
in the IPP schedule? Please confirm asap.
If this change is not possible, then perhaps the PMP should
meet on WEDNESDAY NIGHT to resolve these and other PMP issues.
Lloyd, we need to nail this issue once and for all such that
we don't revisit it again.
> I would like to
> hear more discussion before charging down a path of rolling
> this fix into the MIB.
Lloyd, with all due respect, exactly what is it you expect
in terms of a response? Harry has posted at least two messages
on this topic, and got (only) two POSITIVE responses (from Tom
and myself). There were NO negative responses.
If you believe one or more vendors is concerned about Harry's
proposal, then please say so. (For all we know, Lexmark may
be concerned for some reason...)
It is important to realize that the PWG hasn't done a very good
job historically in driving stakes in the ground with respect
to "voting" and "deadlines". Just saying "I'd like to see what
other folks have to say..." is fine, but if you're looking to
draw consensus, then you must ask something like:
"I would like to hear what others on the list have to say
about this topic. Please submit your comments no later
than XXX, afterwhich I will draw consensus from the posted
comments received as of that date."
Without a firm deadline, most issues will languish indefinitely.
We must do a better job of guiding discussion and resolutions
in a timely and well-defined manner.
> This is the type of problem that can
> be worked out in a very logical fashion. There actually are a
> very simple set of questions that need to be answered and the
> solution should become very obvious:
>
> 1. Is this a problem that needs to be fixed?
> I would like to hear from more of the host application providers.
> Harry, Jay, and Tom have replied that they think it needs to be
> fixed.
Unless you specifically request input from specific participants
(either publicly or privately), then you can't expect a response.
That has ALWAYS been the history of the PWG. (Most participants
are developers actively engaged in product development, with little
time to "chat" on mailing lists.)
> 2. What is the solution to the problem if it needs to be fixed?
> Harry has proposed a solution. My concern is that the fix not
> break any host applications that have appeared to date. I think
> Harry's proposal where we continue to use the existing bits and
> use the additional bits to add additional information seems to
> be a good compromise. However again I would like to hear from
> the host application providers.
Sorry, but I'm really confused here. Are you asking for ALTERNATIVE
proposals to fix the problem, or what?? I have already publicly
stated that Harry's proposal does not "break" our implementations;
more importantly, we stand ready to change our implementation to
fit Harry's proposal in any case. Apparently Xerox (via Tom)
believes something must be done here, although no specific comments
were posted in Tom's message (unfortunately).
> This is one situation where we need to forgot what happened in
> the past and decide how to move forward. I am going to start
> a new thread for this discussion primarily to gather answers
> to the first question.
I guess I just don't get it, Lloyd. Forget what? An unfortunate
binding to an IETF effort that has since languished?
Look, Harry's proposed solution is very, VERY simple, with only
the absolute minimum "tweaks" to the HR MIB integration. Moreover,
Harry's solution proposes to extend the HR MIB in one small area
that was explicitly designed to handle such extensions (ie, the
status bits of the status octet string).
We couldn't ask for a more simple, extensible solution.
> We should not let Draft Standard or Proposed Standard influence
> our decision. It appears in discussions that Chris and I have
> had with our Area Directors that the best thing for the new
> Printer MIB is to go to Proposed and then when the HR MIB
> goes to Draft, we go to Draft immediately afterwards.
My position has been the same all along: as long as all players
in the printer (and related) industries all use the same spec,
then it doesn't matter which organization "sponsors" the spec.
Draft? Proposed? Sanctified? Holy Scroll? Who cares?
What we should ALL care about is whether the HR MIB is changed
in the future such that it interferes with the current Printer
MIB integration. For example, what happens if the HR MIB is
changed such that our use of the "HR MIB magic cookie" values
changes? Then what???
With all due respect, the PMP really should address Harry's
concerns in a timely manner. To date we have effectively
blown off his repeated attempts to address and repair this
longstanding situation. Let's resolve this once and for all.
Besides, the solution is SIMPLE, for once.
> Regards,
> Lloyd
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------