Subject: JMP> HELD vs NEEDS-ATTENTION

From: Harry Lewis <[email-masked]>
Date: Thu, 22 May 1997 19:42:38 -0400

Some of the job state reasons for HELD seem like they would fit better as
reasons for NEEDS-ATTENTION. For example:

  requiredResourcesNotReady           0x20
         The job is in the held state because at least one of the
         resources needed by the job, such as media, fonts, resource
         objects, etc., is not ready on any of the physical devices
         for which the job is a candidate.

     serviceOffLine                      0x400000
         The service/document transform is off-line and accepting no
         jobs.  All pending jobs are put into the held state.  This
         could be true if its input is impaired or broken.

These reasons seem categorically different than "Someone put this
job on Hold 'till midnight".

I guess it is fairly clear that state NeedsAttention should pertain to
actual DEVICE failures, but 0x400000, above, sounds like it could
be just that to me.

Harry Lewis - IBM Printing Systems

---

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

You raise a good point, Harry.  I think we really want the user
to be able to distinguish between jobs not printing due to problems
vs. administrative "hold" (no matter who put the job on hold).

One definition we'll have to nail down is NEEDS-ATTENTION.  Does
that term imply device-only problems, or any kind of problem that
keeps the job from printing (other than HELD)?

Given your statements, I'd vote for having NEEDS-ATTENTION imply
_any_ kind of problem, and not just device-related problems.

Similarly, I'd suggest that HELD implies an administratively-set
condition only.

Quick comments/votes by the others?  (Tick, tick, tick...)

	...jay

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

>From [email-masked] Thu May 22 19:41 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Subject: JMP> HELD vs NEEDS-ATTENTION
Date: Thu, 22 May 1997 19:42:38 -0400

     serviceOffLine                      0x400000

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

---

From: [email-masked] (Robert Herriot)
Date: Thu, 22 May 1997 18:53:40 -0700

You might want to look at the changes that we made in the IPP job-state
at yesterday's meeting.  The current jobs states are:

                         ---> canceled
  pending -> processing -|--> aborted
                         ---> completed

Normally a job progresses only from left to right through three states.

held and retention became job-state-reasons.  The job MIB concept of
needs-attention is in IPP a job-state-reason: printer-stopped which a
job can have as a value of job-state-reasons when its job-state is
pending or processing.

We hoped that the Job MIB group would consider these changes in the
jobMIB as well.

Bob Herriot

> From [email-masked] Thu May 22 17:56:58 1997
>

---

From: Ron Bergman <[email-masked]>
Date: Fri, 23 May 1997 08:06:32 -0700 (PDT)

I agree with all the changes proposed for alignment of the IPP and
JMP job states except for the removal of "Needs Attention".  This
should be the most important state to indicate to a user since 
unless he takes action the job may never complete.  I would think
that this would also be very important for IPP as well.

I also agree with Harry that "requiredResourcesNotReady" and
"serviceOffLine" apply better to "Needs Attention" than "Held".
(I also agree with Harry that "Printing" is a better description
for a user than "Processing".  Since this is an enum, a user or
management ap can display whatever text that is deemed 
appropriate.  So I will vote to keep "Processing" unless there
is very strong support for "Printing".)

(Didn't we discuss "serviceOffLine" in a previous meeting and
determined that no one except Dataproducts has ever implemented
such a capability?  I also indicated that I had recently deleted
the feature because I felt it was "stupid".)

Also, I agree with Jay that "Needs Attention" should apply to all
conditions, other than "Held", that prevents the job from printing.
"Held" only implies an administratively set condition.

Tom, since I could not participate in the Wednesday conference call,
could you explain why "Needs Attention" was not accepted by IPP?
It is very critical that JMP and IPP agree in this area and I would 
hope this can be resolved quickly.

	Ron Bergman
	Dataproducts Corp

---

From: [email-masked]
Date: 23 May 97 16:04:03 EDT

