Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value

From: Harry Lewis <[email-masked]>
Date: Mon, 2 Jun 1997 12:36:04 -0400

Jay, I suggested cfA as the "format ID" for LPR/LPD, even though it "violates"
the 2 (or 1) byte format ID
definition, to accommodate existing systems that utilize this convention. I
have interpreting your
concerns about compatibility as indications that it will be unlikely for system
components to be created
or modified to add the JobSubmissionID format ID byte(s). Am I misreading you?

Yes, I would prefer to have an "architected" 1-byte format ID.

Harry Lewis

---------------------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 10:12 AM
 ---------------------------

        [email-masked]
        05/30/97 04:41 PM
Please respond to [email-masked] @ internet

To: Harry Lewis/Boulder/IBM@IBMUS
cc: [email-masked] @ internet
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value

Harry,

I'm a bit confused by your response.  You suggest that the format
identifier for LPR/LPD could be the "cfA" prefix string; however,
don't we want to be completely consistent with the form for the
format descriptor?

That is, all the other format descriptors are two-digit numeric
characters, and I would have thought that we'd want to define all
format descriptors in that manner to simplify parsing/lookup, etc.

Perhaps I'm missing something here?

Thanks for being agreeable to moving from a two-digit descriptor
to a single-digit descriptor.  Let's see if the rest of the group
can agree to that.

 ...jay

----- Begin Included Message -----

>From [email-masked] Fri May 30 11:14 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value
Date: Fri, 30 May 1997 11:16:01 -0400

Jay, thanks for your informative response on this topic. I agree that 2 bytes
is over-kill. I have no problem moving back to one byte for the Format ID.
Since LPR is already a defined standard, and cfA always
precedes the control file naming string, why not just reserve cfA as the LPR
format identifier? I know it uses more bytes, but this would alleviate the need
for adding the Format ID somewhere in the process.

Harry Lewis - IBM Printing Systems

------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM -----

        [email-masked]
        05/29/97 07:17 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet
cc:
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value

In that previous message I forgot to state that I think it would be
a good idea to formally define a job submission ID specifically for
LPR/LPD, even though such an ID would not necessarily help the kinds
of monitoring apps we've been talking about recently (ie, "out-of-band"
job monitors).

The encoding of the ID for LPR/LPD is quite trivial and follows the
format defined in RFC 1179 for the encoding of the control/data files.
Control file names follow this form:

 cfAnnn<hostname>   example:  cfA027punky.underscore.com

That is, a fixed prefix of "cfA" followed by a three-digit job number
(000-999) followed by the hostname (usually fully qualified).

Data files are similar, except that the "cfA" prefix is replaced with
"dfA".  (Hence the common references to "cf/df" files when talking
about LPD spooling.)

The idea here is that the names of the control and data files are very
similar, with the only exception being the first character (ie, "c"
vs.  "d").  Since this distinction in prefixes is relatively
meaningless for job identification, we shouldn't need to include the
first three characters in the Job MIB job submission ID string.

This results in an encoding of:

 nnn<hostname>   example:  027punky.underscore.com

Of course, the <hostname> component would have to be truncated after
the 27th character, but since hostnames are formed with a left-to-right
hierarchy, this should be sufficient for most environments (right??).

The LPD encoding would be tagged with "04" in the list of defined
job submission ID formats.

By the way, why in the world do we need TWO octets for the format
descriptor?  As it stands we have only 5 formats (including this
new LPD definition)!  If we reduce this to a single byte (and continue
to use a decimal-digit encoding technique), then we have room for
5 additional formats.  Even if we needed more, we could then use
a hex-like technique and start using letters (a-z, etc).

This is a classic case of over-engineering, IMHO.  Here we are worrying
about truncating valuable information when we're wasting it elsewhere.
We should change this.

Comments?

 ...jay

----- End Included Message -----

---

From: JK Martin <[email-masked]>
Date: Mon, 2 Jun 1997 12:37:59 -0400 (EDT)

Harry,

Your concern for integration is most appreciated, however I don't
think it's a big deal to strip the leading "cfA" prefix off the
LPR/LPD job submission string.

