Tom,
Thanks for posting the summary. A couple of quick comments:
> The mandatory attributes are:
>> 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...
> 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?
> 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.
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.)
> 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.
This is good. We really, really must strive to align IPP and JMP to the
maximum possible extent.
> 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.
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?
> Issue 77 - Should jobCompletedDateAndTime/TimeStamp be canceled time too, or
> 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.
> 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.
Do we have specific personnel assignments for these mapping documents?
...jay