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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200515/0e2790a4/attachment.html>