Job Identification Objects Proposed

Job Identification Objects Proposed

rbergma%miami.dnet.dpc.com at gate.dpc.com rbergma%miami.dnet.dpc.com at gate.dpc.com
Mon Aug 5 14:34:46 EDT 1996


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



More information about the Pwg mailing list