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.
On Mon, 17 Nov 1997, Harry Lewis wrote:
> 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
>
>
>
>
> 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 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