Internet-Draft Mario Salzer draft-salzer-xmlplusrpc-00.txt Category: Experimental Expires: July 2004 January 2004 XML+RPC - XML encapsulated Remote Procedure Calls over HTTP (DRAFT) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document expires in July 2004 (or in Unix world: 1090133901). Copyright Notice Copyright (C) The Internet Society 2004. All Rights Reserved. Abstract This document describes a method to make use of remotely available application logic and data processing by sending explicit procedure calls encoded in simple and plattform-independent XML messages over a HTTP connection. Despite other RPC (Remote Procedure Call) implementations it is not encoded as binary data, and concentrates on the most basic functionality. Therefore it is easier to implement and compatible with various programming languages and data representation systems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . $ 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . $ 1.2 Relationship to XML-RPC . . . . . . . . . . . . . . . . . . $ 1.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . $ 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . $ 2. Remote Procedure Calls 2.1 Overall Operation 2.2 Example Call 3. Message Body Syntax 3.1 Restricted XML syntax 3.1.1 Whitespace And Empty Tags 3.1.2 UFT-8 Character Encoding 3.1.3 No CDATA Sections And XML Entities 3.2 Request Messages 3.3 Response Massages 3.4 Error Responses 3.5 Simple Data Types 3.5.1 Boolean 3.5.2 Integer 3.5.3 Double 3.5.4 Date And Time 3.5.5 String 3.5.6 Binary Base64 3.6 Aggregate Data Types 3.6.1 Array 3.6.2 Struct 4. Transportation Over HTTP 4.1 General Discussion 4.1.1 MIME Media Type "application/rpc+xml" 4.1.2 Charset parameter 4.2 Requests 4.3 Responses 4.3.1 Transport Layer Errors 4.4 HTTP Transport Compression 4.4.1 Transport Feature Handshake Requests 4.5 Server Requirements 5. Implementation Notes 5.1 Error Response Codes 5.2 Standardized System Methods 5.2.1 system.listMethods 5.2.2 system.methodSignature 5.2.3 system.multiCall 5.2.4 system.dataTypes 5.3 Compatibility with XML-RPC 5.3.1 Older Media Type 5.3.2 Use Of A XML-Parser 5.4 Simplification Recommendations 6. IESG Section 6.1 IANA Media Type Registration 6.2 Security Considerations 7. Acknowledgements 1. Introduction 1.1 Purpose Remote Procedure Calls allow to share out programm logic and even data storage across multiple networked hosts. The concept of these calls is very similar to that of machine local procedure calls, which often are encoded in machine code and call procedures based on the machines memory access model and processor registers. Unlike local procedure calls and most earlier RPC implementations XML+RPC does not use binary coding to transform send data, but instead uses a XML format for cross-plattform compatibility. The overall design goal was to make it easy to implement and use. It provides only the most basic data types to be useful in conjunction with nearly all programming languages and computer plattforms, which often differ wideley in how data types are internally represented. 1.2 Relationship to XML-RPC The procedures described in this document are almost completely compatible to implementation of UserLands "XML-RPC" interface specification [MINUS] as documented by Dave Winer. This original documentation became the standard reference for most implementations, but until today lacked clearification of important issues, which also lead to various incompatiblities. It is the declared goal of this document to explicitely describe the limitations, requirements and features for a compatible protocol, that can more safely be used as reference for creating new implementations of the interface. TODO: add more SHOULD server requirements for backwards compatibility 1.3 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. An implementation is conforming to this specification if it implements all requirements of this document expressed with "MUST", and all forbidden misinterpretations marked with "MUST NOT" were absent. This document also makes use of the ABNF schemas as described in [RFC2234] for clear specification of the XML+RPC message body syntax. A few paragraphes also utilize regular expressions as introduced by the Perl programming language to fully define the syntax of other constructs. 1.4 Terminology Multiple technical and RFC related terms are used within this document without prior explanation. However here is a list of terms specifically used in this document, which are believed to require definition first. method A remotely callable procedure. gateway An installation of the XML+RPC interface, which provides methods, procedures and funtionality for remote access. procedure A function that is callable by using the XML+RPC interface installed on or as webserver. server Means the actual implementation of the XML+RPC interface, which often however is not a server daemon on its own, but implemented as CGI script and running below an existing server. tag A "tag" is a XML token enclosed in angle brackets. Often this is also code a "node". vendor One of the various organisations, companys and individuals that provide an implementation of XML+RPC. For example Apache.org or UserLand. whitespace Is the class of invisible characters, which includes the space (%x20) and tabulator (%x08) as well as carriage return (%x0D) and the new line character (%x0A). 2. Remote Procedure Calls 2.1 Overall Operation A Remote Procedure Call takes place between two machines. One of them usually provides functionality the other likes to access. We further speak of the server for the machine providing methods and the client that sends processing request to it. A RPC is initiated by a client if its programm logic dictates to requires to invoke a procedure on a remote machine. It then constructs a request from the available data, often by using a specialised XML+RPC library. The required data is made up of the full canonical name of the remote procedure and all the parameter data it requires. The parameter data thereby must first be converted from the machine representation into XML document text strings. The request is then packaged into a HTTP request, which is send to a remote server to process it. If the server accepts XML+RPC requests at the specified address (URL) it decodes it the XML document text stream into a structure useful on the server machine and within the implemented programming language. Then it of course tries to match the requested method name against a list of available ones and additionally checks parameter types against the expected ones so strong typed languages wouldn't be breaked. If the called procedure finishes the server encodes the request or an error message again into XML+RPC and sends this back to the client. The client then decodes the message again and transforms the result data back into its machine representation and continues to use that data within the stopped programm logic. Of course Remote Procedure Calls could also be implemented asynchronous, but it is often more convinient that the client stops programm execution while the contacted server works on the XML+RPC request. 2.2 Example Call As already explained XML+RPC works by encoding requests into XML and transferring them over HTTP. This short example tries to show how a such a call often works. We assume that the client is running a programm written in the C programming language and wishes to execute remote procedure code on another machine while it processes following code: int uu; uu = xmlrpc("http://10.5.0.3/rpc.php", "s.foo", "%s%i", "Hello World!", 2); if (uu < 0) { ... The examplary XML+RPC library expressed as xmlrpc() call here could then encode the call to the remote procedure "s.foo" with exactly two parameters as follows: POST /rpc.php HTTP/1.0 Host: 10.5.0.3 User-Agent: simplified xmlrpc() call Accept: application/rpc+xml Accept-Encoding: bzip2, deflate Content-Type: application/rpc+xml; charset=UTF-8 Content-Length: 245 s.foo Hello World! 2 Server side this call would likeley be accepted as it conforms to the XML+RPC syntax, and the destination function "s.foo" would be executed (in the following PHP code fragment this corresponded to calling the s::foo() method): class s { function foo($str, $int_param) { return( 2 * $int_param - strlen($str) ); } } After having the procedure return a result, the XML+RPC server would then likely construct an answer like: HTTP/1.0 200 OkiDoki Server: Nanoweb/2.2.1 xml+rpc/0.7 FreePHP/4.4.2 Accept: application/rpc+xml Accept-Encoding: deflate, gzip Content-Type: application/rpc+xml; charset=UTF-8 Content-Length: 118 -8 This would then end up as the4 value -8 in the "uu" variable in our original C programm and further influence its results or behaviour. 3. Message Body Syntax 3.1 Restricted XML syntax While this document explicetely recommends to use a XML parser for processing of XML+RPC messages, the protocol was also simple enough to allow processing by highly simplified token parsers (string matching and splitting). In order to allow this, we have to make various restrictions on the allowed XML syntax. Only a subset of the XML functionality may be used in XML+RPC documents, and the overall and the nesting structure is explicitely defined in the next paragraphes. Protocol messages conforming to this specification MUST NOT use data types other than the ones defined herein, and must be mereley canonicalized as defined in [RFC3076]. This means that they MUST NOT use "empty XML tags" but instead an opening tag followed immediately by a closing one. XML+RPC messages MUST NOT make use of XML namespaces and none of the used tags may have attributes nor whitespace within the corresponding < and > of each tag. Moreover XML CDATA sections MUST NOT be used at all, like XML comments are explicetely forbidden as any other processing instruction other than the initial . Whitespace is permitted and insignifacant between nested tags only. All data type flags except and MUST NOT have spaces or tabs or end of line characters inside. The overall structure of XML+RPC messages is precisely defined in the following paragraphs, and MUST NOT differ in any message. 3.1.1 Whitespace And Empty Tags A XML tag is called "empty" if it doesn't enclose further tags or a text node, and would be written simply '' in XML. This is NOT allowed for XML+RPC messages, where this instead MUST be written as '' with a closing tag immediately following the opening tag. Further this specification allows whitespace characters only between and around tags that enclose others, but don't have a text or content node inside. Whitespace is to be considered insignificant, but for the tag described later in this document. 3.1.2 UFT-8 Character Encoding XML+RPC messages SHOULD always be encoded with the UTF-8 character set in favour of anything else. However this document also allows to use ISO-8869-1 for message bodies. Implentors SHOULD NOT assume that any other character set is supported by the other participant of a connection. Despite [RFC2434] section 4.11 this document specifically allows to use binary data within XML+RPC messages. That is all octets in the range from %x00-%xFF can be present in the message stream. This is a violation of the XML specification but allowed for backwards compatiblity with XML-RPC and for further simplification of conformant implementations. Also this rule applies regardless to the used character encoding, and even if the specified character set wouldn't allow octets of a specific range. The encoding of the document could be signalised by means of the initial XML processing instructions encoding parameter in the message body, but it SHOULD always be signalised with the MIME media type charset= parameter as defined in section 4.1.2 of this document. This especially helps not XML parser based implementations to correctly figure out the used character encoding. 3.1.3 No CDATA Sections And XML Entities As poined out earlier, XML " must be encoded into XML entity representations, because they are already used as token separators. The opening angle bracket becomes "<" the ampersand must be written as "&" and the closing angle bracket as ">". This encoding MUST be performed on all text content within the XML stream on generation of the message, and it MUST be decoded again by the recipent of a XML+RPC message. Other XML entities are not allowed and MUST be ignored and NOT decoded by the recipient of a message. Further Unicode character references like " " or "€" MUST NOT be decoded or generated in the first place. Encode "<" and "&" and ">", or leave out the ">" as [MINUS] seems to state?? 3.2 Request Messages A XML+RPC request message is supposed to invoke a remote procedure, and therefore names the remote method to be activated with all the parameters it expects. The structure of a request message is always as follows: XML-processing-instruction = '' Request-Message = XML-processing-instruction "" method-name parameters "" method-name = "" name "" parameters = "" *single-parameter "" single-parameter = "" value "" Hereby only the tag is not permitted to carry any count of whitespace. "value" is defined later in the Data Types paragraph. 3.3 Response Massages Unless a XML+RPC call resulted in an error, a server response MUST have following format: Response-Message = XML-processing-instruction "" parameters "" The sub node MUST always be present, even if it itself does not contain a single node. 3.4 Error Responses In case of an error a server will sent a message that differes from the above specified format: Error-Response = XML-processing-instruction "" fault "" fault = "" failure-struct "" Where the failure-struct is a node containing a node as described later. The struct then contains two elements, the first being named "faultCode" and associtated with an integer, and the second is a string and associated by "faultString". The string thereby corresponds to the returned error number, but both are application dependant, except for the error response numbers described in the section 5.?.? of this document. 3.5 Simple Data Types Data and values encoded in XML+RPC messages are always of a certain type. The plattform and programming language used by the server and the client, and therefore all system depended types must first be converted into a string expression suitable for almost human-readable form for transportation inside the XML stream. Data types are always mapped to a XML+RPC type and encoded into and from a string representation. Only a few data types are defined by this document, in order to provide high interoperability between systems and programming languages, that often could handle a far larger amount and much more complex data types. Therefore programmers must take care to convert the used data structures in the basic types defined by XML+RPC. Every value is encoded as string (from its processor- or language- dependant representation) and written as string into a data type tag additionally enclosed in a tag: value = "" data-type-tag "" data-type-tag = (data-type-string | data-type-integer | data-type-boolean | data-type-double | data-type-base64 | data-type-datetime | data-type-array | data-type-struct ) The "" tag 3.5.1 Boolean Boolean values are in many programming languages just represented by a value of 0 mapped to false and some integer different from 0 as being true. But in order to interoperate reliably and to provide type checking on either side of the participating implementations, XML+RPC uses an explicit boolean type. data-type-boolean = "" (0 | 1) "" Where 0 corresponds to false and 1 represents the true value. There is no whitespace permitted between the opening and closing tag. 3.5.2 Integer Integer values in XML+RPC can contain 32 bit signed values, that is values in the range from (1 - 2^31) to (0 + 2^31) or more precisely from -2147483647 to 2147483648. The string of decimal numbers that make up the string representation of a machines integer value representation may be preceeded by a minus character, but also can have a plus sign in front. integer-value = 0*1 ("+" | "-") integer-string data-type-integer = "" integer-value "" | "" integer-value "" Here the data-type tag can be "" or "" for compatiblity reasons. Implementors are encouraged to further only output the "" tag in the future. Again whitespace is not permitted within the data type tags. 3.5.3 Double Floating point values can be transmitted using the "" data type tag. The sender must first encode the value from its machine representation into a string only consisting of at least one digit before and at least one digit after a full stop charachter (%x25). A minus or plus sign may however preceed the string representation of the floating point value. double-string-representation =~ /^[+-]?\d+[.]\d+$/ data-type-double = "" double-string-representation "" Size restrictions for compatibility?? Whitespace is again not permitted to occour within this data type tag. 3.5.4 Date And Time Combined data and time values can be transported over XML+RPC using the "" date type, with the time value encoded according to [ISO8601]. Basically it is a 14 octets string built out of the 4 year number digits followed by two digits for the month and two for the day, then a literal "T" character and the hour, minutes and seconds with two digits each but separated by colons. iso8601-time-string =~ /^(\d{4})(\d\d)(\d\d)T(\d\d):(\d\d):(\d\d)$/ data-type-datetime = "" iso8601-time-string "" The text node of the tag may again not contain any whitespace. Differently to the original [MINUS] specification, the date and time values of XML+RPC always MUST be specified according to the [UTC]. 3.5.5 String A string can be encoded in a XML+RPC message by enclosing it in the "" tag. As outlined in section 3.1.2 a string may contain any combination of octets, but should be preferrably in the UTF-8 encoding. Also a string MAY contain binary data, and is not limited in length. Only the XML entities "<", ">" and "&" are to be decoded when receiving a "" data value. Unlike all previous data type tags, the string tags text node MAY contain whitespace, which then however MUST NOT be ignored by the recipant, but instead then belongs to the enclosed character string data stream. string-data-type = "" string-stream "" The older XML-RPC specification also allowed to leave out the "" data type tag and to write the string text node directly into the "" tag. Messages encoded according to this document MUST NOT use this syntax, and never enclose a string value without a corresponding type tag around. However for compatibility reasons implementors MAY choose to accept such uncleanly packaged values. 3.5.6 Binary Base64 The data type was introduced in XML-RPC before the whole stream was later defined to be binary-safe. Therefore the data type, originally introduced for carrying binary data within the messages as almost outdated today and of little value for XML+RPC transportation over HTTP. However if a transport other than HTTP is to be used, then the data type MAY be preferred over the type. base64-data-type = "" base64-string-stream "" The base64-string-stream is a string encoded with the base64 method, and thus only contains characters in the range from %x30-%x39 and %x41-%x5A and %x61-%x7A but also %x3D and OPTIONAL whitespace characters. 3.6 Aggregate Data Types Besides the most basic data types most programming languages also provide more complex compound variable types. XML+RPC does however not allow each possible type to be used, but instead concentrates on the minimum of interoperable set of types. The two most important complex data types choosen to be provided by XML+RPC and XML-RPC are the array and the struct constructs. Like the basic types, the more complex constructs like array and struct are always enclosed in a tag, but itself contain more than one subnode. 3.6.1 Array An array is an ordered list of data values, with each of them having the same data type then again. Arrays are provided by most programming languages, even if they sometimes are called very differently. data-type-array = "" "" *(value) "" "" Please note that the "" tag itself always has the redundant "" sub node, which always MUST be present, regardless if there are any values in the array. The number of values is not limited, and an implicit numbering is assumed. The values of an array may itself be any simple or aggregate data type, but all MUST be of the same type for compatibility reasons with strong typed programming languages. 3.6.2 Struct The data type corresponds to the "struct" in C and to the "hash arrays" in most interpreted and scripting languages. A struct has multiple entries, each assigned a name and a value. The order of the struct members is insignificant, and at least one member MUST be present. data-type-struct = "" 1*(struct-member) "" struct-member = "" "" token "" (value) "" The "" subnode MUST preceed the also always present "" sub node in each "" tag. The struct member name assigned withing the "" tag again MUST NOT contain any whitespace, and may be moreover only constructed of letters, numbers and the underscore to meet naming requirements of most programmin languages. 3.7 ??? Certainly there is one important thingi missing here, but which? 4. Transportation Over HTTP 4.1 General Discussion This document only specifies and discusses, how XML+RPC messages are to be transmitted over HTTP. Still it is possible to use different transport channel, but this is out of the scope of this file. When a client makes a RPC to a server, it encodes the method name and call parameters into a message as described in the previous sections, and transfers that message to the server using a POST method request as defined by the HTTP specification [RFC2616]. It must correctly set multiple HTTP request headers and also the response send by the server, which needs to obey to likewise strict rules. The meta data required for compliant transmission over HTTP is discussed in the following paragraphs. 4.1.1 MIME Media Type "application/rpc+xml" All messages conforming to this specification SHOULD be sent using a MIME type of "application/rpc+xml". For compatibility with older [MINUS] compliant servers, an implementation MAY however obey this rule and use "text/xml" instead for compatibility reasons. This type is to be specified within the "Content-Type" header field in both requests and responses. This media type is to be registered with the IANA later in this document. The choosen semantics specifically conforms to [RFC3023] and indicates compliant software that the content is a XML derived format. 4.1.2 Charset Parameter The charset= parameter to the MIME type specified above SHOULD always be given, also in addition to the encoding= attribute already given in the message bodies initial XML processing instruction (see section 3.1.1). A typical MIME type header would therefore look like: Content-Type: application/rpc+xml; charset=UTF-8 4.2 Requests A request MUST be submitted using the POST request method. The destination URL to pass the request to is not specified by this document and is installation dependend, while of course servers could releay messages merely based on the previously defined very specific media type as well. In accordance to [RFC2616] a POST request must not only have a MIME Content-Type header field, but also a Content-Length field, which specifies the length of data transferred in the body of the request. A typical request could therefore look like (each line separated by %x0D%x0A and the body example shortened): POST /cgi-bin/plus.cgi HTTP/1.0 User-Agent: plus-client/2.5.2 Accept: application/rpc+xml, text/xml; q=0.01 Accept-Encoding: deflate, gzip Content-Type: application/rpc+xml; charset=UTF-8 Content-Length: 1234 stream). However, this document also recommends violation of [RFC2616] by including response headers, which normally should only be included in a clients` HTTP request message. This especially counts for the Accept-Encoding: the server should send to allow for client initiated handshake requests to check the server for support of compressed request message bodies. Also the Accept: header SHOULD again be included to allow for older [MINUS] compliant clients. 4.3.1 Transport layer response errors If the receiving server does not understand compressed requests, it should send a HTTP 422 response code to clearify that. The message should be: HTTP/1.1 422 Unsupported Encoding Type Server: XML+RPC/1.3.29 4.3.2 Server Requirements As outlined above XML+RPC server implementations SHOULD support both the "deflate" as well as the "gzip" encoding, and indicate this to every client, which indicates conformance to the protocol described in this documented by an Accept: header containing the MIME media type mentioned earlier. Also server implemented as CGI script below a real HTTP server, should not hide itself below that, but include a response header of "X-Server" to indicate existence. 5. Implementation Notes 5.3 Error Response Codes The returned with a response always gives an error number together with a human readable error description. The currently registered and known error results are as follows: +--------+-------------------------------------------------------+ | Number | Error string | +--------+-------------------------------------------------------+ | 1 | Method does not exist | +--------+-------------------------------------------------------+ | 2 | ??? | +--------+-------------------------------------------------------+ | 3 | ??? | +--------+-------------------------------------------------------+ | 4 | Too many parameters | +--------+-------------------------------------------------------+ | 5 | ??? | +--------+-------------------------------------------------------+ | 100 | ??? | +--------+-------------------------------------------------------+ TODO: Registration with the IANA, above 100 user-definable?? 5.4 Standardized system.methods() The wideley implemented system. call package provides intersting stuff... TODO 5.4.1 system.listMethods Returns an array of strings, each the name of a callable remote procedure... TODO 5.4.2 system.methodSignature Allows to query parameter and return variables number and types for a given method name... TODO 5.4.3 system.multiCall Packages multiple calls in an array with specifically designed structs, where each mimics a single XML+RPC method call. The result is an array likewise... TODO 5.4.4 system.dataTypes This call is a recommendation to allow for future extensibility. The described procedure call will return an array of strings, which name data types supported by the queried server... TODO Would return an array with [ "boolean", "int", "double", "string", "dateTime.iso8601", "base64", "array", "struct" ] for unextented implementations of this specification. Note the absence of the "i4" type, which is deprecated by now. An implementation could invent new types (like "nil" or "unicode" or even "object") and signalise support by means of this method call. Note, that this information however can only by queried from the server by a client, so that a server could never assume the client to support an extended data type unless there is a way to negotiate on this. TODO: Recommend a HTTP X-XmlPlusRpc-Types: header?? Probably not. But what about mentioning a system.putTypes() call?? 5.3 Compatibility with XML-RPC Maintining backwards compatibility with XML-RPC may not be desired, but is a simple task, because there were basically no changes to XML+RPC, except for some deprecations and minor transport level enhancements. 5.3.1 Older Media Type The MIME media type "text/xml" was falsely used by [MINUS] compliant servers and clients and is likely to quickly disappear with final registration of the more appropriate "application/rpc+xml" MIME type. Implementations compliant to the rules outlined in this document may however provide and signalise compatibility to unfixed clients and servers by means of handshake requests and Accept: type negotiation. 5.3.2 Use Of A XML-Parser While the recommendations and restrictions made in section 3.1 especially allow for simple token parsers (flex), it is recommended to use a full fledged XML processor for parsing XML+RPC messages, because this ensures high compatibility in respect to character set issues and also allows to read requests which didn't obey the restriction rules made in section 3. However it is required to specifically instruct XML processors to generate compliant messages, and especially the not-empty-tags rule may not always be supported by every possible XML library. 5.4 Simplification Recommendations Clients wishing to further simplify processing HTTP requests and responses should send requests indicating, that they would obed the HTTP/1.0 standard as outlined in earlier examples. This specifically helps to avoid the "chunked" Transfer-Encoding introcuded with the 1.1 version of the HTTP standard. 6. IESG Section 6.1 IANA Media Type Registration To: ietf-types@iana.org Subject: Registration of Standard MIME Media type application/rpc+xml MIME media type name: application MIME subtype name: rpc+xml Required parameters: none Optional parameters: charset The optional parameter "charset" refers to the character encoding used to represent the character stream encoded in the transmitted XML document as a sequence of octets. Any charset registered with the IANA may be used, but only ISO-8859-1 and UTF-8 are recommended with this specification. Also presence of this parameter is strongly recommended. Encoding considerations: The message format can contain arbitrary binary data, and thus MUST be encoded for non-binary transport channels such as SMTP. The base64 encoding is suitable for transport protocols other than HTTP. Security considerations: See section 7.2 of this document. Interoperability considerations: Registration of this Media Type happens to correct the abuse of the "text/xml" MIME Type within XML-RPC transmissions. In that it will initially raise incompatibilities. Published specification: Use of the Media Type is described within this document. Applications which use this media type: ... Additional information: Magic number(s): none File extension(s): none Macintosh File Type Code(s): none Object Identifier(s) or OID(s): none Person to contact for further information: The author of this document. Intended usage: COMMON Author/Change controller: "Mario Salzer" 6.2 Security Considerations Many evil things could happen to everbody who implemented this protocol... TODO * distinction between read-only and data manipulation calls * sensitive information (visible transport content) ** ticketing within messages ** auth in lower level protocol *** http basic auth *** ssl or tls * data types and strict typed languages * tricking scripting languages? (known bugs only) * compression bombs in deflate or zlib? * drawbacks of compatibility pressure * again recommend full xml parsers (charset issues esp) * ... 7. Acknowledgments Dave Winer wrote the initial specification and various revisions of the [MINUS] protocol. Adam Megacz wrote the first Internet-Draft to attemp to standardize the XML-RPC protocol, then eventually known as "XMC". Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3470] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Informative References [MINUS] D. Winer "XML-RPC Specification", June 1999, . [RFC2434] Narten, H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3076] J. Boyer, "Canonical XML Version 1.0", RFC3076, March 2001. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, . [ISO8601] "International Standardization Organisations` 8601", ... [UTC] "Universal Time Code" (AKA "GMT"), ... [10POINT] W3C Communications Team, "XML in 10 points", November 2001, . [RFC2324] L. Masinter, "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC2324, Apr-01-1998. Authors' Addresses Mario Salzer FH Erfurt, University of Applied Sciences Fischersand 12, 99084 Erfurt Europe / Germany / Thuringia email: mario@erphesfurt.de phone: +49-361-6433638 icq: 95596825 Trademark Statement The name "XML-RPC" is a registered trademark of Userland(?). To allow description of a compatible protocol we named this document and the methods and syntax it describes "XML+RPC". The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.