Hi Smith,
Oops - yes Mike's point about Get-Printer-Supported-Values not
returning the locally added Presets is worth explicitly mentioning.
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/blueroofmusichttp://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 7:44 PM, Ira McDonald <blueroofmusic at gmail.com>
wrote:
> 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
> <(734)%20944-0094>
> May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
> <(906)%20494-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/1ebbcd3d/attachment.html>