[IPP] Slides to discuss feature compatibility topics for IPP EPX

[IPP] Slides to discuss feature compatibility topics for IPP EPX

Kennedy, Smith (Wireless & IPP Standards) smith.kennedy at hp.com
Thu Jun 4 18:52:00 UTC 2020


Hi Mike,


> -----Original Message-----
> From: Michael Sweet <msweet at msweet.org>
> Sent: Thursday, June 4, 2020 12:18 PM
> To: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>
> Cc: Jeremy Leber <jeremy.leber at lexmark.com>; PWG IPP Workgroup
> <ipp at pwg.org>
> Subject: Re: [IPP] Slides to discuss feature compatibility topics for IPP
> EPX
> 
> ... although we could add a 'job-copied' keyword for "job-state-reasons"
> to record whether a copy has been made.
> 
> 
> > On Jun 4, 2020, at 2:16 PM, Michael Sweet <msweet at msweet.org> wrote:
> >
> > Smith,
> >
> >> On Jun 4, 2020, at 2:04 PM, Kennedy, Smith (Wireless & IPP Standards)
> <smith.kennedy at hp.com> wrote:
> >> ...
> >>> Your question led me to wonder if there are “job accounting”
> attributes (Job Status attributes) that indicate that a Job is a copy of
> another Job to construct the audit trail?
> >>
> >> Not at present, although I do remember having a discussion about adding
> a "parent-job-id" attribute at some point for this very reason. It doesn't
> look like it actually made it into JPS2, so that might be something to
> consider adding for EPX. (and then parent-job-id and parent-job-uuid for
> "fun")
> >>
> >> [S.Kennedy] I’ll add “parent-job-id” and “parent-job-uuid” to EPX.
> Should the parent also have a Job Status attribute “copy-job-ids” and
> “copy-job-uuids”?
> >
> > No, that will make implementation a lot more difficult.  Just have the
> child jobs track their immediate parent and the Client can build a tree
> out of it as needed...
>
> ... although we could add a 'job-copied' keyword for "job-state-reasons"
> to record whether a copy has been made.
>

It might be more work to implement adding that, but it seems like that effort would be offset by the work of finding all of the child Jobs.

I started to wonder if "Get-Jobs" can accept a "job-state-reasons" attribute to request filtered results in the response. But if the set of terminal Jobs isn't that massive, the auditing and tree construction could all be done locally without repeated IPP operations. It might be worth discussing this in the "Job Accounting with IPP" once these attributes are defined in EPX.

(Perhaps "parent-job-uuid" ought to be defined in NODRIVER where "job-uuid" is defined?)


More information about the ipp mailing list