Subject: {Disarmed} Re: [IPP] Descriptions of CUPS additions to the Cancel-Job and Purge-Jobs operations

From: Michael Sweet <[email-masked]>
Date: Fri, 2 Oct 2009 08:53:00 -0700

Comments inline...

On Sep 30, 2009, at 7:10 PM, Tom Hastings wrote:
> I'm struggling mightily to write up the Cancel-Job and Purge-Job  
> operations as suggested by Michael and have come up with a bunch of  
> issues.  Since HTML may not come through the email reflector with  
> the 5 MS-WORD ISSUE comments intact and the table shown, I’ve also  
> downloaded the .doc of just these attributes with my suggested  
> descriptions and the ISSUES as MS-WORD comments to: ftp://ftp.pwg.org/pub/pwg/ipp/wd/Attributes_to_add_to_Cancel-Job_and_Purge-Jobs_operations.doc 
> .
>
> The 5 ISSUES are as follows:
>
> ISSUE 1:  Allowing an unprivileged user to purge his job using  
> Cancel-Job, could circumvent accounting in those systems that use  
> Retained Jobs and Job History for accounting.
>
> ISSUE 2:  Allowing an unprivileged user to purge his jobs using  
> Purge-Jobs, could circumvent accounting in those systems that use  
> Retained Jobs and Job History for accounting.
>
> One solution would be to only allow Purge-Jobs for operator or  
> administrator as in [RFC 2911].
>
> ISSUE 3: Instead of adding “my-jobs” and “purge-job” to Purge-Jobs,  
> a simpler way to allow an unprivileged user to cancel all his jobs,  
> instead of just a specified job, would be to add “all-my- 
> jobs” (boolean) Operation attribute to the Cancel-Job operation.   
> When the client supplies this attribute with a ‘true’ value, the  
> client MUST NOT supply a “job-id” or “job-url” Operation attribute.
>
> ISSUE 4: Or should the spec say the Printer MUST reject the Purge- 
> Jobs operation if the unprivileged client supplies the “my-jobs” =  
> ‘false’ and return: client-error-forbidden, client-error-not- 
> authenticated, and client-error-not-authorized as appropriate, as  
> for Purge-Jobs in RFC 2911 section 3.2.9
>
> ISSUE 5: The “purge-job” (boolean) Operation attribute has the  
> ‘true’ value here as its default.  Usually, it’s the ‘false’ value  
> that is the default.  More confusingly, the “purge-job” (boolean)  
> Operation attribute (correctly) has the ‘false’ value in the Cancel- 
> Job operation above.
>
> I’ve included the text in the draft which I will post tomorrow for  
> this Monday’s IPP WG telecon, October 5, at 1:00 PM PDT = 4:00 PM  
> EDT, but I wanted to start people thinking about these issues.   
> Hopefully, we can resolve these issues at the meeting so that I can  
> update the draft for the face to face meeting in Cupertino, the  
> following week, October 12-14.
>
>
> Here is what I've come up with.  Comments and suggestions are welcome:
>
> 4.3 Cancel-Job operation
>
> This section specified an additional operation attribute for use  
> with the Cancel-Jobs operation (see [RFC2911] Section 3.3.3).
>
> 4.3.1 purge-job[th1]   (boolean)
>
> The “purge-job” Operation attribute controls whether the specified  
> job is canceled or purged as follows:
>
> ‘false’:  Default value.  The Printer cancels the specified job as  
> specified in [RFC2911] Section 3.3.3 which MAY leave a Retained Job  
> with document data on the Printer for possible re-processing (e.g.,  
> using the Reprocess-Job or Resubmit-Job operations) and/or Job  
> History.  Note: If the client omits this attribute or supplies the  
> ‘false’ value, the behavior of the Cancel-Job operation is as  
> specified in [RFC2911].
>
> ‘true’:   If the authenticated user is the job owner of the job  
> specified by the “job-id” or “job-uri” operation attribute or is a  
> privileged operator or administrator of the Printer, the Printer  
> MUST purge the specified job according to the semantics of the Purge- 
> Jobs operation independent of the job’s state, but only for the  
> specified job, i.e., remove all record of the specified job,  
> including attributes, history and document data.
>
> The client MAY supply this Operation attribute and the Printer MAY  
> support this Operation attribute in the Cancel-Job operation.
>

I'd just make the authenticated user case more generic, and also  
document that Cancel-Jobs with purge-jobs=true will fail if the user  
is not authorized, e.g.:

‘true’:   If the authenticated user is allowed to purge a job by the  
Printer's security policy (typically if the owner of the job specified  
by the “job-id” or “job-uri” operation attribute matches) or is a  
privileged operator or administrator of the Printer, the Printer MUST  
purge the specified job according to the semantics of the Purge-Jobs  
operation independent of the job’s state, but only for the specified  
job, i.e., remove all record of the specified job, including  
attributes, history and document data. Otherwise, the IPP object MUST  
reject the operation and return: client-error-forbidden, client-error- 
not-authenticated, and client-error-not-authorized as appropriate.

The wording of the last sentence matches RFC 2911's Purge-Jobs  
description.
> 4.4 Purge-Jobs operation
>
> This section specified additional operation attributes for use with  
> the Cancel-Jobs operation (see [RFC2911] Section 3.3.7).
>
> 4.4.1       my-jobs[th2]  [th3]   (boolean)
>
> The “my-jobs” Operation attribute allows the client to request the  
> target jobs to be (1) all jobs or (2) only jobs owned by the  
> requesting user.  However, the Printer MUST further restrict the  
> target jobs as follows:
>
> ‘false’:  Default value.  The target jobs are all jobs, unless the  
> Authenticated user supplying the request is NOT an operator or  
> administrator of the Printer, in which case the Printer MUST  
> restrict the target jobs to those belonging to the requesting user. 
> [th4]
>
> ‘true’:   The target jobs are limited to those owned by the  
> Authenticated user submitting the request.
>
> The client MAY supply this Operation attribute and the Printer MAY  
> support this Operation attribute in the Purge-Jobs operation.

