Jay,
I'm not sure why we are having this Email exchange. My entire purpose
of working on any standards is for their implementation in products
and as fast as possible. TTM is a real concern of mine, as well as yours.
I've been working as fast and as hard as I can to get closure on the
Job Monitoring MIB, starting a year and a half ago when I submitten
a complete, compilable MIB and continuing. I agree that one of the best
ways to get closure and short TTM is to go for simplicity and add after
the first ship.
Furthermore, I am most interested in writing a standard that monitoring
applications from one implementor or vendor can interwork with multiple
agents from other vendors. I'm not very interested in just writing a
MIB that works only for a vendor that writes both the client and agent.
In other words, I'm not interested in writing a standard that just becomes
a checkoff item for procurement specifications. I would think that
my objective would align with Underscore's as well here. So we need
to make sure that all implementors have the same understanding about
the specification.
Sorry you won't be in Austin to discuss this face to face.
We will definitely discuss Harry's good specific proposal for
simplification. It looks real good. Making specific proposals
for simplification, such as Harry's, is the best way to make progress
towards simplification. It doesn't help to say we need to simplify
without making a specific proposal for simplification. So please make
some specific simplification proposals yourself.
Its easier to engineer complication. The hardest and best engineering
is making things simple (and still useful).
Thanks,
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).
>>>> 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
>>