Hi Smith,
Thank you for your response to my comments which, as I had acknowledged, were outside of things to be specified, and if noted at all, might be under "Implementation Considerations". They are things that, as a potential user, I would be concerned about; but I fully understand that they deal with aspects that go beyond the scope and may not be appropriate in a protocol specification. I have no objection to not addressing them in the spec. Comments below.
1. Yes, information of and about the new firmware will be available via IPP. And I think the idea that "printer-new-firmware-support-uri" could point to release notes is very useful. But my concern is that my printer will start behaving differently one day, and I will have no idea that the firmware has changed. It would be helpful if there were a message on the screen, a lit light, a printer message, something apparent to tell me it has new firmware before I go looking for other problems.
2. Indeed, retries, or indeed what prompts initial attempts may be inappropriate in an IPP Spec. My concern is not for the completeness of the spec, but for a user. I envision a printer out of service because it is repeatedly trying to update and failing; or alternatively of no one aware that it does not have critical new firmware.
3. Again, issues with the implementation of providing new firmware, not the protocol. It is an old fashioned idea that a user may want to know what is happening with his equipment, that something is causing security concerns or maybe just doing a DoS attack.
4. That is the expected behavior, but is it reasonable to assumed that things will be implemented as expected?
Again, thank you for considering my concerns. I took the query for Implementation Considerations a bit further than intended.
Bill Wagner
________________________________
From: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>
Sent: Tuesday, June 30, 2026 5:52 PM
To: wamwagner at comcast.net <wamwagner at comcast.net>; PWG IPP WG Reflector <ipp at pwg.org>
Subject: Re: IPP Firmware Update Extensions v1.0 - recommendations for "Security and Privacy" and "Implementation Considerations" sections
Hi Bill,
Replies inline below in red.
Smith
From: wamwagner at comcast.net <wamwagner at comcast.net>
Date: Monday, May 25, 2026 at 2:50 PM
To: PWG IPP WG Reflector <ipp at pwg.org>
Cc: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>
Subject: Re: IPP Firmware Update Extensions v1.0 - recommendations for "Security and Privacy" and "Implementation Considerations" sections
CAUTION: External Email
Smith et al,
There are some things that perhaps cannot be specified, but might be appropriate under implementation considerations. These reflect my apprehension with regard to machines doing their own thing, and might not be considered necessary by others, but suggest the following:
1.
If the new firmware update is successful, there should be some clear indication that a device has firmware and some way a user can get some information about the new firmware. [I have had successful computer updates that have, perhaps inadvertently, affected functionality. ]
If the new firmware was installed successfully, then PWG 5100.13 defines the "printer-firmware-xxx" attributes that will hold the values for the currently installed firmware, which will have been recently updated. In our IPP Firmware Update Extensions v1.0 draft there is a "printer-new-firmware-support-uri" which could point to release notes. Perhaps we should also define a "printer-firmware-support-uri" so that the currently installed firmware's release notes / support info continues to be available?
1.
If a new firmware update fails because of transmission problems or errors, the device can clear itself and retry, but for only a limited number of times, after which there should be an indication to the user that new firmware update attempt failed because of download problems. The user may have the option of allowing an automatic reattempt or initiating a reattempt (perhaps after resolving communication issues.) In either case the device should resume normal operation with the previous un-updated firmware.
Why is there only a limited number of times? Do you mean it might be silently retrying to download before giving up?
I think the current proposal treats retries as an implementation detail which is not visible over IPP. I'm a bit reluctant to expose those details via IPP because it adds complexity. If the Printer wants to expose that as a setting, it can do that in its own administrative interface, but I'd probably resist adding that to IPP Firmware Update Extensions v1.0.
If the download process errors out, it will be indicated by a new "printer-state-reasons" keyword 'new-firmware-download-failure'. If download fails, then there is nothing to install, and so the current firmware will continue to be used, right?
Does this satisfy your concern #2?
1.
If a new firmware update fails because of security issues, or questions about the validity of the update package, the device should resume normal operation with the previous un-updated firmware and there should be clear indication of the failure to the user. It may be desirable to give the user the ability to postpone update attempts until the issue is resolved and new firmware update re-enabled.
This seems to be similar to your download phase concerns, but with the failures occurring during the validation phase.
If the download process errors out, it will be indicated by a new "printer-state-reasons" keyword 'new-firmware-validation-failure'. If validation fails, then the downloaded file(s) are or ought to be discarded, and so there is nothing to install, and the current firmware will continue to be used, right?
1.
It a problem occurs in the attempt to execute the new firmware:
*
There must be a clear indication to the user both of the failure and the current state of the device.
There is a new "activation" phase and it has a similar "printer-state-reasons" keyword 'new-firmware-activation-failure' to indicate that. The expected behavior is that if installation or activation phases fail, the Printer will recover by re-activating the previously installed firmware.
*
If possible, the device should be returned to full operation with the previous firmware.
*
If (b) is not possible, the device should be left in a mode which would allow analyses and perhaps operational recovery by remote maintenance efforts.
I want to be careful about being overly prescriptive with IPP Firmware Update Extensions v1.0. If granular control and exposure of the process is needed, I'd suggest that the printer not implement this and/or that it implement System Service or a proprietary method for managing firmware updates, and the vendor encourage their users to handle firmware updates that way. The original design goal was to expose printer self-update capabilities via an IPP interface so that some level of status is available to users, and to allow stages of those processes to be triggered out of cycle.
Thanks,
Bill Wagner
________________________________
From: ipp <ipp-bounces at pwg.org> on behalf of Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org>
Sent: Thursday, May 21, 2026 4:32 PM
To: PWG IPP WG Reflector <ipp at pwg.org>
Cc: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>
Subject: [IPP] IPP Firmware Update Extensions v1.0 - recommendations for "Security and Privacy" and "Implementation Considerations" sections
Hi there,
For IPP Firmware Update Extensions v1.0, does anybody have any recommendations for items to list in the "Security and Privacy" and "Implementation Considerations" sections? I'd like to get that before I produce my next draft, which will be ready for our IPP WG meeting June 18.
Cheers,
Smith
/**
Smith Kennedy
HP Inc.
*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20260702/b7fb121b/attachment.html>