Subject: JMP> Re: Mandatory objects, Printer MIB relationship and more

From: Tom Hastings <[email-masked]>
Date: Thu, 8 May 1997 15:57:31 PDT

At 07:12 05/07/97 PDT, Jay Martin wrote:
>Tom,
>
>> But changing the jobStateAssociatedValue to use outputBinIndex 
>> brings up another issue, which I'm calling issue 73:
>> 
>> Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue
>> object and attribute require it, but an implementation doesn't have the
>> Printer MIB, the agent has to put 0 as the value.  Should we add one more
>> attribute: outputBinNumber, which is just a number, not an index into the
>> Printer MIB?  If we do, which should be mandatory?  Just one more reason to
>> get rid of the AssociatedValue object and attribute, which is forcing us to
>> pick a particular outputBin implementation and make it mandatory.  If we got
>> rid of the AssociatedValue object/attribute, we could forget about making
>> any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute
>> mandatory.
>> 
>> If we get rid of the AssociatedValue object/attribute, then we don't
>> need to add the outputBinNumber attribute either, since an implementation
>> can just put in the ASCII digits for the bin number into the outputBinName
>> attribute.
>
>I'm sorry, but this is getting to be just plain scarry.
>
>When I read "If outputBinIndex is made mandatory...", it makes me realize
>that I don't have a good handle for exactly what the minimum conforming
>implementation is at this point.
>
>Can you post a simple text-only table of all the mandatory elements of
>the Job MIB?  (Something like one line per mandatory element would be
>great.)

Here is lines 1007-1016 from the Internet-Draft 00 (V0.81:

The mandatory attributes are:

    jobState(3)
    numberOfInterveningJobs(9)
    deviceAlertCode(10)
    jobKOctetsRequested(48)
    jobKOctetsCompleted(50)
    impressionsRequested(54)
    impressionsCompleted(55)
    outputBinName(35)                     [but as Harry pointed out, has to
                                           be an integer to fit with the
                                           AssociatedValue object]

However, I have added Issue 76: So should jobName, jobOwner, and one of
deviceNameRequested or queueNameRequested be made Mandatory?
because they were mandatory when we had a Job Table, but when we deleted
the job table and moved them into the Attribute table, we didn't make
them Mandatory.

>
>Tom, we are really getting down to the wire on the Job MIB (right????).
>When you write words like:
>
>   "Just one more reason to get rid of the AssociatedValue object
>    and attribute..."
>
>it makes me think the basic Job MIB functional model is not completely
>thought out.  It this stage of the game, we need to have the functional
>model complete, wouldn't you agree?

I'm not sure what you mean by "functional model".

Lines 286-319, "1.2 Types of Job Monitoring Applications" has the three
models for applications: monitor one active job, monitor all active jobs
on a printer or server, and gather accounting or usage information on 
completed jobs on a printer or server.

Lines 406-556, "3. Configurations for the Job Monitoring MIB", has the
three system configurations that the MIB is designed to support.

The current draft has two ways to access the 8 mandatory items:

 a. The Job State Table represents 3 as mandatory objects and the other 5
    with the "multi-plexed" AssociatedValue object which has a representation 
    that depends on the state of the job, i.e., which is a "fan out" to 5 
    different attributes depending on which of the 7 job states the job is
    in.  

 b. The same 8 mandatory items ALSO exist as mandatory attributes in the 
    Attribute Table.  So an application can access the same information 
    either by using the Job State table or the Attribute table.

>
>
>Another key question we've danced around over the years is how closely
>is the Printer MIB related to the Job MIB?
>
>Didn't we come to the consensus where an agent supporting the Job MIB
>did not necessarily have support for the Printer MIB?  That is, there
>should no binding between the Job MIB and the Printer MIB.  Do I have
>that right?

Almost.  We agreed that a conforming agent did not need to implement the
Printer MIB.  Therefore, we shouldn't have any Mandatory attributes that
require the Printer MIB.  On the other hand, for Conditionally Mandatory
attributes there is no problem with them being tightly coupled with the
Printer MIB, say, by being indexes into the Printer MIB.
Then an implementation that does include the Printer MIB can get tight
coupling.  In other words, we are trying for a win-win here.  Implementations
that also have the Printer MIB will be able to take advantage of that.
Implementations that don't have the Printer MIB will not be unduly short
changed in what they can express.

>
>I certainly understand the desire to keep the two MIBs conceptually the
>same, at least in terms of modeling characteristics, terminology, etc.
>It's the explicit binding between the two that I'm asking about here.

I hope my answer helps.

>
>
>> On the other hand, I think we considered this and decided that it was
>> cleaner and simpler to have two separate enums, one for the Integer
>> value and the other for the Octets value.
>>
>> [...]
>>
>> ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus?
>> 
>> Analysis of the 78 attributes shows that there are 8 attribute
>> pairs that could be collapsed into one attribute with the implementation
>> using either the Integer or the Octets value (or both) to represent
>> the attribute.  The application would have to query both value objects.
>> But if it is using GetNext, it has to get both each time anyway.
>> Only if it is directly accessing an attribute would it have to get
>> both values.  On the other hand, it would be fewer Gets than having
>> two attributes as we have now.
>>
>> [...]
>>
>> Should we allow an implementation to fill in both with meaningful values?
>
>Can someone state the fundamental rationale for taking the approach of
>having two enums, one for Integer and one for Octets?  This is very
>confusing to me.  A few words of explanation might help here.

First, not every attribute comes in two flavors: integer and octets.
Only 8 out of 78 do.  Most attributes are by their nature, either an
integer or an octet string.  File names and DateAndTime data types are
reprsented as octet strings.  Counts, counters, and enums are represented
as integers.

>
>
>Why, oh why is the Job MIB so COMPLEX ???
>
>To solve the #1 problem of "Is my job done yet?", we have devolved into
>one of the most complex MIB definitions yet.

Gee, I think it is one of the simplest MIBs!.  It has only 4 groups, all 
mandatory, with a total of 13 object.  No read-write, no trapping. 
True, in addition there are 8 mandatory attributes, and 70 conditionally 
mandatory attributes, but implementations can do just the 8 mandatory 
attribute or can do as many more as they want.

We could even simplify further, if we get rid of the Job State table and the 
AssociatedValue multi-plexed attribute)!  It would be only three groups, all 
mandatory, for a total of 10 objects.

