JMP Mail Archive: Re: JMP> Proposed Rules for jmJobSubmissionId

Re: JMP> Proposed Rules for jmJobSubmissionId

Harry Lewis (harryl@us.ibm.com)
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 pr=
oblem.
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 jmJobSubmissionI=
D
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

jmp-owner@pwg.org on 11/17/97 09:44:45 AM
Please respond to jmp-owner@pwg.org @ internet
To: jmp@pwg.org @ 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 t=
he
situation previously discussed relative to PJL with nested headers. He=
re 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 di=
fferent
protocol layers. To attempt to get a handle on this situation, I have
formulated the following analysis of the problem and developed the foll=
owing
rules.

First, these are the possible combinations from the submission protocol=
s
mapped. Combinations with a (?) are possible but may have a low probab=
ly.

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 wit=
h
NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/RPr=
inter
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 somewh=
at
questionable as the mapping information from Scott Isaacson is vague=