>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 =3D "id string") is not included in the PJL >head=
er, a less
than optimal jmJobSubmissionId will be generated. In >this case, the I=
PP
information should be used and the PJL information >should be ignored.
Why is there a jmJobSubmissionID in the PJL header? It's not like anyon=
e is
putting these headers on, today. So I'm perplexed about trying to solve=
a
problem we don't have... that is just because we can imagine nested
jmJobSubmissionIDs we need to somehow fix the problem. Since IPP can pr=
ovide
monitoring capability for the client, why would someone implement an in=
tegrated
driver/monitoring app that relies on both IPP and the Job MIB to report=
TO THE
SAME CLIENT?
I'm trying to get at exactly what problem we're trying to solve, here a=
nd is it
really a problem.
>Maybe an easier rule is to use the last "recommended information forma=
t"
>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?
While the mapping you provided is very helpful in understanding what
combinations of PDL and submission protocol we may encounter, I'd rathe=
r NOT go
the "recommended information format" route. I think this REALLY complic=
ates
things. Now, the agent behavior must be tailored, for each job, dependi=
ng on
how the job was received.
I agree the topic of nested jmJobSubmissionIDs surfaced as the main top=
ic, in
Boulder, which seems unresolved (or misunderstood). I'd like to underst=
and the
system's in which this perceived problem is real, however. Then, if we =
need to
make a change, I would probably favor having the agent map multiple
jmJobSubmissionID's to a single jmJobIndex. I believe this is cleaner a=
nd more
useful if the situation ever does occur.
Harry Lewis - IBM Printing Systems
jmp-owner@pwg.org on 11/18/97 10:02:59 AM
To: Harry Lewis/Boulder/IBM@ibmus
cc: jmp@pwg.org
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
Harry,
If I recall correctly, the discussion in Boulder concluded that the las=
t
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 cha=
nge
to these protocols.
For example, if a job is submitted using IPP with a PJL header on the d=
ata
stream, the "last encountered" rule requires that the PJL header
information override the IPP information. If the proper information (i=
.e.
@PJL JOB SUBMISSIONID =3D "id string") is not included in the PJL heade=
r, a
less than optimal jmJobSubmissionId will be generated. In this case, t=
he
IPP information should be used and the PJL information should be ignore=
d.
My analysis, which I did not explain, assumed that no information to
generate jmJobSubmissionId was included beyond what is currently presen=
ted
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 yo=
ur
> 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 jmJobSubmissio=
nID
> 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 curren=
t
> 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 jmJobSubmission=
Id 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 submissio=
n id in
> front of the client header. In this case, the agreement was to use t=
he last
> submission id encountered in parsing the job, since this would contai=
n 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 hav=
e
> formulated the following analysis of the problem and developed the fo=
llowing
> rules.
>
> First, these are the possible combinations from the submission protoc=
ols
> mapped. Combinations with a (?) are possible but may have a low prob=
ably.
>
> 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 disagreemen=
t.
>
> 1. IPP must always define the jmJobSubmissionId. (Covers 3, 12, and =
22)
>
> 2. PJL or PostScript will define jmJobSubmissionId when transmitted w=
ith
> NPrinter/RPrinter. PJL is preferred over PostScript. (NPrinter/R=
Printer
> 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 some=
what
> questionable as the mapping information from Scott Isaacson is vag=
ue
=