I've updated the Issues list with issues raised on the mailing list.
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-rw-r-- 1 pwg pwg 65024 May 12 16:41 issues.doc
-rw-rw-r-- 1 pwg pwg 78642 May 12 16:42 issues.pdf
-rw-r--r-- 1 pwg pwg 80293 May 12 16:42 issues.pdr
The posted files have a lot more descriptive material about each
issue. Please read that document as preparation for the San Diego meeting.
We want to close on all of them and produce the final MIB out of the meeting.
Please send comments on any of the issues (after reading the issues file)
BEFORE the meeting to get the discussion going.
Here is a synopsis of the issues from the issues file that
are open followed by the closed issues that haven't yet been put into a
document:
The outstanding issues are:
Issue 61 - Need to clarify the semantics of each object and attribute with
respect to Configuration 1, 2, and 3.
ISSUE 67 - Delete the three objects in the Job State table that duplicate
attributes? jmJobStateKOctetsCompleted, jmJobStateImpressionsCompleted, and
jmJobStateAssociatedValue?
ISSUE 68 - Delete the Job State Group/Table all together, since all objects
are also duplicated as attributes?
ISSUE 69- Does order of assignment of JmAttributeTypeTC enums make any
difference?
ISSUE 70 - Add some simple general device alert TC, instead of using the
Printer MIB Alert Codes.
ISSUE 71 - Are there any attributes that need to be clarified as to which
apply to servers and which apply to devices and which apply to either?
ISSUE 72 - What should happen to jmGeneralNewestActiveJobIndex when all the
active jobs complete?
ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus?
ISSUE 75 - Should the Attribute enum values be grouped so additions could be
added in the appropriate section?
Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or
queueNameRequested be made Mandatory?
Issue 77 - Should jobCompletedDateAndTime/TimeStamp be canceled time too, or
add jobCanceledDateAndTime/TimeStamp?
Issue 78 - Should the "multiplexor" jobStateAssociatedValue(4) attribute be
removed from the Job Attribute Table and the equivalent
jmJobStateAssociatedValue object be removed from the Job State table?
Issue 79 - Should the 'printing' state be combined into the 'processing' state,
like IPP?
Issue 80 - How handle IPP "sides" attribute which has 3 enum values?
Issue 81 - Add IPP "numberUp" attribute?
ISSUE 82 - Change the OID assignment as Jeff Case suggests so no holes?
ISSUE 83 - Can some attributes be deleted before the
jmGeneralAttributePersistence expires?
ISSUE 84 - Change Associated Value for 'printing' state to
impressionsCompletedCurrentCopy(56)?
ISSUE 85 - Break the MIB into a monitoring and an accounting MIB?
2. Closed Issues - not yet reflected in the current draft
The following issues have been closed and have been incorporated into the
Internet Draft 00 and version 0.71 or earlier:
Issue 12 - What is the SNMPv1 and SNMPv2 error that an agent shall return if
there is no instrumentation for an object?
Closed: There is no such SNMP error. ALL uninstrumented objects in
mandatory groups of any MIB should always correctly return 'read-only'
static values specified in 'DEFVAL' clauses. 'DEFVAL' is a perfectly good
SMIv2 feature intended to cover this situation. Returning ANY SNMP error
for ANY object in a mandatory group with a legal instance qualifier (i.e.,
set of indices) is NOT legal in a literal reading of the SNMPv2 Protocol
spec (RFC 1905, page 10, in 'Get-Request PDU' handling). That's what 'shall
implement ALL the objects in this group' means! So add DEFVAL clauses to
all objects.
Issue 64 - Need to fill out Appendix A on mapping from the job submission
protocols to the Job Monitoring MIB for each of the three configurations.
Closed: Put into a separate document.
ACTION ITEM (all): Write up your job submission protocol mapping to the Job
Monitoring MIB.
Issue 65 - What Appendices should remain, which should be separate Internet
Drafts and/or informational RFCs and which should disappear?
Closed: No appendices for the Job Monitoring MIB, except for supplemental
information about the semantics of job states. Put any other information
into a separate informational RFC, such as mapping to ISO DPA, mapping to
IPP, mapping to other job submission protocols, etc.
Issue 73 - Is there a problem with outputBinIndex being made mandatory?
If outputBinIndex is made mandatory, but an implementation doesn't have the
Printer MIB, the agent has to put 0 as the value. Should we add one more
attribute: outputBinNumber, which is just a number, not an index into the
Printer MIB? If we do, which should be mandatory? Just one more reason to
get rid of the jmStateTable, which is forcing us to pick a particular
outputBin implementation and make it mandatory. If we got rid of the
JobState table, we could forget about making any of the 3 outputBinName,
outputBinNumber, or outputBinIndex attribute mandatory.
Closed: Don't add outputBinNumber. Just add other(-1), unknown(-2), and
multi(-3) values and keep outputBinIndex as mandatory. This does also
mean that jmAttributeValueAsInteger needs a lower bound of -3, not -2.