attachment

<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi Mike,<br><br></div>Further thoughts about "resource-printer-id" and "resource-job-id".<br></div><br>Delete them.  Several Printers and/or Jobs could need a Resource<br></div>(and would have a pointer to indicate that), but the Resource should<br></div>NOT have pointers.  That is, all Resources are (as we agreed) of<br></div>System scope and can only be managed (or state affected) by the<br></div>System Service.<br><br></div>WDYT?<br><br></div>Cheers,<br></div>- Ira<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094<br>May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Sep 6, 2016 at 7:05 PM, Ira McDonald <span dir="ltr"><<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Mike,<br><br></div>I understand your reservations about 'created' (although it's a proper <br></div>ISO 10175 state that was perhaps erroneously omitted in IPP/1.1).<br><br></div>I have STRONG reservations about easily misinterpreted compound<br></div>state names like 'pending-install'<br><br></div>I've been working on the spec for two days for a release (I hope) later<br></div>this week.<br><br></div>I could live with these values of "resource-state":<br><br></div>'pending' - result of Create-Resource<br><br></div>'available' - result of Send-Resource-Data OR keep 'pending' and<br></div>set 'resource-incoming' in "resource-state-reasons" (if delayed)</div><br>'installed' - result of Install-Resource OR keep 'available' and <br></div>set 'install-requested' in "resource-state-reasons" (if delayed)<br><br></div>'canceled' - result of Cancel-Resource OR keep 'installed' and<br>set 'cancel-requested' in "resource-state-reasons" (if delayed)<br><br></div>'aborted' - result of System decision after any failure of<br></div>Send-Resource-Data or Install-Resource (or their delayed<br></div>completion<br><br></div><div>Primary state transitions should NEVER occur until the work<br></div><div>is finished (e.g., delayed install due to wait-for-reboot) - they<br></div><div>should be correctly foreshadowed by state reasons (as above).<br></div><div><br></div>I've added Resource History phase and written the 300 seconds<br></div>minimum duration stuff (I still can't find the IETF or PWG spec<br></div>where we put this for Job History, but I clearly remember this<br></div>discussion a long time ago with Pete Zehler).<br><br></div>I'll happily abandon Send-Resource-URI, but I point out that this<br></div>means that many Resources cannot be installed by a limited<br></div>capacity mobile phone (e.g., licensed fonts are typically on a<br></div>managed server before installation on a printer or app server).<br><br></div>There is a problem with having the Job specify "resource-ids"<br></div>for previously installed Resources, to whit, the scope of the<br></div>Resource (new value of "resource-job-id") changes AFTER the<br></div>Resource is created.  How then would the System know to <br></div>automatically cancel the Resource after the Job completes?<br></div>Instead, I imagined submitting the the Job into 'pending-held',<br></div>creating/uploading/installing any single-Job-scope Resources<br></div>with proper values of "resource-job-id".  Please puzzle this one<br></div>out a bit more.  I suppose/presume there's a similar ambiguity<br></div>for a Printer-scope Resource?<br><br></div>BTW - Although I reorganized section 6 into subsections for<br></div>Printer, Resource, System, and Subscription operations, this<br></div>made a thorough mess of all the cross-references to section 6<br></div>(not to be fixed up in this next draft, probably - I'm trying to get<br></div>at least something in for all the model comments from the F2F).<br><br></div>Cheers,<br></div>- Ira<br><br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><span class=""><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/<wbr>blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/<wbr>highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Jan-April: 579 Park Place  Saline, MI  48176  <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>May-Dec: PO Box 221  Grand Marais, MI 49839  <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">On Tue, Sep 6, 2016 at 4:49 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ira,<br>
<span><br>
> On Aug 31, 2016, at 5:50 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:<br>
><br>
> Hi Mike,<br>
><br>
> Apologies for late response.  Been a busy week.<br>
><br>
> I like most all of this except for two state names, because they're<br>
> obscure.  The Job state 'pending' has fuzzy applicability here.<br>
><br>
> I suggest states/state reasons:<br>
><br>
> 'created' - result of Create-Resource<br>
<br>
</span>I prefer overloading 'pending' with the 'resource-incomplete' and 'resource-incoming' state-reasons - first, it keeps things consistent/familiar with Jobs and Documents, and second because we've never had a "created but not ready" state anywhere else in the model - that's always been a state-reason, not a first class state.<br>
<span><br>
> 'uploaded' - result of Send-Resource-Data, except when Resource<br>
> stays 'created' w/ state reason 'resource-incoming' (like job-incoming<br>
> in RFC 2911)<br>
<br>
</span>I'm not keen on 'uploaded' since the name can be easily misunderstood (the client uploaded the resource, the system/printer did not, it received it...)<br>
<br>
Maybe 'available' (one of the previous names we used) instead?  Or just use the 'pending' state with 'resource-available' in the state-reasons (instead of 'none')?<br>
<span><br>
> 'installed' - result of Install-Resource, except when Resource<br>
> stays 'uploaded' w/ state reason 'resource-installed'<br>
<br>
</span>I'm not keen on 'resource-installed' as a state-reason indicating that a request to install the resource has been received.  It sounds more like the resource *has* been installed, which would be incorrect.<br>
<span><br>
> 'canceled' - result of Cancel-Resource, except when Resource<br>
> stays 'created/loaded/installed' w/ state reason 'resource-canceled'<br>
<br>
</span>I also think 'aborted' is important to reflect when a resource is canceled by the System, just as we do for Jobs and Documents.<br>
<span><br>
> 'pending-install' meaning "pending but NOT installed" is not symmetric<br>
> with 'pending-held' meaning "pending AND held"<br>
<br>
</span>Perhaps, but for event notifications (and general implementation of resource updates that need a reboot) I think it is important to be able to track a state for resources that need to be installed after a reboot/power cycle.<br>
<br>
Also, pending-install could be more akin to processing-stopped than pending-held.<br>
<br>
pending -> pending-install -> installed -> canceled   (firmware update - reboot needed)<br>
pending --------------------> installed -> canceled   (application update - no reboot needed)<br>
pending ------------------------------<wbr>---> canceled   (resource created but canceled by client without installing)<br>
pending ------------------------------<wbr>---> aborted    (resource created but aborted by system due to errors)<br>
<br>
> ...<br>
<span>> PS - Reasoning behind the 'uploaded' state name is potential<br>
> first class Admin operation Send-Resource-URI (for local domain<br>
> authenticated Resource upload by reference rather than value).<br>
</span>> ...<br>
<br>
Ugh, please let's not go down that path.  We have basically no real world usage of Print-URI/Send-URI for printing after 16 years.  Even assuming that a managed network would allow a printer to make an outgoing connection at all, allowing a client to point a printer at a URL for a firmware update seems like a recipe for disaster.<br>
<div><div><br>
<br>
<br>
> On Wed, Aug 24, 2016 at 6:07 PM, Michael Sweet <<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>> wrote:<br>
> All,<br>
><br>
> The following outline summarizes how I see the IPP Resource object working in the System Service specification. Feedback welcome, and we can discuss this at the next regular IPP conference call (Sept 19).<br>
><br>
> TL;DR summary: Resource states are 'pending', 'pending-install', 'installed', 'aborted', and 'canceled'. No more "resource-category" attribute. State reasons and status codes for resource format and security errors.<br>
><br>
> ........<br>
><br>
> IPP Resource Object<br>
><br>
> IPP Resource objects contain metadata and associated firmware, software, templates, and other static data files.  Resource objects have a simple life cycle: creation, installation, history, and deletion.  Resource objects can be listed (Get-Resources) or queried (Get-Resource-Attributes) until they are deleted by the System.<br>
><br>
><br>
>            Table N - IPP Resource Object Operations and Life Cycle<br>
><br>
>     Operation                resource-state         resource-state-reasons<br>
>     -----------------------  ---------------------  ----------------------<br>
>     Create-Resource          'pending' (3)          'resource-incomplete'<br>
><br>
>     Send-Resource-Data       'pending' (3)          'none'<br>
>                                    OR<br>
>                              'aborted' (8)          'resource-xxx-error'<br>
><br>
>     Install-Resource         'pending-install' (4)  'none'<br>
>                                    OR<br>
>                              'installed' (5)        'none'<br>
>                                    OR<br>
>                              'aborted' (8)          'resource-xxx-error'<br>
><br>
>     Cancel-Resource          'canceled' (7)         'none'<br>
>                                    OR<br>
>                              'installed' (5)        'none'<br>
><br>
>     Get-Resources            All States             All Reasons<br>
>     Get-Resource-Attributes  All States             All Reasons<br>
><br>
><br>
> Resource Creation Phase<br>
><br>
> Resources are created using the Create-Resource operation which creates the object and the Send-Resource-Data operation which provides the data for the resource. The state during creation is 'pending' (3). The state after creation is either 'pending' or 'aborted' (8) if the resource data contains errors or if the Send-Resource-Data operation is not done quickly enough.<br>
><br>
><br>
> Resource Installation Phase<br>
><br>
> Resources are installed using the Install-Resource operation. The state after installation is either 'pending-install' (4) if the Resource data must be installed after a reboot, 'installed' (5) if the Resource data can be installed immediately, or 'aborted' if the Resource data contains errors and cannot be installed.<br>
><br>
><br>
> Resource History Phase<br>
><br>
> Resources in the history phase of their life cycle are in the 'canceled' or 'aborted' states.<br>
><br>
> Resources are aborted by the System when it determines the Resource data contains errors, is missing, or has been replaced.<br>
><br>
> Resources are canceled using the Cancel-Resource operation. That state after cancellation is 'canceled' (7) unless the Resource cannot be canceled, such as running firmware that must be replaced before it can be canceled.<br>
><br>
> Systems delete Resource data when placing a Resource in the 'canceled' or 'aborted' state. Historical resources MUST be retained in these states for at least 300 seconds before deletion of the Resource object by the System service.<br>
><br>
><br>
> Resource Status Attributes<br>
><br>
>     date-time-at-creation (dateTime)<br>
>     date-time-at-history (dateTime)<br>
>     date-time-at-installed (dateTime)<br>
>     resource-data-uri (uri | no-value)<br>
>     resource-format (mimeMediaType)<br>
>     resource-id (integer(1:MAX))<br>
>     resource-job-id (integer(1:MAX))<br>
>     resource-k-octets (integer(0:MAX))<br>
>     resource-printer-id (integer(1:MAX))<br>
>     resource-state (type1 enum)<br>
>     resource-state-message (text(MAX))<br>
>     resource-state-reasons (1setOf type2 keyword)<br>
>     resource-string-version (text(MAX))<br>
>     resource-type (type2 keyword)<br>
>     resource-uuid (uri)<br>
>     time-at-creation (integer(MIN:MAX))<br>
>     time-at-history (integer(MIN:MAX))<br>
>     time-at-installed (integer(MIN:MAX))<br>
><br>
><br>
> Resource Description Attributes:<br>
><br>
>     resource-info (name(MAX))<br>
>     resource-name (name(MAX))<br>
>     resource-owner-col (collection)<br>
>       owner-uri (uri)<br>
>       owner-vcard (1setOf text(MAX))<br>
><br>
><br>
> "resource-state" values:<br>
><br>
>     - 3 ('pending'): state after creation but before installation<br>
>     - 4 ('pending-install'): state after install for resources that require a reboot<br>
>     - 5 ('installed'): state when a resource is installed<br>
>     - 7 ('canceled'): state when a resource has been canceled by Cancel-Resource operation<br>
>     - 8 ('aborted'): state when a resource has been canceled by System service (bad resource, etc.)<br>
><br>
><br>
> "resource-state-reasons" values:<br>
><br>
>     - 'none': No additional state.<br>
>     - 'resource-format-error': The Resource data contains format errors.<br>
>     - 'resource-incomplete': The Resource object has been created but no data has been sent.<br>
>     - 'resource-security-error': The Resource data's digital signature or other security features could not be verified.<br>
>     - 'resource-timeout': The Resource was not installed within the multiple-operation-time-out period.<br>
><br>
> "resource-type" values:<br>
><br>
>     - 'document': Template for creating Document object.<br>
>     - 'firmware': Executable firmware (reboot generally required).<br>
>     - 'font': Static font.<br>
>     - 'icc-profile': Static ICC profile.<br>
>     - 'image': Static image (icon, logo, etc.)<br>
>     - 'job': Template for creating Job object.<br>
>     - 'software': Executable software/application (reboot generally not required).<br>
>     - 'strings': Static message catalog (strings file).<br>
><br>
> "status-code" values (and operations that can return them):<br>
><br>
>     - 'successful-ok': All<br>
>     - 'client-error-bad-request': All<br>
>     - 'client-error-forbidden': All<br>
>     - 'client-error-not-authenticate<wbr>d': All<br>
>     - 'client-error-not-authorized': All<br>
>     - 'client-error-not-found': Cancel-Resource<br>
>     - 'client-error-request-entity-t<wbr>oo-large': Send-Resource-Data<br>
>     - 'client-error-document-format-<wbr>not-supported': Send-Resource-Data<br>
>     - 'client-error-attributes-or-va<wbr>lues-not-supported': Create-Resource<br>
>     - 'client-error-charset-not-supp<wbr>orted': All<br>
>     - 'client-error-conflicting-attr<wbr>ibutes': Create-Resource<br>
>     - 'client-error-document-securit<wbr>y-error': Send-Resource-Data, Install-Resource<br>
>     - 'server-error-internal-error': All<br>
>     - 'server-error-busy': Cancel-Resource, Create-Resource, Send-Resource-Data<br>
>     - (NEW) 'server-error-too-many-resourc<wbr>es': Create-Resource<br>
><br>
> ______________________________<wbr>___________________________<br>
> Michael Sweet, Senior Printing System Engineer<br>
><br>
> ______________________________<wbr>_________________<br>
> ipp mailing list<br>
> <a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
> <a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank">https://www.pwg.org/mailman/li<wbr>stinfo/ipp</a><br>
><br>
<br>
______________________________<wbr>___________________________<br>
Michael Sweet, Senior Printing System Engineer<br>
<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>