Tom,
> You ask some good questions here. We need to discuss what is needed to
> make the Job Monitoring spec be the thing that is being prototyped.
> Lets put this discussion on the JMP agenda for next week?
Regretably, I will not be able to make the Austin meetings. However,
I have been in pretty close contact with Harry Lewis about most of
these issues, and I believe Harry can accurately state my views in
my absense.
--- NOTE TO AUSTIN-BOUND JOB MIB MEETING ATTENDEES ---
Please take a few moments before the Job MIB meeting to read this
message, then form your own opinions and (please!) publicly state
your opinions at the meeting. The day of reckoning draws near...
> Is it some of the remaining issues, such as how a client can find
> a particular job that passes through a server to a Printer with the MIB?
It could very well be. Underscore has studied this problem over the
last year or so, and it appears to be a very difficult nut to crack.
So much so, that we now agree with Harry (and some others) in stating
that the Job MIB should be constrained to a simple client-server
model...with no intervening print server concept. Just a "client"
(server, mgmt app) talking to a "server" (printer, print server).
> Does it take proprietary solutions to solve this problem, so that that
> is why implementors are doing something based on the spec, but not
> actually implementing the spec. Perhaps the proprietary solutions
> can be separate MIBs that merely augments a conforming IETF Job Monitoring
> MIB? Or can we come up with an agreed means that doesn't require any
> proprietary solutions?
You can do anything with proprietary MIBs. But that is not the point.
We need to create standard MIBs here.
A long time ago I passionately argued for a modular approach, whereby
the initial Job MIB would be VERY VERY SIMPLE, and that we would then
augment that simple MIB to support such things as accounting, etc.
That way we could get the SIMPLE MIB out in the marketplace as quickly
as possible so as to gain some real operational experience, particularly
in order to know exactly what kinds of extensions are truly necessary
(ie, "necessary" == "demanded by paying customers").
> Another reason is that, as HP points out, we need to better understand
> how each object is used with each job submission protocol and in each
> of the configurations that we are trying to support. How can we make
> better progress on this part? I'll be glad to document the understandings
> in the spec, so that they can be tested during interoperability testing.
This paragraph really scares me, Tom. I thought the whole purpose of
developing the table of "Existing Protocols Mapped to Job MIB Attributes"
was supposed to address this topic.
And, please recall (PLEASE), that last November in New Orleans, I pointed
out that the Job MIB actually contained attributes for which NO EXISTING
PRINT SUBMISSION PROTOCOL SUPPORTS. That is, you had added attributes
that do not map to any existing print submission protocol.
During that meeting I suggested that we IMMEDIATELY remove those attributes.
You did not agree, stating (as usual) that "someone in the future might
find a need for those attributes" (or something to that effect).
This is sheer lunacy. And the paying marketplace suffers as a result,
not to mention the vendors who wish to develop and deliver useful solutions
to that marketplace.
> Of course, another reason may be that the committee keeps evolving
> the spec with each meeting, so that it is a moving target. Is this
> a problem?
If this weren't so sad, I'd really have to laugh. Tom, YOU are the one
who keeps changing the spec! Yes, the group then ends up making more
changes...but almost always because your new changes don't map to any
known reality in the market-driven world.
> Except for the remaining issues, I think we are reaching
> more stability. We keep removing objects, so that now we are down to
> only 21 mandatory objects (but we have 45 attributes, that are conditionally
> manatory: you implement them if you got them).
I think everyone should listen to what Harry Lewis is going to present.
If the group doesn't buy Harry's approach, then I'd like to propose that
Hewlett-Packard submit their Job MIB to the PWG as a new candidate for
the official Job MIB (with all HP-proprietary stuff removed, of course).
Similarly, any other vendor with a known working solution should be
invited to propose their model.
> Xerox has its own job monitoring MIB as well with its own solutions to
> the above. Xerox would like to implement the IETF spec when it is
> stablized.
Then why on earth didn't you just propose the solution as developed by
Xerox, for heaven's sake?? Why did you constantly view the Job MIB
effort as a "fundamental research activity", apparently ignoring any
and all existing practice?
Tom, you really have quite the ability to generate massive amounts of
spec-oriented material. You do that very well, and much of the content
is quite interesting. However, it is also clear that, unlike almost
all other Job MIB participants, you do not actually develop product.
More importantly, since you don't develop product, you have very little
sensitivity to the concepts of "time to market" and plain, old fashioned
bottom-line responsibility.
The Job MIB effort has been going on for close to TWO YEARS now, and
it's time to come to closure. IMMEDIATELY.
I apologize for the particularly intense flame-o-gram here, but enough
is enough. Standards developed by the PWG are intended as a vehicle
to promote free enterprise within a level-playing-field environment.
The PWG is NOT an altruistic body of interested people, but rather a
group of cooperating competitors trying to raise the reference bar for
new technologies in an evolutionary manner.
Let's close this effort and get to the task of developing products for
our customers.
...jay