Subject: JMP> Calling all Job Monitoring MIB prototypers...

From: Harry Lewis <[email-masked]>
Date: Wed, 26 Mar 1997 16:07:41 -0500

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

Jay, you asked...

>Can we have a public "show of hands" of those persons/companies actively
>engaged in developing one or more prototypes of the Job MIB?

>I know there are at least a few companies that have been involved in
>developing their own, proprietary Job-like MIBs, but how many folks
>out there are actually working on developing an implementation of
>the Job MIB as it is currently defined?

>Given that sooo much time has been spent on this effort, it would be
>nice to know that we are not merely working on a "paper" design after
>all these years.

IBM started prototyping the PWG Job MIB and is now working on what I would call
a "hybrid" of that MIB. If I can get my act together soon enough, I hope to
have some time on the JMP agenda next week to present our findings as a result
of this prototype, the alternate paths we've taken and why.

Not only have we found it necessary to simplify our design (which, admittedly
is specific to printers, not servers) but, in thinking hard about who will use
each object and what for, we've made some changes that we feel enhance the
operation of the MIB.

I sent e-mail outlining some of our findings a few weeks back but received very
little response. I've taken that as a sign that, perhaps, everyone is focused
on IPP and loosing interest in the Job MIB. Therefore, I appreciate your query.
If there are only a small set of companies interested in the Job MIB, now,
perhaps we can reach consensus about the scope and complexity. I am willing
(and hope to be ready) to share our prototype experience and knowledge. I hope
others will do so as well.

Harry Lewis - IBM Printing Systems

---

From: [email-masked]
Date: 26 Mar 97 19:48:13 EST

Jay,

Kyocera is in the process of developing a Job Monitoring MIB which will be 
heavily influenced by the JMP effort.

Stuart Rowley

______________________________ Reply Separator _________________________________
Subject: JMP> Calling all Job Monitoring MIB prototypers...
Author:  INTERNET:[email-masked] at CSERVE
Date:    3/26/97 2:03 PM

     
     
Thanks in advance.
     
     ...jay

---

From: Bob Pentecost <[email-masked]>
Date: Thu, 27 Mar 1997 12:15:07 -0700

HP is very interested in how the Job Monitoring MIB works with our 
proprietary MIB solution. We have been putting in time and effort to make 
sure we would not loose functionality if we convert from our proprietary 
solution to the standard solution. However, it is HP's policy to not 
discuss projects that may or may not be under development.

Bob Pentecost
HP

----------
From:  JK Martin[SMTP:[email-masked]]
Sent:  Wednesday, March 26, 1997 5:18 AM
To:  [email-masked]
Subject:  JMP> Calling all Job Monitoring MIB prototypers...

Thanks in advance.

	...jay

---

From: Lloyd Young <[email-masked]>
Date: 27 Mar 97 16:53:51 EST

Lexmark is not actively engaged in developing a prototype of the
Job MIB because we currently monitor jobs utilizing IEEE 1284.1.
We are spending time reviewing the Job MIB to ensure that it 
contains the objects that we monitor today. While I can not 
directly comment on future product plans, we are potentially 
interested in the Job MIB for a future implementation.

Lloyd Young
Lexmark

----------------- Original message -------------------
To: jmp%pwg.org @ interlock.lexmark.com @ SMTP
cc:  (bcc: Lloyd Young)
From: jkm @ underscore.com (JK Martin) @ interlock.lexmark.com @ SMTP
Date: 03/26/97 12:17:36 PM
Subject: JMP> Calling all Job Monitoring MIB prototypers...

Thanks in advance.

 ...jay

---

From: Tom Hastings <[email-masked]>
Date: Fri, 28 Mar 1997 10:12:45 PST

>Harry Lewis - IBM Printing Systems

Harry,

Sorry not to respond a few weeks ago to your mail, but IPP, and geting 
the Job Monitoring MIB ready for the Internet-Draft has taken all my 
time.  Its clear from the responses to Jay's query, that there is 
real interest in the Job Monitoring MIB.

I think your ideas on adding a mapping table that an application can
use to find a specified job without having to copy the entire job table
is the biggest issue left.  I encourage you to come to the meeting with
your ideas and make a presentation.  Something like adding a table
that has an index that is the identifier that the client knows about.

The hard part is getting such an identifier from the client through the 
server into the printer where the printer agent could put it into a
table with an index that the monitoring application
can use in a single get.  Perhaps the monitoring application only gets
back the jmJobIndex and has to do one more get to get all the data.
So its an additional mapping table.

Thanks,
Tom

---

From: JK Martin <[email-masked]>
Date: Fri, 28 Mar 1997 19:44:31 -0500 (EST)

Tom,

You wrote:

> Its clear from the responses to Jay's query, that there is 

Interest, yes.  Work on a real prototype, NO.

Note that everyone made comments to the effect of either:

  "We're working on a job MIB, and watching what's happening."

or perhaps:

  "The job MIB we're developing is ``heavily influenced'' by the Job MIB"

