Subject: JMP> Issues List posted for I-D (and .71) version

From: Tom Hastings <[email-masked]>
Date: Mon, 31 Mar 1997 01:29:12 PST

I've posted the issues that need to be resolved in our Internet
Draft 00 (revision 0.71).  The file contains the closed issues
as well.

ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-rw-r--   1 pwg      pwg        29184 Mar 31 09:19 issues.doc
-rw-rw-r--   1 pwg      pwg        34494 Mar 31 09:07 issues.pdf
-rw-r--r--   1 pwg      pwg        35417 Mar 31 09:08 issues.pdr

The .pdr is with red revision marks, and the .pdf is with black
revision marks.

The agenda for the upcoming meeting in Austin, 4/4, should be
dealing with these issues.  I see issues 61, 62, and 64 as
being the most significant.

What we will do with the resolutions to these issues for the
meeting the following week at the IETF in Memphis, 4/8, we need to
discuss.

I've moved contributions that have been covered to the historical
sub-directory (but with current dates, unfortunately).

Here is a copy of the open issues.  See the complete file
for the open and close issues with revision marks.

Subj:	Issues from Job Monitoring MIB, version 0.71, dated 3/26/97
From:	Tom Hastings
Date:	3/28/97
File:	issues.doc

This file will be our standing list of open and closed issues for the Job
Monitoring MIB.  The open issues are in the first section,
the closed issues that have not been reflected in the current draft are in
the second section and the closed issues are in the third section (third
section not attached).  When an issue is closed, I indicate the resolution
and why and move the issue to the closed section.

Revision marks show changes from the 2/28/97 version of the issues list.
When I move an issue from Open to Closed, I only show the revision marks of
what changed, not the movement itself.

This version of the issues list includes issues that are in the Internet
Draft 00 (same as revision 0.71) that need to be resolved.
I've updated the issues with the agreements reached at the JMP meeting,
2/7/97 and the reasons behind the resolutions. 
 
If you object to any of the proposed resolutions to the issues, please send
e-mail.

1. Open Issues

Issue 32 - Shouldn't we require any numeric portion of the client-side
identifiers to always be in the jmJobIdNumber object?
ACTION ITEM (Tom Hastings): Send e-mail on this proposal.

Issue 45 - After fully agreeing on what a Job Set is, should the name remain
Job Set, or be changed to Queue, or Job Pool or Job Group to improve
understandability?  The new jmGeneralJobSetName would also be changed to
jmGeneralQueueName, or jmGeneralJobPoolName, or jmGeneralJobGroupName.  See
the Internet Draft 00 and version 0.71.

Issue 48 - Since jmJobIndex cannot be 0 according to SNMP rules for indexes,
what shall an agent do that is instrumenting a printer or server that uses 0
as a valid job-identifier?  Use largest positive integer for job 0?  Or the
agent map the 0 value to the value that is one higher than the maximum that
the server or printer uses?

Issue 49 - Should we change the definition of the jmGeneralMaxNumberOfJobs
to jmGeneralMaxJobIndex meaning the maximum value that the jmJobIndex object
can have and the roll over to 1 happens for the next job received?  Or add
jmGeneralMaxJobIndex as another object in the General table?  Then the
monitoring application would know what the roll over limit would be.  For
agents that instrument servers or printers that use a job identifier of 0,
the actual maximum number would be one more than the actual job identifier
that the server or printer generates.  So for LPD, the value of
jmGeneralMaxJobIndex would by 1000, not 999.  
The current definition of jmGeneralMaxNumberOfJobs is:
jmGeneralMaxNumberOfJobs OBJECT-TYPE
SYNTAX      Integer32(0..2147483647)
MAX-ACCESS  read-only
STATUS      current
DESCRIPTION
"The maximum number of queued and completed jobs that this server or print
can support at the same time.  

The value (-1) indicating other shall indicate that there is no fixed limit."
::= { jmGeneralEntry 4 }
What is the purpose of jmGeneralMaxNumberOfJobs as currently defined?

ISSUE 51 - Should the jmJobCurrentState (and JmJobStateTC) be changed from a
type 2 enum to a type 1 enum, since adding states would have serious impact
on released clients?  Currently the IPP draft has the job-state and
printer-state attributes defined as type 1 enums (actually they've changed
the terminology, but not the concept, to keyword).

ISSUE 52- Should JmJobStateReasonsTC and JmJobServiceTypesTC be defined
using the RFC 1902 BITS built-in?  JmJobStateReasonsTC is 540 bits, while
JmJobServiceTypesTC is only 31 bits.

