Hi Ira,
Sorry for not replying sooner.
On Jul 24, 2024, at 7:29 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
CAUTION: External Email
Hi Smith,
All of this functionality has been defined in IPP System Service all along.
Firmware or application resources can be created and then installed for one
Printer or the whole System. Then either the single Printer or whole System
can be restarted to activate the new firmware or application software.
See sections 5.7, 6.1.1, 6.1.6, 6.2.4, 6.3.2, 6.3.13, and 6.3.17.
Unless I'm mistaken, these sections in System Service are useful if the client is managing the firmware update process directly by fetching the firmware update and pushing that update to the printer as a resource.
But if the Printer is capable of sending a firmware update query on its own to check availability and/or fetch and update itself, we don't seem to have any IPP attributes that can drive that. The "printer-firmware-update-version" and "printer-firmware-update-string-version" are intended to fill that gap. Mike suggested that we might define a new operation to cause the printer to fetch and update itself, and I think that is something we ought to investigate or at least discuss. This would compliment the existing facilities in System Service, and from a user experience and implementation perspective it would be easier for a Client to support this type of firmware update flow than the existing System Service supported process where it would need to download the firmware image / file to itself and then submit it to the printer. I think the existing System Service flow is likely more desirable for larger / enterprise deployments where a fleet might be upgraded using a common firmware image.
The "printer-firmware-update-uri" would provide a link directly to a firmware update page either in the printer or the manufacturer's website.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20240725/41285ebc/attachment.html>