When we chose to implement RPC webservices, this was chosen because the HTTP protocol is well understood and easy to implement, and includes an authentication model that is also easy to implement. Our goal for web services was to offer services that can be used both to remotely manage different GNU Telephony servers such as GNU Bayonne, and to provide services to be used by application developers.
This document intends to outline how we are standardizing these services and their implementation for future servers. The goal is to harmonize our methodologies and offer a consistent RPC programming model that is easy to understand. While we experimented with serverResponse, we will in the future primarily focus on XMLRPC. This became possible as we implemented a very small XMLRPC parser and a small prep routine for generating call structures and replies. I have also implemented a tiny SOAP parser and reply generator, and we may use SOAP in the future as well for offering some application services.
We most commonly will use HTTP as the transport mechanism for XMLRPC (and SOAP) services. However, it may not be the only transport mechanisms supported. For one example, GNU Bayonne may also support SIP-encapsulated XMLRPC and SOAP methods.
All authentication is handled using the existing HTTP “basic” authentication method. Other transports may offer other modalities of authentication. For example, SIP-encapsulated XMLRPC might be authenticated through a SIP registry. Privacy, at least for HTTP, will be offered through SSL-protected sessions as we adapt to the use of GnuTLS.
There are two classes of “users” that will be authenticated. There are users who are restricted in what operations they can perform, based on permissions and attributes the server is internally aware of, and there is a global set of users which can have full access