[IPP] Outline of IPP Resource Object for System Service Spec

[IPP] Outline of IPP Resource Object for System Service Spec

[IPP] Outline of IPP Resource Object for System Service Spec

Michael Sweet msweet at apple.com
Fri Sep 9 16:00:04 UTC 2016


> On Sep 6, 2016, at 7:05 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> Hi Mike,
> I understand your reservations about 'created' (although it's a proper 
> ISO 10175 state that was perhaps erroneously omitted in IPP/1.1).

I'm looking at 10175 right now...  The table of attributes for the Document object in section 9.8 lists the generic "state" and a more specific "document-state".

"state" is defined in section and lists the following values: "ready", "initializing", "on-request", "unavailable", "busy", "terminating", and "unknown".

"document-state" is defined in section and lists the following values: "transfer-pending", "pending", "processing", "printing", and "completed".

I don't see 'created' as a state.

> I have STRONG reservations about easily misinterpreted compound
> state names like 'pending-install'
> I've been working on the spec for two days for a release (I hope) later
> this week.
> I could live with these values of "resource-state":
> 'pending' - result of Create-Resource
> 'available' - result of Send-Resource-Data OR keep 'pending' and
> set 'resource-incoming' in "resource-state-reasons" (if delayed)
> 'installed' - result of Install-Resource OR keep 'available' and 
> set 'install-requested' in "resource-state-reasons" (if delayed)
> 'canceled' - result of Cancel-Resource OR keep 'installed' and
> set 'cancel-requested' in "resource-state-reasons" (if delayed)
> 'aborted' - result of System decision after any failure of
> Send-Resource-Data or Install-Resource (or their delayed
> completion
> Primary state transitions should NEVER occur until the work
> is finished (e.g., delayed install due to wait-for-reboot) - they
> should be correctly foreshadowed by state reasons (as above).

I'm fine with this.

> I've added Resource History phase and written the 300 seconds
> minimum duration stuff (I still can't find the IETF or PWG spec
> where we put this for Job History, but I clearly remember this
> discussion a long time ago with Pete Zehler).
> I'll happily abandon Send-Resource-URI, but I point out that this
> means that many Resources cannot be installed by a limited
> capacity mobile phone (e.g., licensed fonts are typically on a
> managed server before installation on a printer or app server).

I'll point out that mobile phones are not typically primary management devices.  But if somebody did choose to use a mobile phone for this, said phone will likely have multiple gigabytes of storage available and regardless will be perfectly capable of streaming content from a trusted server to the local printer via Send-Resource-Data, using authentication and policy information available only on said phone.  And said phone is far more likely to have current security updates installed than said printer.

> There is a problem with having the Job specify "resource-ids"
> for previously installed Resources, to whit, the scope of the
> Resource (new value of "resource-job-id") changes AFTER the
> Resource is created. How then would the System know to 

> automatically cancel the Resource after the Job completes?

I think since we decided not to allow Resources to be created by ordinary users for a Job, we no longer have Job-scoped resources.  Resources specified in a Job Creation request (via the "resource-ids" operation attribute) naturally must be retained for the life of the Job, but that can be implemented fairly simply (reference counts, etc.)

> Instead, I imagined submitting the the Job into 'pending-held',
> creating/uploading/installing any single-Job-scope Resources
> with proper values of "resource-job-id".  Please puzzle this one
> out a bit more.  I suppose/presume there's a similar ambiguity
> for a Printer-scope Resource?

I don't think we do, since Printer Resource creation is an administrative operation and not a user operation.

Michael Sweet, Senior Printing System Engineer

More information about the ipp mailing list