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

From: Tom Hastings <[email-masked]>
Date: Mon, 19 May 1997 15:33:03 PDT

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:

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:

     fullColorImpressionsCompleted(??),        -- 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.

     highlightColorImpressionsCompleted(??),        -- 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.

>Return-Path: <[email-masked]>
>Date: Thu, 15 May 1997 07:39:22 PDT
>From: "Caruso,Angelo" <[email-masked]>
>Subject: RE: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable
>To: [email-masked]
>Posting-Date: Thu, 15 May 1997 10:49:50 -0400
>Priority: normal
>Hop-Count: 3
>Sender: [email-masked]
>
>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: Ron Bergman <[email-masked]>
Date: Thu, 22 May 1997 06:57:44 -0700 (PDT)

Tom,

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

	Ron Bergman