Jay,
I have some replies to your comments and some diagreements and some
differences of opinion on the facts.
I'm sorry that you won't be in Austin.
Please read my responses carefully.
Tom
At 09:35 03/29/97 PST, JK Martin wrote:
>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).
But HP has desmonstrated with their 5si Mopier that there is a solution
at least with a Novell server sitting between the client and the printer,
correct? That is configuration 3 which I added to the draft, after the
JMP agreed to add it.
>>>> 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.
I agree we need to come up with standard MIBs and that is what I have
been trying to foster.
>>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.
Yes, the mapping will help a lot. On the other hand, if each protocol
maps to the standard in different ways, a monitoring application will
have to know which job submission protocol was used, in order to know how
to display the results to its user. I would hope you would agree that
such a burden on monitoring applications would be unacceptable, especially
since Underscore would be writing monitoring applications that monitor
jobs that are submitted with a variety of job submission protocols.
For example, if LPd uses the jmJobIdNumber for the job number 0 to 999
and PJL uses jmJobIndex for its job number, your monitoring application
will have to know whether the job was submitted by PJL or LPD in order to
know what to display to the user as the job identifier.
>>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.
Jay,
Which objects were you referring to? We have pruned out objects at
successive meetings. We have also agreed to keep jmJobServiceType,
even though no job submission protocol currently has it, except IDPS.
We are down to 21 mandatory objects. Which of those do you want to
remove?
Please make specific proposals to prune out objects to the DL, rather
than complain about the objects that we have not being simple enough.
We'll listen.
I don't make the decisions either. The JMP team attempts to reach
consensus. Ron is the chairman. I'm the editor.
>>>> 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.
I change the spec as a result of the discussion, not because I feel like
changing the spec.
>>>> 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?
>
Where did you get the idea that it was a "fundamental research activity"?
I did submit the Xerox proprietary Job Monitoring MIB a year and a half
ago, and its still on your server under jmp/mibs/historical/.
See all the files with Oct 26 1995. It even compiles. But the JMP group
didn't accept it. The JMP team wanted to develop its own.
>>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.
I have written code in the past: TOPS10, VMS Common Run-time Library.
I tried to jump start the JMP by contributing the Xerox MIB, but you
guys didn't seem to see any urgency in getting the project done. We could
have had a MIB a year ago, if you had considered my contribution seriously.
>>The Job MIB effort has been going on for close to TWO YEARS now, and
>it's time to come to closure. IMMEDIATELY.
I couldn't agree more and I'm working very hard to get such closure.
>>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
>>