[IPP] Registration proposal for additional IPP Printer firmware related attributes[EXTERNAL]

[IPP] Registration proposal for additional IPP Printer firmware related attributes[EXTERNAL]

Kennedy, Smith (Wireless & IPP Standards) smith.kennedy at hp.com
Mon Jul 29 14:45:58 UTC 2024


That’s fine. 


Cheers,
Smith
---
Smith Kennedy
smith.kennedy at hp.com


> On Jul 29, 2024, at 10:21 AM, Michael Sweet <msweet at msweet.org> wrote:
> 
> CAUTION: External Email
> 
> Smith,
> 
> I mostly like and will copy this into the IPP deck.  As for terminology I'm leaning towards:
> 
> - Client-supplied: Client gets firmware updates and uploads to the Printer/System
> - Client-initiated: Client tells Printer/System to perform an update
> - Autonomous: Printer/System autonomously checks and updates firmware from a trusted source
> 
> Thoughts?
> 
> 
>> On Jul 27, 2024, at 1:47 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>> 
>> How's this?
>> 
>> https://ftp.pwg.org/pub/pwg/ipp/slides/IPP-Firmware-Update-Extensions-Registration-Options-20240727.pdf  https://ftp.pwg.org/pub/pwg/ipp/slides/IPP-Firmware-Update-Extensions-Registration-Options-20240727.pptx
>> 
>> Smith
>> 
>> 
>> 
>>>> On Jul 26, 2024, at 2:31 PM, Michael Sweet <msweet at msweet.org> wrote:
>>> 
>>> CAUTION: External Email
>>> 
>>> From: Michael Sweet <msweet at msweet.org>
>>> Subject: Re: [IPP] Registration proposal for additional IPP Printer firmware related attributes[EXTERNAL]
>>> Date: July 26, 2024 at 2:31:54 PM CDT
>>> To: "Kennedy, Smith (Wireless & IPP Standards)" <smith.kennedy at hp.com>
>>> Cc: PWG IPP Workgroup <ipp at pwg.org>
>>> 
>>> 
>>> Smith,
>>> 
>>> Let's stick with slides.  I have collected the proposals in my work-in-progress slide deck but if you have any useful visual diagrams I can include those as well...
>>> 
>>> 
>>>> On Jul 26, 2024, at 1:09 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
>>>> 
>>>> It sounds like we have several different sets of use cases because different manufacturers have made differing choices. I'll see if I can articulate all of those from this thread in a draft registration document that I'll post before the F2F? Or should it just be slides, since there's been discussion of adding different sets of updates to System Service and INFRA?
>>>> 
>>>> Smith
>>>> 
>>>> /**
>>>>   Smith Kennedy
>>>>   HP Inc.
>>>> */
>>>> 
>>>>> On Jul 26, 2024, at 10:19 AM, Michael Sweet via ipp <ipp at pwg.org> wrote:
>>>>> 
>>>>> CAUTION: External Email
>>>>> 
>>>>> So is this something we want to standardize in IPP INFRA?  And what will that look like?
>>>>> 
>>>>> 
>>>>>> On Jul 26, 2024, at 10:57 AM, Uli Wehner via ipp <ipp at pwg.org> wrote:
>>>>>> 
>>>>>> Ira,
>>>>>> We are on the same page, our printers do not fetch the files, they are configured to know where to go to see if there is anything to do for them. The cloud service is then responsible for performing the tasks for that printer. This is a fully authenticated, encrypted process. Zero trust and everything. I just left out the details of our particular solution.
>>>>>> Regards
>>>>>> Uli Wehner
>>>>>> ウリ・ヴェーナー
>>>>>> From: Ira McDonald <blueroofmusic at gmail.com>
>>>>>> Sent: Friday, July 26, 2024 9:38 AM
>>>>>> To: Uli Wehner <ulrich.wehner at ricoh-usa.com>; Ira McDonald <blueroofmusic at gmail.com>
>>>>>> Cc: ISTO-PWG Internet Printing Protocol workgroup discussion forum <ipp at pwg.org>; Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>
>>>>>> Subject: Re: [IPP] Registration proposal for additional IPP Printer firmware related attributes[EXTERNAL]
>>>>>> Hi Uli,
>>>>>> With IPP System Service in the Cloud, a Printer can be notified that firmware updates are available and safely fetch the updates.
>>>>>> Direct fetch from the manufacturer has all the security weaknesses that caused us to deprecate Print-URI.
>>>>>> Cheers,
>>>>>> - Ira
>>>>>> On Fri, Jul 26, 2024, 9:03 AM Uli Wehner <ulrich.wehner at ricoh-usa.com> wrote:
>>>>>> Smith,
>>>>>> With software moving to the cloud, we will not be able to push firmwares to printers directly anymore.
>>>>>> I know we will need to be able to have the printer reach up to the service using an agent on the device. We do this today, just not with IPP as the vehicle.
>>>>>> Regards
>>>>>> Uli Wehner
>>>>>> ウリ・ヴェーナー
>>>>>> From: ipp <ipp-bounces at pwg.org> On Behalf Of Kennedy, Smith (Wireless & IPP Standards) via ipp
>>>>>> Sent: Thursday, July 25, 2024 6:12 PM
>>>>>> To: Ira McDonald <blueroofmusic at gmail.com>
>>>>>> Cc: Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>; PWG IPP WG Reflector <ipp at pwg.org>
>>>>>> Subject: Re: [IPP] Registration proposal for additional IPP Printer firmware related attributes[EXTERNAL]
>>>>>> 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.
>>>>>> _______________________________________________
>>>>>> ipp mailing list
>>>>>> ipp at pwg.org
>>>>>> https://www.pwg.org/mailman/listinfo/ipp
>>>>> 
>>>>> 
>>>>> ________________________
>>>>> Michael Sweet
>>>>> 
>>>>> _______________________________________________
>>>>> ipp mailing list
>>>>> ipp at pwg.org
>>>>> https://www.pwg.org/mailman/listinfo/ipp
>>>> 
>>> 
>>> ________________________
>>> Michael Sweet
>>> 
>>> 
>>> 
>> 
> 
> ________________________
> Michael Sweet
> 


More information about the ipp mailing list