Subject: RE: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable

From: "Caruso,Angelo" <[email-masked]>
Date: Thu, 15 May 1997 05:40:52 PDT

Tom,

Oops! I think you meant:

ftp://ftp.pwg.org/pub/pwg/jmp/contributions/sepstate.doc
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/sepstate.pdf

NOT:

ftp://ftp.pwg.org/pub/pwg/jmp/contributions/attr-tab.doc
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/attr-tab.pdf

I agree with all of your conclusions and was just about to type up a 
 long mailnote with a similar argument. Thanks for saving me the work. 
 I do have some additional comments, also. I will send these in a 
 seperate note.

Ang

----------
From: [email-masked]
To: [email-masked]
Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Issu
Date: Thursday, May 15, 1997 12:00AM

I've posted an 8-page analysis of the utlization of the jmJobStateTable
and the jmAttributeTable in:

ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r--   1 pwg      pwg        34304 May  9 09:35 attr-tab.doc
-rw-r--r--   1 pwg      pwg        48490 May  9 09:36 attr-tab.pdf

in order to attempt to resolve the biggest issues remaining in the
Job Monitorng MIB regarding the redundance between the jmJobStateTable and
the jmAttributeTable and whether we could get rid of the jmJobStateTable and
use just the jmAttributeTable or not.  

Harry, Ron, and I discussed the issue over lunch today. Then I wrote this
paper to capture the discussion, but they have not had a chance to review
the paper.  If there are mistakes in the paper, they
are mine.  Please review the paper to see if my understanding of SNMP
Get and Get Next is correct when used with tables.

Please send comments on this paper today, Thursday, 5/15, so that we
may consider them during our JMP meeting, tommorrow, Friday, 5/16.

One way to send comments is to use MS-WORD, turn on revision marks,
and may comments directly in the .doc file.  If the comments are 
sparse, an e-mail will do.  The .pdf file has line numbers, so that you
can refer to specific lines in an e-mail mesage, perhaps even cutting
and pasting the relevant paragraph.

The conclusions in the paper are:

The jmJobStateTable is very useful because its lowest order index is
jmJobIndex, so that any number of selected objects can be obtained using
multiple Get Next operations in a single PDU for the *next* job, skipping
over jobs that have been removed from the table.  A subsequent PDU can
contain multiple Get operations for any attributes desired using the
returned jmJobIndex value. 

If the mandatory attributes are all put into the jmJobStateTable as objects,
and not in the jmAttributeTable as attributes, it is clear by SNMP rules
that all of the mandatory objects shall be instantiated at the same time
when the new job row is put into the jmJobStateTable.  Also the persistence
time is clearly separated by which table the information is contained.

The jmAttributeTable only contains conditionally mandatory attributes, no
mandatory attributes, so that the jmAttributeTable itself can be
conditionally mandatory, thereby allowing a very small implementation to
only implement the jmJobStateTable and not the jmAttributeTable.

---

From: "Caruso,Angelo" <[email-masked]>
Date: Thu, 15 May 1997 07:39:22 PDT

Ron, Harry, and Tom,

As I mentioned in my previous posting I agree with the conclusions in 
 the 'sepstate.doc' paper. Namely, the mandatory attributes should 
 become distinct objects in the jmJobStateTable, making it the "basic" 
 table for low-end implementations, and the jmAttributeTable then 
 becomes conditionally mandatory. Having implemented a table similar to 
 the jmAttributeTable in a Xerox proprietary MIB (Xerox people read: 
 XCMI Comms Options table), I know that these are tricky things to get 
 right, particularly for low-end implementations.

Along this line of thinking, I believe the second comformance 
 requirement in the internet draft (page 15) of the job MIB is too 
 strong. It states:

"A conforming agent: 
...2.shall implement each  conditionally mandatory attributes, if the
  server or device that the agent is instrumenting has the feature
  represented by the conditionally mandatory attribute.."

