[IPP] Possible updates to IPP INFRA

Hello All,

I was reading the IPP INFRA Spec. (PWG 5100.18-2015:<https://ftp.pwg.org/pub/pwg/candidates/cs-ippinfra10-20150619-5100.18.pdf>) and found some confusing areas (at least to me).
Also had some questions about using X.509 certificates for registering the output device through the Proxy to the Cloud.
I was wondering if an update to IPP INFRA would be warranted, or if we can do an Errata, or maybe even a Best Practice.

Regarding the issues with Registering an Output Device:

*         The INFRA Spec defines "Deregister-Output-Device" operation, but it does not define "Register-Output-Device".

*         Instead, the INFRA Spec says "Update-Output-Device-Attributes" is the inverse of "Deregister-Output-Device".

*         However, IPP System Service (PWG 5100.22-2019:<https://ftp.pwg.org/pub/pwg/candidates/cs-ippsystem10-20191122-5100.22.pdf>) defines the "Register-Output-Device" and refers to INFRA.

*         INFRA does not refer to SYSTEM since INFRA was finalized in 2015, and SYSTEM was finalized in late 2019.

*         I understand now INFRA assumed registration was done out-of-band, and it just dealt with an existing association.

*         If we update INFRA, we may want to clarify the Registration/Provisioning piece was defined in the SYSTEM Spec.

Regarding using X.509 Certificates to establish cryptographic pairing during Registration of the Output Device:

*         The "Register-Output-Device" operation in SYTEM Spec. does not appear to have an attribute to use a certificate.

*         If we want to allow the use of X.509 Certificates for registration, I suppose we could define a new operation attribute.

*         There is also the question if a Self-Signed certificate can be used, or if we need a CA-Signed one (Private or Public).

*         If we define this, we may want to separate the "Client-to-INFRA-Printer" piece from "Proxy-to-INRA-Printer" piece.

*         Then, how would we define what an Admin can do from the Cloud Dashboard/Portal once the Registration is done?

*         Should the Registration be done ONLY from the Proxy to the Cloud, and not through the Cloud Portal for security?

Regarding possible Cloud to Cloud communication use-cases

*         In some instances, jobs may need to travel through multiple Clouds to get to the final Output Device.

*         I don't believe IPP INFRA addresses this specifically, however could the Classic fan-out with IPP used for this?

*         If we do an update to INFRA, we may want to clarify how this type of communication could be handled with IPP.

Regarding the IPP Specifications relevant to a Cloud Model:

*         I think not everyone can navigate easily through all available (Historic and Current) IPP Specifications.

*         So, we may want to list the relevant specifications within the scope of a Cloud Printing model:

o   IPP INFRA (PWG 5100.18-2015:<https://ftp.pwg.org/pub/pwg/candidates/cs-ippinfra10-20150619-5100.18.pdf>)

o   IPP System Service (PWG 5100.22-2019:<https://ftp.pwg.org/pub/pwg/candidates/cs-ippsystem10-20191122-5100.22.pdf>)

o   IPP Encrypted Jobs and Documents (Working Draft<https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipptrustnoone10-20200128.pdf>)

o   Cloud Imaging Requirements and Model (Link<http://ftp.pwg.org/pub/pwg/candidates/cs-cloudimagingmodel10-20150619-5109.1.pdf>)

o   Any other?

I wanted to start a discussion whether it is warranted to update IPP INFRA all together, do an Errata, or a Best Practice.
Best Regards,
Cihan Colakoglu
Kyocera Document Solutions