There has been a significant discussion regarding the length of the
JobSubmissionID Format ID length. I recall that it was changed to
2 bytes in Austin because no one believed that more than 30 bytes
would ever be needed for the Submission ID.
The proposal is:
"Now that we have a valid reason for maximizing the Submission ID
the size should be reduced to one byte."
I have not seen any objections to this proposal. If anyone objects,
please respond ASAP. The proposal will be accepted if there are no
objections by Monday, June 9th.
Ron Bergman
On Mon, 2 Jun 1997, JK Martin wrote:
> 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 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 -----