Tom,
So, one day before the PWG meetings you present a list of 16 new
issues (disregarding, for a second, the many "sub-issues" you've
presented).
This is the same old stuff that has kept the Job MIB from making
significant progress these last two years. This is Not Good.
No matter what, the Job Monitoring MIB is going to CLOSE its
effort on Friday, June 27, right???
...jay
----- Begin Included Message -----
Date: Thu, 19 Jun 1997 14:57:02 PDT
To: jmp at pwg.org
From: Tom Hastings <hastings at cp10.es.xerox.com>
Subject: JMP> Comments on JMP V0.82 from Xerox developers
The following comments are from an internal review at Xerox of the Job
Monitoring MIB, V0.82. I started numbering these issues starting with the
next free issue in issues.doc.
ISSUE 88 - Add jmGeneralNumberOfJobsProcessed object since server or printer
was booted?
Most MIBs have some sort of utlization counter. The Job Monitoring MIB
should have one also. Add the object to the jmGeneralTable. We assume that
this object SHALL NOT be persistent across power cycles.
The DESCRIPTION is proposed to be:
jmGeneralNumberOfJobsProcessed OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of jobs that have completed processing for this job set since
the server or device was powered on."
::= { jmGeneralEntry 7 }
ISSUE 89 - Add jmGeneralAttributesImplemented object with bits for each
attribute implemented?
Instead of an application not knowing which attributes an implementation
implements and trying to discover by getting errors, or by always using Get
Next, instead of Get, how about adding a jmGeneralAttributesImplemented
object to the jmGeneralTable that has a bit for each attribute implemented.
jmGeneralAttributesImplemented OBJECT-TYPE
SYNTAX OCTET STRING(SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A bit string indicating which JmAttributeTypeTC enum values are
implemented. The value is a constant independent of which bits are currenly
in entries in the jmAttributeTable. The most significant bit of the first
octet is assigned the value 0 to correspond to enum 0 (not used), the next
most significant bit of the first octet is assigned the value 1 to
correspond to enum 1 (other), the next bit is assigned the value 2
(unknown), 3 (jobStateReasons2) etc. up to 32*8 - 1 = 255"
::= { jmGeneralEntry 8 }
ISSUE 90 - The (MANDATORY) OCTET STRING objects should have a minimum MAX
size required
Otherwise, trivial implementations can implement too short sizes and be
conforming. The SNMP conformance syntax as the end of the MIB has provision
for specifying the minimum maximum that SHALL be implemented. The 63 in
OCTET STRING(SIZE(0..63)) is the maximum size and the 0 is the minimum size
for an instance returned on a Get operation. The (MANDATORY) OCTET STRING
objects are with suggested MAX size required:
jmGeneralJobSetName 8 octets required to be implemented
jmJobSubmissionID 32 octets required to be implemented
ISSUE 91 - The MANDATORY jobOwner attribute should have a minimum MAX size
required
Otherwise, trivial implementations can implement too short sizes and be
conforming.
We suggest that 16 octets of the maximum 63 be required to be implemented.
Such a maximum will also help with the next issue.
ISSUE 92 - The MANDATORY jobOwner attribute needs to persist as long as
there is job data
92a: The MANDATORY jobOwner attribute needs to persist as long as there is
job data. Otherwise, a client that does not have access to the
jobSubmissionID or a system that does not have a jobSubmissionID cannot
identify the jobs in the jmJobTable, after the agent removes the job's
attributes from the jmAttributeTable.
92b: If it is agreed that the MANDATORY jobOwner SHALL persist for the
longer period of time, then it should be moved to the jmJobTable, where all
the other MANDATORY attributes have been made objects.
92c: Then the jmAttributeTable could be made OPTIONAL, so that really low
end printers would not need to implement the jmAttributeTable at all.
Experience at Xerox with low end non-queuing printers suggests that not
requiring the jmAttributeTable is a win. With a required maximum of only 20
octets (see previous issue), it is reasonable to move the jobOwner to the
MANDATORY jmJobTable.
ISSUE 93 - The jobName and jobSubmission[ToDevice]Time should be MANDATORY
93a: The windows queue monitoring show three attributes: jobOwner, jobName,
and start time. In IPP, jobName is a MANDATORY attribute. In order to work
for all configurations, the jobSubmissionToDeviceTime should be changed to
jobSubmissionTime and be used for all three configurations: configuration 1:
device, configuration 2: server, and configuration 3: device. The
jobSubmissionToServerTime shall only be used in configuration 3, where
jobSubmissionTime is also used (for the device). Then jobSubmissionTime can
be made MANDATORY (since it can be used in all three configurations).
93b: If the jobName attribute is made MANDATORY then it should have a
minimum maximum value specified for conformance. We suggest that 12 octets
is sufficient.
93c: If jobName and jobSubmissionTime are made MANDATORY, then they should
be moved to the jmJobTable as well, so that the jmAttributeTable can remain
OPTIONAL (see previous issue).
ISSUE 94 - Are the 8 octet fields in the jobSubmisionID printable or binary?
The text says "8-decimal-digits". Could it be allowed to be a binary
sequence number or random number? Then the chances of collision are even
lower.
ISSUE 95 - When reducing the size of the jobSubmissionID field from 2 to 1,
the other fields weren't increased by 1.
ISSUE 96 - Add a jobSubmissionID format for jobOwner
The first octet would be an ASCII '4'. The next 8 would be a sequential
number, and the remaining 23 octets would be the low order 23 octets of the
jobOwner.
ISSUE 97 - Add some jobSubmissionID formats for numeric identifiers
97a - Add one for POSIX user numbers
97b - Add one for user account numbers
97c - Add one for DTMF incoming FAX routing number
ISSUE 98 - The sequence number and random number in the jmJobSubmissionID
should be the least significant field, not the most significant field
Then a requester can leave off the sequential number or random number in a
GetNext and find all of the jobs from a particular MAC address or client URL
(or for a particular jobOwner). In order to make this switch, we need to
specify that when the MAC address, client URL, (jobOwner, or numberic id) is
shorter than 23 octets, that the field is shortened, rather than being
padded out to 23 octets. The least significant field is always 8 octets
with leading zeroes, so that we don't need any delimiters between the two
fields.
So the spec would become:
Format
Number Description
------ ------------
1 octets 2 to n: upto last 23 bytes of the jobName
attribute; n < 26
octets n to n+7: 8-decimal-digit random number
2 octets 2 to n: Client MAC address; n < 26
octets n to n+7: 8-decimal-digit sequential
number
3 octets 2 to n: last 23 bytes of the client URL;
n < 26
octets n to n+7: 8-decimal-digit sequential
number
.. to be registered according to procedures of a
type 2 enum. See section 7.3 on page 22.
ISSUE 99 - The jobSubmisionID format '0' makes no sense
98a: There are two interpretations of the text there:
1. The agent only puts a single digit of '0' for the entire jobSubmissionID
index - but each subsequent submission would replace the entry.
2. The agent tacks on whatever it wants after the '0' to make a unique
jobSubmissionID index for each job.
98b: If interpretation 2 is correct, then could we require the agent to use
the jobOwner instead, rather than leaving it unspecified how the agent fills
in the entry if interpretation is correct?
ISSUE 100 - The jobSubmissionIDTable should have jmJobSet and jmJobIndex as
indexes
The current formats will have collisions of jobSubmissionIDs occasionally.
The statement on lines 1695-1697: "None-the-less, collisions could occur,
but without bas consequences, since this MIB is intended to be used only for
monitoring jobs, not for controlling and managing them." is incorrect, since
future IETF and priviate MIBs are likely to have 'missles', not 'cameras'.
We've had experience with a table like this (jobClientIdTable) for a year
and a half and we added the jmJobIndex equivalent to the row entry that the
agent adds to make sure that no entry ever gets overwritten.
So we propose that the jmJobSet object and the jmJobIndex objects be added
as the least significant indexes to the jmJobSubmissionIDTable. They are
only simple integers and jmJobSet is likely to be 1 in most implementations.
ISSUE 101 - add jobSubmissionID as an attribute, so can find the ID when
scanning a job or attribute table.
An accounting program that wants to find the jobSubmissionID would have to
scan the entire jmJobSubmissionIDTable
ISSUE 102 - Make a TC out of the jobSubmissionID formats, so can publish new
ones more easily?
ISSUE 103 - Specify a minimum required persistence time for
jmGeneralAttributePersistence
Put the lower bound right in the ASN.1. We suggest 60 seconds as a minimum
with a recommendation of 300 (5 minutes). Even add a DEFVAL of 300 as the
default. The real low cost device that doesn't want to keep job information
around will have a small number of jobs anyway, since how many jobs can just
a device process in a minute anyway?
The spec would become:
SYNTAX Integer32(60..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum time in seconds for this instance of the Job Set that an entry
will remain in the jmAttributeTable after processing has completed , i.e.,
the time in seconds starting when the job enters the completed, canceled, or
aborted state. The value of this object MAY be either (1) set by the system
administrator by means outside this specification or MAY be (2) fixed by the
implementation, depending on implementation.
This value SHALL be equal to or less than the value of
jmGeneralJobPersistence. This value SHOULD be at least 300 which gives a
monitoring application five minutes in which to poll for job data."
DEFVAL { 300 } -- 5 minutes
::= { jmGeneralEntry 5 }
----- End Included Message -----