>
>Doesn't this concern anyone else?  (Hopefully some of the other vendors
>doing a prototype can respond here.)

Are you concerned about the implementation of agents or applications,
I'm not sure which.  If you could give some specific concern about
complexity, that would help us understand your concerns.

>	...jay

---

From: JK Martin <[email-masked]> (by way of Tom Hastings <[email-masked]>)
Date: Mon, 12 May 1997 08:07:25 PDT

[This reply from Jay to me was inadvertantly cc'd to PMP, instead of JMP.
So I've re-directed it to JMP.]

Tom,

Thanks for taking the time to help me understand the Job MIB.
I appreciate it.  (I really do!)

I realize some of my questions sound like I'm asking you to spoon-feed
me on some of these issues and topics.  Please be patient and indulge
me for a moment.  Imagine I'm a newbie to the Job MIB, one who is thinking
about using the Job MIB to solve a problem surrounding job state monitoring.

>                                            be an integer to fit with the

Sorry, but I probably didn't state the question correctly.  When I asked
for a list of mandatory "elements", I meant MIB objects, not just attributes.
(You discuss such mandatory elements later in your message.)

Here I am asking: What is the minimum skin I have to put in the game to
get going?  I look at the Job MIB and it looks, well...real complicated.

I'm just trying to see where to get going in solving my problem.

> the job table and moved them into the Attribute table, we didn't make

Sounds funny to ask "should jobName and jobOwner be mandatory?"  How does
my app identify the jobs currently in the table?

> At this stage of the game, we need to have the functional

Thanks for the fine pointers to the spec.  I'll admit that it's been
a while since I had last read them, so I'll take another look.

However, here's a very explicit example of the complexities in the
Job MIB; this text was in your descriptions of the pointers for me

>     different attributes depending on which of the 7 job states the job is

Say what???  Can I have that in English, please?  ;-)

Really, though, this kind of "description" scares the bejeezes out of us.
Pray tell, is the term "multi-plexed" a common SNMP-related term?

Or was it expressly invented for use in the Job MIB?  ;-)

>     either by using the Job State table or the Attribute table.

Hmmm, let me state that last question is bit differently, albeit in a
hypothetical manner:

  So an application can access the same information either by using the
  Job State MIB or the Job Accounting MIB.

I'm starting to like that statement a lot better, actually.

> changed in what they can express.

Sounds like a good plan, Tom.  Just to make sure I understand your above
explanation:

  Those objects in the Job MIB having a corresponding relationship in the
  Printer MIB have values that are entirely independent of the Printer MIB.
  That is, an application using the Job MIB does not need to know anything
  about the Printer MIB in any way in order to take advantage of all the
  features provided by the Job MIB.

Is this correct?

> reprsented as octet strings.  Counts, counters, and enums are represented

Sorry, but I don't think you answered my question.

You state that only 8 out of 78 (!) attributes have both integer and string
forms.  But you didn't say WHY having multiple forms was necessary in the
first place.

> attribute or can do as many more as they want.

Your description certainly paints a decent picture of simplicity.  However,
why are the threads between yourself and Harry over the last couple of weeks
so gawd-awfully convoluted?  For something so simple, it sure looks so
complex.

Speaking of those "8 mandatory attributes":

>     outputBinName(35)

Why is outputBinName mandatory, yet the same is not true for the
input tray name?

> mandatory, for a total of 10 objects.

Hey, when I repeatedly asked for a "small number of objects", I didn't
mean for the Job MIB to turn into the virtual Rubick's Cube of MIB
technology.  I mean, all this "multi-plexed AssociatedValue" stuff is
just too much, IMHO.

And speaking of opinions, I sure wish others besides yourself, Harry and
myself spoke up about these issues.

If my opinions represent a minority view, then I'd sure like to know.

> complexity, that would help us understand your concerns.

I'm glad you asked, Tom.

I'm concerned whether any other vendors are planning on implementing
this Job MIB, or will it go the same route as NPAP.  (It took three
years to nail down NPAP...and the Job MIB will soon be approaching
that same period.)

Sure, I'm concerned with application implementation, that's our business.
But without implementations in the marketplace, we can't ship diddly.

Look how long it's taken to get a fair number of Printer MIB-capable
printers in the marketplace.  Until only recently, Underscore has been
able to go after the market...after some three years of MIB development.

And now, with the rapid development of IPP, it's starting to look like
the Job MIB may never really have an impact in the marketplace at all.

Yep, I'm sure Xerox will eventually ship an implementation for the
standard Job MIB (along with their other implementations), but this is
a critical mass problem we're dealing with.  Without a reasonably large
number of players, viable, attractive application solutions are not possible.

Again, thanks for taking the time to explain things, Tom.

	...jay