Harry,
Thanks for your thorough response.
I'm still not sure about this "conditionally mandatory" business. You
said:
>The base interpretation of "conditionally mandatory" is sorta "if you know it
>or can do it... you must not consider it optional". Regarding your particular
>choices, however, I would say it is not always "possible" for the SNMP AGENT
>in the printer to understand each of the attributes you have listed. For
>example, we find that impressionsCompleted is a much more manageable attribute
>than pagesCompleted.
Ok, pagesCompleted may be ambiguous to the agent because it might be printing 4
up without knowing it, but what about sheetsCompleted? It is not mandatory, but
a printer will always know this, therefore wouldn't it be considered mandatory
for all printers which implement the job MIB? Later, you said:
>To answer your question directly, I don't think there is anything preventing a
>printer from implementing a subset of JobStateReasons - or *no*
>JobStateReasons."
With reasons such as "successfulCompletion" I don't understand how
JobStateReasons could be conditionally mandatory. It may be useful to list
which attributes would normally be considered mandatory in a printer agent and
which would normally be considered mandatory in a server agent.
>OK, Stuart. Here's where you ARE showing your Novice status. You obviously have
>never heard of DPA, have you?
Hey, I resent that! I've been a member of the Drug Prevention Association for
years!
>You've hit the "mother lode" of JMP problems with this question. Before IPP was
>even a speck on anyone's white paper, the JMP was calling for a "standard
>submission protocol". I made a proposal a year ago for a simple "Job Attribute
>Wrapper" (not what I called it, but might wish I had) to accompany submission.
>Your observation is correct. Accounting will be hamstrung without these
>submission attributes.
>As recently as two meetings ago, Bob Pentecost of HP made some overture
>regarding possible extensions to PJL with this regard and has discussed
>jmJobSubmissionID here, on the mail list. I think Bob is doing the right thing
>in considering standard PJL extensions to support the Job MIB. I haven't heard
>anything from Adobe regarding this topic. Also, obviously, IPP could become the
>standard submission protocol we're looking for, but I doubt it will become the
>one-and-only protocol and I don't think we're doing a very good job as PWG of
>coordinating IPP and the Job MIB, so there might be some holes to patch.
I remember discussing the PJL extension for JobSubmissionID. PJL and PS
extensions are definitely a step in the right direction, but I think we need to
focus more energy in this area. With no clear standard job submission protocol
the job MIB will be pretty impotent. Until the JMP group articulates its plans
in this area more clearly, I believe it will be a BIG impediment to wide spread
implementation of the job MIB. If IPP is going to become THE standard job
submission protocol, the JMP group needs to carefully evaluate how this will
impact the JMP effort. Unfortunately, aside from Tom, I don't think many of the
IPP group is much aware of what's going on in JMP.
Regarding the attribute table vs. the JobStateTable...
Of course, we are going to discuss this in San Diego. I don't profess to
understand all the issues, but I like the concept of a separate
JobStateTable that provides quick easy access to the most commonly needed
information. I also see that the JobStateAssociatedValue attribute is
complex and may be tricky to implement and there is also the issue of
duplication with the AttributeTable. Let's see how the others feel.
Stuart Rowley
Kyocera Electronics