mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
XEP-332 - Start of Last Call
This commit is contained in:
Matthew A. Miller
parent
e890585a2d
commit
75ffbfe774
159
xep-0332.xml
159
xep-0332.xml
@ -10,7 +10,8 @@
|
||||
<abstract>This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0332</number>
|
||||
<status>Experimental</status>
|
||||
<status>Proposed</status>
|
||||
<lastcall>2014-10-21</lastcall>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
@ -156,7 +157,7 @@
|
||||
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
|
||||
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>
|
||||
@ -180,7 +181,7 @@
|
||||
for encoding headers into XMP defined by this XEP will be re-used in this XEP.
|
||||
</li>
|
||||
<li>
|
||||
&xep0147;: This informational specification proposes ways to define XMPP-actions using URL's. The xmpp URI scheme is formally defined in &rfc5122;.
|
||||
&xep0147;: This informational specification proposes ways to define XMPP-actions using URL's. The xmpp URI scheme is formally defined in &rfc5122;.
|
||||
This document will propose a different URI scheme for HTTP-based resources over an XMPP transport: httpx.
|
||||
</li>
|
||||
</ul>
|
||||
@ -299,9 +300,9 @@
|
||||
If the content consists of a file, <strong>sipub</strong> should be used.
|
||||
</p>
|
||||
<p>
|
||||
Chunked encoding is perfect for dynamic responses of moderate sizes, for instance for API method responses. The server does not know when the response
|
||||
Chunked encoding is perfect for dynamic responses of moderate sizes, for instance for API method responses. The server does not know when the response
|
||||
is begun to be generated what the final size will be, but it will be most probably "manageable". Using the chunked transfer mechanism enables the
|
||||
server to start sending the content, minimizing the need for buffers, and at the same time minimizing the number of messages that needs to be sent,
|
||||
server to start sending the content, minimizing the need for buffers, and at the same time minimizing the number of messages that needs to be sent,
|
||||
increasing throughput.
|
||||
</p>
|
||||
<p>
|
||||
@ -325,8 +326,8 @@
|
||||
or <strong>base64</strong> mechanisms.
|
||||
</p>
|
||||
<p>
|
||||
The client can disable the use of <strong>sipub</strong> by the server, by including a <strong>sipub='false'</strong> attribute in the request.
|
||||
<strong>sipub</strong> is enabled by default. On constrained devices with limited support for different XEP's, this can be a way to avoid the
|
||||
The client can disable the use of <strong>sipub</strong> by the server, by including a <strong>sipub='false'</strong> attribute in the request.
|
||||
<strong>sipub</strong> is enabled by default. On constrained devices with limited support for different XEP's, this can be a way to avoid the
|
||||
use of technologies not supported by the client.
|
||||
</p>
|
||||
</dd>
|
||||
@ -367,7 +368,7 @@
|
||||
</di>
|
||||
</dl>
|
||||
<p>
|
||||
<strong>Note:</strong> Content encoded using <strong>chunkedBase64</strong> encoding method can be terminated, either by the receptor going off-line, or by
|
||||
<strong>Note:</strong> Content encoded using <strong>chunkedBase64</strong> encoding method can be terminated, either by the receptor going off-line, or by
|
||||
sending a <strong>close</strong> command to the sender. The transfer methods <strong>sipub</strong>, <strong>ibb</strong> and <strong>jingle</strong> have
|
||||
their own mechanisms for aborting content transfer.
|
||||
</p>
|
||||
@ -392,7 +393,7 @@
|
||||
</headers>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -423,7 +424,7 @@
|
||||
</headers>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -469,7 +470,7 @@
|
||||
</headers>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -513,7 +514,7 @@ WHERE { ?x dc:title ?title .
|
||||
</data>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -549,9 +550,9 @@ WHERE { ?x dc:title ?title .
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
<strong>Note:</strong> If using <strong>xml</strong> encoding of data, care has to be taken to avoid including the version and encoding information
|
||||
<strong>Note:</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. Care has also to be taken to make sure that the
|
||||
generated XML is not invalid XMPP, even though it might be valid XML. This could happen for instance, if the XML contains illegal elements from the
|
||||
generated XML is not invalid XMPP, even though it might be valid XML. This could happen for instance, if the XML contains illegal elements from the
|
||||
jabber:client namespace. If in doubt, use another encoding mechanism.
|
||||
</p>
|
||||
</section3>
|
||||
@ -576,7 +577,7 @@ WHERE { ?x dc:title ?title .
|
||||
</data>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -606,7 +607,7 @@ WHERE { ?x dc:title ?title .
|
||||
</headers>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -640,7 +641,7 @@ WHERE { ?x dc:title ?title .
|
||||
</headers>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -689,7 +690,7 @@ Host: clayster.com</text>
|
||||
</data>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -748,7 +749,7 @@ Host: clayster.com</text>
|
||||
XML is a convenient 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). Care has also to be taken to make sure that the generated XML is not invalid XMPP, even though it might
|
||||
(<?xml version="1.0"?> as an example). Care has also to be taken to make sure that the generated XML is not invalid XMPP, even though it might
|
||||
be valid XML. This could happen for instance, if the XML contains illegal elements from the jabber:client namespace.
|
||||
</p>
|
||||
<p>
|
||||
@ -756,9 +757,9 @@ Host: clayster.com</text>
|
||||
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 conjunction 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
|
||||
The advantage of <strong>xml</strong> instead of <strong>text</strong> or <strong>base64</strong> encodings is when used in conjunction 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='xml'>
|
||||
@ -800,13 +801,13 @@ Host: clayster.com</text>
|
||||
</section3>
|
||||
<section3 topic='base64'>
|
||||
<p>
|
||||
Base-64 encoding is a simple way to encode content that is easily 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%, since it requires 4 bytes to encode 3 bytes of data.
|
||||
Base-64 encoding is a simple way to encode content that is easily 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%, 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>
|
||||
<strong>Note:</strong> The actual size of the content being sent does not necessarily need to increase if this encoding method is used.
|
||||
If EXI compression is used at the same time, and it uses schema-aware compression, it will actually understand that the character set used
|
||||
<strong>Note:</strong> The actual size of the content being sent does not necessarily need to increase if this encoding method is used.
|
||||
If EXI compression is used at the same time, and it uses schema-aware compression, it will actually understand that the character set used
|
||||
to encode the data only uses 6 bits of information per character, and thus compresses the data back to its original size.
|
||||
</p>
|
||||
<p>
|
||||
@ -865,14 +866,14 @@ Host: clayster.com</text>
|
||||
</data>
|
||||
</resp>
|
||||
</iq>
|
||||
|
||||
|
||||
<message from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'>
|
||||
<chunk xmlns='urn:xmpp:http' streamId='Stream0001' nr='0'>iVBORw0KGgoAAAANSUhEUgAAASwAAAGQCAYAA ...</chunk>
|
||||
</message>
|
||||
|
||||
|
||||
...
|
||||
|
||||
|
||||
<message from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'>
|
||||
<chunk xmlns='urn:xmpp:http' streamId='Stream0001' nr='5' last='true'>... 2uPzi9u+tVWJd+e+y1AAAAABJRU5ErkJggg==</chunk>
|
||||
@ -880,7 +881,7 @@ Host: clayster.com</text>
|
||||
</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>ibb</strong> or <strong>jingle</strong> transfer encodings must be used instead. If the sender is unsure if the content is
|
||||
the <strong>ibb</strong> or <strong>jingle</strong> transfer encodings must be used instead. If the sender is unsure if the content is
|
||||
finite or infinite, <strong>ibb</strong> or <strong>jingle</strong> must be used.
|
||||
</p>
|
||||
<p>
|
||||
@ -901,7 +902,7 @@ Host: clayster.com</text>
|
||||
<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
|
||||
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>
|
||||
@ -928,7 +929,7 @@ Host: clayster.com</text>
|
||||
name='Kermit.png'
|
||||
size='221203'
|
||||
date='2013-03-06T16:47Z'/>
|
||||
</sipub>
|
||||
</sipub>
|
||||
</data>
|
||||
</resp>
|
||||
</iq>]]>
|
||||
@ -942,8 +943,8 @@ Host: clayster.com</text>
|
||||
example.
|
||||
</p>
|
||||
<p>
|
||||
Such content must use the <strong>ibb</strong> transfer mechanism, if used (or the <strong>jingle</strong> transfer machanism).
|
||||
The <strong>ibb</strong> transfer mechanism uses <link url='http://xmpp.org/extensions/xep-0047.html'>In-Band Bytestreams</link>
|
||||
Such content must use the <strong>ibb</strong> transfer mechanism, if used (or the <strong>jingle</strong> transfer machanism).
|
||||
The <strong>ibb</strong> transfer mechanism uses <link url='http://xmpp.org/extensions/xep-0047.html'>In-Band Bytestreams</link>
|
||||
to transfer data from the server to the client. It starts by sending an a <strong>ibb</strong> element containing a <strong>sid</strong>
|
||||
attribute identifying the stream. Then the server sends an <strong>ibb:open</strong> IQ-stanza to the client according to
|
||||
<link url='http://xmpp.org/extensions/xep-0047.html'>XEP-0047</link>. The client can choose to reject, negotiate or acceopt the request
|
||||
@ -964,7 +965,7 @@ Host: clayster.com</text>
|
||||
</headers>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -980,7 +981,7 @@ Host: clayster.com</text>
|
||||
</data>
|
||||
</resp>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='set'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -990,26 +991,26 @@ Host: clayster.com</text>
|
||||
sid='Stream0002'
|
||||
stanza='message'/>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpclient@clayster.com/browser'
|
||||
to='httpserver@clayster.com'
|
||||
id='13'/>
|
||||
|
||||
|
||||
<message from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'>
|
||||
<data xmlns='http://jabber.org/protocol/ibb' sid='Stream0002' seq='0'>...</chunk>
|
||||
</message>
|
||||
|
||||
|
||||
...
|
||||
|
||||
|
||||
<iq type='set'
|
||||
from='httpclient@clayster.com/browser'
|
||||
to='httpserver@clayster.com'
|
||||
id='14'>
|
||||
<close xmlns='http://jabber.org/protocol/ibb' sid='Stream0002'/>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -1086,7 +1087,7 @@ Host: clayster.com</text>
|
||||
<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
|
||||
<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>
|
||||
@ -1094,7 +1095,7 @@ Host: clayster.com</text>
|
||||
</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
|
||||
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'>
|
||||
@ -1112,7 +1113,7 @@ Host: clayster.com</text>
|
||||
<example caption='URL syntax'>
|
||||
<![CDATA[
|
||||
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
|
||||
|
||||
|
||||
hier-part = "//" authority path-abempty
|
||||
/ path-absolute
|
||||
/ path-rootless
|
||||
@ -1139,7 +1140,7 @@ Host: clayster.com</text>
|
||||
httpx_URL = "httpx:" "//" resourceless_jid [ abs_path [ "?" query ]]]]>
|
||||
</example>
|
||||
<p>
|
||||
Here, the host and port parts of normal HTTP URLs have been replaced by the resource-less JID of the HTTP Server, i.e. only the user name,
|
||||
Here, the host and port parts of normal HTTP URLs have been replaced by the resource-less JID of the HTTP Server, i.e. only the user name,
|
||||
the @ character and the domain. The / separator between the resource-less JID and the following abs_path, is part of abs_path.
|
||||
</p>
|
||||
<example caption='Examples of URLs with the httpx scheme'>
|
||||
@ -1150,8 +1151,8 @@ Host: clayster.com</text>
|
||||
</example>
|
||||
<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 seamlessly hosted privately and securely behind firewalls instead,
|
||||
by simply switching from the http URL scheme to the httpx URL scheme in the calling application. All relative URL's within the application, including
|
||||
Web Applications previously requiring web hosting on the Internet will be able to be seamlessly hosted privately and securely behind firewalls instead,
|
||||
by simply switching from the http URL scheme to the httpx URL scheme in the calling application. 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>
|
||||
</section4>
|
||||
@ -1180,26 +1181,26 @@ Host: clayster.com</text>
|
||||
end user, if any, or rejected.
|
||||
</p>
|
||||
<p>
|
||||
For more information, see <link url='#rosterclient'>Roster Handling in web clients</link> and
|
||||
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
|
||||
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
|
||||
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, objects, etc.). If absolute URL's are used (including scheme),
|
||||
Only relative URL's are used within references (images, audio, video, links, objects, 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>
|
||||
@ -1218,8 +1219,8 @@ Host: clayster.com</text>
|
||||
</ul>
|
||||
<p>
|
||||
If the above rules are met, which they should under normal conditions, typing in the httpx 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
|
||||
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>
|
||||
@ -1227,10 +1228,10 @@ Host: clayster.com</text>
|
||||
<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 use of HTTP over XMPP
|
||||
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 use of HTTP over XMPP
|
||||
solves this.
|
||||
</p>
|
||||
<section4 topic='SOAP'>
|
||||
@ -1264,7 +1265,7 @@ Host: clayster.com</text>
|
||||
</data>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@example.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -1283,7 +1284,7 @@ Host: clayster.com</text>
|
||||
<m:Sum>30</m:Sum>
|
||||
</m:AddNumbersResponse>
|
||||
</soap:Body>
|
||||
</soap:Envelope>
|
||||
</soap:Envelope>
|
||||
</xml>
|
||||
</data>
|
||||
</resp>
|
||||
@ -1312,7 +1313,7 @@ Host: clayster.com</text>
|
||||
</headers>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -1359,7 +1360,7 @@ Host: clayster.com</text>
|
||||
technologies beyond "The Internet" while at the same time improving security and controllability of the information.
|
||||
</p>
|
||||
<p>
|
||||
As the semantic web moves closer to Internet of Things and the world of XMPP, it can benefit from work done with relation to the Internet of
|
||||
As the semantic web moves closer 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'>
|
||||
@ -1420,7 +1421,7 @@ Host: clayster.com</text>
|
||||
</headers>
|
||||
<data>
|
||||
<xml>
|
||||
<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
|
||||
<rdf:Description rdf:about="http://clayster.com/xep">
|
||||
<dc:title>HTTP over XMPP</dc:title>
|
||||
@ -1462,7 +1463,7 @@ Host: clayster.com</text>
|
||||
</data>
|
||||
</req>
|
||||
</iq>
|
||||
|
||||
|
||||
<iq type='result'
|
||||
from='httpserver@clayster.com'
|
||||
to='httpclient@clayster.com/browser'
|
||||
@ -1570,7 +1571,7 @@ Host: clayster.com</text>
|
||||
<section2 topic='HTTP Headers' anchor='headers'>
|
||||
<p>
|
||||
HTTP Headers are serialized to and from XML using the XEP-0131 <link url='http://xmpp.org/extensions/xep-0131.html'>Stanza Headers and Internet Metadata</link>.
|
||||
However, this does not mean that the SHIM feature needs to be published by the client, as defined in §3 in
|
||||
However, this does not mean that the SHIM feature needs to be published by the client, as defined in §3 in
|
||||
<link url='http://xmpp.org/extensions/xep-0131.html#disco'>XEP-0131</link>, since the headers will be embedded into the HTTP elements.
|
||||
Also, if there is any conflicts in how to store header values, when it comes to data types, etc., the original format as used by the original
|
||||
HTTP request must be used, and not the format defined in <link url='http://xmpp.org/extensions/xep-0131.html#headers'>Header Definitions</link> or
|
||||
@ -1578,7 +1579,7 @@ Host: clayster.com</text>
|
||||
</p>
|
||||
<p>
|
||||
The HTTP over XMPP tunnel is just a tunnel of HTTP over XMPP, it does not know the semantic meaning of headers used in the transport. It does not know
|
||||
if additional headers added by the myriad of custom applications using HTTP are actually HTTP-compliant. It just acts as a transport, returning the
|
||||
if additional headers added by the myriad of custom applications using HTTP are actually HTTP-compliant. It just acts as a transport, returning the
|
||||
sime kind of response (being deterministric) as if the original request was made through other means, for example over TCP. It does not add, remove or
|
||||
change semantic meaning of keys and values, nor change the format of the corresponding values. Such changes will create uncountable problems very difficult
|
||||
to detect and solve in a general case.
|
||||
@ -1597,7 +1598,7 @@ Host: clayster.com</text>
|
||||
should be applied in particular on audio and video content.
|
||||
</p>
|
||||
<p>
|
||||
The implementor should also consider to send large content in the form of files using file transfer, and large multi-media
|
||||
The implementor should also consider to send large content in the form of files using file transfer, and large multi-media
|
||||
content using Jingle.
|
||||
</p>
|
||||
<p>
|
||||
@ -1608,7 +1609,7 @@ Host: clayster.com</text>
|
||||
</section2>
|
||||
<section2 topic='Bandwidth Limitations'>
|
||||
<p>
|
||||
Some XMPP Servers may also have bandwidth resitrctions enforced. This to limit the possibility of Denial of Service attacks
|
||||
Some XMPP Servers may also have bandwidth resitrctions enforced. This to limit the possibility of Denial of Service attacks
|
||||
or similar flooding of messages. Implementors of the HTTP over XMPP extensions must know however, that the bandwidth
|
||||
limitations for instant messaging and chat may be completely different from that of normal web applications. In chatting,
|
||||
a 1000 bytes/s limit is in most cases sufficient, while the same limit for even a modest web applications will make the
|
||||
@ -1636,7 +1637,7 @@ Host: clayster.com</text>
|
||||
<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
|
||||
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 content hosted by the server per JID.
|
||||
</p>
|
||||
<section3 topic='Public Server'>
|
||||
@ -1860,7 +1861,7 @@ Host: clayster.com</text>
|
||||
<xs:import namespace='http://jabber.org/protocol/sipub'/>
|
||||
<xs:import namespace='http://jabber.org/protocol/ibb'/>
|
||||
<xs:import namespace='urn:xmpp:jingle:1'/>
|
||||
|
||||
|
||||
<xs:element name='req'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
@ -1876,14 +1877,14 @@ Host: clayster.com</text>
|
||||
<xs:attribute name='jingle' type='xs:boolean' use='optional' default='true'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
|
||||
<xs:simpleType name='MaxChunkSize'>
|
||||
<xs:restriction base='xs:int'>
|
||||
<xs:minInclusive value='256'/>
|
||||
<xs:maxInclusive value='65536'/>
|
||||
</xs:restriction>
|
||||
</xs:simpleType>
|
||||
|
||||
|
||||
<xs:element name='resp'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
@ -1895,7 +1896,7 @@ Host: clayster.com</text>
|
||||
<xs:attribute name='statusMessage' type='xs:string' use='optional'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
|
||||
<xs:complexType name='Data'>
|
||||
<xs:choice minOccurs='1' maxOccurs='1'>
|
||||
<xs:element name='text' type='xs:string'>
|
||||
@ -1949,7 +1950,7 @@ Host: clayster.com</text>
|
||||
</xs:element>
|
||||
</xs:choice>
|
||||
</xs:complexType>
|
||||
|
||||
|
||||
<xs:element name="chunk">
|
||||
<xs:complexType>
|
||||
<xs:simpleContent>
|
||||
@ -1961,13 +1962,13 @@ Host: clayster.com</text>
|
||||
</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:simpleType name='Method'>
|
||||
<xs:restriction base='xs:string'>
|
||||
<xs:enumeration value='OPTIONS'/>
|
||||
@ -1980,13 +1981,13 @@ Host: clayster.com</text>
|
||||
<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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user