Subject: JMP> Proposed Rules for jmJobSubmissionId

From: Ron Bergman <[email-masked]>
Date: Mon, 17 Nov 1997 08:33:56 -0800 (Pacific Standard Time)

One of the issues discussed in Boulder was how to map jmJobSubmissionId when 
there are multiple possibilities in the protocol.  This is similar to the 
situation previously discussed relative to PJL with nested headers.  Here it 
is possible for the client to include a PJL header with a submission id and 
then a server to also include another PJL header with a job submission id in 
front of the client header.  In this case, the agreement was to use the last 
submission id encountered in parsing the job, since this would contain the 
information closest to the client.

As agreed in Boulder, although this rule works well when the nesting is within 
one layer, it is not applicable when the information is contained in different 
protocol layers.  To attempt to get a handle on this situation, I have 
formulated the following analysis of the problem and developed the following 
rules.

First, these are the possible combinations from the submission protocols 
mapped.  Combinations with a (?) are possible but may have a low probably.

1) LPR/LPD with PJL
2) AppleTalk with PJL (?)
3) IPP with PJL
4) DPA with PJL (?)
5) NDPS with PJL
6) PServer with PJL
7) NPrinter/RPrinter with PJL
8) SMB with PJL
9) TIP/SI with PJL

10) LPR/LPD with PostScript
11) AppleTalk with PostScript
12) IPP with PostScript
13) DPA with PostScript
14) NDPS with PostScript
15) PServer with PostScript
16) NPrinter/RPrinter with PostScript
17) SMB with PostScript
18) TIP/SI with PostScript

19) PJL with PostScript
20) LPR/LPD with PJL and PostScript
21) AppleTalk with PJL and PostScript (?)
22) IPP with PJL and PostScript
23) DPA with PJL and PostScript (?)
24) NDPS with PJL and PostScript
25) PServer with PJL and PostScript
26) NPrinter/RPrinter with PJL and PostScript
27) SMB with PJL and PostScript
28) TIP/SI with PJL and PostScript

Some rules are immediately obvious and should have little disagreement.

1. IPP must always define the jmJobSubmissionId.  (Covers 3, 12, and 22)

2. PJL or PostScript will define jmJobSubmissionId when transmitted with 
   NPrinter/RPrinter.  PJL is preferred over PostScript.  (NPrinter/RPrinter 
   cannot define jmJobSubmissionId.) (Covers 7 and 16)

New rules must be created for the remaining combinations.

3. NDPS should be used for combinations 5, 14, and 24.  (This is somewhat 
   questionable as the mapping information from Scott Isaacson is vague.  
   Scott, will information to generate jmJobSubmissionId always be available?)

4. TIP/SI should be used for combinations 9, 18, and 28.  (Lloyd or Don, does 
   this seem accurate?)

5. PJL is recommended for combinations 1, 2, 4, 6-8, 19-21, 23, and 25-27, 
   using the SUBMISSIONID option.

6. PostScript should be used for combinations 10, 11, 15, and 17 if the 
   information can be imbedded and extracted from the PostScript comments.

DPA (PrintXchange) should provide sufficient information so that it would 
always provide jmJobSubmissionId.  (No mapping is currently available.)

Any comments?

	Ron Bergman
	Dataproducts Corp.

---

From: Harry Lewis <[email-masked]>
Date: Mon, 17 Nov 1997 17:25:35 -0500

Ron, thanks for trying to tackle this difficult topic. I have read your
recommendations and I'm not sure I understand how they relate to the problem.
For example, when you say

>1. IPP must always define the jmJobSubmissionId.  (Covers 3, 12, and       >
22)

I'm left wondering HOW.

Are you suggesting we change the "always take the last jmJobSubmissionID
encountered" rule to "use jmJobSubmissionID provided by xyz in case A,
czy in case B, etc"...?

I'm not saying this would be wrong, just it's a major departure and
order of magnitude more complex for the Job MIB agent than the current
rule.

Harry Lewis

[email-masked] on 11/17/97 09:44:45 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc:
Subject: JMP> Proposed Rules for jmJobSubmissionId

1) LPR/LPD with PJL

19) PJL with PostScript

3. NDPS should be used for combinations 5, 14, and 24.  (This is somewhat
   questionable as the mapping information from Scott Isaacson is vague

---

From: [email-masked]
Date: Mon, 17 Nov 1997 20:07:23 -0500

Ron,
     
I am increasingly uncomfortable with the agreement to use the last 
submission id encountered.  I believe the original decision was based on 
the idea that it was the simplest solution, but your write-up on the 
Proposed Rules for jmJobSubmissionId shows that this solution is not so 
simple or straight forward after all.
     
I can see the possibility of an application that works closely with the 
driver, such as HP's DocWise, using the driver created jmJobSubmissionId 
for job monitoring.  It is clearly undesirable for something downstream, 
such as NDPS, to then stomp on the jmJobSubmissionId created by the driver. 
     
Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems 
to be a more straight forward solution.  I know the consensus was to not 
re-open this, but maybe others are having second thoughts.  Can someone 
refresh my memory on the negatives of allowing multiple jmJobSubmissionIds?
     
Stuart Rowley
Kyocera Electronics, Inc.

______________________________ Reply Separator _________________________________
Subject: JMP> Proposed Rules for jmJobSubmissionId
Author:  INTERNET:[email-masked] at CSERVE 
Date:    11/17/97 11:41 AM

     
     
1) LPR/LPD with PJL

