IPP>MOD - Job-URI vs. JOb-ID

IPP>MOD - Job-URI vs. JOb-ID

IPP>MOD - Job-URI vs. JOb-ID

Bill Wagner bwagner at digprod.com
Mon Aug 18 18:19:27 EDT 1997


     
     Harry,
     
     The idea of a Job Submission ID format composed of the Printer URI 
     with  the last 4 bytes being the jobID was proposed, discussed and 
     rejected at Redmond. (although that certainly is no reason to not 
     bring it up again). 
     
     My objection to requiring that the Job MIB index and the IPP Job ID be 
     identical was not just for the IPP in NIC case, but for the many  
     configurations  where the IPP server and the Job Monitoring Agent were 
     not in the same place. Indeed, since the IPP interfaces with a logical 
     printer that could include several physical printers, and the 
     Job-monitoring mib may very well be implemented in a physical printer 
     that also includes a local port, assuring synchronism is not trivial. 
     In addition, it was noted that the job submission ID was not a 
     sufficient handle by which to universally identify a job so that the 
     correlation between JobMonitoring MIB index and IPP was of 
     questionable utility.
     
     Bill Wagner  Osicom/DPI


______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: IPP>MOD - Job-URI vs. JOb-ID
Author:  Harry Lewis <harryl at us.ibm.com> at Internet
Date:    8/18/97 5:32 PM




Somewhat paraphrasing Scott I:
     
> ...IPP support for existing practice (32 bit Job ID) is a very valid 
concern...
> The major stumbling issue at the IPP meeting in Munich, was the lack of
> scalability across all configurations in the inter/intra/extra net world. 
> What about sites that want to return location or name information in a
> new Job identifier?  This works well for a URI but not so well for a 
> 32 bit ID.
     
The observation I recall at Redmond, initiated by Paul Moore, but supported 
by many, was that existing OS's largely assign a 32bit Job ID and that IPP 
should acknowledge this in it's model. I don't believe anyone actually 
suggested doing away with the printer URI, so it is quite feasible that
a combination of Printer URI and 32bit JobID could make up the "fully 
qualified" job ID or what might have been previously called the job URI. 
In Redmond, I drew the analogy to the Job MIB jmJobSubmissioID which has 
registered formats, one of which could be just this, for IPP submission. 
The analogy became rather distorted in discussion shifting focus to how 
the Job MIB jmJobIndex could be equal to the IPP 32bit jobID. I think the 
part we missed is that a jmJobSubmissionID format could be registered in 
which the first 38 bytes are the Printer URI and the last 4 bytes are the 
jobID which is identical to jmJobIndex.
     
     
Later, during the JMP meeting, Bill Wagner opposed any strict correlation 
between IPP and JMP job ID's on the grounds that implementations would be 
too difficult to orchestrate between NIC and controller. Bill brings a 
valuable NIC perspective to the group, and his notion warrants further 
discussion. I, for one, believe that the multiple submission channels
and protocols supported by today's printers will mandate some central 
obID authority within the printer and whether this is the NIC, the 
controller or some communication between them is implementation details.
     
> I would like to have a final call of all issues related to Job ID be posted 
> by 8/22 (including all who were at the IETF meetings in Munich that opposed 
> the prosposed solution) so we can close this immediately.
     
So, the issue I would like to raise is the possibility for defining and 
registering a jmJobSubmissionID format wherein the first 2 bytes are the 
registration ID, the next 38 bytes are IPP Printer URI and the last 8 
bytes are the jmJobIndex - and call this the IPP Job URI. I think this 
would satisfy the compatibility, migration and scalabality concerns.
     
Harry Lewis



More information about the Ipp mailing list