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

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

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

Ira McDonald blueroofmusic at gmail.com
Wed Sep 6 23:44:46 UTC 2017


Hi Smith,

Nope - existing attributes are fine.  No changes needed.

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: blueroofmusic at gmail.com
Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434


On Wed, Sep 6, 2017 at 5:51 PM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:

> Would these attributes be any different then the attributes that are
> already defined in the current draft? Or does the Set-Printer-Attributes
> case necessitate the need to define additional attributes?
>
> Cheers,
> Smith
> ---
>
>    Smith Kennedy
>    Wireless Architect - Client Software - IPG-PPS
>    Standards - PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum
>    Chair, IEEE ISTO Printer Working Group
>    HP Inc.
>
>
> On Sep 6, 2017, at 11:45 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>
> Hi Smith,
>
> I agree with Mike that the Presets white paper should define the Printer
> attributes
> for persistent Presets that are configured by the Administrator (never by
> a User)
> using Set-Printer-Attributes and Presets should NOT be a subclass of
> template
> Resources.
>
> 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: blueroofmusic at gmail.com
> Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
> <(734)%20944-0094>
> May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434
> <(906)%20494-2434>
>
>
> On Wed, Sep 6, 2017 at 1:01 PM, Kennedy, Smith (Wireless Architect) <
> smith.kennedy at hp.com> wrote:
>
>> Thanks Ira and Mike for your discussion!
>>
>> In an attempt to bring this to a conclusion and get a stable draft
>> created for review, is your consensus that, for the Presets white paper,
>> that Set-Printer-Attributes is the method of choice? If so, then is the
>> section 4.2 in the latest draft (https://ftp.pwg.org/pub/pwg/i
>> pp/whitepaper/tb-ipp-preset-20170822.pdf) adequate or suitable? And that
>> would also indicate that we ought to remove section 4.3 that is a
>> placeholder for defining Preset resources.
>>
>> Or should the Presets white paper not define a way to push a Preset
>> definition back to the Printer? If so, then both 4.2 and 4.3 should get
>> chopped and the use case / out of scope sections need to be updated.
>>
>> Smith
>>
>>
>>
>> > On Aug 27, 2017, at 10:34 AM, Ira McDonald <blueroofmusic at gmail.com>
>> wrote:
>> >
>> > 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
>> >
>> >
>> > 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: blueroofmusic at gmail.com
>> > Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
>> > May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434
>> >
>> >
>> > On Sat, Aug 26, 2017 at 2:45 PM, Michael Sweet <msweet at apple.com>
>> wrote:
>> > Ira,
>> >
>> > > On Aug 25, 2017, at 6:32 PM, Ira McDonald <blueroofmusic at gmail.com>
>> wrote:
>> > >
>> > > Hi Mike,
>> > >
>> > > For Create-Printer it's really nice to have a template-printer
>> Resource
>> > > for each supported service type.
>> >
>> > 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.
>> >
>> > > 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?
>> >
>> > 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).
>> >
>> > > 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.
>> >
>> > *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?
>> >
>> > > Is even the simple HTTP PUT support too much for IPP native job
>> > > 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.
>> >
>> > _________________________________________________________
>> > Michael Sweet, Senior Printing System Engineer
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20170906/dd04b43b/attachment.html>


More information about the ipp mailing list