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: <ipp-owner at pwg.org>
>X-Sender: hastings at zazen>Date: Wed, 10 Sep 1997 09:57:52 PDT
>To: jmp at pwg.org>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: IPP> Clarifications, additions and movements of some
> job-state-reasons
>Cc: ipp at pwg.org>Sender: ipp-owner at pwg.org>>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
>>>