Somehow, I've received Jay's reply prior to Tom's summary... but I will try to
address some of the questions raised by Jay.
>> 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.
>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?
Yes, "Tell me what my job is doing", but please, just tell me what
I want to know in a simple form that I can understand! Not 93
possible reasons for 7 possible states in 4 seemingly arbitrary
categories! PENDING, PRINTING, CANCELED, COMPLETE. Obscure PRINTING
by calling it PROCESSING and throw in HELD and NEEDS ATTENTION (with
alert code) for good measure - isn't this enough? Jay, have you looked
at the 7.5 page list of Job State Reasons in the Job MIB? I'm behind
on mail so maybe this has all been changed but... given the current state,
of the specification, I prefer to keep the reasons OPTIONAL!
>> Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or
>> queueNameRequested be made Mandatory?
>> Closed: Only jobOwner is made mandatory, but it will remain in the
>> 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?
Yes, we realized after Dave and Jay had left the meeting, that the size
of jmJobOwner blows away the notion of keeping the Job Table terse.
In the minutes, which I posted this morning, I took the liberty to
address this a bit. One, rather simple approach, if Job Owner really
is a "meaningful id across multiple types of spooling systems", is to
truncate it to 30 bytes and register it as one of the jmJobSubmissionID
formats. I'm not sure how the format ID would get tacked on, however,
but this can probably be worked out (have the NIC build it from the LPR
control file?).
An excerpt from my minutes asks:
If the design point is to facilitate a job state notification broker that lives
outside of the submission
framework and correlates users (notification recipients) with print jobs
strictly based on identification
provided via LPR, we need to have this stated.
Is this what we are worried about? There seem to be only two other
major scenarios. If the job Monitor is involved with submission (as in an
NT Port Driver for example), there is a place to couple submission and
monitoring via jmJobSubmissionID. If the monitor is fundamentally an
accounting application, then leaving jmJobOwner in the Attribute table
should not be a problem.
I guess we do loose the ability to guarantee showing the owners name in
a simple overall queue view but this problem can be minimized by "fetching"
the jmJobOwner from the Attribute table for Pending jobs and storing this
association in the job Monitor application until the application is no
longer concerned with the job. This assumes the owner's name is static,
which will be the practical case.
I think, if this is still an issue, we need to get more examples on the
table. I had proposed some additional alleviates in my complete set of
minutes.
Harry Lewis - IBM Printing Systems