Tom, thanks for the thorough overview of possibilities related to job
cancel. This topic could easily be drawn out due to distinct differences
in the worlds of office network printing, operated print farms and heavy
duty production environments with both system and (logged on) machine
operators.
I'll cut to the chase and say I'd probably go with your recommendation
>2. Add a new reason: canceledByLocalUser
>>I prefer (this) alternative, since it is then clear to the remote
>user (job owner) why/who canceled his/her job. So that for systems
>that do have remote operators, the distinction can be made between
>the remote operator and a local user by having two separate reasons.
but for a slightly different reason. Basically, if you look at it from
the point of view of an agent in a standard network printer, the agent may
distinguish between a cancel at the opPanel vs. some other means, but it is
less likely to recognize the name of the person initiating either form of
cancel and match it with the person who initiated the job (per the DPA
definition).
So I feel it will be common for "network printers", at best, to distinguish
what I call LOCAL and REMOTE cancel. I don't have a problem preserving the
DPA definitions for large scale systems. However, given that there remain
2 definitions for REMOTE cancel ("by User" and "by Operator"), many printers
will have to "guess". I suggest "by User" because Operator has a bit more
connotation of someone who might be standing at or near the printer
(granted, not in all environments).
Harry Lewis
---------------------- Forwarded by Harry Lewis/Boulder/IBM on 08/29/97 08:22 AM
---------------------------
jmp-owner at pwg.org on 08/29/97 12:35:50 AM
Please respond to jmp-owner at pwg.org @ internet
To: Harry Lewis/Boulder/IBM at ibmus
cc: ipp at pwg.org @ internet, jmp at pwg.org @ internet
Subject: JMP> MOD - Re: JobStateReasons -1 [semantics of canceledByOp
Harry,
Its very helpful to have your list of the job-state-reasons that you
implemented in your Job Monitoring MIB and your interpretation of the
job-state-reasons. Since the job-state-reasons that are in the JMP
jmJobStateReasons1 object are intended to be the same as the IPP
"job-state-reasons" attribute, we need to keep them sematically
in synch. So I have copied the IPP DL as well on this.
The only description that I have some question about as you draw attention to
is the distinction that you make between the canceledByUser and
canceledByOperator reasons: you use the canceledByOperator when a local
user cancels a job. Now is the time to clarify/fix the specification.
Do you have the concept of a remote operator who has more privileges
than a remote user? For example, can a remote operator cancel any
job, while a remote user can only cancel his/her own jobs? That was the
intent of the canceledByUser versus the canceledByOperator reason
(in DPA and IPP and other systems).
However, you bring up a new kind of user: the local/walkup user who
may have more privileges than a remote user, while having less privileges
(or the same privileges) as a remote operator.
Does your walkup user have to identify himself/herself to the system
somehow, so that the system can prevent such a user from canceling
some other user's job? Or can the local user cancel any user's
job? Or can the local user cancel only the current job?
We at Xerox have been wrestling with the special status of the walkup
user at the local console of the machine, as well. Since the policy of such a
local/walkup user may be more privileged than a remote user, but not as
privileged as a remote (or local) operator, we have seen the need to introduce
this additional category of user. Social pressure may be the
only way to reduce the abuse of the privileges of a walkup/local user
for systems where the policy is to grant local users more privileges
than remote users.
The current specs for the two canceled reasons are:
JMP:
jobCanceledByUser 0x800
The job was canceled by the user, i.e., by an unknown user or by a user
whose name is the same as the value of the job's jmJobOwner object.
jobCanceledByOperator 0x1000
The job was canceled by the operator, i.e., by a user whose name is
different than the value of the job's jmJobOwner object.
IPP:
'job-cancelled-by-user': The job was cancelled by the user using the
CancelJob request, i.e., by a user whose name is the same as the value of
the job's "job-originating-user" attribute.
'job-cancelled-by-operator': The job was cancelled by the operator using
the CancelJob request, i.e., by a user whose name is different than the
value of the job's "job-originating-user" attribute.
[We ought to agree on whether canceled as one or two l's.]
MS-WORDs spell checker prefers one leter l, though I suspect that both
are correct.
So I see two alternative for the specification (and IPP):
1. Generalize the canceledByOperator to include the local/walkup user
2. Add a new reason: canceledByLocalUser
I prefer the second alternative, since it is then clear to the remote
user (job owner) why/who canceled his/her job. So that for systems
that do have remote operators, the distinction can be made between
the remote operator and a local user by having two separate reasons.
Comments?
Tom
At 10:06 08/28/97 PDT, Harry Lewis wrote:
>In review, we have one final request to move a jobStateReason. We would
>like to see submissionInterrupted moved into Reasons-1.
>>I would also like to share the jobStateReasons which we have found the
>most practical and useful.
>>>deviceStopped - open cover, paper jam etc.
>>jobPrinting - from first to last page unless there is an error or the
> printer goes offline
>>submissionInterrupted - I/O timeout occurs
>>processingToStoppedPoint - between cancel request and actual end of
> cancel operation
[I'll proposing adding to IPP in a separate e-mail, since we've moved it
into jmJobStateReasons1 in JMP].
>>serviceOffline - printer is offline (with or without errors)
[I'll proposing adding to IPP in a separate e-mail, since JMP is considering
moving it into jmJobStateReasons1 in JMP].
>>canceledByOperator - canceled at the printer
>>canceledByUser - canceled remotely
>>>We think there is benefit in a design that relies mainly on the Reasons-1
>category due to it's mandatory distinction. This is why we have requested
>a few jobStateReasons be moved to Reasons-1.
>>I'd like to offer our interpretation, above, as sort of a "Top 7" (akin to
>the Alert table top 25) and see if others agree. I know, offhand, that our
>interpretation of the canceled reasons is a bit different than the strict
>definitions and may not fit the server implementation exactly. If anyone
>reads the strict definitions, when you are finished chuckling, you may
>want to help explain them. I think they're from DPA;-) ;-) ;-).
Please point out what is puzzling, so we can fix it.
>>>Harry Lewis
>>