19) PJL with PostScript

     

     

     
     
Any comments?

	Ron Bergman
	Dataproducts Corp.

---

From: [email-masked]
Date: Mon, 17 Nov 1997 20:07:23 -0500

Ron,

     
     
Stuart Rowley

     

1) LPR/LPD with PJL

19) PJL with PostScript

     

     

     
     
Any comments?

	Ron Bergman
	Dataproducts Corp.

---

From: [email-masked]
Date: Mon, 17 Nov 1997 20:07:23 -0500

Ron,

     
     
Stuart Rowley

     

1) LPR/LPD with PJL

19) PJL with PostScript

     

     

     
     
Any comments?

	Ron Bergman
	Dataproducts Corp.

---

From: [email-masked]
Date: Mon, 17 Nov 1997 20:08:16 -0500

Ron,

     
     
Stuart Rowley

     

1) LPR/LPD with PJL

19) PJL with PostScript

     

     

     
     
Any comments?

	Ron Bergman
	Dataproducts Corp.

---

From: Harry Lewis <[email-masked]>
Date: Tue, 18 Nov 1997 10:58:02 -0500

Stuart, are you suggesting that, in an NDPS environment (for example), BOTH  a
"driver spawned" job monitoring client application (like DocWise) AND a NOS
provided monitoring paradigm (NDPS) will be in operation at the same time on
the same job? Why would the end-user want 2 ways to monitor the print job?

Part of the decision to use "last encountered" jmJobSubmissionID was to keep
the agent simple, yes, but this decision was also based on the premise that
only one "tightly coupled" monitoring application need be in control. This is
not to say "out of band" applications can't still monitor - just not in the
"pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping
table.

I don't strongly object to moving to a design where multiple
jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there
is a practical use for this. Could someone offer a high level diagram of a
practical system where the client is getting job progress information from two
sources, simultaneously?

Harry Lewis - IBM Printing Systems

[email-masked] on 11/17/97 06:15:16 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet, [email-masked] @ internet
cc:
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId

Ron,

Stuart Rowley

---

From: [email-masked]
Date: Tue, 18 Nov 1997 18:38:32 -0500

Harry,

Of course the user isn't going to want information from both monitoring 
apps, but they likely will not know that the driver is inserting a 
jmJobSubmissionID.  When they use their NDPS/Unix monitoring component and 
it can't find the job, are they going to slap their forehead and suddenly 
realize they must turn off "Insert Job Submission ID" in their driver?

If we can say that client monitoring is ALWAYS favored over server back 
channel, then our current design (last ID encountered) is ok.  I would 
assume that Novell and others would not be happy with this decision, but we 
are not hearing from them.  The current design works ok for the client 
monitoring/driver folks (which I represent) but I'm not sure it is the best 
overall solution for the user.

Stuart Rowley

______________________________ Reply Separator _________________________________
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
Author:  INTERNET:[email-masked] at CSERVE
Date:    11/18/97 4:35 PM

Yes, I consider this topic (appropriately) re-opened (along with the 
collated/un-collated topic).
     
Without repeating your example (attached, below)... and referencing Stuart's 
"Applet vs. NDPS" example... isn't the user going to feel like there is an echo 
in the room?
     
Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor) 
Page 2 (applet)... Page 2...(UNIX/NDPS)
etc.
     
I'd be quick to turn SOMETHING off in that environment! If client monitoring is 
turned off then
it should not be wrapping jmJobSubmissionID with the job. If client monitoring 
is favored over server back channel, then the fact that legacy LPR submission 
results in a jmJobSubmissionID which is later replaced by the one found in the 
job (the LAST one encountered by the agent)... is no problem.

     
     
[email-masked] on 11/18/97 12:40:30 PM 
Please respond to [email-masked] @ internet 
To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet, 
Harry Lewis/Boulder/IBM@ibmus
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId

This is a multi-part message in MIME format. 
--------------------------------------------------------------------------------
I believe we must reopen the issue of nested job ids and how to
handle them.  I realize that this topic was consciously shelved 
a while back, but further subsequent digging has resulted in the 
need to readdress and handle this issue.  It appears that Stuart 
Rowley has also recognized the need to rethink this topic.

> practical system where the client is getting job progress information from two
     
I don't think the operating requirements is such that a job monitoring 
application is monitoring progress from two sources.  Rather, the 
application is "told" to monitor job ID "XYZ", but the application
has no idea that (potentially) several intermediate servers are 
involved in the complete job submission and delivery process.  And 
this scenario (ie, one or more intermediate servers) is the real 
problem here.
     