I'd add the following to the 4.4 introduction to address th2-th5:

Access Rights: The following attributes may allow the authenticated  
user (see RFC 2911 section 8.3) performing this operation to be an  
ordinary user depending on the Printer's security policy. When  
ordinary users are not allowed to use the Purge-Jobs operation, the  
IPP object MUST continue to reject the operation and return: client- 
error-forbidden, client-error-not-authenticated, and client-error-not- 
authorized as appropriate.

Then move the table into 4.4, before the description of the attributes.

> 4.4.2       purge-job (boolean)
>
> The “purge-job” Operation attribute controls whether the target jobs  
> are canceled or purged as follows:
>
> ‘false’:  The Printer cancels the target jobs as specified in  
> [RFC2911] Section 3.3.3 Cancel-Job which MAY leave a Retained Job  
> with document data on the Printer for possible re-processing (e.g.,  
> using the Reprocess-Job or Resubmit-Job operations) and/or Job  
> History.
>
> ‘true’:   Default value[th5]  .  The Printer purges the target jobs  
> as specified in [RFC2911] Section 3.2.9 Purge-Jobs.  Note: If the  
> client omits this attribute or supplies the ‘true’ value, the  
> behavior of the Purge-Jobs operation is as specified in [RFC2911]  
> for the target jobs.
>
> The client MAY supply this Operation attribute and the Printer MAY  
> support this Operation attribute in the Purge-Jobs operation.
>
> The behavior for the Purge-Jobs operation for these two Operation  
> attributes for unprivileged users vs. operators and administrator of  
> the Printer is shown in Table 2.
>
> Table 2: Interaction of "my-jobs" and "purge-jobs" attributes in the  
> Purge-Jobs operation
>
> Operation attributes
>
> Unprivileged user
>
> Operator or Administrator of the Printer
>
> “my-jobs” = ‘false’ or omitted
> “purge-jobs” = ‘false’
>
> Cancel only my jobs (Printer overrides “my-jobs” = ‘false’)
>
> Cancel all jobs
>
> “my-jobs” = ‘true’
> “purge-jobs” = ‘false’
>
> Cancel only my jobs
>
> Cancel only my jobs
>
> “my-jobs” = ‘false’ or omitted
> “purge-jobs” = ‘true’ or omitted
>
> Purge only my jobs (Printer overrides “my-jobs” = ‘false’)
>
> Purge all jobs
>
> “my-jobs” = ‘true’
> “purge-jobs” = ‘true’ or omitted
>
> Purge only my jobs
>
> Purge only my jobs
>
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of  
> Michael Sweet
> Sent: Monday, September 14, 2009 14:41
> To: [email-masked]
> Subject: [IPP] Descriptions of CUPS additions to the Cancel-Job and  
> Purge-Jobs operations
>
> All,
>
> Here are the descriptions for the CUPS additions to the Cancel-Job and
> Purge-Jobs operations. These came up in today's conference call...
>
> ------------------------------------------------------
>
> Cancel Job Operation
>
> The Cancel-Job operation (0x0008) cancels the specified job. CUPS 1.4
> adds a new purge-job (boolean) attribute that allows you to purge both
> active and completed jobs, removing all history and document files for
> the job as well.
>
> Cancel-Job Request
>
> The following groups of attributes are supplied as part of the Cancel-
> Job request:
>
> Group 1: Operation Attributes
>
> Natural Language and Character Set:
>      The "attributes-charset" and "attributes-natural-language"
> attributes as described in section 3.1.4.1 of the IPP Model and
> Semantics document.
>
> "printer-uri" (uri) and "job-id" (integer)
> OR
> "job-uri":
>      The client MUST supply a URI for the specified printer and a job
> ID number, or the job URI.
>
> "purge-job" (boolean):
>      The client OPTIONALLY supplies this attribute. When true, all job
> files (history and document) are purged. The default is false, leading
> to the standard IPP behavior.
>
>
> Cancel-Job Response
>
> The following groups of attributes are send as part of the Cancel-Job
> Response:
>
> Group 1: Operation Attributes
>
> Status Message:
>      The standard response status message.
>
> Natural Language and Character Set:
>      The "attributes-charset" and "attributes-natural-language"
> attributes as described in section 3.1.4.2 of the IPP Model and
> Semantics document.
>
>
> Purge-Jobs Operation
>
> The Purge-Jobs operation (0x0012) cancels all of the jobs on a given
> destination and optionally removes all history and document files for
> the jobs as well.
>
> Purge-Jobs Request
>
> The following groups of attributes are supplied as part of the Purge-
> Jobs request:
>
> Group 1: Operation Attributes
>
> Natural Language and Character Set:
>      The "attributes-charset" and "attributes-natural-language"
> attributes as described in section 3.1.4.1 of the IPP Model and
> Semantics document.
>
> "printer-uri" (uri):
>      The client MUST supply a URI for the specified printer or "ipp://.../printers
> " for all printers and classes.
>
> "requesting-user-name" (name(MAX)):
>      The client OPTIONALLY supplies this attribute to specify whose
> jobs jobs are purged or canceled.
>
> "my-jobs" (boolean):
>      The client OPTIONALLY supplies this attribute to specify that
> only the jobs owned by the requesting user are purged or canceled. The
> default is false.
>
> "purge-jobs" (boolean):
>      The client OPTIONALLY supplies this attribute to specify whether
> the jobs are purged (true) or just canceled (false). The default is
> true.
>
>
> Purge-Jobs Response
>
> The following groups of attributes are send as part of the Purge-Jobs
> Response:
>
> Group 1: Operation Attributes
>
> Status Message:
>      The standard response status message.
>
> Natural Language and Character Set:
>      The "attributes-charset" and "attributes-natural-language"
> attributes as described in section 3.1.4.2 of the IPP Model and
> Semantics document.
>
>
> ___________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ipp mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/ipp
>  ISSUE:  Allowing an unprivileged user to purge his job using Cancel- 
> Job, could circumvent accounting in those systems that use Retained  
> Jobs and Job History for accounting.
>
>  ISSUE:  Allowing an unprivileged user to purge his jobs using Purge- 
> Jobs, could circumvent accounting in those systems that use Retained  
> Jobs and Job History for accounting.
>
>
>
> One solution would be to only allow Purge-Jobs for operator or  
> administrator as in [RFC 2911].
>
>  ISSUE: Instead of adding “my-jobs” and “purge-job” to Purge-Jobs, a  
> simpler way to allow an unprivileged  user to cancel all his jobs,  
> instead of just a specified job, would be to add “all-my- 
> jobs” (boolean) Operation attribute to the Cancel-Job operation.   
> When the client supplies this attribute with a ‘true’ value, the  
> client MUST NOT supply a “job-id” or “job-url” Operation attribute.
>
>  ISSUE: Or should the spec say the Printer MUST reject the operation  
> and return: client-error-forbidden, client-error-not-authenticated,  
> and client-error-not-authorized as appropriate, as for Purge-Jobs in  
> RFC 2911 section 3.2.9
>  ISSUE: The “purge-job” (boolean) Operation attribute has the ‘true’  
> value here as its default.  Usually, it’s the ‘false’ value that is  
> the default.  More confusingly, the “purge-job” (boolean) Operation  
> attribute (correctly) has the ‘false’ value in the Cancel-Job  
> operation above.
>