This says to me, for example, that if a printer implements the Printer 
 MIB, then the jobSourceChannelIndex attribute is mandatory since it 
 indexes a mandatory table in the Printer MIB. Therefore, for any 
 implementation that implements the Printer MIB, the jmAttributeTable 
 is automatically mandatory. If you're not satisfied with this example 
 I can come up with lots more. I suggest that the comformance 
 requirement above be ammended to read as:

"A conforming agent: 
...2.shall implement each  conditionally mandatory attribute, if the
  server or device that the agent is instrumenting has the feature
  represented by the conditionally mandatory attribute and the
  device provides similar instrumentation of this attribute using
  some other interface or protocol."

Then, if the device made the information about a job's source channel 
 available through some other interface like DPA or IPP, then and only 
 then would the jobSourceChannelIndex attribute become mandatory. This 
 would allow the jmAttributeTable to actually not be mandatory for low 
 end implementations.

Having not followed the JMP discussions closely over the last several 
 months I don't understand why it was decided that outputBinIndex 
 (previously ouputBinName) is mandatory? Speaking as an end user of 
 several networked printers, when I walk over to pick up my job I 
 typically find it sitting on top of the stack of jobs in the single 
 output tray of the printer. If not there, then it is usually in a 
 stack of jobs that someone was too lazy to sort, or, less frequently, 
 someone has been kind enough to file it in some alphabetically 
 organized filing contraption. So why does this value need to be 
 mandatory? The only case I can think of where it is really useful is 
 for devices with a mailbox type output device, but those are the 
 exception rather than the rule. I certainly think that attributes like 
 jobName and jobOwner are much more deserving of mandatory status since 
 they appear in most current job/queue monitoring applications (e.g. 
 PCONSOLE, Win95 print manager, etc). But since they are conditionally 
 mandatory, outputBinIndex should be also.

Lastly, I would like to request two new attribute be added for 
 accounting purposes with color capable devices. Color devices 
 typically cannot measure the exact amount of colorant consumed per 
 job, but can easily measure the number of color impressions. This is 
 important for accurate accounting since color impressions cost more 
 than black impressions with most current marking technologies. I have 
 included the ASN.1 here for your convenience:

     fullColorImpressions(??),        -- Integer32(-2..2147483647)
         -- INTEGER:  The total number of full color impressions 
         -- completed by the device for this job so far.  For printing, the
         -- impressions completed includes interpreting, marking, and
         -- stacking the output.  For other types of job services,
         -- the number of impressions completed includes the number
         -- of impressions processed. Full color impressions are
         -- typically defined as those requiring 3 or more colorants,
         -- but this may vary by implementation.

     highlightColorImpressions(??),        -- Integer32(-2..2147483647)
         -- INTEGER:  The total number of highlight color impressions 
         -- completed by the device for this job so far.  For printing, the
         -- impressions completed includes interpreting, marking, and
         -- stacking the output.  For other types of job services,
         -- the number of impressions completed includes the number
         -- of impressions processed. Highlight color impressions are
         -- typically defined as those requiring black plus one other
         -- colorant, but this may vary by implementation.

Thanks,
Angelo

---

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

I agree with Ron that Tom's two proposed attributes should be
included in the Job MIB.

Any serious objections from anyone?  If so, please speak up, as
we are really getting down to the wire on this draft.

	...jay

----- Begin Included Message -----

>From [email-masked] Thu May 22 11:04 EDT 1997
Date: Thu, 22 May 1997 06:57:44 -0700 (PDT)
From: Ron Bergman <[email-masked]>
To: Tom Hastings <[email-masked]>
cc: [email-masked]
Subject: RE: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable
X-X-Sender: [email-masked]

Tom,

I have no objection to the addition of the two attributes.

	Ron Bergman

On Mon, 19 May 1997, Tom Hastings wrote:

> In going over my notes, I see that we didn't process the last part of paper
> number 9 at the 5/16 JMP meeting.
> 
> Does any one have a problem if I add the following two attributes
> to the Attribute table [with the suffix "Completed" added] as:
> 
> From Paper number 9:
> 
>      fullColorImpressionsCompleted(??),        -- Integer32(-2..2147483647)
>      highlightColorImpressionsCompleted(??),        -- Integer32(-2..2147483647)

----- End Included Message -----