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