___________________________________________________
Michael Sweet, Senior Printing System Engineer

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Ira McDonald <[email-masked]>
Date: Fri, 2 Oct 2009 13:24:25 -0400

Hi,

I generally agree with Mike's comments below.

But I really dislike a boolean that defaults to 'true' - this
needs work.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: [email-masked]
winter:
 579 Park Place  Saline, MI  48176
 734-944-0094
summer:
 PO Box 221  Grand Marais, MI 49839
 906-494-2434

On Fri, Oct 2, 2009 at 11:53 AM, Michael Sweet <[email-masked]> wrote:

> operations as suggested by Michael and have come up with a bunch of issues.
> Since HTML may not come through the email reflector with the 5 MS-WORD ISSUE
> comments intact and the table shown, I’ve also downloaded the .doc of just
> these attributes with my suggested descriptions and the ISSUES as MS-WORD
> comments to:
> ftp://ftp.pwg.org/pub/pwg/ipp/wd/Attributes_to_add_to_Cancel-Job_and_Purge-Jobs_operations.doc.
>
>
>
>
> ISSUE 1:  Allowing an unprivileged user to purge his job using Cancel-Job,
> could circumvent accounting in those systems that use Retained Jobs and Job
> History for accounting.
>
>
>
> Purge-Jobs, could circumvent accounting in those systems that use Retained
> ISSUE 3: Instead of adding “my-jobs” and “purge-job” to Purge-Jobs, a
> simpler way to allow an unprivileged user to cancel all his jobs, instead of
> just a specified job, would be to add “all-my-jobs” (boolean) Operation
> attribute to the Cancel-Job operation.  When the client supplies this
> attribute with a ‘true’ value, the client MUST NOT supply a “job-id” or
> “job-url” Operation attribute.
>
>
>
> ISSUE 4: Or should the spec say the Printer MUST reject the Purge-Jobs
> operation if the unprivileged client supplies the “my-jobs” = ‘false’ and
> return: client-error-forbidden, client-error-not-authenticated, and
> client-error-not-authorized as appropriate, as for Purge-Jobs in RFC 2911
> section 3.2.9
>
>
>
> ISSUE 5: The “purge-job” (boolean) Operation attribute has the ‘true’
> value here as its default.  Usually, it’s the ‘false’ value that is the
> default.  More confusingly, the “purge-job” (boolean) Operation attribute
> (correctly) has the ‘false’ value in the Cancel-Job operation above.
>
>
>
> I’ve included the text in the draft which I will post tomorrow for this
> Monday’s IPP WG telecon, October 5, at 1:00 PM PDT = 4:00 PM EDT, but I
> wanted to start people thinking about these issues.  Hopefully, we can
> resolve these issues at the meeting so that I can update the draft for the
> face to face meeting in Cupertino, the following week, October 12-14.
>
>
>
>
>
> *4.3 Cancel-Job operation*
>
> This section specified an additional operation attribute for use with the
> Cancel-Jobs operation (see [RFC2911] Section 3.3.3).
> *4.3.1 purge-job*[th1]   (boolean)
>
> The “purge-job” Operation attribute controls whether the specified job is
> canceled or purged as follows:
>
> specified in [RFC2911] Section 3.3.3 which MAY leave a Retained Job with
> document data on the Printer for possible re-processing (e.g., using the
> Reprocess-Job or Resubmit-Job operations) and/or Job History.  Note: If the
> client omits this attribute or supplies the ‘false’ value, the behavior of
> the Cancel-Job operation is as specified in [RFC2911].
>
> ‘true’:   If the authenticated user is the job owner of the job specified
> by the “job-id” or “job-uri” operation attribute or is a privileged operator
> or administrator of the Printer, the Printer MUST purge the specified job
> according to the semantics of the Purge-Jobs operation independent of the
> job’s state, but only for the specified job, i.e., remove all record of the
> specified job, including attributes, history and document data.
>
> The client MAY supply this Operation attribute and the Printer MAY support
> this Operation attribute in the Cancel-Job operation.
>
>
> I'd just make the authenticated user case more generic, and also document
> that Cancel-Jobs with purge-jobs=true will fail if the user is not
> authorized, e.g.:
>
> Printer's security policy (typically if the owner of the job specified by
> the “job-id” or “job-uri” operation attribute matches) or is a privileged
> operator or administrator of the Printer, the Printer MUST purge the
> specified job according to the semantics of the Purge-Jobs operation
> independent of the job’s state, but only for the specified job, i.e., remove
> all record of the specified job, including attributes, history and document
> data. Otherwise, the IPP object MUST reject the operation and return:
> client-error-forbidden, client-error-not-authenticated, and
> client-error-not-authorized as appropriate.
>
>
> The wording of the last sentence matches RFC 2911's Purge-Jobs description.
>
> *4.4 *Purge-Jobs operation
>
> This section specified additional operation attributes for use with the
> Cancel-Jobs operation (see [RFC2911] Section 3.3.7).
> *4.4.1       *my-jobs[th2]  [th3]   (boolean)
>
> The “my-jobs” Operation attribute allows the client to request the target
> jobs to be (1) *all* jobs or (2) only jobs owned by the requesting user.
> However, the Printer MUST further restrict the target jobs as follows:
>
> ‘false’:  Default value.  The target jobs are *all* jobs, unless the
> Authenticated user supplying the request is NOT an operator or administrator
> of the Printer, in which case the Printer MUST restrict the target jobs to
> those belonging to the requesting user.[th4]
>
> ‘true’:   The target jobs are *limited to* those owned by the
> The client MAY supply this Operation attribute and the Printer MAY support
> this Operation attribute in the Purge-Jobs operation.
>
>
> Access Rights: The following attributes may allow the authenticated user
> (see RFC 2911 section 8.3) performing this operation to be an ordinary user
> depending on the Printer's security policy. When ordinary users are not
> allowed to use the Purge-Jobs operation, the IPP object MUST continue to
> reject the operation and return: client-error-forbidden,
> client-error-not-authenticated, and client-error-not-authorized as
> appropriate.
>
>
> *4.4.2       *purge-job (boolean)
>
> The “purge-job” Operation attribute controls whether the target jobs are
> canceled or purged as follows:
>
> ‘false’:  The Printer cancels the target jobs as specified in [RFC2911]
> Section 3.3.3 Cancel-Job which MAY leave a Retained Job with document data
> on the Printer for possible re-processing (e.g., using the Reprocess-Job or
> Resubmit-Job operations) and/or Job History.
>
> ‘true’:   Default value[th5]  .  The Printer purges the target jobs as
> specified in [RFC2911] Section 3.2.9 Purge-Jobs.  Note: If the client omits
> this attribute or supplies the ‘true’ value, the behavior of the Purge-Jobs
> operation is as specified in [RFC2911] for the target jobs.
>
> The client MAY supply this Operation attribute and the Printer MAY support
> this Operation attribute in the Purge-Jobs operation.
>
> attributes for unprivileged users vs. operators and administrator of the
> Printer is shown in Table 2.
>
> *Table *2: Interaction of "my-jobs" and "purge-jobs" attributes in the
> Purge-Jobs operation
>
> Operation attributes
>
> Unprivileged user
>
> Cancel *all* jobs
> Purge *all* jobs
>  ------------------------------
>
>  ISSUE:  Allowing an unprivileged user to purge his job using Cancel-Job,
> could circumvent accounting in those systems that use Retained Jobs and Job
> History for accounting.
>
>  ISSUE:  Allowing an unprivileged user to purge his jobs using Purge-Jobs,
> could circumvent accounting in those systems that use Retained Jobs and Job
> History for accounting.
>
>
>
> simpler way to allow an unprivileged  user to cancel all his jobs, instead
> of just a specified job, would be to add “all-my-jobs” (boolean) Operation
> attribute to the Cancel-Job operation.  When the client supplies this
> attribute with a ‘true’ value, the client MUST NOT supply a “job-id” or
> “job-url” Operation attribute.
>
>  ISSUE: Or should the spec say the Printer MUST reject the operation and
> return: client-error-forbidden, client-error-not-authenticated, and
> client-error-not-authorized as appropriate, as for Purge-Jobs in RFC 2911
> section 3.2.9
>
>  ISSUE: The “purge-job” (boolean) Operation attribute has the ‘true’ value
> here as its default.  Usually, it’s the ‘false’ value that is the default.
> More confusingly, the “purge-job” (boolean) Operation attribute (correctly)
> has the ‘false’ value in the Cancel-Job operation above.
>
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 2 Oct 2009 10:50:46 -0700