I agree that "Needs Attention" is an important state which should not be 
removed from jmJobState, but I think it is very important to have alignment 
with IPP.  So we just have to get IPP to come around to our way of thinking 
:-)

Ron, you didn't mention that the IPP job states do not include held 
(pending, processing, cancelled, aborted, and completed).  I believe there 
is also an important distinction between held and pending and that there 
should be both held and pending states.

I think the jmJobStates of Held, Pending, Processing, Needs Attention, 
Cancelled, and Completed are the best at providing the necessary 
information WITH A SINGLE OBJECT.  As Harry has said, most printer agents 
can tell the whole story (as they know it) with just these job states.  The 
JobStateReasons are things the printer agent typically doesn't know about.

Perhaps IPP is hung up on the semantics such as that a hold is really a 
reason it is pending.  I can perhaps see the theoretical justification for 
having held as a reason for the state pending.  But, I believe users, as 
opposed to us grizzled standards developers, would immediately see the 
utility of having held as a separate state from pending, with pending 
applying only to jobs that are waiting and have not been put on 
administrative hold.  The user may then choose to see the reason why it is 
held or pending.  This same arguement applies to the Needs Attention state 
as opposed to making Needs Attention a reason under the one of the other 
states.  It is just more useful to have Held and Needs Attention as job 
states rather than reasons!

Stuart Rowley
Kyocera Electronics, Inc.

______________________________ Reply Separator _________________________________

     

     

	Ron Bergman
	Dataproducts Corp

---

From: JK Martin <[email-masked]>
Date: Fri, 23 May 1997 16:57:09 -0400 (EDT)

I agree wholeheartedly with Stuarts comments regarding the importance
of distinguishing between HELD and PENDING.  Nice job, Stuart.

	...jay

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

>From [email-masked] Fri May 23 16:08 EDT 1997
From: [email-masked]
Date: 23 May 97 16:04:03 EDT
To: <[email-masked]>
Subject: Re[2]: JMP> HELD vs NEEDS-ATTENTION

Stuart Rowley

     

     

	Ron Bergman
	Dataproducts Corp

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

---

From: [email-masked] (Bill Wagner)
Date: Fri, 23 May 1997 18:38:17 -0400

Stuart,
     
     Of course you are right. It is the difference between a logical  
     consideration and a popular perception. I  agree that "needs 
     attention" is not a state, it is a condition that may associate with 
     any printing job state. But the distinction might not be obvious to a 
     casual user. On another semantic difference of opinion, I think that 
     processing is probably more applicable popularly than printing, 
     because the common user might get concerned is his status is printing 
     when the printer is grinding away on a recursive fish file. 
     
     But it seems that this probably should be of more concern to the IPP, 
     when it appears that the actual phases might be seen by the user, than 
     with the Job Monitoring MIB, where a specific user interface will be 
     present to put the information in appropriate terms.  
     
     Also, I suggest that, particularly if the Printer MIB is not 
     supported, some interesting information may be lost by not indicating 
     the printing state at which the job needs attention.
     
     Regardless, I suggest that if the intent is to convince IPP to go with 
     the popular terms, it must be on the basis that these will better 
     serve the user, even if they are logically incorrect. (Who ever said 
     users had to be logical?)
     
     Bill Wagner, Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re[2]: JMP> HELD vs NEEDS-ATTENTION
Author:  [email-masked] at Internet
Date:    5/23/97 4:04 PM

Stuart Rowley

     

     

        Ron Bergman
        Dataproducts Corp

---

From: JK Martin <[email-masked]>
Date: Tue, 27 May 1997 13:17:36 -0400 (EDT)

Ron,

> > The IPP and JMP defintions of requiredResourcesNotReady, say "is not
> > ready on any of the physical devices for which the job is a candidate"
> > meaning before the job starts processing.  Perhaps this reason should
> > have a better name, like "requestedResourcesNotReady".
> > 
> RB> I don't see any difference in "required" vs "requested".