No one actually said they were prototyping an implementation that actually
follows the specification as it stands now.  Note that I *explicitly*
asked this question in my message:

  "I know there are at least a few companies that have been involved in
   developing their own, proprietary Job-like MIBs, but how many folks
   out there are actually working on developing an implementation of
   the Job MIB as it is currently defined?"

If there is so much effort being expended on job MIB-related work,
why is no one actually trying to prototype the proposed spec?

Does anyone have an answer to that question?

Oh, and Tom, by the way.  How is Xerox's Job MIB prototyping effort
going?  I didn't see a "show of hands" from the Xerox camp.  Can you
tell us how you're doing on your prototype?

	...jay

---

From: Tom Hastings <[email-masked]>
Date: Fri, 28 Mar 1997 17:51:29 PST

Jay,

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?

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?
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?

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.

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?  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).

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.

Tom

---

From: JK Martin <[email-masked]>
Date: Sat, 29 Mar 1997 12:35:03 -0500 (EST)

Tom,

> 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...

> 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).

> MIB?  Or can we come up with an agreed means that doesn't require any

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").

> 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.

> 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

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.

> the above.  Xerox would like to implement the IETF spec when it is

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

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Sun, 30 Mar 1997 09:19:55 PST

Hi Jay,

I think you have overstepped the mark here.

You say that it is clear that Tom Hastings doesn't develop product.
That is at best, a half truth.  Tom's closest co-workers in the Xerox
open system management community include the common client group that
I act as system architect for.  Within weeks of the first version of
the Xerox Job Monitoring MIB (two years ago), our common client team
built a live prototype.  Joe Filion, who offerred excellent comments
on the Printer MIB V2.0 draft recently, is a technical team leader
in our common client group.  Joe, Tom, and I are in communication
every single week.

I am puzzled by your objections to the IDEA of the IETF Job Mon MIB.
After converging on how to manage a printer DEVICE (which will only
happen when the various vendors upgrade to the Printer MIB V2.0
and fix conformance problems found in the recent interop testing),
isn't the next natural thing to standardize the management of
printer JOBs?

Certainly robust job management is the single highest priority
that we hear from Xerox marketing and product planning folks, and
they're all DELIGHTED that the IETF Job Mon MIB project is in
progress and (in the view of many participants) making good
headway.

The original Printer MIB took several years to complete and
advance into the IETF standards process.  And experience has
taught us all that it clearly needs refinement and clarification.

Why not ease up on Tom and the other members of the JMP?

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  PO Box 221 
  Grand Marais, MI  49839

---

From: JK Martin <[email-masked]>
Date: Sun, 30 Mar 1997 15:24:31 -0500 (EST)

Ira,

It is unfortunate that you somehow misunderstand some of the major
objections I have with the way the Job Monitoring MIB has been
progressing.  Hopefully this message will serve to improve that
understanding.

First, it is important for you to recall that you have never been
present at any of the JMP meetings.  (And believe me, I wish you
had been there, at least for some of them.)  If you had been to
at least *one* of the meetings, I'm confident you would have
interpreted my last mail message in a very different way.

> Why not ease up on Tom and the other members of the JMP?

I don't recall making any kind of statements about any of the JMP
members other than Tom.  In fact, I think the other members are doing
an excellent job of persevering through the extraordinarily lengthy
process of getting the Job MIB to closure.

Another disturbing comment, for which I have no idea how you've reached

> I am puzzled by your objections to the IDEA of the IETF Job Mon MIB.

How did you ever reach this conclusion?  Those JMP members who've been
attending the JMP meetings all along know very well that your statement
does not reflect my opinion about the Job MIB in any way.  I am very
much in favor of a Job MIB...however, a SIMPLE Job MIB, and not a complex
one that attempts to solve all the world's problems in one fell swoop.

What *many* of us in the JMP group believe is that the approach taken
by Tom has resulted in an overly complicated approach to providing
print job-related info via a job MIB.  Harry Lewis (IBM) has echoed
this position *countless* times over the last several months...yet Tom
always seems to totally ignore this serious concern, and continues to
propose an object model that does not map very well to existing printing
systems.  (True, bits and pieces of the Job MIB map to most printing
system, but only in a "sparse" sense.)

> Within weeks of the first version of
> built a live prototype.

Why didn't Xerox (via Tom or some other Xerox representative) simply
propose this Xerox-developed model as a starting point?  If you review
the history of the JMP Job MIB, you can't help but believe that its
development was *not* spawned from real practice, but rather some sort
of "fundamental research" approach.

Please note that during a break at the JMP meeting in San Jose last
December, I specifically asked Tom about how Xerox's efforts were
going with prototyping the model he has been championing.  His response
was that Xerox was not currently attempting to prototype the Job MIB.
Perhaps you can now understand my concern about this.

> isn't the next natural thing to standardize the management of

It's interesting you've chosen to draw this sequence of events here,
namely "first the Printer MIB, then the Job MIB".  Yes, I agree with
you, but only in basic premise.

