Anton,
IPP System Service (PWG 5100.22) already addresses the "Client push" model of doing firmware updates via Resource objects.
This registration is an attempt to standardize what already happens on consumer printers, namely regular OTA updates from a vendor-controlled (internet) source, and provide a way to redirect such updates to a local vendor-supported repository. Because there is no standard software repository format or protocol, we are necessarily leaving it as generic as possible with a URL pointing to the vendor repository. We expose the current state of things via IPP attributes but how that state is communicated from the firmware repository remains implementation-defined...
For more details, definitely look at section 4 of the registration which discussed how this registration fits in the overall scheme of things...
> On Jan 27, 2026, at 3:53 PM, Anton Thomasson via ipp <ipp at pwg.org> wrote:
>> Hi
>> Over all a very good initiative, but i have some concerns - sorry if they have already been addressed (i couldn't find it).
>> With this mirroring the installed firmware in being able to communicate that there are multiple firmware types and versions,
> i think it could be worth being super-duper clear on that the contents of these lists describe a set of firmware files that would get applied together when triggering an update.
> (...and is not to be used to contain multiple versions of the same thing).
> A naive implementer might be tempted to list all versions offered, only to find out the update operation has no way of saying to what version.
> I also think it is a mistake to only support, possible even to require, some online repository for firmware.
> I think it would be very good to be able to supply the firmware file(s) directly from the client.
> Files tend to stick around much longer than the services that served them most of the time.
> Currently a lot of firmware updates are simply performed by "printing" a file with some magic (often PJL) in it.
> Also think of use in air-gapped environments, not just post-support-window devices.
> With no standard on what a repository is, there is no guarantee i could deploy my own.
>> Br,
> Anton
>> Den tis 27 jan. 2026 kl 19:59 skrev Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org>:
> Greetings,
>> I've posted a new draft of IPP Firmware Update Extensions v1.0:
>>https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfwupdate10-20260127.pdfhttps://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfwupdate10-20260127.docxhttps://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfwupdate10-20260127-rev.pdfhttps://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfwupdate10-20260127-rev.docx>> Changes:
>> • Updates to section 4 to consolidate discussion of the linkage between the new operations, the new attributes, and the new values for existing attributes
> • Updated the abstract
> • Fixed the document file name
> • Added section 4.5 “Enabling or Disabling the Printer Firmware Update Feature” and defined the “printer-firmware-update-enabled” attribute to allow a Client to have an easy way to detect support for the feature, and to provide the Printer and its Administrator with a way to disable the feature.
>> I know we won't be looking at this Thursday but its there for review before the F2F and we could peek at it if we want to.
>> Cheers,
>> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
________________________
Michael Sweet