This started out as a bare framework. Many "nice" bits haven't been put in yet. Specifically, very little type validation or coercion has been put in. PHP being a loosely-typed language, this is going to have to be done explicitly (in other words: you can call a lot of library functions passing them arguments of the wrong type and receive an error message only much further down the code, where it will be difficult to understand).

dateTime.iso8601 is supported opaquely. It can't be done natively as the XML-RPC specification explicitly forbids passing of timezone specifiers in ISO8601 format dates. You can, however, use the iso8601_encode() and iso8601_decode() functions to do the encoding and decoding for you.

Very little HTTP response checking is performed (e.g. HTTP redirects are not followed and the Content-Length HTTP header, mandated by the xml-rpc spec, is not validated); cookie support still involves quite a bit of coding on the part of the user.

If a specific character set encoding other than US-ASCII, ISO-8859-1 or UTF-8 is received in the HTTP header or XML prologue of xml-rpc request or response messages then it will be ignored for the moment, and the content will be parsed as if it had been encoded using the charset defined by xmlrpc_defencoding

Very large floating point numbers are serialized using exponential notation, even though the spec explicitly forbids this behaviour. This will not be a problem if this library is used on both ends of the communication, but might cause problems with other implementations.

Support for receiving from servers version 1 cookies (i.e. conforming to RFC 2965) is quite incomplete, and might cause unforeseen errors.

A PHP warning will be generated in many places when using xmlrpc.inc and xmlrpcs.inc with PHP 5 in strict error reporting mode. The simplest workaround to this problem is to lower the error_reporting level in php.ini.