Yeah, I agree with you, unless someone can make a clear case for a
difference in semantics between "requested" and "required" in this context.

> > IPP says that when the reason 'printer-stopped' is present, the client
> > should check the printer-state and printer-state-reasons.  For JMP the
> > analoguous thing is to check the job's deviceAlert attributes and the
> > associated device MIB.
> > 
> > But the IPP/JMP meeting also got rid of the held state.
> > 
> RB> Have we eliminated too much?

I'm wondering the same thing.  (But have no opinion either way right now.)
It just seems like we might be missing something here by eliminating HELD.

> RB> Again, I would support keeping both the needsAttention and held
> RB> states. These could easily be mapped to IPP.  Comments?

I tend to agree.  However, exactly what is abstracted as a "state"
versus a "reason" depends on exactly what problems we're trying to
solve (and which paradigm to use to solve those problems), would you
agree?

We need to hash this out pretty quickly!

	...jay

---

From: Tom Hastings <[email-masked]>
Date: Tue, 27 May 1997 14:13:00 PDT

Harry,

Here is some discussion on this topic that we had in IPP (and that 
appears in the jobstate.* files I posted today):

Conformance Requirements for job states
---------------------------------------
JMP requires that processing(4), aborted(6), and completed(7) are mandatory, 
so that pending(3), canceled(5), and unknown(2) are conditionally mandatory.
(IPP level 1 does not have CancelJob, so we have to make the canceled state
conditionally mandatory in JMP in order to instrument a level 1 IPP system.)

The former JMP needsAttention state was also mandatory, so that the 
equivalent new job-state-reason: deviceStopped, is a mandatory value of
the JMP jmJobStateReasons1 object.  The deviceStopped value aligns with the 
IPP 'printer-stopped' value of the "job-state-reasons" attribute, but we
are trying to be more general in JMP, so we use the word 'device', not 
'printer'.  

If deviceStopped is a MANDATORY reason, then the jobStateReasons1 attribute
becomes MANDATORY.  Therefore, the jobStateReasons1 JMP attribute moves to 
the jmJobTable, since it is an Integer, not Octets, and will be called 
the jmJobStateReasons1 object.  The other 3 jobStateReasonsN (N=2, 3, and 4) 
will remain in the jmJobAttributeTable as conditionally mandatory attributes.

There were two major reasons that IPP replaced the 'needs-attention' state
with the 'printer-stopped' job-state-reason:

1. IPP felt it was as important for a user to know that the printer that their
job was waiting for was stopped, as it was for the user whose job was the 
current job.  Therefore, whether the job was in the 'pending'
or 'processing' state we wanted to indicate that the printer had stopped for 
the job.  Therefore, need-attention is really a reason, not a state.  

If needs-attention were a job state, when the printer resumes, the job would 
go back to either 'pending' or 'processing', depending on which state the job 
had been in previously.  
Remembering which previous state was a problem.  Also the user should know
whether his job was the current one or some other users was the current job,
since in an unattended shop, the onus might be on the current user to fix the 
problem.  By keeping the job in the same state ('pending' or 'processing'),
instead of moving the job to a different 'needs-attention' state
and setting the job-state-reason, there was no need to remember the 
previous state.  

2.  The job state reason was renamed from 'needs-attention' to 
'printer-stopped', because the printer might need attention but the current 
job could still make progress because the printer hasn't stopped.  For 
example, toner low or media low or an input tray is empty, but the current 
job is not using that tray.  Also the operator might have intentionally
stopped the printer, so needs-attention would be misleading.

To help distinguish between your interpretation of requiredResourcesNotReady,
IPP changed the reason to jobHeldUntilResourcesAreReady with the following
description:

Optional.  At least one of the resources needed by the job, such as media,
fonts, resource objects, etc., is not ready on any of the physical printer's
for which the job is a candidate.  Usually such a condition is detected
while the job is in the 'pending' state.  

