Nope - existing attributes are fine. No changes needed.
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
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?
>> 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
> 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
> - 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 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.
>>>>>>>> > On Aug 27, 2017, at 10:34 AM, Ira McDonald <blueroofmusic at gmail.com>
>> > 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"),
>> > 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>
>> > Ira,
>> > > On Aug 25, 2017, at 6:32 PM, Ira McDonald <blueroofmusic at gmail.com>
>> > >
>> > > Hi Mike,
>> > >
>> > > For Create-Printer it's really nice to have a template-printer
>> > > 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
>> > > 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
>> > > 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...