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

From: Michael Sweet <[email-masked]>
Date: Mon, 14 Sep 2009 14:41:01 -0700

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

---

From: "Tom Hastings" <[email-masked]>
Date: Mon, 14 Sep 2009 15:51:28 -0700

Michael,

Thanks for posting.

I assume that Purge-Jobs doesn't work on all jobs, if the user isn't the
Operator.  As you mentioned on the phone it only purges your jobs, if you
aren't the operator.  But the behavior isn't in the text below.

RFC 2911 has the section:

   Access Rights: The authenticated user (see section 8.3) performing
   this operation [MUST] be an operator or administrator of the Printer
   object (see Sections 1 and 8.5).  Otherwise, the IPP object MUST
   reject the operation and return: client-error-forbidden, client-
   error-not-authenticated, and client-error-not-authorized as
   appropriate.

Presumably, the second sentence could be modified to something like either:

Otherwise, the IPP object MUST behave as if the user supplied the "my-jobs"
attribute with the 'true' value, no matter whether the client supplied the
"my-jobs" attribute.

OR

Otherwise, the IPP object MUST reject the operation and return:
client-error-forbidden, client-error-not-authenticated, and
client-error-not-authorized as appropriate, unless the client explicitly
supplied the "my-jobs" with a 'true' value (since the default value is
'false').

Since the IPP WG agreed today to add these ideas to the Set2 spec, I'd
appreciate feed back while I'm editing that.

Also I assume that the new "purge-job" (boolean) attribute will be OPTIONAL
for a Printer to support in our Set2 draft, since they are new attributes in
existing operations, right?

Tom

-----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,

Cancel Job Operation

Cancel-Job Request

"purge-job" (boolean):

Cancel-Job Response

Status Message:

Purge-Jobs Operation

Purge-Jobs Request

"printer-uri" (uri):
     The client MUST supply a URI for the specified printer or
"ipp://.../printers 
" for all printers and classes.

"my-jobs" (boolean):

"purge-jobs" (boolean):

Purge-Jobs Response

Status Message:

---

From: Michael Sweet <[email-masked]>
Date: Tue, 15 Sep 2009 13:08:53 -0700

> aren't the operator.  But the behavior isn't in the text below.

Right, the CUPS documentation isn't always up to the same levels of  
clarity as public specs...

> supplied the "my-jobs" with a 'true' value (since the default value is

The second version matches the current default behavior, although CUPS  
*does* offer a lot of configurability when it comes to policies like  
this.

> appreciate feed back while I'm editing that.

I'm more than happy to provide it! :)

> existing operations, right?

Right.  The new attributes, "purge-job" for the Cancel-Job operation  
and "purge-jobs" for the Purge-Jobs operation, are optional, just as  
my-jobs and requesting-user-name are optional.

---

From: "Tom Hastings" <[email-masked]>
Date: Wed, 30 Sep 2009 19:10:52 -0700

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.  

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.

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.

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-----

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):

"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]

  _____  

 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.