Subject: JMP> Changes agreed to for Job Monitoring MIB last week, 5/16/97

From: Tom Hastings <[email-masked]>
Date: Wed, 21 May 1997 23:43:25 PDT

I've posted the changes that I'm making to the Job Monitoring MIB
that we agreed to last week in San Diego:

ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r--   1 pwg      pwg        22016 May 22 06:23 iss-list.doc
-rw-r--r--   1 pwg      pwg        19414 May 22 06:23 iss-list.pdf
-rw-r--r--   1 pwg      pwg        12629 May 22 06:24 iss-list.txt

We had a good meeting today resolving the job-state and job-state-reasons
differences with IPP, but not too many JMP people were present. So I'll
send out those changes separately to see if there is any problems with them.

I've also attached the iss-list.txt.  NOTE: the .txt file does not have
revision marks, that the .doc and .pdf file have.  For the .txt file,
the revisions have been accepted.

Tom

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.

---

From: JK Martin <[email-masked]>
Date: Thu, 22 May 1997 12:07:26 -0400 (EDT)

Tom,

>   jobOwner  (63 octet string)

Is this the _only_ mandatory attribute?  I thought there were a
couple more (although I don't remember which ones).  Or are you saying
here that jobOwner is now added to the mandatory list?

More on the issue of "jobOwner as an attribute vs. an object" later
in this message...

> and the job-state-reasons attributes are mandatory.

You know, not mandating a "reason" string with the job state doesn't
feel good, given that the state may not really say what's going on
with the job.  This topic was touched on during yesterday's IPP telecon
in which we talked about job attributes wrt IPP vs. JMP definitions.

We might want to mandate jobStateReasons1, and not let it fall into
the "conditionally mandatory" void, since it supports the #1 target
requirement for "tell me what my job is doing".

Comments on this?

> 'canceled' is a final state, as is the 'completed' state.

Tom, as you know, I had to leave the IPP telecon early yesterday.
I don't recall the discussion about a job going into a "retained" state,
then transitioning to "completed" for IPP.  Was this discussed and
decided after I left the telecon?  If so, can you describe what this
is all about?  (That is, I don't understand the value of having a short-
term "retained" state.)

> We decided to put this issue on the IPP agenda for this coming Wednesday,

This is good.  We really, really must strive to align IPP and JMP to the
maximum possible extent.

> Attribute table, rather than being moved to the Job table.

Hmmm...  Is this really what we agreed to?  I submitted that jobOwner
should be a fundamental part of job identification (and gave lots of
examples of existing systems where this value is the only meaningful
identification item across multiple types of spooling systems).

By making jobOwner an "attribute", there is a serious risk of losing
this information when the agent "ages out" attribute information.
(The reader should recall that "attributes" are designed primarily
for accounting purposes, and these values are able to be removed from
the agent's store in a faster manner than the jobState values.)

I worry that an agent will age-out the jobOwner too soon, thereby
making it impossible to identify jobs for a target user.

Can we please discuss this issue on the list asap?

> add jobCanceledDateAndTime/TimeStamp?

We didn't get to this issue, right?  In any case, why would we need a
date/timestamp for Cancel?  I suggest that we just leave the Completed
time intact for both situations.

> ACTION ITEM (all):  Write up your job submission protocol mapping to the Job

Do we have specific personnel assignments for these mapping documents?

	...jay