Subj: Synopsis of Issue Resolution at the JMP Meeting, 5/16/97 From: Tom Hastings Date: 5/16/97 File: iss-list.doc Summary of the major decisions: 1. No duplication between attributes and objects. 2. Any attributes that are mandatory will be in the Job Status table (renamed back to Job table), except the mandatory jobOwner attribute, which is a string and will remain as a mandatory attribute in the Attribute table. The Attribute table has a shorter lifetime than the Job table. Also the jobOwner is a STATIC attribute, so that a monitoring application is unlikely to need to get it on each poll cycle, only the first. However, the value of keeping jmJobTable entries without the jobOwner only works for systems that have the jmJobSubmissionID that is known to the client. The 7 mandatory objects in the jmJobTable are: jmJobState jmJobKOctetsRequested jmJobKOctetsProcessed (by the interpreter) [name change from xxxCompleted] jmJobImpressionsRequested jmJobImpressionsCompleted (stacked) jmJobSheetsCompleted (stacked) jmNumberOfInterveningJobs The mandatory attributes are: jobOwner (63 octet string) The deviceAlertCode and outputBinIndex attributes will remain in the jmAttributeTable and will NOT be mandatory attributes. 3. The multiplexed object/attribute jmJobStateAssociatedValue/jobStateAssociatedValue has been deleted from both tables. 4. Any attribute that is implemented shall be instantiated when the job is instantiated. The agent shall not add attributes as the job is processed. If the agent doesn't know the value at submit time, the agent shall fill in the "unknown" value. This allows a management app that has once discovered what attributes are implemented by an agent to request multiple attributes in a single PDU and not have one of them bomb out because the agent had not yet put it in the table. 5. We reviewed the comparison with IPP (ipp-jmp.doc) and made the following decisions: a. Don't add "number-up" as an attribute - number up usage can be better determined from comparing the conditionally mandatory jobPagesCompleted attribute with the jmImpressionsCompleted object. b. Add "printer-resolution" with keyword/enum values from IPP which are: normal, 'res-100', 'res-200', 'res-240', 'res-300', 'res-600', 'res- 800', 'res-1200', 'res-1800', 'res-100x200', 'res-300x600', 'res- 600x300', 'res-400x800', 'res-800x400', 'res-600x1200', 'res-1200x600', and 'res-1800x600'. c. Add "job-originating-host" from IPP with the same meaning that it is only the end-user host, not an intermediate server host. d. We did not agree to add the IPP job-state-message, though the JMP processingMessage(11) is pretty similar. e. The remaining issue is that the jmJobState object and the jobStateReason1 attribute don't align with IPP's job-state and job-state-reasons attributes. In JMP, jmJobState object is mandatory, but the jobStateReasons1 attribute is conditionally mandatory, while in IPP, both the job-state and the job-state-reasons attributes are mandatory. JMP jmJobState object values are: other, unknown, held, pending, processing, [printing was dropped to agree with IPP], needsAttention, canceled, and completed. IPP job-state attribute valeus are: unknown, pending, processing, terminating, retained, completed. IPP represents the 'held' state with various "job-state-reasons" attribute values while the job is in the 'pending' state. IPP represents the 'needsAttention' state with the "job-state-reasons"='printer-stopped attribute' IPP 'terminating' is like JMP 'canceled's states, except that IPP 'terminating' transitions into 'retained' then 'completed', while JMP 'canceled' is a final state, as is the 'completed' state. JMP represents IPP's 'retained' state using the "jobStateReasons"='jobRetained' attribute. We decided to put this issue on the IPP agenda for this coming Wednesday, 1-3pm PDT. ********************************************************************* Since most of the JMP participants were not present at the Wed IPP call, I'll send out those agreements separately for approval of the JMP participants. ********************************************************************* 6. We made a few changes to the paper entitled: "Property Table of JMP attributes" (attr-tab.doc). Then we agreed that it would be kept a separate document and referred to from the web page and the FAQ. ACTION ITEM (Tom): Update and re-post. Get web page to cite. 7. Here are the resolutions to the specific issues. Issues with ???? were not covered and are still issues. If you want more description of the issue, see the issues.doc and issues.pdf file in: ftp://ftp.pwg.org/pub/pwg/jmp/contributions/ 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? Closed: Delete the duplicates from the Attributes Table instead. ISSUE 68 - Delete the Job State Group/Table all together, since all objects are also duplicated as attributes? Closed: No, the Job State Table is useful to scan for jobs using Get Next and select the desired columns. ISSUE 69- Does order of assignment of JmAttributeTypeTC enums make any difference? Closed: No, can't use Get Next to step through jobs. The requester can specify which attributes using Get, since the agent is now required to materialize each supported attribute when the job is accepted. So the application can supply a number of Gets in a single PDU without fear of a error, once the application has learned which attributes the agent implements. ISSUE 70 - Add some simple general device alert TC, instead of using the Printer MIB Alert Codes. Closed: No, use the 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? Closed: the agent shall reset it to 0 and keep an internal variable for the next row to assign. That internal variable shall be persistent across power cycles. Also the agent shall find the next newest active job, when the newest is canceled or completes and there are still active jobs in the tables. ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus? Closed: Yes, and allow agents to implement one, the other, or both values. Making it easy for an agent to do both will make such an application that doesn't want to depend on the Printer MIB being implemented, i.e., the application wants to work with all three configurations. ISSUE 75 - Should the Attribute enum values be grouped so additions could be added in the appropriate section? Closed: Yes. Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or queueNameRequested be made Mandatory? Closed: Only jobOwner is made manadatory, but it will remain in the Attribute table, rather than being moved to the Job table. 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? Closed: Yes. The application can request each object and/or attribute directly and it will fit into a single PDU (20 objects or attributes). Now that attributes are required to be instantiated as the same time as the job is received, whether the value is known then or not, avoids the problem that a PDU with multiple gets would get aborted because the agent hadn't instantiated the attribute in the table. Issue 79 - Should the 'printing' state be combined into the 'processing' state, like IPP? Closed: Yes, but the other differences between JMP and IPP need discussion with IPP. Issue 80 - How handle IPP "sides" attribute which has 3 enum values? Closed: Don't inculde the IPP values; the agent can map them to 1 or 2. Issue 81 - Add IPP "numberUp" attribute? Closed: No. Can get whether number up is being used by comparing the conditionally mandatory jobPagesCompleted attribute with the jmImpressionsCompleted object. ISSUE 82 - Change the OID assignment as Jeff Case suggests so no holes? Closed: Yes, including reserving an OID for traps, in case we need them in the future. ISSUE 83 - Can some attributes be deleted before the jmGeneralAttributePersistence expires? Closed: No. All attributes shall be instantiated at the same time and deleted at the same time. Then applications can requrest any number of objects and attributes in a single PDU and not get an error back on one that has been implemented but hasn't been put in the table. The values may change at any time. ISSUE 84 - Change Associated Value for 'printing' state to impressionsCompletedCurrentCopy(56)? Closed: Since the AssociatedValue object/attribute is being deleted, this issue is moot. ISSUE 85 - Break the MIB into a monitoring and an accounting MIB? Closed: No. There are too many attributes that are used for both monitoring and accounting. ISSUE 86 - Clarify jobCopiesRequrested(44) vs. documentCopiesRequested(46) Closed: Use jobCopiesRequested for single document jobs for both systems that support only one documen t per job and ones that support mujltiple documents. Only use documentCopiesRequested, when a multiple document job actually specifies that individual documents are to be made copies. 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. Also keep outputBinIndex as a MULTI-ROW attribute, so don't need to add multi(-3) enum value. 5