FWIW, we can rev this to use a "cancel-jobs" attribute instead of  
"purge-jobs" for the Purge-Jobs operation, and I'll update CUPS  
accordingly (to support both the old and new names...) so that the  
defaults are all false.

On Oct 2, 2009, at 10:24 AM, Ira McDonald wrote:

>> MUST purge the specified job according to the semantics of the  
>> Purge-Jobs operation independent of the job’s state, but only for  
>> the specified job, i.e., remove all record of the specified job,  
> Printer's security policy (typically if the owner of the job  
> specified by the “job-id” or “job-uri” operation attribute matches)  
> or is a privileged operator or administrator of the Printer, the  
> Printer MUST purge the specified job according to the semantics of  
> the Purge-Jobs operation independent of the job’s state, but only  
> for the specified job, i.e., remove all record of the specified job,  
> including attributes, history and document data. Otherwise, the IPP  
> object MUST reject the operation and return: client-error-forbidden,  
> error-forbidden, client-error-not-authenticated, and client-error- 
> not-authorized as appropriate.
>
>> The “purge-job” Operation attribute controls whether the target  
>> jobs are canceled or purged as follows:
>>
>> attributes for unprivileged users vs. operators and administrator  
>> of the Printer is shown in Table 2.
>>
>> Table 2: Interaction of "my-jobs" and "purge-jobs" attributes in  
>> the Purge-Jobs operation
>>
>> Operation attributes
>>
>> Unprivileged user
>>
>>  ISSUE:  Allowing an unprivileged user to purge his job using  
>>  ISSUE:  Allowing an unprivileged user to purge his jobs using  
>>  ISSUE: Instead of adding “my-jobs” and “purge-job” to Purge-Jobs,  
>> a simpler way to allow an unprivileged  user to cancel all his  
>> jobs, instead of just a specified job, would be to add “all-my- 
>>  ISSUE: Or should the spec say the Printer MUST reject the  
>> operation and return: client-error-forbidden, client-error-not- 
>>  ISSUE: The “purge-job” (boolean) Operation attribute has the

