Subject: IPP> Restart-Job (bad) and Reprocess-Job (OK, but costly)

From: "Ira McDonald" <[email-masked]>
Date: Tue, 17 Jun 2008 13:33:13 -0400

Hi,

Per our discussion at yesterday's IPP WG telecon,
I looked up these two operations, just now:

Restart-Job - section 3.3.7 in RFC 2911
- MUST not change job-id - eek!
- moves job from completed state to pending
  or pending-held - violates state diagram
- BAD idea for accounting and security

Reprocess-Job - section 4.1 of RFC 3998
- MUST copy job attributes and create new Job
  with new job-id (returned in response)
- fixes the awful Restart-Job bugs

But, as we discussed yesterday, Reprocess-Job
means that the system (spooler or printer) must
keep all job attributes AND all job data for the
entire job history duration - costly and dubious.

Conclusions:

(1) We really should DEPRECATE Restart-Job
     in IPP/2.x Profiles and explain the rationale.

(2) Reprocess-Job is technically OK, but costly.
     Should remain OPTIONAL, even for IPP/2.2
     (Production Printing).

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

---

From: Michael R Sweet <[email-masked]>
Date: Tue, 17 Jun 2008 11:04:09 -0700

> - BAD idea for accounting and security

Not really - accounting can keep track of the job being printed
multiple times and keep the counts/quotas/etc. in sync.

As for security, it is no more or less secure than any other IPP
operation.

> entire job history duration - costly and dubious.

Keep in mind that the environments we are looking to make
it required already have large resources for this, so it
is not unreasonable to store the data and attributes.

Also, this can be a configurable option - CUPS, for example,
offers an option to determine whether job data is preserved
and how many jobs are preserved.  Future versions will offer
this as a per-printer and per-job option as well.

>      in IPP/2.x Profiles and explain the rationale.

Given that there is no other way to retry a failed print job,
I would be against complete deprecation but OK with
clarification or partial deprecation (i.e. OK to restart a
canceled, stopped, or aborted job, not OK to restart a
completed job...)

>      Should remain OPTIONAL, even for IPP/2.2

I would argue that production printing already requires large
resources to support things like document objects and the tight
integration with the print device, so Reprocess-Job should be
REQUIRED for IPP/2.2 and OPTIONAL for IPP/2.0 and IPP/2.1.

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer

---

From: "Ira McDonald" <[email-masked]>
Date: Tue, 17 Jun 2008 14:56:41 -0400

Hi Michael

************************************
On Tue, Jun 17, 2008 at 2:04 PM, Michael R Sweet <[email-masked]> wrote:

<snip>

    Conclusions:

<ira> Good point - I like keeping this operation ONLY
for use on unsuccessful jobs - but I think still OPTIONAL
in 2.1 (Enterprise), because of your stored resources
reasoning (below).
</ira>

<ira> I agree. </ira>

Cheers,
- Ira