JMP Mail Archive: Re: JMP> Proposed Rules for jmJobSubmissionId
Re: JMP> Proposed Rules for jmJobSubmissionId
Stuart_Rowley@KEI-CA.CCMAIL.compuserve.com
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:rbergma@dpc.com at CSERVE
Date: 11/17/97 11:41 AM
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.