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 <msweet at msweet.org> wrote:
>> 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 <ipp at pwg.org> wrote:
> >
> > 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 <ipp at pwg.org> 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 "msweet at msweet.org" and I will summarize what I receive at the F2F.
> >>
> >> Thank you!
> >>
> >> ________________________
> >> Michael Sweet
> >>
> >>
> >>
> >> _______________________________________________
> >> ipp mailing list
> >> ipp at pwg.org> >> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> >
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org> > https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>> ________________________
> Michael Sweet
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20191023/d594fad7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20191023/d594fad7/attachment.sig>