---

From: "Tom Hastings" <[email-masked]>
Date: Sat, 03 Oct 2009 18:09:00 -0700

Good discussion.

If Michael is willing to update CUPS (to support the old and something new),
another new alternative would be to add the following Operation attribute to
Cancel-Jobs:

 "all-my-jobs" (boolean) with default 'false' to the Cancel-Jobs operation

instead of adding "cancel-jobs" (boolean) with default 'false' to the
Purge-Jobs operation.  Then we wouldn't have an operation attribute
("cancel-jobs") which changes an one operation (Purge-Jobs) into another
operation (Cancel-Jobs).   

A variant on my alternative above which would allow the
Operator/Administrator to be able to cancel all jobs (as is possible with
current CUPS, but uses Purge-Jobs) is to add the following Operation
attribute to the Cancel-Jobs operation: 

"which-jobs" (type2 keyword) with values:

'specified-job' - (default) the job specified by the supplied "job-id" or
"job-url"

'all-my-jobs' - cancel all my jobs

'all-jobs' - cancel all jobs;  If the Printer's security policy does not
allow the authenticated user to cancel jobs for which the requesting user is
not the owner, then the IPP object MUST reject the operation and return
client-error-not-authorized

Following the thrust of the above alternatives which avoid having an
operation attribute change the semantics of the operation to that of another
operation, how about also adding "job-id" (integer(1:MAX)) and "job-url"
(URL) to the Purge-Jobs operation.  If either are supplied, then the
specified job is purged, rather than all jobs.  If the requesting user is
NOT an Operator/Administrator AND the specified job is NOT owned by the
requesting user, then the IPP object MUST reject the operation and return
client-error-not-authorized.

Think about these alternative for the discussion at the IPP WG telecon, this
Monday, October 5, 1:00 PM PDT = 4:00 PM EDT.

In the meantime, I'll post the original CUPS approach rather than making
some of these discussed changes.

Thanks,

Tom

  _____  

From: Michael Sweet [mailto:[email-masked]] 
Sent: Friday, October 02, 2009 10:51
To: Ira McDonald
Cc: [email-masked]; [email-masked]
Subject: Re: {Disarmed} Re: [IPP] Descriptions of CUPS additions to the
Cancel-Job and Purge-Jobs operations

FWIW, we can rev this to use a "cancel-jobs" attribute instead of
"purge-jobs" for the Purge-Jobs operation, and I'll update CUPS accordingly
(to support both the old and new names...) so that the defaults are all
false.

Hi,

Cheers,
- Ira

Comments inline...

I'm struggling mightily to write up the Cancel-Job and Purge-Job operations
as suggested by Michael and have come up with a bunch of issues.  Since HTML
may not come through the email reflector with the 5 MS-WORD ISSUE comments
intact and the table shown, I've also downloaded the .doc of just these
attributes with my suggested descriptions and the ISSUES as MS-WORD comments
to:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/Attributes_to_add_to_Cancel-Job_and_Purge-J
obs_operations.doc.  

ISSUE 2:  Allowing an unprivileged user to purge his jobs using Purge-Jobs,
could circumvent accounting in those systems that use Retained Jobs and Job
History for accounting.

One solution would be to only allow Purge-Jobs for operator or administrator
as in [RFC 2911].

ISSUE 3: Instead of adding "my-jobs" and "purge-job" to Purge-Jobs, a
simpler way to allow an unprivileged user to cancel all his jobs, instead of
just a specified job, would be to add "all-my-jobs" (boolean) Operation
attribute to the Cancel-Job operation.  When the client supplies this
attribute with a 'true' value, the client MUST NOT supply a "job-id" or
"job-url" Operation attribute.

ISSUE 4: Or should the spec say the Printer MUST reject the Purge-Jobs
operation if the unprivileged client supplies the "my-jobs" = 'false' and
return: client-error-forbidden, client-error-not-authenticated, and
client-error-not-authorized as appropriate, as for Purge-Jobs in RFC 2911
section 3.2.9

ISSUE 5: The "purge-job" (boolean) Operation attribute has the 'true' value
here as its default.  Usually, it's the 'false' value that is the default.
More confusingly, the "purge-job" (boolean) Operation attribute (correctly)
has the 'false' value in the Cancel-Job operation above.

