Why did you decide to use the LAST 39 octets of the jmJobOwner value,
rather than the FIRST 39 octets?
...jay
----- Begin Included Message -----
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 -----