I've posted the usual files for version V0.85 which corresponds to
Internet-Draft: draft-ietf-printmib-job-monitor-05.txt.
Please make any comments this week or by next Tuesday, 9/2 (day after
Labor Day), so we can decide whether to have a telecon later that week
(or beginning of the following week).
Also please do your mapping assignments. Use them as a way to review
the MIB specification. Pretend you are an SNMP agent responding to
a Get for each object and attribute listed in the mapping template and
determine how to get that information from the job submission protocol
for the service or device that your agent is providing access.
ftp://ftp.pwg.org/pub/pwg/jmp/mibs/
-rw-r--r-- 1 pwg pwg 119999 Aug 25 23:06 jmp-mib.mib
-rw-r--r-- 1 pwg pwg 285892 Aug 25 23:08 jmp-mib.pdf
-rw-r--r-- 1 pwg pwg 212538 Aug 25 23:10 jmp-mib.txt
-rw-r--r-- 1 pwg pwg 355840 Aug 25 23:14 jmp-mibr.doc
-rw-r--r-- 1 pwg pwg 312336 Aug 25 23:17 jmp-mibr.pdf
-rw-r--r-- 1 pwg pwg 317841 Aug 25 23:19 jmp-mibr.pdr
-rw-r--r-- 1 pwg pwg 8631 Aug 25 23:20 jmp.dic
The jmp-mib.pdf is without revision marks and has line numbers. This
is the version that JMP should make any comments against.
The jmp-mib.txt == draft-ietf-printmib-job-monitor-02.txt
The jmp-mibr.doc is with revision marks.
The jmp-mibr.pdr is with red revision marks.
The jmp-mibr.pdf is with black revision marks.
The jmp-mib.mib file compiles with one warning (assignment of the
temporary OID).
ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/
-rw-r--r-- 1 pwg pwg 212538 Aug 26 00:01 draft-ietf-printmib-job-monitor-05.txt
The issues list and the issues that we closed at the 8/8/97 JMP meeting
are available:
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r-- 1 pwg pwg 7177 Aug 25 23:23 issue111.txt
-rw-r--r-- 1 pwg pwg 6683 Aug 25 23:23 issue112.txt
-rw-r--r-- 1 pwg pwg 104448 Aug 25 23:24 issues.doc
-rw-rw-r-- 1 pwg pwg 113295 Aug 25 23:25 issues.pdf
-rw-r--r-- 1 pwg pwg 118819 Aug 25 23:27 issues.pdr
-rw-r--r-- 1 pwg pwg 78168 Aug 25 23:28 issues.txt
We closed issues 110 to 120 at the 8/6/97 meeting. The text portion
of those issues is:
ISSUE 110: Break jmAttributeTable into two tables: jmAttributeAsIntegerTable
and jmAttributeAsOctetsTable as suggested by David Perkins? Then an
application will need about half as many Get Next operations in order to
"harvest" all of the attributes, since there won't be any zero-length string
values for attributes that don't have strings and -1 or 1 values
representing 'other' for attributes that don't have integer values.
Closed: Do not divide the table into two tables. There is some benefit to
walking the table in pairs even though most attributes are either integer or
octet string, and not both.
ISSUE 111 (restated): How does an application determine the coded character
set for the objects and attributes that the agent generates (that cannot
come from the job submitting client)? Raised by David Perkins.
The following 3 objects and attributes are in question:
jmGeneralJobSetName object
processingMessage attribute
physicalDevice (name value) attribute
Closed: Add the JmUTF8StringTC for these three object/attributes. See
separate issue111.doc .pdf.
ISSUE 112 (re-stated): How does a management application determine the
coded character set for the per-job objects and attributes that are returned
by the agent whether submitted by the job submitting client or defaulted by
the agent when the job submitting client does not supply? Raised by David
Perkins.
Closed: Add the JmUTF8StringTC for these objects and add a jobCodedCharSet
attribute to indicate the set being used.
ISSUE 113: The big concern [from the Area directors] is that from the
user's perspective, jobs can be submitted via serial, parallel, or network
connections, and the Job MIB is only going to know about the network
connections. Raised by Chris Wellens.
Closed: Add additional text to clarify that the device may be directly
connected over a serial or parallel port or networked to the client and/or
server.
ISSUE 114: If nested jobs are sent to the printer and all have a
JobSubmissionID attached, what does the agent do? When a spooler receives a
job, it can put a banner page on the job by wrapping it inside of a job.
When this occurs, there can be separate JobSubmissionID's for each job. In
fact, if the printer doesn't find a JobSubmissionID on the outer job, it
will assign one. When the printer gets to the inner job, it will get the
true JobSubmissionID that was attached to the client's job. Raised by Bob
'Pentecost on 4/17/97 and re-raised by Harry Lewis on 7/16/97.
Closed: Add a reference to the Appendix B where PJL use of the job
submission ID is included and indicate in Appendix B that the later
occurrence of a job submission ID is the one that the agent uses. The
Appendix B text is:
NOTE - Some PJL implementations wrap a banner page as a PJL job around a job
submitted by a client. In this case, there will be two job submission ids.
The outer one being the one with the banner page and the inner one being the
original user's job. The agent SHALL use the last received job submission
ID for the jmJobSubmissionID index, so that the original user's job
submission ID will be used, not the banner page job ID.
ISSUE 115: If the agent changes state to CANCEL as soon as it becomes aware
of the cancel command (to satisfy the end user), there may still be a page
or two in the pipeline that the accounting application would miss if it
noticed the state change and performed it's data collection.
So, we suggest using jobStateReasons in this case.
CANCEL - processingToStopPoint
which progresses to
CANCEL - jobCanceledByUser
The question is, since these jobStateReasons are not "mandatory", how do we
communicate and agree on this recommendation? In other words, how do we
achieve interoperability? Raised by Harry Lewis on 7/8/97.
Closed: Move the processingToStopPoint reason from the jobStateReasons2
attribute to the jmJobStateReasons1 object immediately after abortedBySystem
reason and renumber the ones following. Also recommend using
processingToStopPoint reason with the aborted and canceled states. The new
text is:
processingToStopPoint 0x4000
The requester has issued an operation to cancel or interrupt the job or the
server/device has aborted the job but the server/device is still performing
some actions on the job until a specified stop point occurs or job
termination/cleanup is completed.
This reason is recommended to be used in conjunction with the canceled or
aborted job state to indicate that the server/device is still performing
some actions on the job after the job leaves the processing state, so that
some of the jobs resources consumed counters may still be incrementing while
the job is in the canceled or aborted job states.
ISSUE 116: Delete the 'other(1)' jmJobState value? I thought we had
covered all possible states with the 7 primary plus the JmJobStateReasons.
Why do we need other? Did we not accomplish what was claimed?Raised by Ron
Bergman on 7/28/97.
Closed: delete the 'other(1)' jmJobState value.
ISSUE 117: What is the difference between Toner Economy
(tonerEconomyRequested and tonerEconomyUsed) and Toner Density
(tonerDensityRequested and tonerDensityUsed)? (see page #51) They appear to
be identical from the description (or very very close!) Raised by Ron
Bergman on 7/28/97.
Closed: Cut and paste error copied the explanation from one to the other.
Change the tonerEconomy to say toner economy. Economy is an enum, density
is a number from 1 to 100. Several printers have both, so we need both.
ISSUE 118: Alignment of IPP and JMP. A job monitoring MIB agent providing
access to an IPP system should be able to access the same data as is created
by IPP. Lengths of text characters should be the same, not different (255
vs 63, respectively). Are there any other differences that would cause
problems. See ietf-ipp.doc .pdf in protomap sub-directory. Raised by Paul
Moore on 8/7/97.
Closed: Leave the lengths as they are. Most real IPP implementations will
not exceed the 63 length in practice.
ISSUE 119: Is the new 32-bit IPP "job-identifier" now the same as the
32-bit jmJobIndex? Is the maximum range 31-bits: 1 to 2**31-1 in both?
Raised by Paul Moore on 8/7/97.
Closed: Clarify that the jmJobIndex is the same as the IPP
"job-identifier", if IPP keeps the job-identifier. However, push back since
the IPP meeting indicates that maybe this issue isn't settled. Also there
was discussion that an agent that is providing access to a device that
supports multiple job submission protocols, including IPP, may have a
problem using the IPP "job-identifiers", unless the device also assigns the
identifiers for the other job submission protocols from the same
job-identifier number space.
The following text has been incorporated into section 3.6:
It is recommended that agents that are providing access to servers/devices
that already allocate job-identifiers for jobs as integers use the same
integer value for the jmJobIndex. Then the jobs will have the same job
identifier value as the jmJobIndex value, so that users viewing jobs by
management applications using this MIB and applications using other
protocols will see the same job identifiers for the same jobs. Agents
providing access to systems that contain jobs with a job identifier of 0
SHALL map the job identifier value 0 to a jmJobIndex value that is one
higher than the highest job identifier value that any job can have on that
system. Then only job 0 will have a different job-identifier value than the
job's jmJobIndex value.
NOTE - If a server or device accepts jobs using multiple job submission
protocols, it may be difficult for the agent to meet the recommendation to
use the job-identifier values that the server or device assigns as the
jmJobIndex value, unless the server/device assigns job-identifiers for each
of its job submision protocols from the same job-identifier number space.
ISSUE 120: The management app should be able to read an object(s) to get
the number of consecutive rows in a "packed" table to put into a single Get,
so as to reduce network traffic and decrease the time to get the data. What
about falling off the end of the job and attribute tables? Raised by Paul
Moore on 8/7/97 after having this trouble with the Printer MIB Alert table.
Closed: The attribute table is by definition sparse, since the fourth index
is present. For the other tables, since jobs may be canceled or aborted
before completing, there can be holes in the job tables, even though we
require that the jmJobIndex be assigned incrementally on job acceptance. So
we can't add any objects that can help in addition to the
jmGeneralOldestActiveJobIndex and jmGeneralNewestActiveJobIndex that we
already have that say where to start and end. SNMP v2 solves the problem of
reducing network traffic by using bulk get.
ISSUE 121: jmJobKOctetesProcessed can be a multiple of
jmJobKOctetsRequested, for implementations that make multiple passes over
the data. However, the same difference is not specified for
jmJobImpressionsComplete/jmJobImpressionsRequested objects and for
pagesCompleted/pagesRequested attributes. Brought up by the JMP committee
at the meeting.
Closed: Make jmJobImpressionsComplete/jmJobImpressionsRequested objects and
for pagesCompleted/pagesRequested attributes consistent with
jmJobKOctetesProcessed/jmJobKOctetsRequested.