I've included the text in the draft which I will post tomorrow for this
Monday's IPP WG telecon, October 5, at 1:00 PM PDT = 4:00 PM EDT, but I
wanted to start people thinking about these issues.  Hopefully, we can
resolve these issues at the meeting so that I can update the draft for the
face to face meeting in Cupertino, the following week, October 12-14.

4.3 Cancel-Job operation

The "purge-job" Operation attribute controls whether the specified job is
canceled or purged as follows:

'false':  Default value.  The Printer cancels the specified job as specified
in [RFC2911] Section 3.3.3 which MAY leave a Retained Job with document data
on the Printer for possible re-processing (e.g., using the Reprocess-Job or
Resubmit-Job operations) and/or Job History.  Note: If the client omits this
attribute or supplies the 'false' value, the behavior of the Cancel-Job
operation is as specified in [RFC2911].

'true':   If the authenticated user is the job owner of the job specified by
the "job-id" or "job-uri" operation attribute or is a privileged operator or
administrator of the Printer, the Printer MUST purge the specified job
according to the semantics of the Purge-Jobs operation independent of the
job's state, but only for the specified job, i.e., remove all record of the
specified job, including attributes, history and document data. 

'true':   If the authenticated user is allowed to purge a job by the
Printer's security policy (typically if the owner of the job specified by
the "job-id" or "job-uri" operation attribute matches) or is a privileged
operator or administrator of the Printer, the Printer MUST purge the
specified job according to the semantics of the Purge-Jobs operation
independent of the job's state, but only for the specified job, i.e., remove
all record of the specified job, including attributes, history and document
data. Otherwise, the IPP object MUST reject the operation and return:
client-error-forbidden, client-error-not-authenticated, and
client-error-not-authorized as appropriate.

4.4 Purge-Jobs operation

The "my-jobs" Operation attribute allows the client to request the target
jobs to be (1) all jobs or (2) only jobs owned by the requesting user.
However, the Printer MUST further restrict the target jobs as follows:  

'false':  Default value.  The target jobs are all jobs, unless the
Authenticated user supplying the request is NOT an operator or administrator
of the Printer, in which case the Printer MUST restrict the target jobs to
those belonging to the requesting user.[th4]  

'true':   The target jobs are limited to those owned by the Authenticated
user submitting the request.   

 

The "purge-job" Operation attribute controls whether the target jobs are
canceled or purged as follows: 

'false':  The Printer cancels the target jobs as specified in [RFC2911]
Section 3.3.3 Cancel-Job which MAY leave a Retained Job with document data
on the Printer for possible re-processing (e.g., using the Reprocess-Job or
Resubmit-Job operations) and/or Job History.  

'true':   Default value[th5]  .  The Printer purges the target jobs as
specified in [RFC2911] Section 3.2.9 Purge-Jobs.  Note: If the client omits
this attribute or supplies the 'true' value, the behavior of the Purge-Jobs
operation is as specified in [RFC2911] for the target jobs.

The behavior for the Purge-Jobs operation for these two Operation attributes
for unprivileged users vs. operators and administrator of the Printer is
shown in Table 2.

Operation attributes

Unprivileged user

"my-jobs" = 'false' or omitted
"purge-jobs" = 'false'

Cancel only my jobs (Printer overrides "my-jobs" = 'false')

Cancel all jobs

"my-jobs" = 'true'
"purge-jobs" = 'false'

Cancel only my jobs

Cancel only my jobs

"my-jobs" = 'false' or omitted
"purge-jobs" = 'true' or omitted

Purge only my jobs (Printer overrides "my-jobs" = 'false')

Purge all jobs

"my-jobs" = 'true'
"purge-jobs" = 'true' or omitted

Purge only my jobs

Purge only my jobs

 -----Original Message-----
From:  <mailto:[email-masked]> [email-masked] [mailto:
<mailto:[email-masked]> [email-masked]] On Behalf Of Michael Sweet
Sent: Monday, September 14, 2009 14:41
To:  <mailto:[email-masked]> [email-masked]
Subject: [IPP] Descriptions of CUPS additions to the Cancel-Job and
Purge-Jobs operations

All,

Cancel Job Operation

the job as well.

Cancel-Job Request

Job request:

Semantics document.

OR

"job-uri":

"purge-job" (boolean):

 

Cancel-Job Response

Response:

Status Message:

Semantics document.

Purge-Jobs Operation

the jobs as well.

Purge-Jobs Request

Jobs request:

Semantics document.

"printer-uri" (uri):

     The client MUST supply a URI for the specified printer or
"ipp://.../printers 

"my-jobs" (boolean):

default is false.

"purge-jobs" (boolean):

true.

Purge-Jobs Response

Response:

Status Message:

Semantics document.

 __________________________________________________

-- 

believed to be clean.

ipp mailing list

[email-masked]

  _____  

One solution would be to only allow Purge-Jobs for operator or administrator
as in [RFC 2911].

 ISSUE: Instead of adding "my-jobs" and "purge-job" to Purge-Jobs, a simpler
way to allow an unprivileged  user to cancel all his jobs, instead of just a
specified job, would be to add "all-my-jobs" (boolean) Operation attribute
to the Cancel-Job operation.  When the client supplies this attribute with a
'true' value, the client MUST NOT supply a "job-id" or "job-url" Operation
attribute.

 ISSUE: The "purge-job" (boolean) Operation attribute has the 'true' value
here as its default.  Usually, it's the 'false' value that is the default.
More confusingly, the "purge-job" (boolean) Operation attribute (correctly)
has the 'false' value in the Cancel-Job operation above.

__________________________________________________

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: Michael Sweet <[email-masked]>
Date: Sat, 3 Oct 2009 20:34:30 -0700

That would be great if we *did* have a Cancel-Jobs operation; when you  
mentioned it I looked and wasn't able to find it - Cancel-Job and  
Cancel-Current-Job are all that I see...

