JMP> Re: job mib feedback [more explanation about attributes]

[Tom Hastings <[e-mail]>]

At 11:55 07/27/98 PDT, Keith Moore wrote:
snip ...

>> 3.The structure of the MIB is totaly "non-SNMP" like.
>>   It is the 2nd wierdest MIB I have ever seen.
>>   I have difficulty saying go ahead and publish.
>>   But... it is work of the PWG which is outside of the
>>   IETF, right? So not sure what we can/should do.
>>   I would certainly NOT let this thing go on the standards
>>   track.

This is a more complete explanation of the reason that we advanced the
attribute structure in the PWG job monitoring MIB.  Its been prototyped
for over a year.  The reason for the new structure is that we found in 
doing the Printer MIB (RFC 1759) that printers vary from model to model
and vendor to vendor that attempting to combine objects into a group
for perpurposes of conformance was too difficult.  One implementation would
only have one or two items in a group, and so would forced with the decision
to implement the whole group, returning empty strings or other(1) enums
for most of the objects or omit the group entirely.

So we invented the attribute concept which is conceptually like most
job submission protocols, such as IPP, DPA, or LPD, in that an 
implementation of a job need only support the attributes that the device 
or server contains.  Furthermore, each job submission could omit any 
attributes that were not needed for that job.

The idea is that a TC defines the enum values that identify each attribute.
That enum is used as a index into the attribute table.  Thus an NMS can
either access the attribute directly with a Get operation specifying
the index enum value for that attribute or can "harvest" a bunch of
attributes doing GetNext, skipping over the unimplemented or unsupplied
attributes for that job.

We also added one final index to allow an attribute to have more than one
value (integer or octet string), as in most job submission protocols.

So, while the Job MIB doesn't look like other MIBs, its attribute concept
reflects the semantics of jobs that have attributes.  Also the indexing,
Get, and GetNext semantics seems to lend themselves well for representing
jobs which vary so much between product implementations and between each
job submission with a particular product.

Does that make sense?

Thanks,
Tom