You see, after years of developing the Printer MIB, there is a
significant number of PMP participants who now believe the Printer MIB
itself is too complicated.  (Steve Waldbusser, our original IETF
advisor and "mentor") repeatedly warned us about going too far in the
specification, both in terms of scope and depth.  We appeared to have
ignored his warnings, and now we're paying the price.

Several of us in the JMP group believe the Job MIB has already crossed
the line of excessive complexity (quite some time ago), and we're now
trying to reign in some of that complexity, using this basic approach:

  "Start off with a SIMPLE spec to get product in the market
   and gain experience, then augment that work in the future."

However, whenever the group tries to seriously pare down the scope
and model of the Job MIB, Tom always seems to ignore these concerns
and continues to push on with a "let's get it all in on the first
draft" approach.  (How many times have we heard Tom say in a JMP
meeting "I'd like to revisit XXX..."?)

I'm hoping other JMP participants state their views on this topics.
This is not meant to be a "bash Xerox" or "bash Tom" effort, but
rather a serious plea to SIMPLIFY the spec and come to CLOSURE.

The true success of a standards effort is the IMPLEMENTATION of
that standard within products available in the marketplace.  Many
of us in the JMP believe the current model is too complex, and
will result in a "sparse" implementation for the average product.

Interoperability is key, which usually translates to lots of
products offering the same capabilities.  As it stands now, the
current Job MIB design does not promote this.

	...jay

---

From: Harry Lewis <[email-masked]>
Date: Mon, 31 Mar 1997 10:42:11 -0500

Classification:
Prologue:

>MIB?  Or can we come up with an agreed means that doesn't require any

Yes, tying together print job submission and print job monitoring
is definitely still an issue. We didn't really have a firm grasp on the
difficulties with the current PWG Job Group until we started
prototyping. The Job ID Group that I propose will accommodate registered forms
of client generated job identification. While I can devise proprietary job ID's
to operate with this MIB, I'd rather engage in open discussion about
feasibility and likelihood of the industry adopting standard formats.

I anticipate 2 areas of "controversy" with respect to my latest proposal. First
is the pwgjmJobSubmissionID (as I've called it), how it gets generated and
whether it is feasible to seek a standard. Second is in the Job State Table ...
the use of a single object pwgjmJobStateValue which has different meaning
depending on the value of another object (pwgjmJobState).

I'm telling you this "up-front" to be completely open and honest about my
proposal and it's potential shortcomings. I think the rest of my Job MIB tracks
the PWG effort closely, as it should, since what I'm presenting is the result
of our attempt to prototype the PWG Job MIB.
Harry Lewis - IBM Printing Systems

---

From: [email-masked] (Caruso,Angelo)
Date: Mon, 31 Mar 1997 10:05:13 PST

Jay,

>(server, mgmt app) talking to a "server" (printer, print server).

I agree that this problem is a tough one to solve. But, I think that 
 constraining the MIB to a simple client to one-server model will 
 result in a MIB that is useless to a huge portion of the existing 
 market. How will the simple model allow Netware-based customers to 
 monitor their jobs as they progress from client to netware print queue 
 to one of perhaps several printers that may service the queue? What 
 good is this MIB if it does not provide a solution for the majority of 
 the non-unix customer base?

>and all existing practice?

In Tom's defense, the original proposal to the PWG by Tom was in fact 
 the Xerox proprietary solution with a very few proprietary objects removed.

Thanks,
Angelo

---

From: Tom Hastings <[email-masked]>
Date: Mon, 31 Mar 1997 13:45:14 PST

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

>(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.

>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.

>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.

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.

>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.

>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.

>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.

>it's time to come to closure.  IMMEDIATELY.

I couldn't agree more and I'm working very hard to get such closure.

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Mon, 31 Mar 1997 16:38:05 PST

Hi Harry,

The Xerox community agrees with you that mapping between a CLIENT
generated job submission ID and the managed devices LOCAL job ID
is critical - thus the ClientIdMapTable in the Xerox Job Monitoring
MIB (which Tom Hastings posted to the PWG server over a year ago).

We also agree that it is desirable to register one (or probably
several) 'well-known' forms of client job ID.  We have a form
(really a family of forms) which has worked well and has been
in product for over two years.  If the JMP folks are interested,
we'll be glad to show them.

Although Xerox (like most of the JMP members) is cautious about
announcing future product plans, I can say for certain that
truly open, standards-based, network management of network
connected products is the end objective of the Xerox community.

Thanks for your efforts prototyping the IETF Job Mon MIB.  I
reviewed your very interesting slides last week.  Good work!

Cheers,

>------------------------ Included Message ----------------------<
>From [email-masked] Mon Mar 31 10:52:16 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Subject: Re: JMP> Calling all Job Monitoring MIB prototypers...
Date: Mon, 31 Mar 1997 07:42:11 PST
Sender: [email-masked]
Status: R

Classification:
Prologue: