Many documents have been written about how to transport XMPP datagrams using HTTP. The motivation behind such solutions has often been to be able to use XMPP in scripting languages such as Java Script running in web browsers.

But very little has been written up to this point about the reverse: How to transport HTTP methods and HTTP responses over an XMPP-based peer-to-peer network. Here, the motivation is as follows: There are multitudes of applications and APIs written that are based on HTTP over TCP as the basic communication transport protocol. As these are moving closer and closer to the users, problems arise when the users want to protect their data and services using firewalls. Even though there are methods today to open up firewalls manually or automatically permit communication with such devices and applications, you still open up the application for everybody. This rises the need for more advanced security measures which is sometimes difficult to implement using HTTP.

The XMPP protocol however does not have the same problems as HTTP in these regards. It's a peer-to-peer protocol naturally allowing communication with applications and devices behind firewalls. It also includes advanced user authentication and authorization which makes it easier to make sure unauthorized access to private content is prevented.

Furthermore, with the advent of semantic web technologies and its use in web 3.0 and Internet of Things applications, such applications move even more rapidly into the privte spheres of the users, where security and privacy is of paramount importance, the need to use more secure transport protocols than HTTP over TCP is necessary.

There are many different types of HTTP-based communication that one would like to be able to transport over XMPP. A non-exhaustive list can include:

• Web Content like pages, images, files, etc.
• Web Forms.
• Web Services (SOAP, REST, etc.)
• Semantic Web Resources (RDF, Turtle, etc.)
• Federated SPARQL queries (SQL-type query language for the semantic web, or web 3.0)
• Streamed multi-media content in UPnP and DLNA networks.

Instead of trying to figure out all possible things transportable over HTTP and make them transportable over XMPP, this document ignores the type of content transported, and instead focuses on encoding and decoding the original HTTP requests and responses, building an HTTP tunnel over an existing XMPP connection. It would enable existing applications to work seamlessly over XMPP if browsers and web services supported this extension (like displaying your home control application on your phone when you are at work), without the need to update the myriad of existing applications. It would also permit federated SPARQL queries in personal networks with the added benefit of being able to control who can talk to who (or what can talk to what) through established friendship relationships.

Previous extensions handling different aspects of XMPP working together with HTTP:

• &xep0070;: This specification handles client authentication of resources, where there are three parties: HTTP Client <-> HTTP Server/XMPP Client <-> XMPP Server. Here HTTP Client authentication to resources on the HTTP Server is made by a third party, an XMPP Server.
• &xep0072;: This speification handles execution of SOAP-based web services specifically. This specification have some benefits regarding to Web Service calls over XMPP, but is only one example of all types of HTTP-based communucation one would desire to transport over XMPP.
• &xep0124;: This specification handles XMPP-based communication over HTTP sessions (BOSH), allowing for instance, java script to communicate using XMPP using the XML HTTP Request object. This is in some way the reverse of what this document proposes to do.
• &xep0147;: This informational specification proposes ways to define XMPP-actions using URL's. This document will propose a different URI scheme for HTTP-based resources over an XMPP transport.

This document presupposes the server already has a web server (HTTP Server) implementation, and that it hosts content through it, content which can be both dynamic (i.e. generated) or static (for example files) in nature. Content, which it wants to publish to XMPP clients as well as HTTP clients. It also presupposes that the client is aware of HTTP semantics and MIME encoding.

The following table lists common terms and corresponding descriptions.

HTTP

Hyper Text Transfer Protocol. Version 1.1 of HTTP is described in RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 <http://tools.ietf.org/html/rfc2616> . The PATCH method is described in RFC 5789: PATCH Method for HTTP <http://tools.ietf.org/html/rfc5789>

HTTP Client

An HTTP Client is the initiator of an HTTP Request.

HTTP Method

HTTP Methods are: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and PATCH. The HTTP Method CONNECT is not supported by this specification.

HTTP Request

An HTTP Request consists of a Method, version information, headers and optional body.

HTTP Resource

A resouce on an HTTP Server identified by a path. Each path begins with a separator character (/).

HTTP Response

An HTTP Response consists of a status code, optional status message, headers and optional body.

HTTP Server

An HTTP Server responds to HTTP Client requests.

Web Server

Used synonymously with HTTP Server.

All HTTP communication is done usig the Request/Response paradigm. Each HTTP Request is made sending an iq-stanza containing a req element to the server. Each iq-stanza sent is of type get (not to be confused by the HTTP Method GET).

When the server responds, it does so by sending an iq-stanza response (type result) back to the client containing a resp element. Since responses are asynchronous, and since multiple requests may be active at the same time, responses may be returned in a different order than the in which the original requests were made.

Requests or responses containing data must also consider how this data should be encoded within the XML telegram. Normally in HTTP, content and headers are separated by a blank line, and the transfer of the content is made in the same stream. Specific HTTP headers are used to define how the content is transfered and encoded within the stream (Content-Type, Content-Length, Content-Encoding, Content-Transfer-Encoding). This approach is not possible if the response is to be inbedded in an XML telegram, since it can interfere with the encoding of the encompassing XML.

To solve this, this document specifies additional data transfer mechanisms that are compatible with the XMPP protocol. The normal HTTP-based content transfer headers will still be transported, but do not affect the content encoding used in the XMPP transport. The following content encoding methods are available:

• text: Normal text content. The text is encoded as text within XML, using the same encoding used by the XML stream. XML escape characters (<, > and &) are escaped using the normal &lt;, &gt; and &amp; character escape sequences.

• xml: Xml content embedded in the XML telegram. Note however, that any processing instructions or XML version statements must be avoided, since it may cause the XML stream to become invalid XML. If this is a problem, normal text encoding can be used as an alternative. The advantage of xml instead of text or base64 encodings is when used in conjuncion with EXI compression &xep0322;. EXI compression has the ability to compress XML efficiently. Text will not be compressed, unless response exists in internal string tables. Base-64 encoded data will be compressed so that the 33% size gain induced by the encoding is recaptured.

• base64: Base-64 encoded binary content. Can be used to easily embed binary content in the telegram.

• chunkedBase64: Chunked Base-64 encoded binary content. The content is not embedded in the telegram. Instead it is sent in chunks, using separate chunk messages to the client. Chunked transport can be used by the server when it doesn't know the size of the final result. Chunked transport is similar to the streamBase64 encoding with the (loose) distinction that a stream is indefinite, while chunked transport conveys finitely sized content.

• sipub: The sender might deem the content to be too large for sending embedded in the XMPP telegram. To circumnavigate this, the sender publishes the content as a file using &xep0137; (Publishing Stream Initiation Requests), instead of embedding the content directly. This might be the case for instance, when a client requests a video resource, without using a ranged request.

• streamBase64: This option may be used to encode indefinite streams, like live audio or video streams (HLS, SHOUTcast, Motion JPeg web cams, etc). It works as chunkedBase64 with the distinction that the content is indefinite. This option is not available in requests, only in responses.

• jingle: For demanding multi-media streams alternative methods to transport streaming rather than embedded into the XMPP stream may be required. Even though the streamBase64 method may be sufficient to stream a low-resolution web cam in the home, or listen to a microphone or a radio station, it is probably badly suited for high-resolution video streams with multiple video angles and audio channels. If such content is accessed and streamed, the server can negotiate a different way to stream the content using &xep0166;.

Note: Content endoded using chunkedBase64 or streamBase64 encoding methods can be terminated, either by the receptor going off-line, or by sending a close command to the sender.