Subject: Re: JMP> Proposed Rules for jmJobSubmissionId

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

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

---

From: Ron Bergman <[email-masked]>
Date: Tue, 18 Nov 1997 08:57:52 -0800 (Pacific Standard Time)

Harry,

If I recall correctly, the discussion in Boulder concluded that the last
jmJobSubmissionId encountered was not always the proper rule.  The
situation is muddled primarily due to our attempts to generate a proper
jmJobSubmissionId using existing job submission protocols without a change
to these protocols.  

For example, if a job is submitted using IPP with a PJL header on the data
stream, the "last encountered" rule requires that the PJL header
information override the IPP information.  If the proper information (i.e.
@PJL JOB SUBMISSIONID = "id string") is not included in the PJL header, a
less than optimal jmJobSubmissionId will be generated.  In this case, the
IPP information should be used and the PJL information should be ignored.

My analysis, which I did not explain, assumed that no information to
generate jmJobSubmissionId was included beyond what is currently presented
in the protocol.

Maybe an easier rule is to use the last "recommended information format"
encountered and only use an "alternative information format" if a
"recommend information format" is not required.  The Mapping document
would then indicate for each submission protocol one or both of these
formats.  Is this less complex?

Comments please!

	Ron Bergman
	Dataproducts Corp.