If a job starts processing and encounters a resource that is not ready,
there are two possible implementations:

(1) the device is stopped and no jobs can run until the resource(s) are made
ready, in which case the Printer shall keep the job in the 'processing'
state and shall add the 'printer-stopped' reason to the job's
"job-state-reasons" attribute (not the 'job-hold-until-resources-are-ready'
value) 

OR

(2) another job is found to use the device while the current job goes back
to waiting for its turn and for the resources to be made ready, in which
case the Printer shall change the job's "job-state" attribute to 'pending'
and add the 'job-hold-until-resources-are-ready' value to the job's
"job-state-reasons" attribute.Applicable job states: 'pending'.

Here is the corresponding description that I put into the Job Monitoring MIB
for the jobHeldUntilResourcesAreReady:

At least one of the resources needed by the job, such as media, fonts,
resource objects, etc., is not ready on any of the physical devices for
which the job is a candidate.Usually such a condition is detected while the
job is in the pending state.  

If a job starts processing and encounters a resource that is not ready,
there are two possible implementations:

(1) the device is stopped and no jobs can run until the resource(s) are made
ready, in which case the agent shall keep the job in the processing state
and shall add the deviceStopped reason to the job's jmJobStateReasons1 object 

OR

(2) another job is found to use the device while the current job goes back
to waiting for its turn and for the resources to be made ready, in which
case the Printer shall change the job's jmJobState object to pending and add
the jobHoldUntilResourcesAreReady value to the job's jmJobStateReasons1
object.  Job states: pending, jobHeld shall be set.

Does this help?

Tom

>actual DEVICE failures, but 0x400000, above, sounds like it could

serviceOffLine is a particular type of device failure: the device is no
longer contactable either because it is broken or because the operator
has decided that it is down.  Perhaps it has to be painted.  The "could
be true, is an example of why the device might be off-line, not the only
reason.

---

From: Tom Hastings <[email-masked]>
Date: Tue, 27 May 1997 14:18:18 PDT

>Return-Path: <[email-masked]>
>Date: Thu, 22 May 1997 17:54:27 PDT
>From: JK Martin <[email-masked]>
>To: [email-masked]
>Subject: Re: JMP> HELD vs NEEDS-ATTENTION
>Cc: [email-masked]
>X-Sun-Charset: US-ASCII
>Sender: [email-masked]
>

This confusion as to what "NEEDS-ATTENTION" might mean is why IPP
change the name from needs-attention to printer-stopped and changed
it from a job state to a job-state-reason, since the printer can stop
whether you are the current job or just one of the hapless waiting
in the pending state.

>Similarly, I'd suggest that HELD implies an administratively-set

In the updated IPP and JMP, we don't have a held state, but several of
the job-state-reasons indicate that the job can't be run and usually
because the user or the administrator took some action or specified some
resource that isn't ready.

Ok?

Tom

---

From: Tom Hastings <[email-masked]>
Date: Tue, 27 May 1997 14:49:08 PDT

>with IPP.  So we just have to get IPP to come around to our way of thinking 

So we needed you on the agreed to joint IPP/JMP call last Wendesday.

>should be both held and pending states.

Again,  JMP can have additional states, not in IPP, if we want to.

So JMP could have the held state and the needs-attention state, if we
want to with a clear mapping for an agent to use that is instrumenting
an IPP system.  However, I had the sense from JMP that we wanted to 
align more directly with IPP and only have additional reasons, not
additional states, so that is what I have written up for JMP.

>can tell the whole story (as they know it) with just these job states.  

But what about the pending job that is waiting for a printer that 
has stopped printing the current job?  The problem with needs-attention
as a state, in stead of a reason, is that it only can be for the
current job, not the pending jobs  (Unless all the pending jobs jump
into the needs-attention state too, which I hadn't thought anyone wanted,
since that would lose the information as to which job or jobs were
actually currently printing).

>                                                                       The 