Here is a real-world scenario we frequently encounter in enterprise 
environments:
     
  1) A Windows user submits a job to the native Windows printing
     system; the PC has been configured to automatically launch 
     a "print job monitor" application, where the application is
     instructed to monitor job "XYZ", where "XYZ" is the *Windows* 
     job id.
     
  2) The user's PC is configured to route all print jobs to a Unix
     (or NetWare, or other non-Windows) server using an appropriate 
     spooling protocol, such as (gasp) LPD/LPR.
     
  3) The printing system on the Unix server uses printer-specific
     driver software to deliver the print job to the target printer 
     using an appropriate (and potentially proprietary) delivery 
     mechanism.
     
In this scenario there are at least two (if not three) different 
job ids created by the time the paper starts rolling out of the 
printer.  Yet, the PC-based monitor application only knows about 
the first (original) job id.
     
What can we do about this problem?  Some quick options:
     
  1) Force the monitoring application to know about all possible
     job ids that may be subsequently created as the job moves 
     thru the printing system.  This means the app must "learn" 
     about all other job ids, or at least job id *patterns* that 
     might be used to derive the relationship of subsequent job 
     ids with the original job id.
     
  2) Extend the Job MIB to allow for a parallel set of job id
     "aliases" for any given job.  As a job moves thru the printing 
     system, the current "handler" (job transfer agent, if you will) 
     assigns an appropriate job id, then adds the previously 
     assigned job id as an "alias" for the job.  The monitoring app 
     can then search for the target job in both the primary job id 
     list or the list of aliases for each job.
     
  3) Do nothing about this problem, declaring that job monitoring
     using the Job MIB is only useful in very simple printing systems.
     
My quick opinions on each of these options:
     
  1) This approach is very, very messy, and probably won't work for
     diverse environments in which several server types are used 
     within a single environment (ie, Unix *and* NetWare, etc).
     
  2) A good approach, IMHO, that can be fairly easily solved, given
     that we have already devised clever ways to attach variable 
     lists of information with any given job.
     
  3) This approach would disappoint us greatly, needless to say...
     
Given the work done to date by Ira and Tom, it's not hard to imagine 
that they can come up with some wonderfully elegant approach to 
providing multiple job ids in the Job MIB, one that can be designed 
in the very near future.  (Right, guys?? ;-)
     
Again, we at Underscore strongly encourage the JMP group to address 
this problem now so that simple, effective and accurate job monitoring 
applications can be delivered to the marketplace independent of the 
underlying platform.
     
 ...jay
     
---------------------------------------------------------------------- 
--  JK Martin               |  Email:   [email-masked]          -- 
--  Underscore, Inc.        |  Voice:   (603) 889-7000              -- 
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              -- 
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   -- 
----------------------------------------------------------------------
--------------------------------------------------------------------------------
Stuart, are you suggesting that, in an NDPS environment (for example), BOTH  a 
"driver spawned" job monitoring client application (like DocWise) AND a NOS 
provided monitoring paradigm (NDPS) will be in operation at the same time on
the same job? Why would the end-user want 2 ways to monitor the print job?

     

     

Ron,

     
     
Stuart Rowley
     
--------------------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 18 Nov 1997 18:38:32 -0500

Harry,

Stuart Rowley

     

     

     

     

     

     

     

     

     

 ...jay

     

     

Ron,

     
     
Stuart Rowley

---

From: [email-masked]
Date: Tue, 18 Nov 1997 18:38:32 -0500

Harry,

Stuart Rowley

     

     

     

     

     

     

     

     

     

 ...jay

     

     

Ron,

     
     
Stuart Rowley

---

From: [email-masked]
Date: Tue, 18 Nov 1997 18:38:33 -0500

Harry,

Stuart Rowley

     

     

     

     

     

     

     

     

     

 ...jay

     

     

Ron,

     
     
Stuart Rowley

---

From: [email-masked]
Date: Tue, 18 Nov 1997 18:40:02 -0500

Harry,

Stuart Rowley

     

     

     

     

     

     

     

     

     

 ...jay

     

     

Ron,

     
     
Stuart Rowley

---

From: Harry Lewis <[email-masked]>
Date: Tue, 18 Nov 1997 20:04:20 -0500

Stuart,

>Of course the user isn't going to want information from both
>monitoring apps, but they likely will not know that the driver
>is inserting a jmJobSubmissionID.  When they use their
>NDPS/Unix monitoring component and it can't find the job,
>are they going to slap their forehead and suddenly realize
>they must turn off "Insert Job Submission ID" in their driver?

what we're really talking about, here, is coexistence of drivers with print
platforms. If the only option
for coexistence is "plug and pray", then I agree with your assessment.  It is
my experience, however, in the Windows and OS/2 environments, the driver and
monitor are separate elements and it should be the monitor portion of the
system which is adding the ID, not always the "driver".  If a driver is
submitting through a UNIX server rather than an NT port monitor, then there
should be no ID coming from the (let's say - Windows) "driver".