Smith,
> On Aug 27, 2026, at 10:42 AM, Smith <smitty.standards at gmail.com> wrote:
>> I think specifically we are interested in the time span when the Printer is unreachable during the update process.
There is a disconnect in the state model for firmware resources between FWUPDATE and SYSTEM, namely that the SYSTEM "resource-state" attribute has states 'pending', 'available', 'installed', 'canceled', and 'aborted' while FWUPDATE uses "printer-state-reasons" keywords that (loosely) provide 'available', 'acquisition' (downloading), 'validation', 'installation', 'cleanup', and 'recovery'.
SYSTEM says nothing about Printer/System down time, and the only hint that an update will be installed is the 'install-requested' keyword for "resource-state-reasons".
The more I look at this the more I want to normalize the two documents so they agree with each other. FWUPDATE has gotten a lot more detailed about the states it reports but I don't know that that is either necessary or beneficial in the long term (i.e. we might be painting ourselves into a corner). Conversely, SYSTEM probably doesn't go far enough since it doesn't really talk about potential down time when installing a resource, nor about failed installs.
I'll follow up with some proposed changes after I have some time to sit with both documents open side-by-side.
> We have described how the client can be monitoring the status of the update process using normal IPP methods. But when the printer is unavailable on the network, the client just has to guess how long this is going to take. This attribute was intended to try to make it so that the guess would be less open ended.
I have no objection to this, but we are (to use an IETF expression) painting a bike shed.
IMHO "printer-new-firmware-SOMETHING-time" is the right naming and we can decide on what we want to call SOMETHING. 'restart' would be consistent with the existing operations we have for restarting Printer objects, and those Printers are unavailable during the shutdown/startup sequence. If the implementation requires no downtime ("less than 1 second") then the Printer can report 0.
> Along with this, we might want to add a “printer-state-reasons” keyword ‘restart-imminent’ to warn the client that the printer will be disappearing from the network.
In keeping with the existing reason keywords this should be called 'restarting'.
________________________
Michael Sweet