Isn't the job of the agent to map what ever state information it can get
from the device to the MIB?  So if the agent has to map the information
to a reason or to a state, its the same amount of work.

>states rather than reasons!

The MIB isn't the UI for the user (though many applications just map the 
MIB to a UI.)  So an application could show any reason as a state, if it 
wanted to.

---

From: "Caruso,Angelo" <[email-masked]>
Date: Tue, 27 May 1997 15:05:04 PDT

There seem to be two extremes on this whole issue. On the one side 
 there are those who would like all their favorite states included in 
 one easy to use job state object. On the other side are those who want 
 to keep the job state object ultra simple and have lots of job state 
 reasons. Both points of view have been backed up by many good 
 arguments. Last week at the IPP teleconference it seemed that a 
 reasonable COMPROMISE was reached. Unfortunately, several key JMP 
 folks were not present for that discussion and now we're waffling on 
 the whole issue again. Based on todays mail volume there does not 
 appear to be any end in sight.

For the record, here is my position.

IPP and JMP should use EXACTLY the same set of job states and the same 
 state reasons (the agreement reached at the last IPP/JMP 
 teleconference seemed reasonable to me). How are we to expect the PWG 
 to be taken seriously if we simultaneously create two specifications 
 with different job models? The rest of the world expects and deserves 
 a consistent set of standards from this working group! Please don't 
 respond again how easy it is to map between the two different state 
 models. I understand the mapping because I have been following the 
 discussions. But the rest of the world will not find the mapping to be 
 so obvious. If we learned anything from the Printer MIB interop 
 testing it is that interpreting ONE model correctly is hard enough. 
 Now, we are on the verge of generating two different models to 
 represent the same thing. It's time to find a compromise.

Thanks,
Angelo

---

From: Tom Hastings <[email-masked]>
Date: Wed, 28 May 1997 02:06:14 PDT

>with IPP.  So we just have to get IPP to come around to our way of thinking 

I just noticed that a lot of this JMP comments to convince IPP of ...
is only being sent to JMP, not to the IPP list.  We are never going
to convince IPP of anything if we don't send comments to IPP as well.
Just cross post your messages.

Tom

---

From: Tom Hastings <[email-masked]>
Date: Wed, 28 May 1997 02:06:39 PDT

I agree with Ron, that JMP doesn't need to have the same states
as IPP, as long as JMP can be easily mapped from IPP, so that a JMP
agent can easily instrument an IPP system.

So JMP coul have a held state, instead of the jobHeld generic state
reason.  One of the reasons that IPP merged the held job state into
the pending job state, is the difficulty of doint state diagrams where
there is a branch into two states, depending on the situation, such as
a job going into held or pending depending on its attributes and the
configuration of the printer.

However a JMP agent isn't implementing the state machine, its only reflecting
what the underlying printer implementation is doing.  So the comlication
of having two state: held and pending is a problem for the agent.   The
agent just represents to the application through the MIB, the underlying
state of the implementation.  So the agents doesn't have the problem of
implementing the more complicated state machine with both a held and a
pending state.

For those of you into object modeling, the Shlaer-Mellor school only
allows a decision when exiting a state, not when entering.  So with
Shlaer-Mellor implementation you have to introduce a temporary intermediate
evaluating-hold state in which the exit from the state is whether the job
goes into the held state or into the pending state.  But with using 
job-state-reasons, instead, all this complication goes away, because the
job is always in the pendin state.  Its the job state reasons that prevent
the implementation from choosing a job that can't be processed.

