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