Subject: IPP> MOD - "job-state-reason" clarifications, additions and movements

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Sep 1997 19:42:48 PDT

I'd like to put this job-state-reasons clarification, additions, and
movements on the IPP agenda next week, so that we can keep IPP and JMP
in synch.

Thanks,
Tom

>Return-Path: <[email-masked]>
>X-Sender: hastings@zazen
>Date: Wed, 10 Sep 1997 09:57:52 PDT
>To: [email-masked]
>From: Tom Hastings <[email-masked]>
>Subject: IPP> Clarifications, additions and movements of some
>  job-state-reasons
>Cc: [email-masked]
>Sender: [email-masked]
>
>Subj:  Clarifications, additions and movements of some job-state-reasons
>From:  Tom Hastings and Harry Lewis
>Date:  9/10/97
>File:  reasons.doc
>
>On the JMP DL, Harry has made the following proposals for movement
>of some job state reasons to jmJobStateReason1 object and clarifications.
>Some of these may want to be added to IPP (but IPP can remain a subset
>of JMP, since JMP is attempting to cover other job submission protocols
>as well as IPP).
>
>1. Move 'submssionInterrupted' to jmJobStateReasons1 to indicate that
>the server has timed out the job and closed it.
>Should be added to IPP as well.
>
>2. Move 'serviceOffLine" to jmJobStateReason1 to indicate that the
>service has been disabled, so that all pending jobs are not going to
>be processed.
>
>3. Distinguish between canceling by (authenicate) operator and canceled
>at local (unauthenticated) op panel, by adding 'canceled-at-device'.
>
>4. Rename 'canceled-by-user' to 'canceled-by-owner' to agree with the
>semantics.
>
>5. Clarify 'canceled-by-operator' to mean authenticated as a privileged
>user in some way.
>
>6. Add 'canceled-by-non-owner' for those systems that have more
>comprehensive security mechanisms, such as group privileges in POSIX.
>
>
>If we add these to JMP, Harry has indicated that we could put them
>in their logical place in the order of likely occurrence, but only
>we need to agree quickly.  If we can't agree quickly, then we should
>put them at the end of the bit assignments in JMP.  (Fortunately, in 
>IPP, we use keywords, instead of bits, so there is no problem with ordering).
>
>I've indicated the new bit assignements below for the JMP spec.
>
>
>The proposed specs for each of these job state reasons becomes:
>
>For JMP:
>
>submissionInterrupted	0x8
>Indicates that the job was not completely submitted for some unforeseen
>reason, such as: (1) the server has crashed before the job was closed by the
>client, (2) the server or the document transfer method has crashed in some
>non-recoverable way before the document data was entirely transferred to the
>server, (3) the client crashed or failed to close the job before the
>time-out period.
>
>
>jobCanceledByOwner	0x1000
>The job was canceled by the owner of the job, i.e., by a user
>whose name is the same as the value of the job's jmJobOwner object.
>
>
>jobCanceledByOperator	0x2000
>The job was canceled by the operator, i.e., by a user whose has been
>authenticated as having operator privileges (whether local or remote).
>
>
>jobCanceledAtDevice	0x4000
>The job was canceled by an unidentified local user, i.e., a user 
>at a walkup console or operator's panel.
>
>
>jobCanceledByNonOwner	0x8000
>The job was canceled by an authenticated user that is not the owner of the
>job.  This reason may be used in systems that have the concept of group or
>other security mechanisms that allow jobs to be canceled by users other than
>the job owner but that are not operators.
>
>
>serviceOffLine	0x40000 
>The service or document transform is off-line and accepting no jobs.  
>All pending jobs are put into the pendingHeld state.  This situation 
>could be true if the service's or document transform's input is impaired 
>or broken.
>
>
>
>NOTE: Just two more spare bits in JMP jmJobStateReasons object before we use
>the 3 other 32-bit job state reasons attributes.
>
>
>
>IPP:
>
>For IPP, the names change to all lower case with hyphens to follow keyword
>syntax.
>
>'submission-interrupted':  The job was not completely submitted for some
>unforeseen reason, such as: (1) the Printer has crashed before the job was
>closed by the client, (2) the Printer or the document transfer method has
>crashed in some non-recoverable way before the document data was entirely
>transferred to the Printer, (3) the client crashed or failed to close the
>job before the time-out period.
>
>'job-canceled-by-owner':  The job was canceled by the owner of the job, 
>i.e., by a user whose name is the same as the value of the job's
>"job-originating-user" attribute.
>
>'job-canceled-by-operator':  The job was canceled by the operator 
>using the CancelJob request, i.e., by a user who has been granted 
>special privileges.
>
>'job-canceled-at-device':  The job was canceled by an unidentified local
>user, i.e., i.e., a user at a walkup console or operator's panel.
>
>'serviceoff-line':  The Printer is off-line and accepting no jobs.  All
>pending jobs are put into the 'pending-held' state.  This situation 
>could be true if the Printer's input is impaired or broken.
>
>Comments?
>
>Tom
>
>
>