Hi Pete,
Structural changes from Nancy's original SM Resource Service:
(1) No longer any Resource Service
(2) All Resources are owned by the System
(3) Improved set of Resource-level operations (Create, SendResourceData,
Install are all REQUIRED before allocation of any Resource)
(4) New "resource-state" (pending, available, installed, canceled, aborted)
replaces dubious resource leases (my original lousy idea).
Printer-scope Resources can be allocated to more than one instance
of Print Service. We have avoided using the first-class verb "Associate"
to avoid confusion with security/access-control aspects.
A number of Resources can (usually will) be pre-installed on a System
at manufacturing time. These can be allocated with Create-Printer (with
the operation attribute "resource-ids"). Also later implicitly allocated
with
HTTP PUT request (per IPP Shared Infra Ext). But when an Admin has
later installed a bunch of new Resources (fonts, forms, ICC profiles), we
want to use a first-class operation to allocate them to specific Printers.
For this case "Acquire" is the wrong semantic and "Release" would be
overloaded (we have avoiding ever doing this in System Service drafts).
WDYT?
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 Mon, Oct 3, 2016 at 8:48 AM, Zehler, Peter <Peter.Zehler at xerox.com>
wrote:
> When it comes to resources that can be shared and are “owned” by another
> entity (i.e. Resource Service) I prefer “Acquire” and “Release”.
>>>> Peter Zehler
>> Xerox Corp.
> Global Development Group
> 800 Phillips Rd, 111-04A
> Webster NY, 14580-9701
> Email: Peter.Zehler at Xerox.com> Office: +1 (585) 265-8755
> Fax: +1 (585) 422-0238 <%2B1%20%28585%29%20265-8755>
> Mobile: +1 (585) 329-9508
>>>> *From:* ipp [mailto:ipp-bounces at pwg.org] *On Behalf Of *
>wamwagner at comcast.net> *Sent:* Monday, October 3, 2016 8:04 AM
> *To:* Ira McDonald <blueroofmusic at gmail.com>; ipp at pwg.org> *Subject:* Re: [IPP] Proposed System Service operations for Printers w/
> Resources
>>>> Ira,
>> ‘Allocate’ sounds good to me, especially since the resource may be shared.
>> Thanks,
>> Bill Wagner
>>>>>>>> *From: *Ira McDonald <blueroofmusic at gmail.com>
> *Sent: *Monday, October 3, 2016 7:15 AM
> *To: *ipp at pwg.org; Ira McDonald <blueroofmusic at gmail.com>
> *Subject: *[IPP] Proposed System Service operations for Printers w/
> Resources
>>>> Hi,
>> In my editor's draft of IPP System Service, I've added two new
>> operations for associating Resources with Printers (in addition
>> to the current methods of Create-Printer and HTTP PUT as
>> described in IPP Shared Infrastructure Extensions):
>> Allocate-Printer-Resources (printer-id, resource-ids)
>> Deallocate-Printer-Resources (printer-id, resource-ids)
>> Particularly for systems with multiple Print Service instances,
>> these would allow more flexible Resource management.
>> I propose the verb "Allocate" (as in memory allocation) rather
>> than "Assign" to avoid confusion with "output-device-assigned".
>> WDYT?
>> 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
>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161003/31d30a89/attachment.html>