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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp>>
--
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/ba76e3da/attachment-0001.html>