Ron,
Some comments and questions on the object definitions:
> *** PROPOSED ALTERNATIVES TO THE ABOVE TWO OBJECTS ***
> 2. jobIdOnPktSrc: (String, max TBD) This object specifies the
> identifier as assigned by the entity that is currently sending the data
> set. The value of this object will change as the data set moves from
> server to server.
What is the significance of the "Pkt" portion of the name? That is,
what does it stand for? (Packet?)
> 4. jobIdOnDevice: (String, max TBD) This object identifies the job on
> the device which is currently processing the job. The processing device
> includes, but is not limited to, printers, faxes, scanners, spoolers,
> and files servers. The value of this object may change for systems that
> include intermediate devices such as file servers and spoolers.
The last sentence in this paragraph is pretty scary IMHO. When it says
"The value of this object may change...", what does this mean exactly?
Does it mean the format will (may?) be different depending on the types
of intermediate systems? Or does it mean the value (and possibly the format)
may change during the life of the Job?
> 5. jobType: (enum) This object specifies the type of service requested
> to process the job.
Can we get some examples here? Sounds like an interesting object, but only
if a *single* parameter can reasonably denote the service required.
> 6. jobOwner: (String, max TBD) This object identifies the client that
> submitted the job. The method of assigning this name will be system
> and/or site specific but the method must insure that the name is unique
> to the network visible to the client and target device.
Warning, Will Robinson!! Ensuring network-wide uniqueness is virtually
impossible without some stated rules. For example, this value could be
relatively arbitrary, but MUST have (as a prefix, or suffix, or whatever)
a valid, fully-qualified hostname, or something like that.
>> 7. jobChannel: (enum) This object defines an equivalent to the print
> job delivery channel as defined in the Printer MIB.
May god forgive us all. ;-)
> 8. jobMagicCookie: (??) This object defines the protocol path from the
> physical layer to the jobChannel. The format of this object will be
> similar to the work in process for the Printer MIB.
The use of the term "protocol path" to describe this kind of "wartly"
object is interesting. Is this a reasonable term? Does it really express
the concept? (Whatever that may be.) Note that the corresponding object
in the Printer MIB does not attempt to define such a concept as "protocol
path" Perhaps it should?
> 9. jobName: (String, max TBD) This object is an ASCII text string which
> identifies the job. This is expected to be human readable form of
> jobIdOnClient.
> *** IS THIS OBJECT SIGNIFICANTLY UNIQUE TO BE OF VALUE ??? ***
If "jobName" can be likened to what is often called the "job title" on some
printing systems, then this object can have real value (IMHO). However, if
the "jobComment" object can provide equivalent utility, then perhaps this
object should be removed.
> 10. jobDocument: (String, max TBD) This object defines a name for the
> job. The name is typically expected to be the file or file/path name of
> the source of the job. The name does not need to be globally unique.
> (The name would typically be repeated if several jobs from the same file
> are simultaneously in the jon queue.)
How is this different than "jobName"???
> 13. jobDeviceName: (String, max TBD) This object specifies the
> administratively defined name of the target device.
I would strongly suggest that the value for this object be the same as
the new "administrative name" object in the Printer MIB, iff the target
device is Printer MIB-compliant, etc.
>> JOB PARAMETERS:
>> *** THE VALUE OF THESE PARAMETERS HAS BEEN QUESTIONED, ***
> *** SINCE THIS IS NOT A JOB SUBMISSION PROTOCOL ***
> *** PROPOSE THAT ONLY THE ITEMS THAT INDICATE STATUS OR ***
> *** PROVIDE ACCOUNTING INFORMATION BE RETAINED !!! ***
You're right, Ron. Drawing the line between "monitoring" and "submission"
can be quite difficult. Perhaps these objects can be deferred to the very
end of the project; that way if a project gets started for a standard
network printing protocol, these two efforts can be combined to create
commonly defined objects, etc.
> STATUS AND ACCOUNTING PARAMETERS:
>> 1. jobState (enum ?) This object defines the current state of the job.
> (e.g. queued, printing, completed, etc.)
Seems like a good object, but we won't know until someone posts a proposed
list of states. Only then will we be able to know how applications will be
able to use this object (if at all).
> 2. jobStateReason (bit map) This object provides additional information
> regarding the the jobState.
A bit map?? That would make it a finite set, right? If so, then someone
should post some example values.
> 3. jobDeviceUsed (hrDeviceIndex) This object identifies the physical
> device or devices used to complete the job.
> *** FURTHER WORK IS REQUIRED TO DEFINE THIS OBJECT AND ***
> *** ITS RELATION TO THE REMAINING OBJECTS !!! ***
> *** SHOULD A SEPARATE PACKET BE RETURNED FOR EACH DEVICE OR ***
> *** TRY TO COMBINE ALL INTO ONE ??? ***
> *** HOW IS ALL THIS INFORMATION TO BE COMBINED ??? ***
Not sure what you mean about having a "separate packet be returned for
each device". Can you explain a bit more on this?
> 4. jobOctetsCompleted (Counter64) This object defines the number of
> octetes currently processed by the device. For multiple copies
> generated from a single data stream, the value shall be incremented as
> if each copy was printed from a new data stream without resetting the
> count between copies.
What is the rationale for handling copies in this manner? Doesn't it
seem useful to know how many data bytes actually flew across the network
as part of the job? Yeah, you could use a "copies completed" object to
derive the actual bytes transferred, but really, what value is having
a total byte count calculated in the manner described above? Perhaps
a real world application scenario description would help here?
> 11. jobWarningCount (Counter32) This object contains a count of the
> number of warning events that occurred during the processing of the job.
Without being able to know what kinds of warnings occurred, what is the
value of this object? That is, what are the semantics of the job entry
if this value is non-zero? (That is, what can/should an application do
if this value is non-zero?)
> 12. jobErrorCount (Counter32) This object contains a count of the
> number of error events that occurred during the processing of the job.
Same comments as #11.
> 13. jobPositionInQueue (Counter32) This object indicates the number of
> jobs preceeding this job in the print queue.
This sounds like an implementation problem. If it is expected that the
agent maintains all jobs as entries in a job table, then isn't the job
index a better qualifier for this kind of information? If this object
remains as described above, then every time a job is removed from the
table (due to completion of processing), then ALL OTHER job entries will
have to have this object updated. This is not a typical situation in
MIB-land, is it? (Sounds like a real implementation pain, both for the
agent and the mgmt application.)
> 19. pdlUsed (enum) This object defines the PDL(s) used by the job.
It would seem imperative to reconcile this object to the equivalent
Printer MIB object, no?
All in all, things are coming along. This is good. However, we still
seem to be floundering with respect to having solid, proven rationale
for many of these objects. (What problem are we trying to solve? And
how does this object solve that problem?)
This may seem like a bit of a strange proposal, but do you think it would
be useful to assign a "sponsor" for each of the proposed objects; that is,
have a person responsible for the definition, qualification and rationale
for each object? That way when a question arises, that person would be
the one to respond and otherwise "defend" the object as necessary.
...jay