Looks good!
Ron
On Tue, 29 Jul 1997, Tom Hastings wrote:
> 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
> >
> >
>
>