At 08:29 05/27/97 PDT, Ron Bergman wrote:
>
>
>On Sun, 25 May 1997, Tom Hastings wrote:
>
>> At 08:06 05/23/97 PDT, Ron Bergman wrote:
>> >
>> In IPP the job-state-reasons 'printer-stopped' is used instead of a separate
>> job state called 'needs-attention'.  The job can be in either the 'pending' 
>> or 'processing' state when the reason 'printer-stopped appears.
>> If the job is in the pending state, it is some other job that is having
>> the problem, but ALL pending jobs are affected, unless the printer
problem is 
>> attended to.
>> 
>> We have two choices for the Job Monitoring MIB:
>> 
>> 1. Follow IPP and get rid of the needsAttention state and add the
>> deviceStopped value to the JmJobStateReasons1TC.
>> 
>> 2. Keep the needsAttention state.  Don't add the deviceStopped value to the
>> jmJobStateReasons1TC.  When an agent is instrumenting IPP,
>> the agent shall map the IPP 'processing' state to the JMP processing state, 
>> except when the IPP "job-state-reasons" contains 'printer-stopped'.  Then
the 
>> JMP agent shows the job in the JMP needsAttention state.  When the IPP
>> 'printer-stopped' value is removed from the IPP "printer-state-reasons" 
>> attribute, the JMP agent shall change the value of the job's jmJobState
object
>> from the needsAttention state to the processing state.  The JMP
>> jmJobStateReasons1 object would remain unchanged during this.
>>
>RB> I would vote for number two if these were are only choices.

Alternative 2 is fine with me too, if we relax our zeal of trying to 
convince IPP to change.  Can we agree to just make sure that it is easy
for a JMP agent to map IPP to the MIB?

Can you think of other alternatives?

>RB> I don't see any difference in "required" vs "requested".

You are right.  You can't put everything into the spec.
Does the following description help for the condition which has been
further rename by IPP to:  job-hold-until-resources-are-ready
which in the MIB is jobHoldUntilResourcesAreReady:

At least one of the resources needed by the job, such as media, fonts,
resource objects, etc., is not ready on any of the physical devices for
which the job is a candidate.

Usually such a condition is detected while the job is in the pending state.
If a job starts processing and encounters a resource that is not ready,
there are two possible implementations:

OR

>RB> Have we eliminated too much?

Maybe.  But the jobHold generic state reason in JMP (not in IPP) is another
way to represent the held state, but using the reason mechanism.
It depends on whether it is more important for JMP to have the same
state as IPP and JMP only have additional job state reasons, or whether
JMP can also have additional job states that cleanly sub-divide an IPP
job state.  E.g., the IPP pending state maps to either the JMP held state
or the JMP pending state, depending on the job state reasons that do or don't
prevent the job from being a candidate for processing.

>
>> IPP also renamed 'required-resources-not-ready' to
>> 'job-hold-until-resources-are-ready'.  The prefix "job-hold-" indicates
>> that the job is held and will not process until the reason goes away.
>> 
>> Again, JMP could still keep the held state, even though IPP doesn't have it.
>> Which may be a good idea, since MIBs use enums, not keywords, so that an
>> application can't tell from the enum code whether the job has to have the
>> reason removed before it can be processed, or whether the reason is a less
>> important one that doesn't affect whether the job will start processing
or not.
>> 
>> Then a JMP agent would represent the IPP 'pending' state with certain
>> "job-state-reasons" value, such as 'job-hold-until-specified', and
>> 'job-hold-until-required-resoureces-are-ready' as:
>> 
>>   the JMP 'held' state and also show the same jmJobStateReasons1 object
values. 
>>
>RB> I propose that we include the states that make sense for the Job MIB
>RB> even if they are not in IPP, as long as they can be mapped into 
>RB> currently defined IPP states and reasons.

Makes sense to me also for IPP 'pending' to map to JMP held vs. pending.

How can we get a "vote" on this?

However, for needsAttention, we still haven't discussed the IPP point that 
as far as the user is concerned his/her pending job that is pending for a 
stopped printer is just as much affected as when his/her processing job is 
the current job that is using the printer when the printer stopped.  
Neither the pending job nor the processing job will finish until the 
printer attended to so that the printer is no longer stopped.

