Subject: Re: JMP> Last Call for JobSubmissionID Format ID Length

From: Tom Hastings <[email-masked]>
Date: Tue, 3 Jun 1997 14:26:39 PDT

I agree that we can go with one byte.  We need all the octets we can get.

We probably need to agree how to extend after format "9".

I suggest that we use single UPPER CASE letters, then single
lower case letters.

Tom

P.S. Ron,
I like this process for resolving issues too.

At 12:10 06/03/97 PDT, Ron Bergman wrote:
>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 <[email-masked]>
>> To: <[email-masked]>
>> Cc: <[email-masked]>
>> 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 -----
>> 
>>         [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: Ron Bergman <[email-masked]>
Date: Tue, 3 Jun 1997 17:56:03 -0700 (PDT)

Tom,

Your suggested method of extension is exactly what I would have
proposed.  This allows a total of 62 (if zero is included?) formats.
Seems like more than enough.

	Ron Bergman