Ron, Harry, and Tom,
As I mentioned in my previous posting I agree with the conclusions in
the 'sepstate.doc' paper. Namely, the mandatory attributes should
become distinct objects in the jmJobStateTable, making it the "basic"
table for low-end implementations, and the jmAttributeTable then
becomes conditionally mandatory. Having implemented a table similar to
the jmAttributeTable in a Xerox proprietary MIB (Xerox people read:
XCMI Comms Options table), I know that these are tricky things to get
right, particularly for low-end implementations.
Along this line of thinking, I believe the second comformance
requirement in the internet draft (page 15) of the job MIB is too
strong. It states:
"A conforming agent:
...2.shall implement each conditionally mandatory attributes, if the
server or device that the agent is instrumenting has the feature
represented by the conditionally mandatory attribute.."
This says to me, for example, that if a printer implements the Printer
MIB, then the jobSourceChannelIndex attribute is mandatory since it
indexes a mandatory table in the Printer MIB. Therefore, for any
implementation that implements the Printer MIB, the jmAttributeTable
is automatically mandatory. If you're not satisfied with this example
I can come up with lots more. I suggest that the comformance
requirement above be ammended to read as:
"A conforming agent:
...2.shall implement each conditionally mandatory attribute, if the
server or device that the agent is instrumenting has the feature
represented by the conditionally mandatory attribute and the
device provides similar instrumentation of this attribute using
some other interface or protocol."
Then, if the device made the information about a job's source channel
available through some other interface like DPA or IPP, then and only
then would the jobSourceChannelIndex attribute become mandatory. This
would allow the jmAttributeTable to actually not be mandatory for low
end implementations.
Having not followed the JMP discussions closely over the last several
months I don't understand why it was decided that outputBinIndex
(previously ouputBinName) is mandatory? Speaking as an end user of
several networked printers, when I walk over to pick up my job I
typically find it sitting on top of the stack of jobs in the single
output tray of the printer. If not there, then it is usually in a
stack of jobs that someone was too lazy to sort, or, less frequently,
someone has been kind enough to file it in some alphabetically
organized filing contraption. So why does this value need to be
mandatory? The only case I can think of where it is really useful is
for devices with a mailbox type output device, but those are the
exception rather than the rule. I certainly think that attributes like
jobName and jobOwner are much more deserving of mandatory status since
they appear in most current job/queue monitoring applications (e.g.
PCONSOLE, Win95 print manager, etc). But since they are conditionally
mandatory, outputBinIndex should be also.
Lastly, I would like to request two new attribute be added for
accounting purposes with color capable devices. Color devices
typically cannot measure the exact amount of colorant consumed per
job, but can easily measure the number of color impressions. This is
important for accurate accounting since color impressions cost more
than black impressions with most current marking technologies. I have
included the ASN.1 here for your convenience:
fullColorImpressions(??), -- Integer32(-2..2147483647)
-- INTEGER: The total number of full color impressions
-- completed by the device for this job so far. For printing, the
-- impressions completed includes interpreting, marking, and
-- stacking the output. For other types of job services,
-- the number of impressions completed includes the number
-- of impressions processed. Full color impressions are
-- typically defined as those requiring 3 or more colorants,
-- but this may vary by implementation.
highlightColorImpressions(??), -- Integer32(-2..2147483647)
-- INTEGER: The total number of highlight color impressions
-- completed by the device for this job so far. For printing, the
-- impressions completed includes interpreting, marking, and
-- stacking the output. For other types of job services,
-- the number of impressions completed includes the number
-- of impressions processed. Highlight color impressions are
-- typically defined as those requiring black plus one other
-- colorant, but this may vary by implementation.
Thanks,
Angelo