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/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 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/> ipp/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/3a10248b/attachment.html>