mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 18:22:24 -05:00
1600 lines
86 KiB
XML
1600 lines
86 KiB
XML
|
<?xml version='1.0' encoding='UTF-8'?>
|
||
|
|
<!--
|
||
|
|
TODO: Write IETF RFC.
|
||
|
|
TODO: Inform:
|
||
|
|
* Browser developers
|
||
|
|
* Web Server developers
|
||
|
|
* Media Player developers
|
||
|
|
* XMPP Server developers
|
||
|
|
* SOA Developer tools (Web Service bindings)
|
||
|
|
* HTTP WG
|
||
|
|
* Scientists (XMPP, CoAP, MQTT)
|
||
|
|
* W3C Technical Architecture Group (TAG) (dev of REST)
|
||
|
|
* SPARQL WG
|
||
|
|
-->
|
||
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||
|
|
%ents;
|
||
|
|
]>
|
||
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||
|
|
<xep>
|
||
|
|
<header>
|
||
|
|
<title>HTTP over XMPP transport</title>
|
||
|
|
<abstract>This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks.</abstract>
|
||
|
|
<legal>
|
||
|
|
<copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).</copyright>
|
||
|
|
<permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.</permissions>
|
||
|
|
<warranty>## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
|
||
|
|
<liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
|
||
|
|
<conformance>
|
||
|
|
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <<link url='http://www.xmpp.org/extensions/ipr-policy.shtml'>http://www.xmpp.org/extensions/ipr-policy.shtml</link>> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
|
||
|
|
</conformance>
|
||
|
|
</legal>
|
||
|
|
<number>xxxx</number>
|
||
|
|
<status>ProtoXEP</status>
|
||
|
|
<type>Standards Track</type>
|
||
|
|
<sig>Standards</sig>
|
||
|
|
<approver>Council</approver>
|
||
|
|
<dependencies>
|
||
|
|
<spec>XMPP Core</spec>
|
||
|
|
<spec>XEP-0001</spec>
|
||
|
|
<spec>XEP-0030</spec>
|
||
|
|
<spec>XEP-0137</spec>
|
||
|
|
<spec>XEP-0166</spec>
|
||
|
|
</dependencies>
|
||
|
|
<supersedes/>
|
||
|
|
<supersededby/>
|
||
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
||
|
|
<author>
|
||
|
|
<firstname>Peter</firstname>
|
||
|
|
<surname>Waher</surname>
|
||
|
|
<email>peter.waher@clayster.com</email>
|
||
|
|
<jid>peter.waher@jabber.org</jid>
|
||
|
|
<uri>http://se.linkedin.com/pub/peter-waher/1a/71b/a29/</uri>
|
||
|
|
</author>
|
||
|
|
<revision>
|
||
|
|
<version>0.0.1</version>
|
||
|
|
<date>2013-05-05</date>
|
||
|
|
<initials>pw</initials>
|
||
|
|
<remark>
|
||
|
|
<p>First draft.</p>
|
||
|
|
</remark>
|
||
|
|
</revision>
|
||
|
|
</header>
|
||
|
|
<section1 topic='Introduction' anchor='intro'>
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
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:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li>Web Content like pages, images, files, etc.</li>
|
||
|
|
<li>Web Forms.</li>
|
||
|
|
<li>Web Services (SOAP, REST, etc.)</li>
|
||
|
|
<li>Semantic Web Resources (RDF, Turtle, etc.)</li>
|
||
|
|
<li>Federated SPARQL queries (SQL-type query language for the semantic web, or web 3.0)</li>
|
||
|
|
<li>Streamed multi-media content in UPnP and DLNA networks.</li>
|
||
|
|
</ul>
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Previous extensions handling different aspects of XMPP working together with HTTP:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li>
|
||
|
|
&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.
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
&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.
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
&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.
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
&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.
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Requirements' anchor='reqs'>
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Glossary' anchor='glossary'>
|
||
|
|
<p>The following table lists common terms and corresponding descriptions.</p>
|
||
|
|
<dl>
|
||
|
|
<di>
|
||
|
|
<dt>HTTP</dt>
|
||
|
|
<dd>
|
||
|
|
Hyper Text Transfer Protocol. Version 1.1 of HTTP is described in <note>
|
||
|
|
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 <<link url='http://tools.ietf.org/html/rfc2616'>http://tools.ietf.org/html/rfc2616</link>>
|
||
|
|
</note>. The PATCH method is described in <note>
|
||
|
|
RFC 5789: PATCH Method for HTTP <<link url='http://tools.ietf.org/html/rfc5789'>http://tools.ietf.org/html/rfc5789</link>>
|
||
|
|
</note>
|
||
|
|
</dd>
|
||
|
|
</di>
|
||
|
|
<di>
|
||
|
|
<dt>HTTP Client</dt>
|
||
|
|
<dd>An HTTP Client is the initiator of an HTTP Request.</dd>
|
||
|
|
</di>
|
||
|
|
<di>
|
||
|
|
<dt>HTTP Method</dt>
|
||
|
|
<dd>
|
||
|
|
HTTP Methods are: <strong>OPTIONS</strong>, <strong>GET</strong>, <strong>HEAD</strong>, <strong>POST</strong>,
|
||
|
|
<strong>PUT</strong>, <strong>DELETE</strong>, <strong>TRACE</strong> and <strong>PATCH</strong>. The HTTP
|
||
|
|
Method CONNECT is not supported by this specification.
|
||
|
|
</dd>
|
||
|
|
</di>
|
||
|
|
<di>
|
||
|
|
<dt>HTTP Request</dt>
|
||
|
|
<dd>An HTTP Request consists of a Method, version information, headers and optional body.</dd>
|
||
|
|
</di>
|
||
|
|
<di>
|
||
|
|
<dt>HTTP Resource</dt>
|
||
|
|
<dd>A resouce on an HTTP Server identified by a path. Each path begins with a separator character (/).</dd>
|
||
|
|
</di>
|
||
|
|
<di>
|
||
|
|
<dt>HTTP Response</dt>
|
||
|
|
<dd>An HTTP Response consists of a status code, optional status message, headers and optional body.</dd>
|
||
|
|
</di>
|
||
|
|
<di>
|
||
|
|
<dt>HTTP Server</dt>
|
||
|
|
<dd>An HTTP Server responds to HTTP Client requests.</dd>
|
||
|
|
</di>
|
||
|
|
<di>
|
||
|
|
<dt>Web Server</dt>
|
||
|
|
<dd>Used synonymously with HTTP Server.</dd>
|
||
|
|
</di>
|
||
|
|
</dl>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
||
|
|
<p>
|
||
|
|
All HTTP communication is done usig the <strong>Request</strong>/<strong>Response</strong> paradigm. Each HTTP Request is made sending an <strong>iq</strong>-stanza
|
||
|
|
containing a <strong>req</strong> element to the server. Each <strong>iq</strong>-stanza sent is of type <strong>get</strong> (not to be confused by the HTTP Method
|
||
|
|
<strong>GET</strong>).
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
When the server responds, it does so by sending an <strong>iq</strong>-stanza response (type <strong>result</strong>) back to the client containing a <strong>resp</strong>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
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.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
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:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
<strong>text</strong>: 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.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
<strong>xml</strong>: 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 <strong>text</strong> encoding can be used as an alternative. The advantage of <strong>xml</strong>
|
||
|
|
instead of <strong>text</strong> or <strong>base64</strong> 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.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
<strong>base64</strong>: Base-64 encoded binary content. Can be used to easily embed binary content in the telegram.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
<strong>chunkedBase64</strong>: Chunked Base-64 encoded binary content. The content is not embedded in the telegram. Instead it is sent in chunks, using separate
|
||
|
|
<strong>chunk</strong> 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 <strong>streamBase64</strong> encoding with the (loose) distinction that a stream is indefinite, while chunked transport conveys finitely sized content.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
<strong>sipub</strong>: 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.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
<strong>streamBase64</strong>: 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 <strong>chunkedBase64</strong> with the distinction that the content is indefinite. This option is not available in requests, only in responses.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
<strong>jingle</strong>: For demanding multi-media streams alternative methods to transport streaming rather than embedded into the XMPP stream may be
|
||
|
|
required. Even though the <strong>streamBase64</strong> 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;.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> Content endoded using <strong>chunkedBase64</strong> or <strong>streamBase64</strong> encoding methods can be terminated, either by the receptor going
|
||
|
|
off-line, or by sending a <strong>close</strong> command to the sender.
|
||
|
|
</p>
|
||
|
|
<section2 topic='HTTP Methods'>
|
||
|
|
<p>
|
||
|
|
The following use cases show how different HTTP methods may work when transported over XMPP. To facilitate the readability in these examples,
|
||
|
|
simple text or xml results are shown.
|
||
|
|
</p>
|
||
|
|
<section3 topic='OPTIONS' anchor='OPTIONS'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of an OPTIONS method call. OPTIONS is described in <link url='http://tools.ietf.org/html/rfc2616#section-9.2'>§9.2 in RFC 2616</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='OPTIONS'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='1'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='OPTIONS' resource='*' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='1'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 13:52:10 GMT-4'/>
|
||
|
|
<header name='Allow' value='OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE'/>
|
||
|
|
<header name='Content-Length' value='0'/>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='GET' anchor='GET'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a GET method call. GET is described in <link url='http://tools.ietf.org/html/rfc2616#section-9.3'>§9.3 in RFC 2616</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='GET'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='2'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='GET' resource='/rdf/ex1.turtle' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='2'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 16:39:54GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='text/turtle'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<header name='Connection' value='Close'/>
|
||
|
|
<data>
|
||
|
|
<text>@base <http://example.org/> .
|
||
|
|
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
||
|
|
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
||
|
|
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
|
||
|
|
@prefix rel: <http://www.perceive.net/schemas/relationship/> .
|
||
|
|
|
||
|
|
<#green-goblin>
|
||
|
|
rel:enemyOf <#spiderman> ;
|
||
|
|
a foaf:Person ; # in the context of the Marvel universe
|
||
|
|
foaf:name "Green Goblin" .
|
||
|
|
|
||
|
|
<#spiderman>
|
||
|
|
rel:enemyOf <#green-goblin> ;
|
||
|
|
a foaf:Person ;
|
||
|
|
foaf:name "Spiderman", "Человек-паук"@ru .</text>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> The XMPP/HTTP bridge at the server only transmits headers literally as they are reported, as if it was normal HTTP over TCP
|
||
|
|
that was used. In the HTTP over XMPP case, connections are not handled in the same way, and so the "Connection: Close" header has no meaning in this
|
||
|
|
case. For more information about connection handling in the HTTP over XMPP case, see the section on <link url='#httpconnections'>Connection Handling</link>.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
<strong>Note 2:</strong> The above Turtle example was taken from <link url='http://www.w3.org/TR/turtle/#sec-intro'>http://www.w3.org/TR/turtle/#sec-intro</link>.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='HEAD' anchor='HEAD'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a HEAD method call. HEAD is described in <link url='http://tools.ietf.org/html/rfc2616#section-9.4'>§9.4 in RFC 2616</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='HEAD'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='3'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='HEAD' resource='/video/video1.m4' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='3'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 16:57:12GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='video/mp4'/>
|
||
|
|
<header name='Content-Length' value='12345678'/>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='POST' anchor='POST'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a POST method call. POST is described in <link url='http://tools.ietf.org/html/rfc2616#section-9.5'>§9.5 in RFC 2616</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='POST'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='4'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='POST' resource='/sparql/?default-graph-uri=http%3A%2F%2Fanother.example%2Fcalendar.rdf' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
<header name='User-agent' value='Clayster HTTP/XMPP Client'/>
|
||
|
|
<header name='Content-Type' value='application/sparql-query'/>
|
||
|
|
<data>
|
||
|
|
<text>PREFIX foaf: <http://xmlns.com/foaf/0.1/>
|
||
|
|
SELECT ?name ?mbox ?hpage
|
||
|
|
WHERE { ?x foaf:name ?name .
|
||
|
|
OPTIONAL { ?x foaf:mbox ?mbox } .
|
||
|
|
OPTIONAL { ?x foaf:homepage ?hpage }
|
||
|
|
}
|
||
|
|
</text>
|
||
|
|
</data>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='4'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 17:09:34-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='application/sparql-results+xml'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<xml>
|
||
|
|
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
|
||
|
|
<head>
|
||
|
|
<variable name="name"/>
|
||
|
|
<variable name="mbox"/>
|
||
|
|
<variable name="hpage"/>
|
||
|
|
</head>
|
||
|
|
<results>
|
||
|
|
<result>
|
||
|
|
<binding name="name">
|
||
|
|
<literal>Alice</literal>
|
||
|
|
</binding>
|
||
|
|
<binding name="hpage">
|
||
|
|
<literal><http://work.example.org/alice/></literal>
|
||
|
|
</binding>
|
||
|
|
</result>
|
||
|
|
<result>
|
||
|
|
<binding name="name">
|
||
|
|
<literal>Bob</literal>
|
||
|
|
</binding>
|
||
|
|
<binding name="mbox">
|
||
|
|
<literal><mailto:bob@work.example></literal>
|
||
|
|
</binding>
|
||
|
|
</result>
|
||
|
|
</results>
|
||
|
|
</sparql>
|
||
|
|
</xml>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> The above SPARQL example was taken from <link url='http://www.w3.org/TR/sparql11-query/#MultipleOptionals'>http://www.w3.org/TR/sparql11-query/#MultipleOptionals</link>
|
||
|
|
in combination with <link url='http://www.w3.org/TR/sparql11-protocol/#select-longpost'>http://www.w3.org/TR/sparql11-protocol/#select-longpost</link>.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
<strong>Note 2:</strong> If using <strong>xml</strong> encoding of data, care has to be taken to avoid including the version and encoding information
|
||
|
|
(<?xml version="1.0"?>) at the top of the document, otherwise the resulting XML will be invalid.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='PUT' anchor='PUT'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a PUT method call. PUT is described in <link url='http://tools.ietf.org/html/rfc2616#section-9.6'>§9.6 in RFC 2616</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='PUT'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='5'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='PUT' resource='/index.html' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
<header name='Content-Type' value='text/html'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<text><html><header/><body><p>Beautiful home page.</p></body></html></text>
|
||
|
|
</data>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='5'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='204' statusMessage='No Content'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 17:40:41GMT-4'/>
|
||
|
|
<header name='Content-Length' value='0'/>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='DELETE' anchor='DELETE'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a DELETE method call. DELETE is described in <link url='http://tools.ietf.org/html/rfc2616#section-9.7'>§9.7 in RFC 2616</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='DELETE'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='6'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='DELETE' resource='/index.html' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='6'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='403' statusMessage='Forbidden'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 17:46:07GMT-4'/>
|
||
|
|
<header name='Content-Type' value='text/plain'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<text>You're not allowed to change the home page!</text>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='TRACE' anchor='TRACE'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a TRACE method call. TRACE is described in <link url='http://tools.ietf.org/html/rfc2616#section-9.8'>§9.8 in RFC 2616</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='TRACE'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='7'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='TRACE' resource='/rdf/ex1.turtle' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='7'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 17:55:10GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='message/http'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<text>GET /rdf/ex1.turtle HTTP/1.1
|
||
|
|
Host: clayster.com</text>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> The Trace command returns the request it received from the client by the server. Here, however, it is assumed that the request
|
||
|
|
is made over HTTP/TCP, not HTTP/XMPP. Therefore, in this example, the XMPP layer has transformed the HTTP/XMPP request into an HTTP/TCP-looking
|
||
|
|
request, which is returned as the response to the TRACE Method call. RFC 2616 is silent to the actual format of the TRACE response
|
||
|
|
(MIME TYPE message/http), and TRACE is only used (if not disabled for security reasons) for debugging connections and routing via proxies.
|
||
|
|
Therefore, a response returning the original XMPP request should also be accepted by the caller.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='PATCH' anchor='PATCH'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a PATCH method call. PATCH is described in <link url='http://tools.ietf.org/html/rfc5789'>RFC 5789</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='PATCH'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='8'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='PATCH' resource='/file.txt' version='1.1'>
|
||
|
|
<header name='Host' value='www.example.com'/>
|
||
|
|
<header name='Content-Type' value='application/example'/>
|
||
|
|
<header name='If-Match' value='e0023aa4e'/>
|
||
|
|
<header name='Content-Length' value='100'/>
|
||
|
|
<data>
|
||
|
|
[description of changes]
|
||
|
|
</data>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='8'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='204' statusMessage='No Content'>
|
||
|
|
<header name='Content-Location' value='/file.txt'/>
|
||
|
|
<header name='ETag' value='e0023aa4e'/>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> The example is taken from <link url='http://tools.ietf.org/html/rfc5789#section-2.1'>§2.1 RFC 5789</link>.
|
||
|
|
</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='Response formats'>
|
||
|
|
<p>
|
||
|
|
In the following sub-sections, the different data encoding formats are discussed with corresponding examples to illustrate how they work.
|
||
|
|
The interesting part of these examples is the <strong>data</strong> element and its contents.
|
||
|
|
</p>
|
||
|
|
<section3 topic='Text'>
|
||
|
|
<p>
|
||
|
|
Text responses is a simple way to return text responses (i.e. any MIME Type starting with text/). Since the text is embedded into XML, the
|
||
|
|
characters <, > and & need to be escaped to &lt;, &gt; and &amp; respectively.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
The following example shows how a TURTLE response, which is text-based, is returned using the <strong>text</strong> encoding:
|
||
|
|
</p>
|
||
|
|
<example caption='Text'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='2'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 16:39:54GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='text/turtle'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<header name='Connection' value='Close'/>
|
||
|
|
<data>
|
||
|
|
<text>@base <http://example.org/> .
|
||
|
|
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
||
|
|
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
||
|
|
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
|
||
|
|
@prefix rel: <http://www.perceive.net/schemas/relationship/> .
|
||
|
|
|
||
|
|
<#green-goblin>
|
||
|
|
rel:enemyOf <#spiderman> ;
|
||
|
|
a foaf:Person ; # in the context of the Marvel universe
|
||
|
|
foaf:name "Green Goblin" .
|
||
|
|
|
||
|
|
<#spiderman>
|
||
|
|
rel:enemyOf <#green-goblin> ;
|
||
|
|
a foaf:Person ;
|
||
|
|
foaf:name "Spiderman", "Человек-паук"@ru .</text>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='XML'>
|
||
|
|
<p>
|
||
|
|
XML is a conveniant way to return XML embedded in the XMPP response. This can be suitable for MIME Types of the form <strong>.*/(.*[+])?xml</strong>
|
||
|
|
(using regular expression to match them), like text/xml, application/soap+xml or application/sparql-results+xml. Care has to be taken however, since
|
||
|
|
not all XML constructs can be embedded as content to an XML element without invalidating it, like the xml version and encoding declaration
|
||
|
|
(<?xml version="1.0"?> as an example).
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
If unsure how to handle XML responses using the <strong>xml</strong> encoding type, you can equally well use the <strong>text</strong> type, but
|
||
|
|
encode the XML escape characters <, > and &, or use another encoding, like <strong>base64</strong>.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
The advantage of <strong>xml</strong> instead of <strong>text</strong> or <strong>base64</strong> encodings is when used in conjuncion with
|
||
|
|
<link url='http://xmpp.org/extensions/xep-0322.html'>EXI compression</link>. 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.
|
||
|
|
</p>
|
||
|
|
<example caption='POST'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='4'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 17:09:34-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='application/sparql-results+xml'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<xml>
|
||
|
|
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
|
||
|
|
<head>
|
||
|
|
<variable name="name"/>
|
||
|
|
<variable name="mbox"/>
|
||
|
|
<variable name="hpage"/>
|
||
|
|
</head>
|
||
|
|
<results>
|
||
|
|
<result>
|
||
|
|
<binding name="name">
|
||
|
|
<literal>Alice</literal>
|
||
|
|
</binding>
|
||
|
|
<binding name="hpage">
|
||
|
|
<literal><http://work.example.org/alice/></literal>
|
||
|
|
</binding>
|
||
|
|
</result>
|
||
|
|
<result>
|
||
|
|
<binding name="name">
|
||
|
|
<literal>Bob</literal>
|
||
|
|
</binding>
|
||
|
|
<binding name="mbox">
|
||
|
|
<literal><mailto:bob@work.example></literal>
|
||
|
|
</binding>
|
||
|
|
</result>
|
||
|
|
</results>
|
||
|
|
</sparql>
|
||
|
|
</xml>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Base-64 encoding'>
|
||
|
|
<p>
|
||
|
|
Base-64 encoding is a simple way to encode content that is easilly embedded into XML. Apart from the advantage of being easy to encode,
|
||
|
|
it has the disadvantage to increase the size of the content by 33% (unless EXI compression is used at the same time), since it requires
|
||
|
|
4 bytes to encode 3 bytes of data. Care has to be taken not to send too large items using this encoding.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
The following example shows an image is returned using the <strong>base64</strong> encoding:
|
||
|
|
</p>
|
||
|
|
<example caption='Base-64 encoding'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='9'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 16:39:54GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='image/png'/>
|
||
|
|
<header name='Content-Length' value='221203'/>
|
||
|
|
<data>
|
||
|
|
<base64>iVBORw0KGgoAAAANSUhEUgAAASwAAAGQCAYAAAAUdV17AAAAAXNSR0 ... tVWJd+e+y1AAAAABJRU5ErkJggg==</base64>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Chunked Base-64 encoding'>
|
||
|
|
<p>
|
||
|
|
In HTTP, Chunked Transfer Encoding is used when the sender does not know the size of the content being sent, and to avoid having its buffers
|
||
|
|
overflow, sends the content in chunks with a definite size.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
A similar method exists in the HTTP over XMPP transport: The <strong>chunkedBase64</strong> allows the sender to transmit the content in chunks.
|
||
|
|
Every chunk is base-64 encoded. The stream of chunks are identified by a <strong>streamId</strong> parameter, since chunks from different responses
|
||
|
|
may be transmitted at the same time.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Another difference between normal chunked transport, and the <strong>chunkedBase64</strong> encoding, is that the size of chunks does not have to be
|
||
|
|
predetermined. Chunks are naturally delimited and embedded in the XML stanza. The last chunk in a response must have the <strong>last</strong>
|
||
|
|
attribute set to true.
|
||
|
|
</p>
|
||
|
|
<example caption='Chunked Base-64 encoding'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='10'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 04 May 2013 13:43:12GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='image/png'/>
|
||
|
|
<header name='Content-Length' value='221203'/>
|
||
|
|
<data>
|
||
|
|
<chunkedBase64 streamId='Stream0001'/>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<message from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'>
|
||
|
|
<chunk xmlns='urn:xmpp:http' streamid='Stream0001'>iVBORw0KGgoAAAANSUhEUgAAASwAAAGQCAYAA ...</chunk>
|
||
|
|
</message>
|
||
|
|
|
||
|
|
...
|
||
|
|
|
||
|
|
<message from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'>
|
||
|
|
<chunk xmlns='urn:xmpp:http' streamid='Stream0001' last='true'>... 2uPzi9u+tVWJd+e+y1AAAAABJRU5ErkJggg==</chunk>
|
||
|
|
</message>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> Chunked encoding assumes the content to be finite. If content is infinite (i.e. for instance live streaming),
|
||
|
|
the <strong>streamBase64</strong> transfer encoding must be used instead. If the sender is unsure if the content is finit or inifinite,
|
||
|
|
the <strong>streamBase64</strong> must be used.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='File'>
|
||
|
|
<p>
|
||
|
|
Often content being sent can be represented by a file, virtual or real, especially if the content actually represents a file and is not
|
||
|
|
dynamically generated. In these instances, instead of embedding the contents in the response,
|
||
|
|
since content can be potentially huge, a File Stream Initiation is returned instead, as defined in
|
||
|
|
<link url='http://xmpp.org/extensions/xep-0137.html'>XEP 0137: Publishing Stream Initiation Requests</link>. This is done using the
|
||
|
|
<strong>sipub</strong> element.
|
||
|
|
</p>
|
||
|
|
<example caption='File'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='11'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 16:39:54GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='image/png'/>
|
||
|
|
<header name='Content-Length' value='221203'/>
|
||
|
|
<data>
|
||
|
|
<sipub xmlns='http://jabber.org/protocol/sipub'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
id='file-0001'
|
||
|
|
mime-type='image/png'
|
||
|
|
profile='http://jabber.org/protocol/si/profile/file-transfer'>
|
||
|
|
<file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
|
||
|
|
name='Kermit.png'
|
||
|
|
size='221203'
|
||
|
|
date='2013-03-06T16:47Z'/>
|
||
|
|
</sipub>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Streams' anchor='#streams'>
|
||
|
|
<p>
|
||
|
|
Some web servers provide streaming content, i.e. content where packets are sent according to a timely fashion. Examples are video
|
||
|
|
and audio streams like HLS (HTTP Live Streams), SHOUTcast, ICEcast, Motion JPeg, etc. In all these examples, content is infinite,
|
||
|
|
and cannot be sent "all as quickly as possible". Instead, content is sent according to some kind of bitrate or frame rate for
|
||
|
|
example.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Such content must use the <strong>streamBase64</strong> encoding scheme, if used. The <strong>streamBase64</strong> is similar to
|
||
|
|
the <strong>chunkedBase64</strong> encoding, except it is imlicitly understood that the stream can be indefinite and needs an
|
||
|
|
explicit way to close the stream. Closing the stream is done by sending a <strong>close</strong> command to the sender of the
|
||
|
|
stream. The <strong>close</strong> command can also be used to close a chunked stream, and senders of chunked data should
|
||
|
|
support terminating the output if a <strong>close</strong> command on the stream is received.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> All streams (or chunked responses) are automatically closed if one of the parties goes off-line.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
<strong>Note 2:</strong> A streamed response does not need to be indefinite. It can be finite. If it is finite, the last chunk
|
||
|
|
must have the <strong>last</strong> attribute set to true.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
<strong>Note 3:</strong> The <strong>close</strong> command can be sent using a message or iq stanza. Use iq stanzas if a
|
||
|
|
response is desired. The response will be the same close command sent.
|
||
|
|
</p>
|
||
|
|
<example caption='Streamed Base-64 encoding'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='12'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='GET' resource='/webcam1.jpg' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='12'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 04 May 2013 15:05:32GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='multipart/x-mixed-replace;boundary=__2347927492837489237492837'/>
|
||
|
|
<data>
|
||
|
|
<chunkedBase64 streamId='Stream0002'/>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<message from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'>
|
||
|
|
<chunk xmlns='urn:xmpp:http' streamid='Stream0002'>...</chunk>
|
||
|
|
</message>
|
||
|
|
|
||
|
|
...
|
||
|
|
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='13'>
|
||
|
|
<close xmlns='urn:xmpp:http' streamId='Stream00002'/>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='13'>
|
||
|
|
<close xmlns='urn:xmpp:http' streamId='Stream00002'/>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Jingle' anchor='jingle'>
|
||
|
|
<p>
|
||
|
|
For demanding multi-media streams alternative methods to transport streaming rather than embedded into the XMPP stream may be
|
||
|
|
required. Even though the <strong>streamBase64</strong> 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 <link url='http://xmpp.org/extensions/xep-0166.html'>XEP 0166: Jingle</link>.
|
||
|
|
</p>
|
||
|
|
<example caption='Jingle'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='14'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 16:39:54GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='video/mp4'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<jingle xmlns='urn:xmpp:jingle:1'
|
||
|
|
action='session-initiate'
|
||
|
|
initiator='romeo@montague.lit/orchard'
|
||
|
|
sid='a73sjjvkla37jfea'>
|
||
|
|
<content creator='initiator' name='voice'>
|
||
|
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
|
||
|
|
<payload-type id='96' name='speex' clockrate='16000'/>
|
||
|
|
<payload-type id='97' name='speex' clockrate='8000'/>
|
||
|
|
<payload-type id='18' name='G729'/>
|
||
|
|
<payload-type id='0' name='PCMU' />
|
||
|
|
<payload-type id='103' name='L16' clockrate='16000' channels='2'/>
|
||
|
|
<payload-type id='98' name='x-ISAC' clockrate='8000'/>
|
||
|
|
</description>
|
||
|
|
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
|
||
|
|
pwd='asd88fgpdd777uzjYhagZg'
|
||
|
|
ufrag='8hhy'>
|
||
|
|
<candidate component='1'
|
||
|
|
foundation='1'
|
||
|
|
generation='0'
|
||
|
|
id='el0747fg11'
|
||
|
|
ip='10.0.1.1'
|
||
|
|
network='1'
|
||
|
|
port='8998'
|
||
|
|
priority='2130706431'
|
||
|
|
protocol='udp'
|
||
|
|
type='host'/>
|
||
|
|
<candidate component='1'
|
||
|
|
foundation='2'
|
||
|
|
generation='0'
|
||
|
|
id='y3s2b30v3r'
|
||
|
|
ip='192.0.2.3'
|
||
|
|
network='1'
|
||
|
|
port='45664'
|
||
|
|
priority='1694498815'
|
||
|
|
protocol='udp'
|
||
|
|
rel-addr='10.0.1.1'
|
||
|
|
rel-port='8998'
|
||
|
|
type='srflx'/>
|
||
|
|
</transport>
|
||
|
|
</content>
|
||
|
|
</jingle>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> Example taken from <link url='http://xmpp.org/extensions/xep-0166.html#howitworks'>XEP 166: Jingle</link>.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
<strong>Note2:</strong> Using Jingle in this way makes it possible for an intelligent server to return multiple streams the client
|
||
|
|
can choose from, something that is not done in normal HTTP over TCP. The first candidate should however correspond to the same stream
|
||
|
|
that would have been returned if the request had been made using normal HTTP over TCP.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='Applications'>
|
||
|
|
<p>
|
||
|
|
The following section lists use cases based on type of application. It is used to illustrate what types of applications would benefit from
|
||
|
|
implementing this extension.
|
||
|
|
</p>
|
||
|
|
<section3 topic='Browsers'>
|
||
|
|
<p>
|
||
|
|
HTTP began as a protocol for presenting text in browsers. So, browsers is a natural place to start to list use cases for this extensions.
|
||
|
|
In general, content is identified using URL's, and in the browser a user enters the URL into Address Field of the browser, and the corresponding
|
||
|
|
content is displayed in the display area. The content itself will probably contain links to other content, each such item identified
|
||
|
|
by an absolute or relative URL.
|
||
|
|
</p>
|
||
|
|
<section4 topic='xmpp:// scheme' anchor='xmppscheme'>
|
||
|
|
<p>
|
||
|
|
A simplified way to describe an URL is to describe it as having three parts:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li>Scheme</li>
|
||
|
|
<li>Domain</li>
|
||
|
|
<li>Path</li>
|
||
|
|
</ul>
|
||
|
|
<p>
|
||
|
|
In the HTTP over TCP case, the scheme is <strong>http://</strong> or <strong>https://</strong>, and the domain is the name or IP address of the
|
||
|
|
web server with an optional port number. Some even allow for user credentials to be passed directly in the URL, something which is blocked in
|
||
|
|
many browsers, for security reasons.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
By creating a new scheme for HTTP over XMPP transport, and implementing support for it in web browsers, XML HTTP request objects and web servers,
|
||
|
|
Web Applications previously requiring web hosting on the Internet will be able to be hosted privatly behind firewalls instead, by simply switching
|
||
|
|
from the http:// scheme to an xmpp:// scheme. All relative URL's within the application, including URL's sent to the XHR object (Ajax) will automatically
|
||
|
|
be directed to use the HTTP over XMPP transport instead.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
So, this specification proposes a new transport for HTTP over XMPP, as follows:
|
||
|
|
</p>
|
||
|
|
<example caption='xmpp:// scheme'>
|
||
|
|
<![CDATA[
|
||
|
|
xmpp://Resourceless_JID/PATH]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
Here, the JID to use in the URL, must not include a resource. Only user name, the @ character and the domain. The / separator between the JID
|
||
|
|
and the Path is actually part of the Part.
|
||
|
|
</p>
|
||
|
|
<example caption='Examples of URLs with the xmpp scheme'>
|
||
|
|
<![CDATA[
|
||
|
|
xmpp://httpServer@clayster.com/index.html
|
||
|
|
xmpp://httpServer@clayster.com/images/image1.png
|
||
|
|
xmpp://httpServer@clayster.com/api?p1=a&p2=b]]>
|
||
|
|
</example>
|
||
|
|
</section4>
|
||
|
|
<section4 topic='Friendship requests'>
|
||
|
|
<p>
|
||
|
|
It's beyond the scope of this specification to define how browsers handles its own XMPP account(s) and roster. This section only
|
||
|
|
makes a suggestion to show how this can be handled. It is assumed in this discussion that the browser has a working XMPP
|
||
|
|
connection with a server, and has its own JID. For simplicity, we will assume the browser has only one connection. Extension to
|
||
|
|
multiple connection is canonical.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
When resolving an URL using the xmpp scheme, the browser needs to extract the JID of the server hosting the resource. If that JID
|
||
|
|
is already in the roster, the request can proceed as usual.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
If not in the roster, the browser needs to send a friendship request. A non-exhaustive list of states could be made:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li>No response: This could be presented as a connection to the content server being made.</li>
|
||
|
|
<li>Request rejected: This could be handled in the same way as HTTP Error Forbidden.</li>
|
||
|
|
<li>Request accepted: Connection made, proceed with fetching content.</li>
|
||
|
|
<li>Timeout: If no friendship request response have been returned, the browser can choose to time out.</li>
|
||
|
|
</ul>
|
||
|
|
<p>
|
||
|
|
Since XMPP works both ways, the browser can receive friendship requests from the outside world. Any such requests should be displayed to the
|
||
|
|
end user, if any, or rejected.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
For more information, see <link url='#rosterclient'>Roster Handling in web clients</link> and
|
||
|
|
<link url='#rosterserver'>Roster Handling in web servers</link>.
|
||
|
|
</p>
|
||
|
|
</section4>
|
||
|
|
<section4 topic='Seamless use of web applications hosted at home'>
|
||
|
|
<p>
|
||
|
|
Today, most people who want to host their own web applications (HTML/HTTP based applications) need to host them on a server publicly
|
||
|
|
available on the Internet. However, many applications of a private nature like a family blog, home automation system, etc., is not
|
||
|
|
suited for public hosting, since it puts all private data at risk of being compromised, or access to home security functions (like
|
||
|
|
home web cams) to get in the hands of people you don't want to have access to them.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
To solve this, one can host the application on a server at home, perhaps a small cheap plug computer consuming as little as 1 or 2 Watts
|
||
|
|
of electricity, using a web server supporting this extension. If the following design rules are followed, the application should be visible
|
||
|
|
in any browser also supporting this extensions, as long as friendship exists between the browser and the web server:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
Only relative URL's are used within references (images, audio, video, links, objekts, etc.). If absolute URL's are used (including scheme),
|
||
|
|
the browser might get the first page correctly, but will be unable to get the content with the absolute URL, unless the URL has the same scheme
|
||
|
|
as the principal page.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
URL's to web forms must also be relative, for the same reason.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
<li>
|
||
|
|
<p>
|
||
|
|
Any URL's sent to the XML HTTP Request Object directed to API's or resources hosted by the same application must also be relative,
|
||
|
|
for the same reasons as above. The XHR Object supports relative URL's.
|
||
|
|
</p>
|
||
|
|
</li>
|
||
|
|
</ul>
|
||
|
|
<p>
|
||
|
|
If the above rules are met, which they should under normal conditions as well, typing in the xmpp:// URL in the browser (for instance when
|
||
|
|
you're at the office) should display the application (hosted for example at home behind a firewall) in the same way as when you use http://
|
||
|
|
(or https://) when you have access to the server (for instance when you're home), as long as friendship exists between the browser JID and
|
||
|
|
the server JID.
|
||
|
|
</p>
|
||
|
|
</section4>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Web Services'>
|
||
|
|
<p>
|
||
|
|
Many applications use a Service Oriented Architecture (SOA) and use web services to communicate between clients and servers. These web services
|
||
|
|
are mostly HTTP over TCP based, even though there are bindings which are not based on this. The most common APIs today (REST) are however all
|
||
|
|
based on HTTP over TCP. Being HTTP over TCP requires the web server hosting the web services either to be public or directly accessible by the
|
||
|
|
client. But as the services move closer to end users (for instance a Thermostat publishing a REST API for control in your home), problems arise
|
||
|
|
when you try to access the web service outside of private network in which the API is available. As explained previously, the HTTP over XMPP solves this.
|
||
|
|
</p>
|
||
|
|
<section4 topic='SOAP'>
|
||
|
|
<p>
|
||
|
|
The following example shows a simple SOAP method call, taken from
|
||
|
|
<link url='http://www.w3schools.com/soap/soap_example.asp'>http://www.w3schools.com/soap/soap_example.asp</link>:
|
||
|
|
</p>
|
||
|
|
<example caption='SOAP method call'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@example.com'
|
||
|
|
id='15'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='POST' resource='/InStock' version='1.1'>
|
||
|
|
<header name='Host' value='www.example.com'/>
|
||
|
|
<header name='Content-Type' value='application/soap+xml; charset=utf-8'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<xml>
|
||
|
|
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
|
||
|
|
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
|
||
|
|
<soap:Body xmlns:m="http://www.example.org/stock">
|
||
|
|
<m:GetStockPrice>
|
||
|
|
<m:StockName>IBM</m:StockName>
|
||
|
|
</m:GetStockPrice>
|
||
|
|
</soap:Body>
|
||
|
|
</soap:Envelope>
|
||
|
|
</xml>
|
||
|
|
</data>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@example.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='15'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Content-Type' value='application/soap+xml; charset=utf-8'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<xml>
|
||
|
|
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
|
||
|
|
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
|
||
|
|
<soap:Body xmlns:m="http://www.example.org/stock">
|
||
|
|
<m:GetStockPriceResponse>
|
||
|
|
<m:Price>34.5</m:Price>
|
||
|
|
</m:GetStockPriceResponse>
|
||
|
|
</soap:Body>
|
||
|
|
</soap:Envelope>
|
||
|
|
</xml>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> Other components of SOAP, such as WSDL and disco-documents are just examples of content
|
||
|
|
handled by simple <link url='#GET'>GET</link> requests.
|
||
|
|
</p>
|
||
|
|
</section4>
|
||
|
|
<section4 topic='REST'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a REST method call. REST method calls are just simple <link url='#GET'>GET</link>,
|
||
|
|
<link url='#POST'>POST</link>, <link url='#PUT'>PUT</link> or <link url='#DELETE'>DELETE</link> HTTP calls with
|
||
|
|
dynamically generated content.
|
||
|
|
</p>
|
||
|
|
<example caption='REST'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='16'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='GET' resource='/api/multiplicationtable?m=5' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='16'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 05 May 2013 15:01:53GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='text/xml'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<xml>
|
||
|
|
<table>
|
||
|
|
<value n='1' nTimesM='5'/>
|
||
|
|
<value n='2' nTimesM='10'/>
|
||
|
|
<value n='3' nTimesM='15'/>
|
||
|
|
<value n='4' nTimesM='20'/>
|
||
|
|
<value n='5' nTimesM='25'/>
|
||
|
|
<value n='6' nTimesM='30'/>
|
||
|
|
<value n='7' nTimesM='35'/>
|
||
|
|
<value n='8' nTimesM='40'/>
|
||
|
|
<value n='9' nTimesM='45'/>
|
||
|
|
<value n='10' nTimesM='50'/>
|
||
|
|
</table>
|
||
|
|
</xml>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
</section4>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Semantic Web & IoT'>
|
||
|
|
<p>
|
||
|
|
The Semantic Web was originally developed as a way to link data between servers on the Web, and understand it. However, with the advents
|
||
|
|
of technologies such as <link url='http://www.w3.org/TR/sparql11-query/'>SPARQL</link>, the Semantic Web has become a way to
|
||
|
|
unify API's into a universal form of distributed API to all types of data possible. It also alows for a standardized way to perform
|
||
|
|
grid computing, in the sense that queries can be federated and executed in a distributed fashion ("in the grid").
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
For these reasons, and others, semantic web technologies have been moving closer to Internet of Things, and also into the private spheres
|
||
|
|
of its end users. Since the semantic web technologies are based on HTTP, they also suffer from the shortcomings of HTTP over TCP, when it
|
||
|
|
comes to firewalls and user authentication and authorization. Allowing HTTP transport over XMPP greatly improves the reach of semantic
|
||
|
|
technologies beyond "The Internet" while at the same time improving security and controllability of the information.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
As the semantic web comes closed to Internet of Things and the world of XMPP, it can benefit from work done with relation to the Internet of
|
||
|
|
Things, such as &xep0324;, which would give automatic control of who (or what) can communicate with whom (or what).
|
||
|
|
</p>
|
||
|
|
<section4 topic='Turtle'>
|
||
|
|
<p>
|
||
|
|
Turtle <note>
|
||
|
|
Turtle: Terse RDF Triple Language <<link url='http://www.w3.org/TR/turtle/'>http://www.w3.org/TR/turtle/</link>>
|
||
|
|
</note>, is a simple way to represent semantic data. The following example shows Turtle-encoded semantic data being returned
|
||
|
|
to the client as a response to a request.
|
||
|
|
</p>
|
||
|
|
<example caption='Turtle'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='2'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 16:39:54GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='text/turtle'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<header name='Connection' value='Close'/>
|
||
|
|
<data>
|
||
|
|
<text>@base <http://example.org/> .
|
||
|
|
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
|
||
|
|
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
|
||
|
|
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
|
||
|
|
@prefix rel: <http://www.perceive.net/schemas/relationship/> .
|
||
|
|
|
||
|
|
<#green-goblin>
|
||
|
|
rel:enemyOf <#spiderman> ;
|
||
|
|
a foaf:Person ; # in the context of the Marvel universe
|
||
|
|
foaf:name "Green Goblin" .
|
||
|
|
|
||
|
|
<#spiderman>
|
||
|
|
rel:enemyOf <#green-goblin> ;
|
||
|
|
a foaf:Person ;
|
||
|
|
foaf:name "Spiderman", "Человек-паук"@ru .</text>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> The above example was taken from <link url='http://www.w3.org/TR/turtle/#sec-intro'>http://www.w3.org/TR/turtle/#sec-intro</link>.
|
||
|
|
</p>
|
||
|
|
</section4>
|
||
|
|
<section4 topic='RDF'>
|
||
|
|
<p>
|
||
|
|
RDF <note>
|
||
|
|
RDF: Resource Description Framework <<link url='http://www.w3.org/RDF/'>http://www.w3.org/RDF/</link>>
|
||
|
|
</note>, is a another way to represent semantic data, better suited than Turtle for M2M communication. Related technologies,
|
||
|
|
such as the micro format RDFa <note>
|
||
|
|
RDFa: RDF through attributes <<link url='http://www.w3.org/TR/rdfa-syntax/'>http://www.w3.org/TR/rdfa-syntax/</link>>
|
||
|
|
</note> allows for embedding RDF into HTML pages or XML documents. The following example shows RDF-encoded semantic data being returned
|
||
|
|
to the client as a response to a request.
|
||
|
|
</p>
|
||
|
|
<example caption='RDF'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='17'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 05 May 2013 16:02:23GMT-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='application/rdf+xml'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<xml>
|
||
|
|
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||
|
|
xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#">
|
||
|
|
<contact:Person rdf:about="http://www.w3.org/People/EM/contact#me">
|
||
|
|
<contact:fullName>Eric Miller</contact:fullName>
|
||
|
|
<contact:mailbox rdf:resource="mailto:em@w3.org"/>
|
||
|
|
<contact:personalTitle>Dr.</contact:personalTitle>
|
||
|
|
</contact:Person>
|
||
|
|
</rdf:RDF>
|
||
|
|
</xml>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> The above example was taken from
|
||
|
|
<link url='http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#intro'>http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#intro</link>.
|
||
|
|
</p>
|
||
|
|
</section4>
|
||
|
|
<section4 topic='SPARQL'>
|
||
|
|
<p>
|
||
|
|
This section shows an example of a SPARQL query executed as a POST call.
|
||
|
|
</p>
|
||
|
|
<example caption='SPARQL'>
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='4'>
|
||
|
|
<req xmlns='urn:xmpp:http' method='POST' resource='/sparql/?default-graph-uri=http%3A%2F%2Fanother.example%2Fcalendar.rdf' version='1.1'>
|
||
|
|
<header name='Host' value='clayster.com'/>
|
||
|
|
<header name='User-agent' value='Clayster HTTP/XMPP Client'/>
|
||
|
|
<header name='Content-Type' value='application/sparql-query'/>
|
||
|
|
<data>
|
||
|
|
<text>PREFIX foaf: <http://xmlns.com/foaf/0.1/>
|
||
|
|
SELECT ?name ?mbox ?hpage
|
||
|
|
WHERE { ?x foaf:name ?name .
|
||
|
|
OPTIONAL { ?x foaf:mbox ?mbox } .
|
||
|
|
OPTIONAL { ?x foaf:homepage ?hpage }
|
||
|
|
}
|
||
|
|
</text>
|
||
|
|
</data>
|
||
|
|
</req>
|
||
|
|
</iq>
|
||
|
|
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='4'>
|
||
|
|
<resp xmlns='urn:xmpp:http' version='1.1' statusCode='200' statusMessage='OK'>
|
||
|
|
<header name='Date' value='Fri, 03 May 2013 17:09:34-4'/>
|
||
|
|
<header name='Server' value='Clayster'/>
|
||
|
|
<header name='Content-Type' value='application/sparql-results+xml'/>
|
||
|
|
<header name='Content-Length' value='...'/>
|
||
|
|
<data>
|
||
|
|
<xml>
|
||
|
|
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
|
||
|
|
<head>
|
||
|
|
<variable name="name"/>
|
||
|
|
<variable name="mbox"/>
|
||
|
|
<variable name="hpage"/>
|
||
|
|
</head>
|
||
|
|
<results>
|
||
|
|
<result>
|
||
|
|
<binding name="name">
|
||
|
|
<literal>Alice</literal>
|
||
|
|
</binding>
|
||
|
|
<binding name="hpage">
|
||
|
|
<literal><http://work.example.org/alice/></literal>
|
||
|
|
</binding>
|
||
|
|
</result>
|
||
|
|
<result>
|
||
|
|
<binding name="name">
|
||
|
|
<literal>Bob</literal>
|
||
|
|
</binding>
|
||
|
|
<binding name="mbox">
|
||
|
|
<literal><mailto:bob@work.example></literal>
|
||
|
|
</binding>
|
||
|
|
</result>
|
||
|
|
</results>
|
||
|
|
</sparql>
|
||
|
|
</xml>
|
||
|
|
</data>
|
||
|
|
</resp>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
<strong>Note:</strong> The above SPARQL example was taken from <link url='http://www.w3.org/TR/sparql11-query/#MultipleOptionals'>http://www.w3.org/TR/sparql11-query/#MultipleOptionals</link>
|
||
|
|
in combination with <link url='http://www.w3.org/TR/sparql11-protocol/#select-longpost'>http://www.w3.org/TR/sparql11-protocol/#select-longpost</link>.
|
||
|
|
</p>
|
||
|
|
</section4>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Streams'>
|
||
|
|
<p>
|
||
|
|
There are many types of streams and streaming protocols. Several of these are based on HTTP or variants simulating HTTP. Examples of such HTTP-based or
|
||
|
|
pseudo-HTTP based streaming protocols can include <note>
|
||
|
|
HLS: HTTP Live Streaming <<link url='http://en.wikipedia.org/wiki/HTTP_Live_Streaming'>http://en.wikipedia.org/wiki/HTTP_Live_Streaming</link>>
|
||
|
|
</note> used for multi-media streaming,
|
||
|
|
<note>
|
||
|
|
SHOUTcast <<link url='http://en.wikipedia.org/wiki/SHOUTcast'>http://en.wikipedia.org/wiki/SHOUTcast</link>>
|
||
|
|
</note> used for internet radio and
|
||
|
|
<note>
|
||
|
|
Motion JPeg <<link url='http://en.wikipedia.org/wiki/Motion_JPEG'>http://en.wikipedia.org/wiki/Motion_JPEG</link>>
|
||
|
|
</note> common format for web cameras.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Common for all streaming data, is that they are indefinite, but at the same time rate-limited depending on quality, etc. Because of this, the
|
||
|
|
web server is requried to use the <link url='#streams'>streamsBase64 encoding</link> or the <link url='#jingle'>Jingle</link> encoding to
|
||
|
|
transport the content to the client.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
</section2>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Determining Support' anchor='support'>
|
||
|
|
<p>If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:http" in response to &xep0030; information requests.</p>
|
||
|
|
<example caption="Service discovery information request">
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='get'
|
||
|
|
from='httpclient@clayster.com/browser'
|
||
|
|
to='httpserver@clayster.com'
|
||
|
|
id='disco1'>
|
||
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<example caption="Service discovery information response">
|
||
|
|
<![CDATA[
|
||
|
|
<iq type='result'
|
||
|
|
from='httpserver@clayster.com'
|
||
|
|
to='httpclient@clayster.com/browser'
|
||
|
|
id='disco1'>
|
||
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||
|
|
...
|
||
|
|
<feature var='urn:xmpp:http'/>
|
||
|
|
...
|
||
|
|
</query>
|
||
|
|
</iq>]]>
|
||
|
|
</example>
|
||
|
|
<p>
|
||
|
|
In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined
|
||
|
|
in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
|
||
|
|
</p>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Implementation Notes' anchor='impl'>
|
||
|
|
<section2 topic='Connection handling' anchor='httpconnections'>
|
||
|
|
<p>
|
||
|
|
HTTP over TCP includes headers for connection handling. The basic sequence for an HTTP request might be:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li>Client connects to server</li>
|
||
|
|
<li>Clients sends request</li>
|
||
|
|
<li>Client received response</li>
|
||
|
|
<li>Client closes connection</li>
|
||
|
|
</ul>
|
||
|
|
<p>
|
||
|
|
However, in the HTTP over XMPP case, there are no connections between the client and the server. Both clients and servers
|
||
|
|
have active connections to the XMPP Server, but these remain unchanged during the sequence of requests. Therefore, both
|
||
|
|
clients and servers should ignore any HTTP over TCP connection settings, since they have no meaning in the HTTP over XMPP
|
||
|
|
case. However, the corresponding headers should always be transported as is, to maintain the information.
|
||
|
|
</p>
|
||
|
|
</section2>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='Security Considerations' anchor='security'>
|
||
|
|
<p>
|
||
|
|
It's beyond the scope of this document to define how HTTP clients or HTTP servers handle rosters internally. The following
|
||
|
|
sections list suggestions on how these can be handled by different parties.
|
||
|
|
</p>
|
||
|
|
<section2 topic='Roster handling in browsers' anchor='rosterclient'>
|
||
|
|
<p>
|
||
|
|
Since browsers are operated by end users, any friendship request received from the outside should be either shown to the user
|
||
|
|
(if the browser also maintains an IM client), or automatically rejected.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
On the other hand, when the browser wants to access an URL using the xmpp scheme, an automatic friendship request to the
|
||
|
|
corresponding JID should be done, if not already in the roster. It is assumed thay by entering the URL, or using the URL
|
||
|
|
of an application already displayed, is the same as giving permission to add that JID as a friend to the roster of the
|
||
|
|
browser.
|
||
|
|
</p>
|
||
|
|
</section2>
|
||
|
|
<section2 topic='Roster handling in web servers' anchor='rosterserver'>
|
||
|
|
<p>
|
||
|
|
A web server should have different security settings available. The following subsections list possible settings for different
|
||
|
|
scenarios. Note that these settings only reflect roster handling and cannot be set per resource. However, the server can
|
||
|
|
maintain a set of JIDs with different settings and restrict access to parts of the conted hosted by the server per JID.
|
||
|
|
</p>
|
||
|
|
<section3 topic='Public Server'>
|
||
|
|
<p>
|
||
|
|
A public server should accept requests from anybody (reachable from the current JID). All friendship requests should be
|
||
|
|
automatically accepted.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
To avoid bloating the roster, friendship requests could be automatically unsubscribed once the HTTP session has ended.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Manual Server'>
|
||
|
|
<p>
|
||
|
|
All new friendship are shown (or queued) to an administrator for manual acception or rejection. Once accepted, the client
|
||
|
|
can access the corresponding content. During the wait (which can be substantial), the client should display a message
|
||
|
|
that the friendship request is sent and response is pending.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Automatic unsubscription of friendships should only be done on a much longer inactivity timeframe than the normal session
|
||
|
|
timeout interval.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Private Server'>
|
||
|
|
<p>
|
||
|
|
All new friendship requests are automatically rejected. Only already accepted friendships are allowed to make HTTP requests
|
||
|
|
to the server.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
<section3 topic='Provisioned Server'>
|
||
|
|
<p>
|
||
|
|
All new friendship requests are delegated to a trusted third party, according to
|
||
|
|
<link url='http://xmpp.org/extensions/xep-0324.html'>XEP 0324: Internet of Things - Provisioning</link>. Friendship
|
||
|
|
acceptance or rejection is then performed according to the response from the provisioning server(s).
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
Automatic friendship unsubscription can be made to avoid bloating the roster. However, the time interval for unsubscribing
|
||
|
|
inactive users should be longer than the normal session timeout period, to avoid spamming any provisioning servers each
|
||
|
|
time a client requests friendship.
|
||
|
|
</p>
|
||
|
|
</section3>
|
||
|
|
</section2>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
||
|
|
<p>
|
||
|
|
The XMPP URL scheme, as described <link url='#xmppscheme'>above</link>, must be registered.
|
||
|
|
</p>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||
|
|
<!-- TODO -->
|
||
|
|
<p>REQUIRED.</p>
|
||
|
|
</section1>
|
||
|
|
<section1 topic='XML Schema' anchor='schema'>
|
||
|
|
<code>
|
||
|
|
<![CDATA[
|
||
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
||
|
|
<xs:schema
|
||
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||
|
|
targetNamespace='urn:xmpp:http'
|
||
|
|
xmlns='urn:xmpp:http'
|
||
|
|
xmlns:sipub='http://jabber.org/protocol/sipub'
|
||
|
|
xmlns:jingle='urn:xmpp:jingle:1'
|
||
|
|
elementFormDefault='qualified'>
|
||
|
|
|
||
|
|
<xs:import namespace='http://jabber.org/protocol/sipub'/>
|
||
|
|
<xs:import namespace='urn:xmpp:jingle:1'/>
|
||
|
|
|
||
|
|
<xs:element name='req'>
|
||
|
|
<xs:complexType>
|
||
|
|
<xs:sequence>
|
||
|
|
<xs:element name='header' type='Header' minOccurs='0' maxOccurs='unbounded'/>
|
||
|
|
<xs:element name='data' type='Data' minOccurs='0' maxOccurs='1'/>
|
||
|
|
</xs:sequence>
|
||
|
|
<xs:attribute name='method' type='Method' use='required'/>
|
||
|
|
<xs:attribute name='resource' type='xs:string' use='required'/>
|
||
|
|
<xs:attribute name='version' type='Version' use='required'/>
|
||
|
|
</xs:complexType>
|
||
|
|
</xs:element>
|
||
|
|
|
||
|
|
<xs:element name='resp'>
|
||
|
|
<xs:complexType>
|
||
|
|
<xs:sequence>
|
||
|
|
<xs:element name='header' type='Header' minOccurs='0' maxOccurs='unbounded'/>
|
||
|
|
<xs:element name='data' type='Data' minOccurs='0' maxOccurs='1'/>
|
||
|
|
</xs:sequence>
|
||
|
|
<xs:attribute name='version' type='Version' use='required'/>
|
||
|
|
<xs:attribute name='statusCode' type='xs:positiveInteger' use='required'/>
|
||
|
|
<xs:attribute name='statusMessage' type='xs:string' use='optional'/>
|
||
|
|
</xs:complexType>
|
||
|
|
</xs:element>
|
||
|
|
|
||
|
|
<xs:element name="chunk">
|
||
|
|
<xs:complexType>
|
||
|
|
<xs:simpleContent>
|
||
|
|
<xs:extension base="xs:base64Binary">
|
||
|
|
<xs:attribute name="streamId" type="xs:string" use="required"/>
|
||
|
|
<xs:attribute name="last" type="xs:boolean" use="optional" default="false"/>
|
||
|
|
</xs:extension>
|
||
|
|
</xs:simpleContent>
|
||
|
|
</xs:complexType>
|
||
|
|
</xs:element>
|
||
|
|
|
||
|
|
<xs:element name='close'>
|
||
|
|
<xs:complexType>
|
||
|
|
<xs:attribute name='streamId' type='xs:string' use='required'/>
|
||
|
|
</xs:complexType>
|
||
|
|
</xs:element>
|
||
|
|
|
||
|
|
<xs:complexType name='Header'>
|
||
|
|
<xs:attribute name='name' type='xs:string'/>
|
||
|
|
<xs:attribute name='value' type='xs:string'/>
|
||
|
|
</xs:complexType>
|
||
|
|
|
||
|
|
<xs:complexType name='Data'>
|
||
|
|
<xs:choice minOccurs='1' maxOccurs='1'>
|
||
|
|
<xs:element name='text' type='xs:string'/>
|
||
|
|
<xs:element name='xml'>
|
||
|
|
<xs:complexType>
|
||
|
|
<xs:sequence minOccurs='0' maxOccurs='1'>
|
||
|
|
<xs:any processContents="lax" namespace="##any"/>
|
||
|
|
</xs:sequence>
|
||
|
|
</xs:complexType>
|
||
|
|
</xs:element>
|
||
|
|
<xs:element name="base64" type="xs:base64Binary"/>
|
||
|
|
<xs:element name="chunkedBase64">
|
||
|
|
<xs:complexType>
|
||
|
|
<xs:attribute name="streamId" type="xs:string" use="required"/>
|
||
|
|
</xs:complexType>
|
||
|
|
</xs:element>
|
||
|
|
<xs:element ref='sipub:sipub'/>
|
||
|
|
<xs:element name="streamBase64">
|
||
|
|
<xs:complexType>
|
||
|
|
<xs:attribute name="streamId" type="xs:string" use="required"/>
|
||
|
|
</xs:complexType>
|
||
|
|
</xs:element>
|
||
|
|
<xs:element ref="jingle:jingle"/>
|
||
|
|
</xs:choice>
|
||
|
|
</xs:complexType>
|
||
|
|
|
||
|
|
<xs:simpleType name='Method'>
|
||
|
|
<xs:restriction base='xs:string'>
|
||
|
|
<xs:enumeration value='OPTIONS'/>
|
||
|
|
<xs:enumeration value='GET'/>
|
||
|
|
<xs:enumeration value='HEAD'/>
|
||
|
|
<xs:enumeration value='POST'/>
|
||
|
|
<xs:enumeration value='PUT'/>
|
||
|
|
<xs:enumeration value='DELETE'/>
|
||
|
|
<xs:enumeration value='TRACE'/>
|
||
|
|
<xs:enumeration value='PATCH'/>
|
||
|
|
</xs:restriction>
|
||
|
|
</xs:simpleType>
|
||
|
|
|
||
|
|
<xs:simpleType name='Version'>
|
||
|
|
<xs:restriction base='xs:string'>
|
||
|
|
<xs:pattern value='\d[.]\d'/>
|
||
|
|
</xs:restriction>
|
||
|
|
</xs:simpleType>
|
||
|
|
|
||
|
|
</xs:schema>]]>
|
||
|
|
</code>
|
||
|
|
</section1>
|
||
|
|
</xep>
|