After reviewing Tom Hasting's proposal (based upon DPA) for the four
Job Identification objects, I am concerned that this model will not
be useable or be too complex for our needs. I would like Tom, or
anyone else involved with DPA, to comment on and possibly clarify
these issues. I am also proposing two alternatives, which I would
like to be considered.
At the first reading of the descriptions of these objects, which
unfortunately was during the meeting at Portland, I found the set
of objects to be extremely confusing. It was very difficult to
determine the purpose of each object and the relationship of one
object to another. The object names agreed upon in Portland do
remove much of the confusion.
If my present understanding of the DPA model is correct, then Tom's
table (line number 296 of jmp-spec version 0.1) can be expanded to:
DPA |job-client-id|job-id-on-client|job-identifier|job-id-on-printer
JMP |jobClientId |jobUpStreamId |jobCurrentId |jobDownStreamId
----|-------------|----------------|--------------|-----------------
A | 123 | not applicable | unspecified | 123
B | 123 | unspecified | 123 | 456
C | 123 | 123 | 456 | 789
D | 123 | 456 | 789 | not applicable
A = Client submitting job
B = First downstream server
C = Second downstream server
D = Printing device
I find it strange that DPA allows the jobClientId to be assigned by
server B. In the DPA case this may be acceptable, since DPA controls
both submission and monitoring. However, where monitoring and
submission are independent this operation should be completely
transparent to the job monitoring application. (i.e. The identifier
on A and B would be identical, but A would reply as if it had
assigned the identifier value.)
The object set we are trying to define is only meaningful at the
printer and the client. At the end points, either the jobUpStreamId
or jobDownStreamId are superfluous. These objects must be maintained
in a table on the intermediate servers. So why do we need to include
these in a MIB?
My first proposal also provides four objects defined as follows: (The
definitions are brief on purpose and will require additional text.)
jobIdOnClient - This is the id assigned by the client submitting
the job. This object would be the same as
job-client-id, except for the assignment issue
as described above.
jobIdOnDevice - This is the id as defined on the device (printer)
which is the final destination for the job. This
identifier will be visible to all entities that
can access the MIB.
jobIdOnPktSrc - 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.
jobIdOnPktDest - This object specifies the identifier as
assigned by the entity that is currently receiving
the data set. The value of this object will change
as the data set moves from server to server.
If I use the same example as Tom presented, but use "258" as the
value for jobIdOnClient, I can use the following table to describe
this alternative proposal.
|jobIdOnClient |jobIdOnPktSrc |jobIdOnPktDest |jobIdOnDevice
-----|--------------|--------------|---------------|--------------
A->B | 258 | 258 | 123 | 789
B->C | 258 | 123 | 456 | 789
C->D | 258 | 456 | 789 | 789
D->C | 258 | 789 | 456 | 789
C->D | 258 | 456 | 123 | 789
B->C | 258 | 123 | 258 | 789
My second concern is the need for four objects whose only purpose is
to identify the job. Does each server need to provide a unique Id
for the job? The only purpose for all these identification numbers
appears to be routing. (DPA experts?)
My second proposal is to use only jobIdOnClient and jobIdOnDevice.
Can anyone think of a situation where this will not work?
Ron Bergman
Dataproducts Corp
rbergma at dpc.com