Subject: Re: [IPP] RFC: Job Accounting and Managed Printing Solutions

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Fri, 11 Oct 2019 18:35:17 +0000

Hi Mike,

Here are the Job Accounting fields that are important to HP Inc.:

Source application name
Source application version
Client operating system name
Client operating system version
Source document name(s)
Job UUID
Client host network identifier(s) (hostname, various addresses)
Client User identifiers (including qualifiers such as Windows Active Directory domain names)
Extensibility mechanism to handle ISV extensions

I believe all of these have pretty clear mappings to currently defined IPP Job Description or Job Status attributes, though the details may depend on the values held by these attributes having a particular content or structure.

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Sep 27, 2019, at 9:07 AM, Michael Sweet via ipp <[email-masked]> wrote:
> 
> All,
> 
> The IPP workgroup is working on a Best Practice document on job accounting and managed printing solutions and would like your help in identifying key functionality and data elements needed to support those solutions. The ultimate goal is to determine any gaps and have specifications and best practices in place to better support job accounting and managed printing through IPP, rather than depending on vendor MIBs and network protocols, which will allow all types of IPP clients to utilize these solutions seamlessly.
> 
> To this end, I am asking that any member that has a job accounting or managed printing solution to send me a list of data elements/attributes that your solution(s) depend on along with any special requirements or use cases that are addressed. Of particular importance is information that you currently gather outside of IPP since we want IPP to provide everything that is needed. All solution-specific information can be kept confidential if necessary - I will be using it to identify any deficiencies that need to be addressed in IPP or common use cases that should be highlighted in our Best Practice document.
> 
> Also, I would be very interested to know whether your solutions use IPP or some other protocol(s), and the reasons for doing so - again so that we can make sure that IPP can satisfy as many printing requirements and use cases as possible.
> 
> We plan to next discuss this topic at the November 2019 Face-to-Face, and your participation in this effort would be greatly appreciated! Please send all information to "[email-masked]" and I will summarize what I receive at the F2F.
> 
> Thank you!
> 
> ________________________
> Michael Sweet
> 
> 
> 
> _______________________________________________
> ipp mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet via ipp <[email-masked]>
Date: Tue, 22 Oct 2019 08:55:07 -0400

Smith,

It would be extremely useful to know *why* you collect each of these data items - what is the use case, how is the information used, etc?

> On Oct 11, 2019, at 2:35 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked]> wrote:
> 
> Hi Mike,
> 
> 	• Source application name
> 	• Source application version
> 	• Client operating system name
> 	• Client operating system version
> 	• Source document name(s)
> 	• Job UUID
> 	• Client host network identifier(s) (hostname, various addresses)
> 	• Client User identifiers (including qualifiers such as Windows Active Directory domain names)
> 	• Extensibility mechanism to handle ISV extensions
> 

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Wed, 23 Oct 2019 17:43:49 +0000

Hi Mike,

How those elements of information are used depends on the solution that is taking advantage of it. They fall under at least one of the abstract use cases in the whitepaper. Here are the job accounting data items HP Inc. requested previously, labeled with letters for later reference:

A. Source application name
B. Source application version
C. Client operating system name
D. Client operating system version
E. Source document name(s)
F. Job UUID
G. Client host network identifier(s) (hostname, various addresses)
H. Client User identifiers (including qualifiers)
I. Extensibility mechanism to handle ISV extensions

I'm also adding a new one:

J. Source document type or format (e.g. MIME media type)

Using the use case titles from the updated draft you posted today, here are the fields that apply to each use case:

3.1.1 Auditing of Printing Usage: A, B, C, D, E?, F, G, H, I, J?

3.1.2 Auditing of Print Content: A, B, C, D, E, F, G, H, I?, J?

3.1.3 Billing: F, G, H, I?

3.1.4 Diagnostics and Debugging: A, B, C, D, E, F, G, H, I, J

3.1.5 Supplying Required Information: F, G?, H, I

3.1.6 Supplying Optional Information: A, B, C, D, F, G?, H?, I?

There are also some systems that use these "Job Accounting" data items, along with user authentication, as a way of limiting features that are available to users. For instance, we have customers that set up a system where certain users can only print in color from certain applications, and they base the processing alternatives on the values provided with the Job. Although I think we should be promoting Get-User-Printer-Attributes for this because it provides a superior user experience, this is another way that these data items are employed.

One other thing we may want to consider is adding an additional authentication identity or encryption key for the job accounting attributes that are sensitive. In some accounting systems, the job accounting information is not sent in-band with the Job by the driver chain to the printer, but is instead reported to a separate collection service by an agent on the client system. The security model is interesting because the accounting agent is running as an administrator user and authenticating using separate credentials. Basically, if the device itself is trusted to not be compromised, then the information is assumed to be trustable. This is a little different from the in-band job accounting communications topology we are articulating in the PWG, where the job accounting info is reported as job metadata and the job is submitted using a communications channel authorized using end-user authentication credentials, if the channel is authorized at all.

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Oct 22, 2019, at 6:55 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 24 Oct 2019 11:30:29 -0400

Smith,

> On Oct 23, 2019, at 1:43 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> ...

I think it is worth talking about this in the Job Accounting document, although I will note that currently Apple does not support Get-User-Printer-Attributes for some (unfortunately hard) architectural/security issues.  Therefore, such policies need to be supported via a two-prong approach: Get-User-Printer-Attributes to provide the per-user capabilities, and Validate-Job/Create-Job/Print-Job/Print-URI enforcement/substitution for unsupported values.

> One other thing we may want to consider is adding an additional authentication identity or encryption key for the job accounting attributes that are sensitive.

This is where the Encrypted Jobs and Documents specification comes in, I think.  In the interests of getting something deployed sooner, I would like to defer adding any discussion of this in the Job Accounting document until we have published that specification, which will likely mean a Job Accounting v1.1 or v2.0 BP in 2021...

> In some accounting systems, the job accounting information is not sent in-band with the Job by the driver chain to the printer, but is instead reported to a separate collection service by an agent on the client system. The security model is interesting because the accounting agent is running as an administrator user and authenticating using separate credentials. Basically, if the device itself is trusted to not be compromised, then the information is assumed to be trustable. This is a little different from the in-band job accounting communications topology we are articulating in the PWG, where the job accounting info is reported as job metadata and the job is submitted using a communications channel authorized using end-user authentication credentials, if the channel is authorized at all.

That is something we should mention in v1.0, with the goal of providing a direct IPP interface (probably in Encrypted Jobs and Documents) to replace these custom solutions.

(but let's make sure not to confuse an accounting solution that is bolted to the side of an OS printing system with a "native" IPP print service that provides accounting)

________________________
Michael Sweet