ISSUE 53 - Should there be an object that specifies the current default
coded character set of the Job Monitoring MIB, so that the client can figure
out how to interpret objects of type OCTET STRING that are coded characters,
in case the client might not be configured the same as the server or
printer?  See Section 6 in the Internet Draft 00 and revision 0.71 for the
discussion of coded character sets, including the use of Unicode/ISO 10646.

ISSUE 54 - Should we move all of the objects in the jmJobTable (9 objects)
into the jmAttributeTable as enums and then specify some of them to be
required for implementation?  What about the jmQueueTable (6 objects)?  What
about the jmCompletedTable (3 objects)?  This would reduce the number of
required objects from 21 mandatory objects and 6 conditionally mandatory
objects to just 9 mandatory objects and no conditionally mandatory objects.

ISSUE 55 - Should we remove the needsAttention state to align with IPP (and
DPA)?  The printer-stopped job-state-reasons value from IPP has already been
added to the JmJobStateReasonsTC, so that the user will be able to find out
that the job that is processing has a printer stopped.

ISSUE 56 - Which of the jmJobTable entries that were moved to the
jmAttributeTable should be mandatory enums, if any?  They were all mandatory
when they were in the jmJobTable.
1. physicalDeviceName (or physicalDeviceIndex)
2. jobSourceChannelIndex
3. jobSubmissionDateAndTime or jobSubmissionTimeStamp
4. jobComment
5. jobKOctetsTotal
6. jobKOctetsCompleted
7. jobStartedProcessingDateAndTime or jobStartedProcessingTimeStamp
8. jobCompletedDateAndTime or jobCompletedTimeStamp
9. jobAccountName
Or should we move any mandatory attributes, such as sheetsCompleted back to
the jmJobTable, so that the attributes table contains no mandatory
attributes, only conditionally mandatory attributes and the jmJobTable is
the place that we put the mandatory information?

ISSUE 57 - OK to change jmAttributeTypeIndex from not-accessible to
read-only, so that it can be mentioned in the conformance clause where we
specify that sheetsCompleted is the only attribute that is mandatory (so
far).  Currently the Internet Draft and version 0.71 get a compile error
when attempting to mention an enum that is mandatory for an object that is
not listed in the conformance clause.  Objects that are not-accessible
cannot be mentioned in the conformance clauses, but read-only can, since
they (jmAttributeTypeIndex) would also get added to the list of objects in
the group.

Issue 58 - OK that sides, documentFormat, and physicalDeviceIndex/Name,
remain as the only attributes that are both requested and used at the same
time (with the same instance in the jmAttributeTable) as suggested in Ron's
EMail of 2/15, or should we make four new attributes that are used/consumed
and change the current ones to be requested?

Issue 59 - Add the name of the source server or client?  As an object or an
attribute?  See Bob Pentecost EMail of 2/25.  Need more specific text for
such proposals.

Issue 60 - Add the "file name of the job" and a "source port object to tell
which client port the job came from"?  As objects or attributes?  See Bob
Pentecost EMail of 2/25.  Need more specific text for such proposals.

Issue 61 - Need to clarify the semantics of each object and attribute with
respect to Configuration 1, 2, and 3.  See Bob Pentecost EMail of 3/10 (HP
internal review).  Most objects refer to the jobs as they exist in the
server or printer that the agent embedded in, i.e., is instrumenting.  A few
objects, represent information that comes from upstream places in the case
of configuration 1 from the client, in the case of configuration 2, the
client as well, and in the case of configuration 3, the server and maybe
even the client as well.

Issue 62 - Harry Lewis has a proposal for a mapping table that allows a
monitoring application that knows a client identifier to directly address
the mapping table with a single get in order to find the jmJobIndex that the
printer is using.  See 3/5/97 and 3/28/97 EMail and
ftp.pwg.org/pub/pwg/jmp/contributions/pwgjm.pdf.  Harry will make a
presentation at the JMP meeting.

Issue 63 - Should we add attributes for inkjet plotters?  See EMail from
Patrick Powell, of 3/4/97

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.

Issue 65 - What Appendices should remain, which should be separate Internet
Drafts and/or informational RFCs and which should disappear?

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 26 - Which indexes shall be persistent across power off and which need
not be?
Closed:  The persistent indexes shall be:  jmJobIndex and jmJobSetIndex