Subject: [IPP] What to remove from latest JPS2v2 draft to create first draft of "IPP Enterprise Printing Extensions"?

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Thu, 28 Feb 2019 21:29:03 +0000

Hi there,

As we just discussed in the IPP WG meeting today, I will take my latest JPS2v2 draft and start removing stuff to produce the first draft of "IPP Enterprise Printing Extensions". What should I remove from "IPP Enterprise Printing Extensions"?

To Be Removed
============================
- "job-save-disposition" and whatever we don't like about the "Job Save and Reprint" feature
- "proof-print" (because we are going to redefine how that works too since it has crossover with Job Storage)
- Stuff Mike is moving over to IPP Job Extensions v1.1 (Cancel-Jobs, Cancel-My-Jobs, some others)
- Deprecated or obsoleted operations and attributes

To Be Added
============================
- Smith's "job-storage" collection and related attributes (draft, to be debated)
- Smith's "job-print-password" and related attributes (draft, to be debated)
- Use case and requirements first drafts for the NextGen IPP Job Accounting solution (to replace "document-format-details" since that is now deprecated / obsoleted)

What else?

Smith

/**
    Smith Kennedy
    HP Inc.
*/

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 28 Feb 2019 17:17:50 -0500

Smith,

> On Feb 28, 2019, at 4:29 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked]> wrote:
> 
> Hi there,
> 

Agreed.

> - "proof-print" (because we are going to redefine how that works too since it has crossover with Job Storage)

I *thought* we weren't decided on this - the main issues brought up at the F2F were:

- There is no way to discard a proof print job, either explicitly or implicitly (i.e. how long is the job retained for?) - the "job-retain-until" Job Template attribute was a potential fix for this and the more general Job Storage use case.
- Today's Clients can just submit a new job with the same document data for the "production run"; whether this matches with enterprise/light production work flows is a question I'd like to answer.

IMHO we really just need to answer the second question before we decide proof-print's fate.

> - Stuff Mike is moving over to IPP Job Extensions v1.1 (Cancel-Jobs, Cancel-My-Jobs, some others)

Aside from the (REQUIRED) Cancel-Jobs, Cancel-My-Jobs, and Close-Job operations, I think I should move over the following (mostly OPTIONAL) attributes to Job Extensions v1.1:

- job-creation-attributes-supported
- job-hold-until-time/-supported
- job-ids/-supported (REQUIRED)
- job-spooling-supported
- media-col.media-tooth
- media-col.media-grain
- media-col.media-thickness
- media-col-database
- printer-detailed-status-messages
- which-jobs-supported

and the (OPTIONAL) keyword values for:

- pdl-override-supported
- which-jobs

and the amended semantics for Get-Printer-Attributes (media-col-database), Get-Jobs (which-jobs), Hold-Job (job-hold-until-time), and Set-Job-Attributes (job-hold-until-time).

These all have a clear focus on jobs and job submission/creation and are definitely not limited to the scope of Enterprise Printing.  There is a slight process issue we need to discuss, however: the new Job Extensions will have conformance requirements for required operations and attributes that were not in v1.0 of Job Extensions but *were* in v1.0 of JPS2 - the errata process doesn't allow us to change conformance requirements without going through PWG Last Call and Formal Vote, but then we are kindof merging JOBEXT and JPS2 into a single errata update and publishing a new Enterprise Printing specification with updated JPS2 content.  Fuzzy logic... :)

Anyways, since this constitutes all of the non-obsoleted/migrated content from JPS2, I'd prefer to update things in one shot rather than processing two documents.

(I'll also need to update the v1.1 version of IPP Everywhere for these attributes/operations)

> - Deprecated or obsoleted operations and attributes

IMHO, the following attributes should be obsoleted:

- feed-orientation/-default/-supported: Really bad way for Client to tell Printer which way the media is loaded; media-feed-orientation replaces it in JPS3...
- font-name-requested/-default/-supported: No sense specifying a font name when the size is useless, Unicode plain text printing often requires multiple fonts
- font-size-requested/-default/-supported: Font sizes in integer points are useless
- job-save-disposition/-default/-supported: Poorly specified, not interoperable
- pdl-init-file/-default/-supported: Poorly specified, not interoperable, too much focus on proprietary PDLs
- job-save-printer-make-and-model: Supports job-save-disposition
- max-save-info-supported: Supports job-save-disposition

and we can remove the "media-type" registrations since MSN2 imported them.

> - Use case and requirements first drafts for the NextGen IPP Job Accounting solution (to replace "document-format-details" since that is now deprecated / obsoleted)

- job-retain-until/-default/-supported (how long is job retained/stored?)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer