Ira,
> 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 9.1.6.4 and lists the following values: "ready", "initializing", "on-request", "unavailable", "busy", "terminating", and "unknown".
"document-state" is defined in section 9.3.5.2 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