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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20091002/4e18068a/attachment-0001.html>