Re: IPP under emacs [was: Re: Post-22.1 development?]

[Ken Raeburn]

On Jun 8, 2007, at 10:25, Vinicius Jose Latorre wrote:
> Some time ago, Eric Marsden created the ipp.el package, see the links:
>
> http://www.emacswiki.org/cgi-bin/wiki/EricMarsden
> http://www.emacswiki.org/cgi-bin/wiki/InternetPrintingProtocol

Skimming the code (via the "permanent" link on the former page, not  
the latter, which seems to be out of date), it looks like at least  
some of the security aspects of the protocol have been omitted.  As  
opposed to some other protocols Emacs implements, where you can use  
it directly without any security, or you can use a helper program in  
a subprocess.

(putting my Network Security Geek hat on...)

I think it would be helpful for Emacs to grow some more network- 
protocol building blocks in this area.  Exactly what functionality  
would be needed and what the APIs should look like, I don't know off  
the top of my head, but it seems that Emacs has to call out to helper  
programs currently for protocols using Kerberos, GSSAPI, SASL, and  
TLS/SSL at least.  Making primitives for some of these available in  
Emacs (perhaps via helper programs, at least initially) would make it  
possible for Emacs to more directly implement application protocols  
like IMAP, IPP, and SMTP even with security features enabled, instead  
of adding helper programs for every application protocol that can  
negotiate security.

Like I said, I'm not sure what the APIs should look like in general.   
From my own work, I'm pretty sure that GSSAPI primitives would be  
easy to implement with a helper program; the GSSAPI itself mostly  
operates by doing work on data blocks, leaving the caller to manage  
the low-level wire encoding and transmission as specified by the  
application protocol; that would fit in with the helper subprocess  
approach pretty easily.  I seem to recall seeing some work on TLS for  
Emacs done too, but I don't recall how general it was.

An obvious drawback to moving the support into Emacs itself is that  
we probably don't want to require that people have Kerberos/GSSAPI/ 
SASL/TLS/whatever installed in order to install a pre-packaged Emacs,  
nor do we want to inflate the number of Emacs packages that get put  
together by exploding the power set of options.  There are other  
approaches, though: dlopen on the libraries in question, helper  
programs in separate packages, Emacs extensions in C loadable at run  
time, etc.

Ken