Privet Local Printing Spec

[jamesjo...@gmail.com]

We are looking at an application where the printer/connector uses Privet local printing and is permanently "offline" (not connected to, or registered with, GCP).

The GCP 2.0 spec could be improved in a few areas, according to our understanding and experimental results.  We do not know if this spec is locked in at this point, or if addendums can be made.

(1)  There seems to be no mention of the printer/connector advertising that it also accepts (or only accepts) encrypted transactions from clients.  We therefore thought that TLS-vs-plaintext might be automatically detected by the client.  We set up an experiment with the printer/connector SUT set up as a http/plaintext server, and verified that Chrome browser can find the printer.  We then changed the SUT to a https/TLS server and changed the port to match in the DNS-SD record.  Chrome browser makes a connection to the TLS port, goes through part of the negotiation and then gives up without listing the printer.  It seems that encryption would be a highly desirable option in the enterprise environment, and for that matter in the environment at large, where wireless transmission will be the de facto medium.

(2)  There seems to be no facility for a connector that is hosting multiple printers to expose them all from a single IP address/TCP port.  If the protocol allowed requests like "GET /privet/info?printer=Printer2" where the name "Printer2" was obtained from the list of results from DNS-SD, the connector could serve responses for the multiple printers it fronts.  This is how iOS printing works, except that the capabilities requests are submitted through ipp/ipps instead of http.  I certainly see how we got to the thinking that a single address/port == a single device, but an addition like this could really make this protocol scream with extensibility.

Please let me know if we are missing something in our interpretation of the specification and the experimental results.

[sc...@collobos.com]

The fact that Privet printing seems to depend on multicast DNS to discover printers is also something that will render it ill suited for enterprise use, as it's the rare enterprise that has print servers and wireless devices on a common subnet.

[jamesjo...@gmail.com]

Does anyone on the development team have any responses for my points?  I am not trying to be argumentative or a nuisance.  I am trying to develop a solution using this API and have questions.

[Gene Gutnik]

Hi,

Thank you for feedback.

(1) There is no encryption in the Privet v1. Doing proper secure channel in the local network is tricky. If we just enable TLS support - there is no way to verify authenticity of the printer endpoint. That will make it vulnerable to the men in the middle attack and may give a false sense of security. So, for v1 we make it over unencrypted channel. We'll try to address this issue in v2.

(2) Unfortunately for v1 we don't support multiple printers on the same ip/port. This was done for simplicity reasons, and we should address this in the next version as well.   

On Fri, Jul 25, 2014 at 8:57 AM, <jamesjo...@gmail.com> wrote:

Does anyone on the development team have any responses for my points?  I am not trying to be argumentative or a nuisance.  I am trying to develop a solution using this API and have questions.

--
You received this message because you are subscribed to the Google Groups "Google Cloud Print Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gcp-developer...@googlegroups.com.
Visit this group at http://groups.google.com/group/gcp-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/gcp-developers/31ad6e9b-043c-4a9c-8683-829e5c080872%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.