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

From: Roger K Debry <[email-masked]>
Date: Fri, 15 Aug 1997 13:01:51 -0400

>From Carl-Uno's minutes of the IETF meeting, it appears that the
issue of Job-URI vs. Job-ID has been thrown up in the air again.  We
spent a considerable amount of time working on an implementation
of the job-URI, but were willing to change based on the agreement
made in the Redmond PWG meeting.  However, the longer this particular
issue continues to go unresolved, the harder it will be to change our
design, as this is quite a fundamental part of our object model.  We can
adapt to changes but not if they continue to drag on. Let's get this one
resolved once and for all or we may end up with multiple solutions being
implemented!

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: JK Martin <[email-masked]>
Date: Sat, 16 Aug 1997 14:18:30 -0400 (EDT)

This issue also concerns me quite a bit, as it appears we have once
again taken a 90-degree turn without sufficient public explanation.

No one has yet to respond to the previous message on this topic from
Randy Turner.  As I recall, Randy appeared *very* concerned about this
move, so can we get a discussion going on this list about this apparently
major architectural change?

	...jay

----- Begin Included Message -----

>From [email-masked] Fri Aug 15 13:09 EDT 1997
From: Roger K Debry <[email-masked]>
To: <[email-masked]>
Subject: IPP>MOD - Job-URI vs. JOb-ID
Date: Fri, 15 Aug 1997 13:01:51 -0400

Roger K deBry

----- End Included Message -----

---

From: [email-masked] (Bill Wagner)
Date: Sun, 17 Aug 1997 13:28:02 -0400

Jay,
     
     I will offer some observations about this proposed change. 
     
     1. The concept of the job as an object with an URI was part of the IPP 
     initial concept  and pervades the documents. It will be no mean task 
     to find and edit out all of the allusions to this in the documents.
     
     2. Paul Moore of Microsoft strong voiced his opposition to have the 
     job as an URI'able object citing, if I recall correctly,  
     implementation difficulties.
     
     3. A potential advantage to identifying the job by a  number  at the 
     Printer URI was synchronization with the Job Monitoring MIB job index. 
     However, at the following Job Monitoring MIB meeting, I pointed out 
     that the IPP server assigning the IPP job was not necessarily in the 
     same place, dealing with the same physical entities or privy to the 
     information in the agent assigning the Job Monitoring MIB index and 
     that it was unrealistic to require that the same number be used. I 
     recall no other inherent advantages voiced to the proposed change.
     
     4. The argument to retain the JOB URI centered about the need to 
     identify a job independently of the Printer which assigned the ID. No 
     good arguments could be found for this requirement.
     
     5. Three proposals were presented. 
        a. to identify each job by an ID at the printer URI
        b. to identify each job by a URI composed of the printer URI plus 
     some job specific term, that would easily correlate to the IP in (a).
        c. to identify each job with a URI  without the constraints in (b).
     
     The almost absolute consensus was (a).
     
     I agree that the decision of which way to go is probably less 
     important than agreeing on the way.
     
     Bill Wagner, Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re: IPP>MOD - Job-URI vs. JOb-ID
Author:  JK Martin <[email-masked]> at Internet
Date:    8/16/97 2:18 PM

     
        ...jay
     
----- Begin Included Message -----

     
Roger K deBry

----- End Included Message -----

---

From: Scott Isaacson <[email-masked]>
Date: Mon, 18 Aug 1997 11:26:33 -0600

I had no access to email while in Munich, but I have been anxoious to
respond to this thread.

>>> Bill Wagner <[email-masked]> 08/17/97 11:28AM >>>
>     Jay,
>     

>     to find and edit out all of the allusions to this in the documents.

I started this editing task after the Seattle meetings and before the Munich
meetings.  As Bill points out, the subtleties of this are "part of the
model".  They
are spread through the document.  Do we have Job operations are just
Printer operations that apply to a certain Job.   Steve Z. makes the point
that Jobs are still first class objects, they have operations.  Their
"identifier"
is just not a single URI, but a two part identifier (Printer URI and Job
ID).
I think it is do-able, but extensive.

>     implementation difficulties.
   
Other participants voiced the same concern about mapping from existing
application interfaces (APIs) to a new on the wire protocol to existing
print
services.  From my point of view there is always a trade off between
new and old (anyting) along the dimension labled:

                potential     vs.    migration and legacy

This IPP support for existing practice is a very valid concern given the
somewhat theoretical "potential".  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 an 32 bit ID.

>     recall no other inherent advantages voiced to the proposed change.

I recall just stating that the Job ID was a 32 bit integer with the
potential of
being the same as the Job Index, however that was not mandatory was it?
     
>    good arguments could be found for this requirement.
     
Other than that is what the model has claimed for the past 9 months and
prototyping has shown it ti be valid and scalable.

     

>     Bill Wagner, Osicom/DPI
     
Although I initially opposed the Job ID rather than Job URI proposal, I
became
convinced at the meeting that  "consensus" was to go the "proposal a route".
 However, I do agree that in the IETF, the only "real" face to face meetings
are the IETF sponsored ones and the discussion list is the place for
real consensus.   The last decision on the DL about Job URI was to add
Printer URI as an operation attribute to all Printer operations and Job URI
as
an operation parameter to all Job operations.

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.

A final note, only a few of the more than 40 attendees had even claimed to
read the posted I-Ds.

Scott I.

---

From: [email-masked] (Bill Wagner)
Date: Mon, 18 Aug 1997 18:19:27 -0400

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 <[email-masked]> 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.
     
> by 8/22 (including all who were at the IETF meetings in Munich that opposed 
     
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