Subject: [IPP] New draft of IPP Presets posted; discussion needed on storing presets in Printer

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 22 Aug 2017 21:22:04 +0000

Greetings,

I have just posted a new draft of IPP Presets:

    https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822.pdf
    https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822.odt
    https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822-rev.pdf
    https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ipp-preset-20170822-rev.odt

Changes include:

• Extensively updated structure of section 4 “IPP Presets Definitions”
  ◦ Added section 4.2 to discuss storing presets using Set-Printer-Attributes
  ◦ Added section 4.3 (placeholder) to discuss storing presets as resources
• Added “Client Implementation Recommendations” section
• Added “Conformance Requirements” section
• Added “IANA and PWG Considerations” section

As you can see, there remains an open issue of how to best support a Client's ability to store presets in a Printer. Ira articulated in our last IPP WG meeting that there were precedent and protocol congruency issues with using Set-Printer-Attributes for doing this. If advocates for these competing methods could describe their particular perspectives, that would help to resolve this aspect of the Presets ecosystem.

Cheers,

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/

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

---

From: Michael Sweet <[email-masked]>
Date: Fri, 25 Aug 2017 14:28:14 -0400

Thanks Smith!

Some comments on the discussions about how to store presets and triggers:

1. Printer/server-side Presets should necessarily be managed by an operator or administrator and are NOT per-user - that's what Client-side presets are for.  So I do not agree with Ira about the operation for this - I think Set-Printer-Attributes is absolutely the right way to do this, just as we do for ICC profiles, metadata (location, organization, etc.), etc.

2. A Job (or Document) Template resource (as envisioned by PWG 5108.03: MFD Resource Service) resembles a Preset, but is not Client-friendly since there is no way for the Client to discover or retrieve the contents of the resource from the Printer (just the System).  Changing the "job-presets" attribute to be a "preset-name", "resource-id", and "resource-data-uri" (for the client to access the template) would allow the Client to discover and retrieve the contents but seems like a step in the wrong direction since it is more complicated, resource intensive, slower, etc.

Personally I would like to see us focus on using resources for things that cannot be expressed/encoded directly in IPP: forms, fonts, ICC profiles, logos/images, etc.  With that in mind, I'm thinking that we should drop the 'template-xxx' values for "resource-type" (no templates for documents, jobs, or printers) and just add a "resource-ids (1setOf integer(1:MAX))" member attribute to "job-presets" to instruct a Client to include the numbered resources in the Create-Job or Print-Job/URI operations for other types of resources.

> On Aug 22, 2017, at 5:22 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Greetings,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: Ira McDonald <[email-masked]>
Date: Fri, 25 Aug 2017 16:27:44 -0400

Hi Mike,

Fine - as long as End Users don't get to use Set-Printer-Attributes.

We really need to keep "template-job" Resources.  Xerox has implemented
them for 20 years in DPA-based production systems.  Others have done so.

The idea is that there's a NEW End User operation on a Printer called
Get-User-Resources that mirrors Get-Resources from System Service.

Having End Users push presets to Printers for use by other End Users
assumes the whole fine-grained access control policies of original IDS
work.  Too much new ground for too little benefit.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, Aug 25, 2017 at 2:28 PM, Michael Sweet <[email-masked]> wrote:

