Subject: IPP> MOD - Comments on IPP Model V1.1, printer-state attribute

From: Tom Hastings <[email-masked]>
Date: Tue, 11 Feb 1997 12:11:37 PST

We've agreed to subset ISO DPA printer states to the bare minimum
and to add a printer-state-reasons attribute which is multivalued
and printer-state-message which is a text string to augment the
printer-state attribute.

I believe that we also agreed (but its not yet in the draft) to add
the ISO DPA Boolean printer attribute of enabled to indicate that the 
current policy of the Printer is to accept Print operations or not.  
The value of the enabled attribute is
orthogonal to the printer-state attribute, since the printer can be
not accepting jobs while finishing the currents jobs that it has, i.e.,
be in any of the printer-state states.

Perhaps, make the name clearer as:  "enabled-to-accept-jobs", instead
of just "enabled".  

I have the following comments on the current text of printer-state which is:

5.5.5 printer-state (type1Enum)

This attribute identifies the current state of the printer and shall be set
by the Printer.  The protocol support all values for printer states, however
a Printer shall only generate the printer states which are appropriate for
the particular implementation.

The following standard values are defined:

unknown         The printer state is not known, or is indeterminate, or is
not returned by the operation

idle            The printer is ready to accept jobs, but none have been
scheduled on it.

printing        The printer is currently printing a job

needs-attention The printer needs human attention (no special skills
required).  This state typically includes adding paper, clearing a jam,
changing the medium, etc.

Comments:

1. Add "s" to support.

2. "idle" should not indicate whether the Printer is accepting jobs or not,
that is what the enabled attribute is for.  So change the definition of
idle to:

idle          The Printer is not processing any jobs.

3. Change the name of the "printing" state to "processing", so that
the state may be used by Printers when interpreting, and by non-Printer
output devices, like CD-ROM writers and fax-out.  So change the definition
to:

processing    The Printer is currently processing a job.

4. "needs-attention" may now need special training, since needs-attention
is for any reason that the Printer needs human attention. Also the operator
may have paused the printer or the job may contain instructions to stop
the printer and wait for human interaction.  So change the definition of
needs-attention to:

needs-attention    The Printer needs human attention.  This state typically
includes adding paper, clearing a jam, changing the medium, etc.  It also
includes when a system operator has paused the printer or the job contains
special instructions to stop the printer at a particular point in the job
to wait for operator or end-user interaction, such as installing special
forms or entering a password.  The printer-state-reasons and
printer-state-messsage printer attributes give further information about why
the output device
needs attentions.

5. I also belive that we need the ISO DPA "shutdown" state, which indicates 
that the Printer has been shutdown.  It seems too surprising to end-users
to indicate a shutdown condition as a printer-state-reason when the printer 
is in the needs-attention or idle states.  So bring back "shutdown":

shutdown	The Printer has been taken out of service, (for a long time),
whether for repairs or others reasons.  The Printer's printer-state message
attribute may be used to record a reason and estimated time for return to
service.

6. Here is the suggested text for "enabled-to-accept-jobs" Boolean printer
attribute:

enabled-to-accept-jobs (boolean)

Indicates whether the Printer is accepting job submission Print operations
or not.  A Printer shall reject Print operations when the value of the
Printer enabled attribute indicates false (no, n, false, or f).  

NOTE - The enabled-to-accept-jobs printer attribute is set by the operator 
using means outside the scope of IPP V1.0.

7. The printer-state-reasons should include the following deleted ISO DPA 
printer states as values:

paused	The operator has (temporarily) paused the Printer, by means outside
the scope of IPP V1.0.

needs-key-operator	The output device needs the attention of a key operator.
Key operator functions require special training and are device-specific, but 
typically include adding toner or developer, or attending to a hardware fault.

connecting-to-printer	The server has scheduled a job on the Printer and is
in the process of connecting to a shared network output device (and may not
be able to actually start printing the job for an arbitrarily long time
depending on the usage of the output device by other servers on the network).

timed-out	The server was able to connect to the output device (or is always
connected), but was unable to get a response from the output device in the
time specified by the printer's printer-timeout-period attribute.

The following ISO DPA deleted printer states do not need to be added 
as printer-state-reasons, since IPP does not have the job attributes that
go with them:

job-start-wait	The currently processing job was started with the
job-start-wait attribute set, and is awaiting operator intervention or time-out.

job-end-wait	The currently processing job was started with the job-end-wait
attribute set, and is awaiting operator intervention or time-out.

job-password-wait	The currently processing job was started with the
job-password attribute set, and is awaiting the operator or user to enter
the password supplied by the job-password attribute.

By the way, the OMG Print Facility standards project is on the same
schedule as IPP and is trying to align with IPP, so this above discussion
on printer states relates to work they are currently doing.  So I hope we
can get closure on these printer attributes soon in order to keep the two
developing standards aligned.

Thanks,
Tom

---

From: Tetsuya Morita <[email-masked]>
Date: Wed, 19 Feb 1997 23:21:04 +0900

Tom,

We have considered how we could align our OMG Printing Facility model
with your comments on 5.5.5 printer-state. You might know that our
model and attributes are also strongly affected by DPA, so your DPA
oriented approach is easy to accept to our model.

 > printer-state-message printer attributes give further information about why
 > the output device needs attentions.
 > 
 > 5. I also believe that we need the ISO DPA "shutdown" state, which indicates 

Most of the differences between our previous state model and your's are
on the name descriptions.

  Tom's States      Ricoh's States  Comments
 ============================================================================
   shutdown          power-off      Same meaning
   processing        executing      Same meaning
   needs-attention   error          needs-attention and needs-key-operator included
   unknown           unknown        Same meaning
   idle              idle           Same meaning

Assuming IPP may be one of the candidates for implementation of
OMG Printing Facility, we slightly changed our Device STD to be
a superset of IPP printer states as follows,

        /----------\         /----------\
        | shutdown |	     | unknown  |
        \----------/	     \----------/
           |    ^
           |    |
    /------+------------- active -------------------\
    |      |                                        |
    |      V                                        |
    |   /------------\     /-- needs-attention --\  |
    |   | initialize |<-+  |                     |  |
    |   \------------/  |  |  /-- error --------\|  |
    |      |            +--+->|                 ||  |
    |      |               |  | (needs-key-op)  ||  |
    | /----+-----------\   |  |                 ||  |
    | |    V           |   |  | (connect-to-p)  ||  |
    | |  /----------\  |<--+->|                 ||  |
    | |  | idle     |  |   |  | (timeout)       ||  |
    | |  \----------/  |   |  |                 ||  |
    | |    |    ^      |   |  \-----------------/|  |
    | |    |    |      |   |                     |  |
    | |    V    |      |   |                     |  |
    | | /------------\ |   |  /----------\       |  |
    | | | processing | |<--+->|  paused  |       |  |
    | | \------------/ |   |  \----------/       |  |
    | |                |   |                     |  |
    | \--operational---/   \---------------------/  |
    |                                               |
    \-----------------------------------------------/
    
         Device State Transition Diagram 
    (in OMG Printing Facility submission by Ricoh)

Although we know the 'initialize' state is not defined by DPA, we added
it because print client might select other 'operational' device and start 
printing quickly. Today's almost available printers have some warm-up time.

I suppose the 'initialize' could be included in 'idle' state in IPP
model, right?
    
 > developing standards aligned.

We would be so happy to make liaison with IPP Working Group. I hope our
new Device STD is well aligned to IPP printer-state attributes.

Thanks,

--
Tetsuya Morita
Ricoh Company Ltd.
Printer Business Center