If one or more persons have indicated the expectation of a *large*
number of registered job ID formats, then great. (I had not heard
that before.) If we think we need two bytes, then as long as someone
can *really* justify it, then it should probably stay two bytes.
(We just don't want to here a line like "somebody somehow for some
reason just might want to register a lot of ID formats..." ;-)
Ron: Would you mind asking for "Last Call" on this issue? Thanks.
...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: 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 -------
jmp-owner at pwg.org
06/02/97 11:18 AM
Please respond to jmp-owner at pwg.org @ internet
To: Harry Lewis/Boulder/IBM at IBMUS
cc: jmp at pwg.org @ internet
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value
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 harryl at us.ibm.com Mon Jun 2 12:34 EDT 1997
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: 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
---------------------------
jkm at underscore.com
05/30/97 04:41 PM
Please respond to jkm at underscore.com @ internet
To: Harry Lewis/Boulder/IBM at IBMUS
cc: jmp at pwg.org @ 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 harryl at us.ibm.com Fri May 30 11:14 EDT 1997
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 -----
----- End Included Message -----
----- End Included Message -----