> 1. Printer/server-side Presets should necessarily be managed by an
> operator or administrator and are NOT per-user - that's what Client-side
> presets are for.  So I do not agree with Ira about the operation for this -
> I think Set-Printer-Attributes is absolutely the right way to do this, just
> as we do for ICC profiles, metadata (location, organization, etc.), etc.
>
> 2. A Job (or Document) Template resource (as envisioned by PWG 5108.03:
> MFD Resource Service) resembles a Preset, but is not Client-friendly since
> there is no way for the Client to discover or retrieve the contents of the
> resource from the Printer (just the System).  Changing the "job-presets"
> attribute to be a "preset-name", "resource-id", and "resource-data-uri"
> (for the client to access the template) would allow the Client to discover
> and retrieve the contents but seems like a step in the wrong direction
> since it is more complicated, resource intensive, slower, etc.
>
> Personally I would like to see us focus on using resources for things that
> cannot be expressed/encoded directly in IPP: forms, fonts, ICC profiles,
> logos/images, etc.  With that in mind, I'm thinking that we should drop the
> 'template-xxx' values for "resource-type" (no templates for documents,
> jobs, or printers) and just add a "resource-ids (1setOf integer(1:MAX))"
> member attribute to "job-presets" to instruct a Client to include the
> numbered resources in the Create-Job or Print-Job/URI operations for other
> types of resources.
>
>
> > As you can see, there remains an open issue of how to best support a
> Client's ability to store presets in a Printer. Ira articulated in our last
> IPP WG meeting that there were precedent and protocol congruency issues
> with using Set-Printer-Attributes for doing this. If advocates for these
> competing methods could describe their particular perspectives, that would
> help to resolve this aspect of the Presets ecosystem.
> >
> > Cheers,
> >
> > Smith
> >
> > /**
> >    Smith Kennedy

---

From: Michael Sweet <[email-masked]>
Date: Fri, 25 Aug 2017 17:20:56 -0400

Ira,

> On Aug 25, 2017, at 4:27 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 

Well, just because that is the way things have been done in the past by a single vendor doesn't mean we need to encourage future use of templates in the same form.

In IPP a template resource would be an IPP message containing the document, job, or printer attributes that would be used in a creation request.  A Client that used such a resource would need to:

1. Lookup Printer resources using a new Printer operation (which should probably be Get-Printer-Resources, not Get-User-Resources - the resources are associated with the Printer object, not with a User),

2. Present the user with a list of templates, which when selected either:
   a. Disable all of the user controls for the attributes; or
   b. Cause the Client software to download and decode the resource so that the individual controls can be set to match the template.

3. When the User submits the Job, either:
   a. Include the resource ID in the Job Creation request; or
   b. Include the individual attributes and values from the resource, including overrides by the User without specifying the resource ID in the Job Creation Request.

It's steps 2b and 3b that bother me the most - a lot of extra requests for little benefit.  And even if you decide to define the template resource as overlaying the default values for each attribute, with any other attributes in the creation request overriding the template, you make the Client either track differences from the template or send all of the attributes anyways.  And if the template resource is canceled before the Client's Job Creation request is accepted, the Job will fail in a way that will require the Client to do a lot of additional processing (is resource-ids in the unsupported attributes group?) or show a (questionable) error to the User, probably requiring them to cancel the print UI and try again...

Then there is the question of storing the template resources on the Printer - since resources are managed by the System you need to first create and install the resource on the System (three operations with authorization for the System) and then allocate the resource to the Printer (a fourth operation, this time authorized for the Printer).  How likely do you think it will be that the ACLs for that sequence of operations will be misconfigured?!?

I understand the reasons for wanting job/document/printer template resources.  But I question the need for such complexity in 2017, particularly when such templates introduce further exceptions without an obvious benefit over Presets.

> work.  Too much new ground for too little benefit.

Agreed.

---

From: Ira McDonald <[email-masked]>
Date: Fri, 25 Aug 2017 18:32:16 -0400

Hi Mike,

For Create-Printer it's really nice to have a template-printer Resource
for each supported service type.

I agree about the template-job (too heavyweight to configure).  But
we already plan that the HTTP PUT of a font to a well-known URL
will quietly create a corresponding Resource object for that font.
Why not do that simple HTTP PUT for job templates?

Pete's retired from PWG work or he'd be speaking up for Job Templates
(they're part (in XML at present) of PWG Job Ticket spec).  I think the
MIME type of a Job Template Resource should allow application/ipp
or text/xml.

Is even the simple HTTP PUT support too much for IPP native job
templates (i.e., wire-encoded IPP attributes, not PAPI or XML)?

Cheers,
- Ira

On Fri, Aug 25, 2017 at 5:20 PM, Michael Sweet <[email-masked]> wrote:

> Well, just because that is the way things have been done in the past by a
> single vendor doesn't mean we need to encourage future use of templates in
> the same form.
>
> In IPP a template resource would be an IPP message containing the
> document, job, or printer attributes that would be used in a creation
> request.  A Client that used such a resource would need to:
>
> 1. Lookup Printer resources using a new Printer operation (which should
> probably be Get-Printer-Resources, not Get-User-Resources - the resources
> are associated with the Printer object, not with a User),
>
>    b. Cause the Client software to download and decode the resource so
> that the individual controls can be set to match the template.
>
>    b. Include the individual attributes and values from the resource,
> including overrides by the User without specifying the resource ID in the
> Job Creation Request.
>
> It's steps 2b and 3b that bother me the most - a lot of extra requests for
> little benefit.  And even if you decide to define the template resource as
> overlaying the default values for each attribute, with any other attributes
> in the creation request overriding the template, you make the Client either
> track differences from the template or send all of the attributes anyways.
> And if the template resource is canceled before the Client's Job Creation
> request is accepted, the Job will fail in a way that will require the
> Client to do a lot of additional processing (is resource-ids in the
> unsupported attributes group?) or show a (questionable) error to the User,
> probably requiring them to cancel the print UI and try again...
>
> Then there is the question of storing the template resources on the
> Printer - since resources are managed by the System you need to first
> create and install the resource on the System (three operations with
> authorization for the System) and then allocate the resource to the Printer
> (a fourth operation, this time authorized for the Printer).  How likely do
> you think it will be that the ACLs for that sequence of operations will be
> misconfigured?!?
>
> I understand the reasons for wanting job/document/printer template
> resources.  But I question the need for such complexity in 2017,
> particularly when such templates introduce further exceptions without an
> obvious benefit over Presets.
>

---

From: Michael Sweet <[email-masked]>
Date: Sat, 26 Aug 2017 14:45:57 -0400

Ira,

> On Aug 25, 2017, at 6:32 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mike,
> 

Agreed, and for a sometimes-used admin operation with likely vendor extension attributes, I think it is appropriate.

I also think that we should define the semantics of template resources in general, i.e., the order of precedence used in creation operations:

    1. Attributes in request (highest)
    2. Attributes in resource
    3. Default attributes (lowest)

That makes it clear how a template resource is applied during a create request.

> Why not do that simple HTTP PUT for job templates?  

Well, while we do have HTTP PUT for creating and allocating Printer resources (as defined in IPP INFRA), that interface is also quite limited compared to using the Create-Resource operation since you cannot specify a "resource-name" different from the filename in the PUT.  So either the Printer has to pull the "resource-name" value from the file's metadata, e.g., the typeface name, and/or you use the "base name" from the URL, e.g., "http://printer.example.com/ipp/print/resources/Foo%20Bold.otf" has a "resource-name" value of 'Foo Bold'.

For IPP messages we'd be limited to using the base name approach, which means UTF-8 with percent escapes in the URL (ugh).

> MIME type of a Job Template Resource should allow application/ipp

*If* an implementation chose to support a PWG PJT (with whichever schema) we need to use a specific MIME media type for it, not just "text/xml".  Also, I believe IETF currently wants us to use application-scoped media types for this kind of thing, so that would probably mean registering "application/pwg-pjt+xml".

There is also the issue of schema versions - do we make that part of the media type (a parameter) that can be included in "resource-formats-supported" values?

> templates (i.e., wire-encoded IPP attributes, not PAPI or XML)?

The issue is how hard will it be for the Client to support them?  Doing N requests (Get-User/Printer-Resources + a bunch of HTTP GET requests) to get presets (which is all Job Template resources are) is inefficient and complicated compared to looking at a single collection attribute that is returned by the (common) Get-Printer-Attributes request that Clients already do.

I can also say we (Apple) are more likely to support the "job-presets" and "job-triggers" attributes than we are to support Job Template resources - philosophically they are better aligned with how presets and our internal trigger implementations work on macOS, and adding support for them will be easier (since we already have the interface for querying Printer attributes) than if we have to add additional code to query and pull resources.  And because there are fewer requests, the time to show the Print UI will remain low.

Many Printers also already support Set-Printer-Attributes, so I think adding support for a couple attributes will be easier than adding all of the resource infrastructure.

---

From: Ira McDonald <[email-masked]>
Date: Sun, 27 Aug 2017 12:34:12 -0400

Hi Mike,

Thanks - i agree with all your points.

Shoehorning presets into Resources would always be a bit strange.

Smith had (verbally) hoped to perhaps use Resources for finer-grained
access control (i.e., "this is a preset Resource for my user group"), but
even so, there's no getting around that End Users shouldn't be doing
the Printer configuration (by whatever operations), so pushing Client
side presets to Printers from End Users just doesn't work.

I agree with your explicit precedence of attributes for Create-Printer.

Pete's original thought about Job Template resources was that they
formed a neat alternative to a lot of pre-configured Printers (color,
double-sided, etc.).  I'll give this a bit more thought.

Cheers,
- Ira

On Sat, Aug 26, 2017 at 2:45 PM, Michael Sweet <[email-masked]> wrote:

> Agreed, and for a sometimes-used admin operation with likely vendor
> extension attributes, I think it is appropriate.
>
> I also think that we should define the semantics of template resources in
> general, i.e., the order of precedence used in creation operations:
>
> Well, while we do have HTTP PUT for creating and allocating Printer
> resources (as defined in IPP INFRA), that interface is also quite limited
> compared to using the Create-Resource operation since you cannot specify a
> "resource-name" different from the filename in the PUT.  So either the
> Printer has to pull the "resource-name" value from the file's metadata,
> e.g., the typeface name, and/or you use the "base name" from the URL, e.g.,
> "http://printer.example.com/ipp/print/resources/Foo%20Bold.otf" has a
> "resource-name" value of 'Foo Bold'.
>
> For IPP messages we'd be limited to using the base name approach, which
> means UTF-8 with percent escapes in the URL (ugh).
>
> *If* an implementation chose to support a PWG PJT (with whichever schema)
> we need to use a specific MIME media type for it, not just "text/xml".
> Also, I believe IETF currently wants us to use application-scoped media
> types for this kind of thing, so that would probably mean registering
> "application/pwg-pjt+xml".
>
> There is also the issue of schema versions - do we make that part of the
> media type (a parameter) that can be included in
> "resource-formats-supported" values?
>
> The issue is how hard will it be for the Client to support them?  Doing N
> requests (Get-User/Printer-Resources + a bunch of HTTP GET requests) to get
> presets (which is all Job Template resources are) is inefficient and
> complicated compared to looking at a single collection attribute that is
> returned by the (common) Get-Printer-Attributes request that Clients
> already do.
>
> I can also say we (Apple) are more likely to support the "job-presets" and
> "job-triggers" attributes than we are to support Job Template resources -
> philosophically they are better aligned with how presets and our internal
> trigger implementations work on macOS, and adding support for them will be
> easier (since we already have the interface for querying Printer
> attributes) than if we have to add additional code to query and pull
> resources.  And because there are fewer requests, the time to show the
> Print UI will remain low.
>
> Many Printers also already support Set-Printer-Attributes, so I think
> adding support for a couple attributes will be easier than adding all of
> the resource infrastructure.
>