Tom's suggestion for extending the format byte definitions
looks ok to me.
...jay
----- Begin Included Message -----
Date: Tue, 3 Jun 1997 14:26:39 PDT
To: Ron Bergman <rbergma at dpc.com>
From: Tom Hastings <hastings at cp10.es.xerox.com>
Subject: Re: JMP> Last Call for JobSubmissionID Format ID Length
Cc: jmp at pwg.org, Harry Lewis <harryl at us.ibm.com>, jkm at underscore.com
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 <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 -----
>>>
----- End Included Message -----