Subject: JMP> Straw vote request: interest in splitting the Job MIB into two MIBs

From: JK Martin <[email-masked]>
Date: Fri, 9 May 1997 15:01:38 -0400 (EDT)

At this risk of ticking off our fine chairman (Ron Bergman), I'd
like to ask everyone to participate in a quick-and-dirty straw vote.

Stuart Rowley commented:

>      Jay said he is starting to like the sound of a Job State MIB and a Job 
>      Attribute MIB.  Maybe this isn't as far fetched as it sounds.  Like 
>      Harry, I view the monitoring and accounting aspects of the MIB as 
>      addressing distinctly different needs.  Perhaps we should separate the 
>      MIB to meet these different needs.  We sure could make a simple Job 
>      State MIB which would likely be implemented across the board!

How many others feel this way?  (And how many others are opposed?)

Would it be possible for all list participants to post their one-word
opinion/vote on this question:

  Are you in favor of the JMP group exploring the potential for
  splitting the current Job Monitoring MIB into two separate MIBs,
  one that focuses on job status and the other for job accounting?

Just a simple "Yes" or "No" is being requested; if you want to add
something to the discussion, then great!  But let's at least see
whether this is a topic worth investigating *before* the San Diego
meetings next week.

	...jay

---

From: Ron Bergman <[email-masked]>
Date: Mon, 12 May 1997 08:07:39 -0700 (PDT)

Jay,

I would vote NO to split the Job MIB.

The functionality of the Job Monitoring and Job Accounting are so closely
related that it would be foolish to try to separate.  Also, we are so
very close to completion, it would most likely take longer to perform
a split.  (I agree that this point is subject to different opinions.)

I believe that the issues that are currently open are not as serious as
some folks perceive and will be quickly solved.  

The MIB is now very small even though the document is very large.  The
document does contain a large amount of descriptive text, some of which
could be eliminated.  Suggestions here are encouraged.

A significant portion of the document is devoted to the job attributes.
While I agree that most of these attributes are not useful to present
day printers, they may be useful in future products that are IPP 
compatible.  I have not objected to the inclusion of the many
attributes in an attempt to maintain compatibility with IPP.  The
attribute list is similar to the Channel Table enums in the printer 
MIB, where only a small percentage of the available values are
actually used.

	Ron Bergman
	Dataproducts Corp