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

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

Michael Sweet msweet at apple.com
Sun Oct 4 03:34:30 UTC 2009


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  
> 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:msweet at apple.com]
> Sent: Friday, October 02, 2009 10:51
> To: Ira McDonald
> Cc: tom.hastings at alum.mit.edu; ipp at pwg.org
> 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.
>
> On Oct 2, 2009, at 10:24 AM, Ira McDonald wrote:
>
>
> 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: blueroofmusic at gmail.com
> 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 <msweet at apple.com>  
> wrote:
> 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: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of  
> Michael Sweet
> Sent: Monday, September 14, 2009 14:41
> To: ipp at pwg.org
> 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
> ipp at pwg.org
> 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
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
> ___________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>
>

___________________________________________________
Michael Sweet, Senior Printing System Engineer




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




More information about the ipp mailing list