[cups-devel] Print-URI implementation

[Michael Sweet]

Stephan,

> On Jan 19, 2017, at 7:01 AM, Stephan <stephanwib at googlemail.com> wrote:
> ...
> Why ist Print-URI (and optionally Send-URI) not implemented? What´s
> required to do that?

Print-URI is not supported because it has extremely limited usefulness and would require CUPS to retrieve the URI which might require an indefinite amount of time.  Aside from making it easy to perform a denial of service attack, you have to deal with credentials and handle when somebody removes the file referenced by the URI before your job has been processed... (since the document is not bound to the job).

Print-URI with file URIs is a security nightmare since cupsd runs with different privileges from the user.  Aside from some very limited situations which don't apply to stock CUPS, you should be copying the file to CUPS using the Print-Job (or Create-Job + Send-Document) operation.

Print-URI with network URIs could be implemented, but you'll need to decide how to support auto-typing (if at all), URI credentials (there are some new IPP attributes for this, but they are not supported by CUPS yet), and how to retrieve the document(s) without causing cupsd to block all other clients.  For the latter, you could develop a simple filter that retrieves the file and sends it to stdout, similar to how the gziptoany filter works for compressed documents.

> Thanks and regards,
> 
> Stephan
> 
> PS: I´m not sure if I will need it, but it would also be good if
> Print-URI would be supported in the IPP backend, so the document to be
> printed does not necessarily need be sent through the print server. I
> have already verified that some printers can obtain the print data
> from arbitrary web services.

Since the IPP backend deals with local files or a stream of print data from the filters, it has no way to use the Print-URI operation since there is no accessible URI it can provide.

Moreover, the only URI scheme that is required for the (optional) Print-URI operation is "ftp".  So even if we *did* have a print-ready file on an Internet-accessible server (assuming that we could determine *that*), we'd still have to check whether the printer supports the access protocol in the first place.

You might want to look at the IPP Shared Infrastructure Extensions specification, which defines how to do Cloud printing for IPP and can be found here:

	http://ftp.pwg.org/pub/pwg/candidates/cs-ippinfra10-20150619-5100.18.pdf <http://ftp.pwg.org/pub/pwg/candidates/cs-ippinfra10-20150619-5100.18.pdf>

_________________________________________________________
Michael Sweet, Senior Printing System Engineer