>> Thanks for being flexible.
>> 
>> >
>> I don't remember this.  Xerox has systems with service-off-line reason.
>> The jobs that have been previously accepted are indicated as being in the
>> held state with the serviceOffLine reason.  Clients can still query the
>> server since its the device that is really off-line, not the server.
>> Perhaps we should rename the reason from serviceOffLine, to deviceOffLine
>> and indicate that it is for configuration 2 in JMP?
>> 
>RB> I did not intend this to be a major issue.  Leave it in.

Done.

>> How can the Needs Attention job state apply to all conditions (states)?  
>> It could if Needs Attention were a job state reason.  In IPP we made Needs 
>> Attention a job state reason, but then renamed it to 'printer-stopped', 
>> because a device could need attention even though jobs were still
>> progressing, such as toner low.
>> 
>RB> Not States.. Conditions that prevent the job from printing, i.e. paper
>RB> out, paper jam, out of toner, printer unplugged, etc, etc, etc.  Then
>RB> the "needsAttention" state applies.

But what about the pending jobs?  They are just as much affected by the
printer needing attention as the job in the processing state.  The jobs
in the pending state won't get done until the printer is attended
to either.

>
>> So maybe you and Harry could support the IPP job-state-reason
'printer-stopped'
>> as equivalent a Needs Attention job state reason and more flexible than
>> if Needs Attention were a job state?
>> 
>> >
>> As I explained above, IPP thought that Needs Attention was better as a
>> job state reason, rather than a job state, and then we renamed the reason
>> to printer-stopped to be clearer.
>> 
>> I'm sorry that neither you nor Harry were able to call into the IPP
>> call last Wednesday.  The ball is in yours and Harry's court to see if
>> you like the IPP approach and we can use it directly in JMP or whether
>> JMP should perform a straight forward mapping when instrumenting an IPP
>> system as I outlined above to the JMP held and/or JMP needsAttention states
>> and some fiddling with job-state-reasons.
>> 

Adding a JMP held state that is not in IPP is fine. The mapping from IPP
to JMP done by the JMP agent is that any IPP job-state-reasons value keyword
that starts with 'job-held-' would cause the agent to display the job in the
held state, instead of the pending state.  If there were no 'job-held-xxx'
reason, then the IPP 'pending' state maps to the JMP pending state.  As soon
as all of the 'job-held-xxx' IPP reasons are gone, the agent would display
the job in the pending state, instead of the held state.  Again, the agent
need not make the state change until an application makes a query of that
job and then the agent performs a "lazy evaluation" of the job state by
looking at the current IPP job-state-reasons attribute values.

For mapping the IPP printerStopped job-state-reason, if JMP wants only
the processing jobs have have a problem to be in the JMP needsAttention
state, then the agent maps as follows:

  IPP state    IPP job-state-reasons    JMP state        JMP jmJobStateReasons1
  ---------    ---------------------    ---------        ---------------------- 
  pending      printer-stopped           pending         -
  pending      job-held-until-specified  held            jobHeldUntilSpecified
  processing   printer-stopped           needsAttention  -
  processing   job-printing              processing      jobPrinting

Several tweaks to the above  mapping table are:

1. Change the first "-" above to: deviceStopped.  Then all the pending jobs 
get to see that they are waiting for a printer that is stopped.

2. Change the second "-" above to deviceStopped which would be redundant
with the needsAttention state, but does preserve the job state reasons
compatibility between JMP and IPP for this reason.

---

From: Patrick Powell <[email-masked]>
Date: Thu, 29 May 1997 09:24:08 -0700 (PDT)

Having thought about this,  I realize that I really don't care
WHICH form we use,  as long as there is ONE form (format) that is
common between the JMP and IPP protocols/standards.

Note:  while I want one set,  I wouldn't be opposed to two sets of 'names'
with a well defined (i.e. -cast into standard) mapping between the two sets.

Patrick Powell

	From: "Caruso,Angelo" <[email-masked]>
	Subject: RE: JMP> HELD vs NEEDS-ATTENTION

	Thanks,
	Angelo