At 09:25 07/30/97 PDT, JK Martin wrote:
>Why did you decide to use the LAST 39 octets of the jmJobOwner value,
>rather than the FIRST 39 octets?
All the other ones were that way. The end is more likely to be
unique than the beginning.
Also now that we have 39 characters, the chances that some truncation
is going to happen is even less.
The idea is to try to pick the end that will increase the chances
of uniqueness. So for user names that have first and last, the last
name is more likely to be unique than the first names.
But do you have other experience that shows we should change jobOwner
to the first 39 characters?
Do we need to make this an ISSUE?
Tom
>> ...jay
>>----- Begin Included Message -----
>>>From jmp-owner at pwg.org Tue Jul 29 19:29 EDT 1997
>Date: Tue, 29 Jul 1997 16:25:50 PDT
>To: Harry Lewis <harryl at us.ibm.com>
>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: Re: JMP> JobSubmission ID Format 0 [Harry's and Tom's
> resolution]
>Cc: <jmp at pwg.org>
>>Harry talked with his developers and we've come up with the following
>resolution:
>>Format 0 will be reserved to the agent to use when the client does not
>supply a job submission id in the job submission protocol. In this
>format the agent SHALL use the last 39 octets of the jmJobOwner value.
>>We will add a new format 8 for the client's to use in a job submission ID
>that includes the job owner's name.
>>In the future, if agents need other formats for use when the client doesn't
>supply a job submission ID, they can be proposed for registration.
>>In the meantime, agents will use the job owner format (format 0) and
>clients will use formats 1-8.
>>The new text will be:
>>JmJobSubmissionTypeTC ::= TEXTUAL-CONVENTION
>STATUS current
>DESCRIPTION
>"Identifies the format type of a job submission ID.
>>The ASCII characters '0-9', 'A-Z', and 'a-z' are assigned in order giving 62
>possible formats.
>>Each job submission ID is a fixed-length, 48-octet printable ASCII coded
>character string, consisting of the following fields:
>> octet 1 The format letter.
> octets 2-40 A 39-character, ASCII trailing SPACE filled
> field specified by the format letter, if the
> data is less than 39 ASCII characters.
> octets 41-48 A sequential or random number to make the ID
> quasi-unique.
>>If the client does not supply a job submission ID in the job submission
>protocol, then the server SHALL assign a job submission ID using any of the
>standard formats that are reserved to the agent. Clients SHALL not use
>formats that are reserved to agents.
>>The format values registered so far are:
>> Format
> Letter Description
> ------ ------------
> '0' octets 2-40: last 39 bytes of the jmJobOwner
> object.
> octets 41-48: 8-decimal-digit sequential number
> This format is reserved to agents for use when
> the client does not supply a job submission ID.
> Clients wishing to use a job submission ID that
> incorporates the job owner, SHALL use format '8'.
>> NOTE - other formats may be registered that are
> reserved to the agent for use when the client does
> not supply a job submission ID.
>> '1' octets 2-40: last 39 bytes of the jobName attribute.
> octets 41-48: 8-decimal-digit random number
>> '2' octets 2-40: Client MAC address: in hexadecimal
> with each nibble of the 6 octet address being
> '0'-'9' or 'A' - 'F' (uppercase only).
> Most significant octet first.
> octets 41-48: 8-decimal-digit sequential number
>> '3' octets 2-40: last 39 bytes of the client URL
> [URI-spec].
> octets 41-48: 8-decimal-digit sequential number
>> '4' octets 2-40: last 39 bytes of the URI [URI-spec]
> assigned by the server or device to the job when
> the job was submitted for processing.
> octets 41-48: 8-decimal-digit sequential number
>> '5' octets 2-40: last 39 bytes of a user number, such
> as POSIX user number.
> octets 41-48: 8-decimal-digit sequential number
>> '6' octets 2-40: last 39 bytes of the user account
> number.
> octets 41-48: 8-decimal-digit sequential number
>> '7' octets 2-40: last 39 bytes of the DTMF incoming
> FAX routing number.
> octets 41-48: 8-decimal-digit sequential number
>> '8' octets 2-40: last 39 bytes of the job owner name
> (that the agent returns in the jmJobOwner object).
> octets 41-48: 8-decimal-digit sequential number
>>NOTE - the job submission id is only intended to be unique between a limited
>set of clients for a limited duration of time, namely, for the life time of
>the job in the context of the server or device that is processing the job.
>Some of the formats include something that is unique per client and a random
>number so that the same job submitted by the same client will have a
>different job submission id. For other formats, where part of the id is
>guaranteed to be unique for each client, such as the MAC address or URL, a
>sequential number SHOULD suffice for each client (and may be easier for each
>client to manage). Therefore, the length of the job submission id has been
>selected to reduce the probability of collision to an extremely low number,
>but is not intended to be an absolute guarantee of uniqueness.
>None-the-less, collisions are remotely possible, but without bad
>consequences, since this MIB is intended to be used only for monitoring
>jobs, not for controlling and managing them."
>REFERENCE
>"This is like a type 2 enumeration. See section 3.6.3."
>SYNTAX OCTET STRING(SIZE(1)) -- ASCII '0'-'9', 'A'-'Z', 'a'-'z'
>>>At 08:23 07/28/97 PDT, Harry Lewis wrote:
>>Tom wrote:
>>>>>I think we also agreed that the agent could use any of the standard
>>>formats, if the job submitter didn't submit a jobsubmissionid, rather
>>>than constraining the agent to a particular format. So I deleted
>>>format 0. The 0 format is no longer the default format that the agent
>>>uses if the submitter didn't supply a jobsubmissionid. The agent is
>>>free to use any format. Ok?
>>>>No, This is not OK. We agreed the agent can use any scheme to derive the
>>jmJobSubmissionID, if not passed in, including URL's, jobOwner etc, if known.
>>But, if the agent does not use a unique format ID, there is a high
probability
>>that the sequential part of the ID's will intersect - something which I think
>>should be avoided. Sequential ID's are, by definition, fairly local
constructs.
>>Keeping format 0 for the agent prevents the agent from "stepping on" the local
>>id's of a server, for example, because the server will always be using some
>>format ID other than 0.
>>>>>When adding the jobOwner format, I assigned it to 0, rather than the
>>>end. It seems like a particularly useful and important format.
>>>>Formats will "come and go". I don't this the enum given to the format has any
>>significance in terms of indicating it's "importance".
>>>>>>There's a pretty big question in my mind exactly WHY we think JobOwner needs
>>>>to be part of a default format 0, especially since jmJobOwner is a mandatory
>>>>object in the Job Table. I only offer the following definition as a
potential
>>>>compromise. I would prefer to keep format 0 as previously defined...
>basically
>>>>agent assigned.
>>>>>>I agree that it would be a problem if the spec says that a job owner has
>>>to be part of the default format. That is why we got away from having
>>>a single default format, I thought. So now the agent is free to use any
>>>if the standard formats, not just the 0 format when the submitter doesn't
>>>submit an ID.
>>>>Here, we do agree. Format 0 was never supposed to be a "fixed" format, just
>>an enum that assured this ID was assigned by the agent. I thought I picked
>>up in Nashua that folks wanted JobOwner to be the primary choice if the agent
>>had to assign an ID. We can establish preferred conventions via FAQ, if this
>>would be useful, but format 0 is intended to be "open" for the agent to make
>>intelligent choices based on what information is available (given the absence
>>of a "legitimate" jmJobSubmissioID).
>>>>>Are you worrying that one client might not supply a job submission id
>>>for a particular job owner, but that same user from another client
>>>might. So that the second client might assign a sequence number that was
>>>the same as the agent assigned for the first one and thereby be a collision?
>>>>>>That could happen with any of the formats, if the agent assigns
>>>the trailing number sometimes and the submitter does other times.
>>>>>>Do we want to fix that?
>>>>>>We could make separate format numbers for assigned by agent, versus
>>>assigned by the job submitter, for all the formats, thereby doubling
>>>the number of format numbers.
>>>>This really CAN'T happen with any format if the agent sticks to format 0.
>>That's the point. There is not need to double the number of format numbers!
>>>>Harry Lewis - IBM Printing Systems
>>>>>>>>----- End Included Message -----
>>>