Ron Bergman:  It looks like we're going to need a "vote" (ie, in
IETF terms, a "statement of consensus" ;-) regarding the change
in the length of the format descriptor for the job submission ID
string.  (From the current 2 bytes to 1 byte.)

	...jay

----- Begin Included Message -----

>From [email-masked] Mon Jun  2 12:34 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value
Date: Mon, 2 Jun 1997 12:36:04 -0400

Jay, I suggested cfA as the "format ID" for LPR/LPD, even though it
"violates" the 2 (or 1) byte format ID definition, to accommodate
existing systems that utilize this convention. I have interpreting your
concerns about compatibility as indications that it will be unlikely
for system components to be created or modified to add the
JobSubmissionID format ID byte(s). Am I misreading you?

Harry Lewis

        [email-masked]
        05/30/97 04:41 PM

Harry,

 ...jay

------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM -----

        [email-masked]
        05/29/97 07:17 PM

Comments?

 ...jay

----- End Included Message -----

----- End Included Message -----

---

From: Harry Lewis <[email-masked]>
Date: Mon, 2 Jun 1997 15:32:25 -0400

I appreciate the "Call to vote" for JobSubmissionID format ID (1 vs. 2 bytes).
I want to add that I believe the original proposal was 1 byte and I think we
"up'd" it to 2 bytes in Austin based on some expectation that other (how shall
I phrase this...) individuals were aware of (close your ears...) Companies...
that may have a lot of additional formats to register.

So, we should make sure we receive some input from Tom. He seemed like the
individual most likely to know of such a company.

Harry Lewis

-------- Forwarded by Harry Lewis/Boulder/IBM on 06/02/97 01:19 PM -------

        [email-masked]
        06/02/97 11:18 AM

Harry,

 ...jay

----- Begin Included Message -----

Harry Lewis

        [email-masked]
        05/30/97 04:41 PM

Harry,

 ...jay

------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM -----

        [email-masked]
        05/29/97 07:17 PM

Comments?

 ...jay

----- End Included Message -----

----- End Included Message -----

---

From: Harry Lewis <[email-masked]>
Date: Tue, 3 Jun 1997 11:47:46 -0400

I like Patricks proposal

>I would like to suggest:
>    user@host+jobnumber

>For example:
>    root@dickory+024  or [email-masked]+024

>The job ID embeds the user, originating host, and job number id
>into one  'string'.

>The job ID would fix up the problem of conflicts in job numbers
>which could occur from different hosts,  if there was not a distinguisher.
>In addition,  I like to see the user's name in the id.

I agree with Jay, that this does not fully satisfy the desire for a reliable
attribute that indicates JobOwner.

>The question now might be:  can this format serve as a useful way to
>identify the job owner, thereby eliminating the need to have the
>jobOwner object in the jobState table?

>I still think the answer is No, due to the length restrictions for the
>jmJobSubmissionID object.  If that object were to increase in size to,
>say, 63 bytes, then maybe this could work.  (I can hear Harry cringing
>even as I write this... ;-)

I would *strongly* object to making jmJobSubmissionID any larger (as Jay
predicted). I believe we MUST keep in mind that we are moving job
identification from the paradigm of an element in a (LPR/LPD) submission
control file to an object in a job MIB. This implies database storage in the
printer with some degree of persistence (to be useful). Yes, I am defending the
"low-end" embedded controller, but I don't think any of us really want to
design a job MIB that no printers take advantage of.

>If the submission ID object were increased to 63 bytes (hey, or even
>more! ;-), then it might very well be that jobOwner can stay in the
>quickly-aged-out jobAttribute table.

So I am in favor of an LPR/LPD jmJobSubmissionID format (along the lines of
Patricks proposal) plus keeping JobOwner as a *mandatory* job Attribute. As Jay
points out, the job MIB does allow separate
persistence between the Job Table and the Attribute Table and does insist that
Job Table will persist as long or longer than Attribute Table. But, no where,
does the job MIB imply that the Attribute table
should age "rapidly".

The notion of JobOwner being a *mandatory* attribute, coupled with the idea
that this attribute must be "instantiated" as soon as the job is Pending should
allow the management or accounting application to
make an association between the jmJobIndex (effectively the printer assigned
job id) and the jobOwner during the Pending and Processing states. It is only
*after* the job has reached the Completed state that the two persistence clocks
start ticking.