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: Harry Lewis <harryl at us.ibm.com>
To: <jkm at underscore.com>
Cc: <jmp at pwg.org>
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 -----
jmp-owner at pwg.org
05/29/97 07:17 PM
Please respond to jmp-owner at pwg.org @ internet
To: jmp at pwg.org @ 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 -----