On Oct 3, 2009, at 6:09 PM, Tom Hastings wrote:

> Good discussion.
>
> If Michael is willing to update CUPS (to support the old and  
> something new), another new alternative would be to add the  
> following Operation attribute to Cancel-Jobs:
>
>  “all-my-jobs” (boolean) with default ‘false’ to the Cancel-Jobs  
> operation
>
> instead of adding “cancel-jobs” (boolean) with default ‘false’ to  
> the Purge-Jobs operation.  Then we wouldn’t have an operation  
> attribute (“cancel-jobs”) which changes an one operation (Purge- 
> Jobs) into another operation (Cancel-Jobs).
>
> A variant on my alternative above which would allow the Operator/ 
> Administrator to be able to cancel all jobs (as is possible with  
> “which-jobs” (type2 keyword) with values:
> ‘specified-job’ – (default) the job specified by the supplied “job- 
> id” or “job-url”
> ‘all-my-jobs’ – cancel all my jobs
> ‘all-jobs’ – cancel all jobs;  If the Printer’s security policy does  
> not allow the authenticated user to cancel jobs for which the  
> requesting user is not the owner, then the IPP object MUST reject  
> the operation and return client-error-not-authorized
>
>
>
> operation attribute change the semantics of the operation to that of  
> another operation, how about also adding “job-id” (integer(1:MAX))  
> and “job-url” (URL) to the Purge-Jobs operation.  If either are  
> supplied, then the specified job is purged, rather than all jobs.   
> If the requesting user is NOT an Operator/Administrator AND the  
> specified job is NOT owned by the requesting user, then the IPP  
> object MUST reject the operation and return client-error-not- 
> authorized.
>
> Think about these alternative for the discussion at the IPP WG  
> telecon, this Monday, October 5, 1:00 PM PDT = 4:00 PM EDT.
>
> In the meantime, I’ll post the original CUPS approach rather than  
> making some of these discussed changes.
>
> Thanks,
> Tom
>
>
> Subject: Re: {Disarmed} Re: [IPP] Descriptions of CUPS additions to  
> the Cancel-Job and Purge-Jobs operations
>

---

From: "Tom Hastings" <[email-masked]>
Date: Sun, 04 Oct 2009 09:22:58 -0700

Michael,

My mistake in my email.  I meant to say Cancel-Job operation, not
Cancel-Jobs operation.  We don't have a Cancel-Jobs operation.  So I was
trying to suggest to either add "all-my-jobs" (boolean) or add "which-jobs"
(type2 keyword) Operation attribute to the existing Cancel-Job operation.

Tom

-----Original Message-----
From: Michael Sweet [mailto:[email-masked]] 
Sent: Saturday, October 03, 2009 20:35
To: [email-masked]
Cc: 'Ira McDonald'; [email-masked]
Subject: Re: {Disarmed} Re: [IPP] Descriptions of CUPS additions to the

On Oct 3, 2009, at 6:09 PM, Tom Hastings wrote:

> instead of adding "cancel-jobs" (boolean) with default 'false' to  
> the Purge-Jobs operation.  Then we wouldn't have an operation  
> attribute ("cancel-jobs") which changes an one operation (Purge- 
> 'specified-job' - (default) the job specified by the supplied "job- 
> id" or "job-url"
> 'all-jobs' - cancel all jobs;  If the Printer's security policy does  
> another operation, how about also adding "job-id" (integer(1:MAX))  
> and "job-url" (URL) to the Purge-Jobs operation.  If either are  
> In the meantime, I'll post the original CUPS approach rather than  
>> the 5 MS-WORD ISSUE comments intact and the table shown, I've also  
>> descriptions and the ISSUES as MS-WORD comments to:
obs_operations.doc 
>> ISSUE 3: Instead of adding "my-jobs" and "purge-job" to Purge-Jobs,  
>> instead of just a specified job, would be to add "all-my- 
>> jobs" (boolean) Operation attribute to the Cancel-Job operation.   
>> When the client supplies this attribute with a 'true' value, the  
>> client MUST NOT supply a "job-id" or "job-url" Operation attribute.
>>
>>
>> Jobs operation if the unprivileged client supplies the "my-jobs" =  
>> 'false' and return: client-error-forbidden, client-error-not- 
>> ISSUE 5: The "purge-job" (boolean) Operation attribute has the  
>> 'true' value here as its default.  Usually, it's the 'false' value  
>> that is the default.  More confusingly, the "purge-job" (boolean)  
>> Operation attribute (correctly) has the 'false' value in the Cancel- 
>> Job operation above.
>>
>>
>> I've included the text in the draft which I will post tomorrow for  
>> this Monday's IPP WG telecon, October 5, at 1:00 PM PDT = 4:00 PM  
>> The "purge-job" Operation attribute controls whether the specified  
>> 'false':  Default value.  The Printer cancels the specified job as  
>> 'false' value, the behavior of the Cancel-Job operation is as  
>> specified in [RFC2911].
>>
>> 'true':   If the authenticated user is the job owner of the job  
>> specified by the "job-id" or "job-uri" operation attribute or is a  
>> Purge-Jobs operation independent of the job's state, but only for  
> specified by the "job-id" or "job-uri" operation attribute matches)  
> the Purge-Jobs operation independent of the job's state, but only  
>> The "my-jobs" Operation attribute allows the client to request the  
>> 'true':   The target jobs are limited to those owned by the  
> The "purge-job" Operation attribute controls whether the target jobs  
> 'false':  The Printer cancels the target jobs as specified in  
> 'true':   Default value[th5]  .  The Printer purges the target jobs  
> client omits this attribute or supplies the 'true' value, the  
"ipp://.../printers
>  ISSUE: Instead of adding "my-jobs" and "purge-job" to Purge-Jobs, a  
> instead of just a specified job, would be to add "all-my- 
> jobs" (boolean) Operation attribute to the Cancel-Job operation.   
> When the client supplies this attribute with a 'true' value, the  
> client MUST NOT supply a "job-id" or "job-url" Operation attribute.
>
>  ISSUE: The "purge-job" (boolean) Operation attribute has the 'true'  
> value here as its default.  Usually, it's the 'false' value that is  
> the default.  More confusingly, the "purge-job" (boolean) Operation  
> attribute (correctly) has the 'false' value in the Cancel-Job  
> operation above.
>

---

From: "Tom Hastings" <[email-masked]>
Date: Mon, 05 Oct 2009 02:13:21 -0700

For our IPP WG telecon today, I'd like to consider two alternatives to
enhancing Cancel-Job and Purge-Jobs operations that are simpler to
understand than the ones we agreed to at the last IPP Telecon.  Alternative
1 does not quite provide all of the flexibility as CUPS:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Job-and-Purge-Jobs-alternative1-v6-2
0091004.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Job-and-Purge-Jobs-alternative1-v6-2
0091004.doc
<ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippprodprintext10-v6-20091004.pdf> 

while Alternative 2 does:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Job-and-Purge-Jobs-alternative2-v6-2
0091004.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Job-and-Purge-Jobs-alternative2-v6-2
0091004.doc

In order to make the comparison easier, I've also uploaded just the proposed
changes to Cancel-Job and Purge-Jobs as agreed to at the last IPP WG
telecon:

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Job-and-Purge-Jobs-additions-v6-2009
1004.pdf

ftp://ftp.pwg.org/pub/pwg/ipp/wd/Cancel-Job-and-Purge-Jobs-additions-v6-2009
1004.doc
<ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippprodprintext10-v6-20091004.pdf> 

Alternative 1 Summary

Alternative 1 includes the following functionality:

being able to cancel all my jobs, instead of just the specified job

being able to purge all my jobs, instead of just all jobs

If Michael is willing to update CUPS (to support the old and something new),
Alternative 1 would be to add only the following Operation attribute to
Cancel-Job:

 "all-my-jobs" (boolean) with default 'false'

instead of adding "cancel-jobs" (boolean) with default 'false' to the
Purge-Jobs operation.  Then we would NOT have an operation attribute
("cancel-jobs") which changes one operation (Purge-Jobs) into another
operation (Cancel-Job).   

Similarly, another new and simpler alternative to add only the following
Operation attribute to Purge-Jobs:

"my-jobs" (boolean) with default value 'false'.

instead of adding either "purge-jobs" (boolean) or "cancel-jobs" (boolean)
operation attribute to Purge-Jobs.  Then we would NOT have an operation
attribute ("cancel-jobs" or "purge-jobs") which changes one operation
(Purge-Jobs) into another operation (Cancel-Job).

Furthermore, I think that this alternative for Purge-Jobs is so simple that
we don't need the complicated table.

Alternative 2 Summary

This Alternative 2 is slightly more complicated than alternative 1, but gets
all of the functionality that the CUPS proposal includes:

being able to cancel all jobs or all my jobs, instead of just the specified
job

being able to purge a specified job or all my jobs, instead of just all
jobs.

If Michael is willing to update CUPS (to support the old and something new),
alternative 2 would be to add only the following Operation attribute to
Cancel-Job operation:

'specified-job' - (default) cancel the job specified by the supplied
"job-id" or "job-url"

'all-jobs' - cancel all jobs;  

If the Printer's security policy does not allow the authenticated user to
cancel jobs for which the requesting user is not the owner, then the IPP
object MUST reject the operation and return client-error-not-authorized

instead of adding "cancel-jobs" (boolean) with default 'false' to the
Purge-Jobs operation.  Then we would NOT have an operation attribute
("cancel-jobs") which changes one operation (Purge-Jobs) into another
operation (Cancel-Job).   

Similarly, alternative 2 to add the following 3 Operation attribute to
Purge-Jobs:

"job-id" (integer(1:MAX)) - specifies the job to be purged

"job-url" (url) - specifies the job to be purged

'specified-job' - purge the job specified by the supplied "job-id" or
"job-url"

'all-my-jobs' - purge all my jobs

'all-jobs' - (default) purges all jobs

If the Printer's security policy does not allow the authenticated user to
purge jobs for which the requesting user is not the owner, then the IPP
object MUST reject the operation and return client-error-not-authorized

instead of adding either "purge-jobs" (boolean) or "cancel-jobs" (boolean)
operation attribute to Purge-Jobs.  Then we would NOT have an operation
attribute ("cancel-jobs" or "purge-jobs") which changes one operation
(Purge-Jobs) into another operation (Cancel-Job).

Furthermore, I think that this alternative for Purge-Jobs is so simple that
we don't need the complicated table.

Tom

-----Original Message-----
From: Tom Hastings [mailto:[email-masked]] 
Sent: Sunday, October 04, 2009 09:23
To: 'Michael Sweet'; [email-masked]
Cc: 'Ira McDonald'; [email-masked]
Subject: RE: {Disarmed} Re: [IPP] Descriptions of CUPS additions to the

Michael,

Tom

-----Original Message-----

>  "all-my-jobs" (boolean) with default 'false' to the Cancel-Jobs  

> On Fri, Oct 2, 2009 at 11:53 AM, Michael Sweet <[email-masked]>  

> wrote:

obs_operations.doc 

>> Here is what I've come up with.  Comments and suggestions are  

>> welcome:

> Then move the table into 4.4, before the description of the  

> attributes.

"ipp://.../printers