moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

XEP-332 - Start of Last Call

Browse Source
This commit is contained in:
Matthew A. Miller 2014-10-08 10:27:34 -06:00
parent e890585a2d
commit 75ffbfe774
1 changed files with 80 additions and 79 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

159
xep-0332.xml
View File

@ -10,7 +10,8 @@
<abstract>This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks.</abstract> <abstract>This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks.</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0332</number> <number>0332</number>
<status>Experimental</status> <status>Proposed</status>
<lastcall>2014-10-21</lastcall>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<approver>Council</approver> <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, 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 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 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. benefit of being able to control who can talk to who (or what can talk to what) through established friendship relationships.
</p> </p>
<p> <p>
@ -180,7 +181,7 @@
for encoding headers into XMP defined by this XEP will be re-used in this XEP. for encoding headers into XMP defined by this XEP will be re-used in this XEP.
</li> </li>
<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. This document will propose a different URI scheme for HTTP-based resources over an XMPP transport: httpx.
</li> </li>
</ul> </ul>
@ -299,9 +300,9 @@
If the content consists of a file, <strong>sipub</strong> should be used. If the content consists of a file, <strong>sipub</strong> should be used.
</p> </p>
<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 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. increasing throughput.
</p> </p>
<p> <p>
@ -325,8 +326,8 @@
or <strong>base64</strong> mechanisms. or <strong>base64</strong> mechanisms.
</p> </p>
<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. 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 <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. use of technologies not supported by the client.
</p> </p>
</dd> </dd>
@ -367,7 +368,7 @@
</di> </di>
</dl> </dl>
<p> <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 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. their own mechanisms for aborting content transfer.
</p> </p>
@ -392,7 +393,7 @@
</headers> </headers>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -423,7 +424,7 @@
</headers> </headers>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -469,7 +470,7 @@
</headers> </headers>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -513,7 +514,7 @@ WHERE { ?x dc:title ?title .
</data> </data>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -549,9 +550,9 @@ WHERE { ?x dc:title ?title .
</iq>]]> </iq>]]>
</example> </example>
<p> <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
(&lt;?xml version="1.0"?&gt;) at the top of the document, otherwise the resulting XML will be invalid. Care has also to be taken to make sure that the (&lt;?xml version="1.0"?&gt;) 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. jabber:client namespace. If in doubt, use another encoding mechanism.
</p> </p>
</section3> </section3>
@ -576,7 +577,7 @@ WHERE { ?x dc:title ?title .
</data> </data>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -606,7 +607,7 @@ WHERE { ?x dc:title ?title .
</headers> </headers>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -640,7 +641,7 @@ WHERE { ?x dc:title ?title .
</headers> </headers>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -689,7 +690,7 @@ Host: clayster.com</text>
</data> </data>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' 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> 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 (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 not all XML constructs can be embedded as content to an XML element without invalidating it, like the xml version and encoding declaration
(&lt;?xml version="1.0"?&gt; as an example). Care has also to be taken to make sure that the generated XML is not invalid XMPP, even though it might (&lt;?xml version="1.0"?&gt; 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. be valid XML. This could happen for instance, if the XML contains illegal elements from the jabber:client namespace.
</p> </p>
<p> <p>
@ -756,9 +757,9 @@ Host: clayster.com</text>
encode the XML escape characters &lt;, &gt; and &amp;, or use another encoding, like <strong>base64</strong>. encode the XML escape characters &lt;, &gt; and &amp;, or use another encoding, like <strong>base64</strong>.
</p> </p>
<p> <p>
The advantage of <strong>xml</strong> instead of <strong>text</strong> or <strong>base64</strong> encodings is when used in conjunction with 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. <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 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. gain induced by the encoding is recaptured.
</p> </p>
<example caption='xml'> <example caption='xml'>
@ -800,13 +801,13 @@ Host: clayster.com</text>
</section3> </section3>
<section3 topic='base64'> <section3 topic='base64'>
<p> <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, 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. 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. Care has to be taken not to send too large items using this encoding.
</p> </p>
<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. <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 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. to encode the data only uses 6 bits of information per character, and thus compresses the data back to its original size.
</p> </p>
<p> <p>
@ -865,14 +866,14 @@ Host: clayster.com</text>
</data> </data>
</resp> </resp>
</iq> </iq>
<message from='httpserver@clayster.com' <message from='httpserver@clayster.com'
to='httpclient@clayster.com/browser'> to='httpclient@clayster.com/browser'>
<chunk xmlns='urn:xmpp:http' streamId='Stream0001' nr='0'>iVBORw0KGgoAAAANSUhEUgAAASwAAAGQCAYAA ...</chunk> <chunk xmlns='urn:xmpp:http' streamId='Stream0001' nr='0'>iVBORw0KGgoAAAANSUhEUgAAASwAAAGQCAYAA ...</chunk>
</message> </message>
... ...
<message from='httpserver@clayster.com' <message from='httpserver@clayster.com'
to='httpclient@clayster.com/browser'> to='httpclient@clayster.com/browser'>
<chunk xmlns='urn:xmpp:http' streamId='Stream0001' nr='5' last='true'>... 2uPzi9u+tVWJd+e+y1AAAAABJRU5ErkJggg==</chunk> <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> </example>
<p> <p>
<strong>Note:</strong> Chunked encoding assumes the content to be finite. If content is infinite (i.e. for instance live streaming), <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. finite or infinite, <strong>ibb</strong> or <strong>jingle</strong> must be used.
</p> </p>
<p> <p>
@ -901,7 +902,7 @@ Host: clayster.com</text>
<p> <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 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, 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 <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. <strong>sipub</strong> element.
</p> </p>
@ -928,7 +929,7 @@ Host: clayster.com</text>
name='Kermit.png' name='Kermit.png'
size='221203' size='221203'
date='2013-03-06T16:47Z'/> date='2013-03-06T16:47Z'/>
</sipub> </sipub>
</data> </data>
</resp> </resp>
</iq>]]> </iq>]]>
@ -942,8 +943,8 @@ Host: clayster.com</text>
example. example.
</p> </p>
<p> <p>
Such content must use the <strong>ibb</strong> transfer mechanism, if used (or the <strong>jingle</strong> transfer machanism). 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> 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> 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 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 <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> </headers>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -980,7 +981,7 @@ Host: clayster.com</text>
</data> </data>
</resp> </resp>
</iq> </iq>
<iq type='set' <iq type='set'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -990,26 +991,26 @@ Host: clayster.com</text>
sid='Stream0002' sid='Stream0002'
stanza='message'/> stanza='message'/>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpclient@clayster.com/browser' from='httpclient@clayster.com/browser'
to='httpserver@clayster.com' to='httpserver@clayster.com'
id='13'/> id='13'/>
<message from='httpserver@clayster.com' <message from='httpserver@clayster.com'
to='httpclient@clayster.com/browser'> to='httpclient@clayster.com/browser'>
<data xmlns='http://jabber.org/protocol/ibb' sid='Stream0002' seq='0'>...</chunk> <data xmlns='http://jabber.org/protocol/ibb' sid='Stream0002' seq='0'>...</chunk>
</message> </message>
... ...
<iq type='set' <iq type='set'
from='httpclient@clayster.com/browser' from='httpclient@clayster.com/browser'
to='httpserver@clayster.com' to='httpserver@clayster.com'
id='14'> id='14'>
<close xmlns='http://jabber.org/protocol/ibb' sid='Stream0002'/> <close xmlns='http://jabber.org/protocol/ibb' sid='Stream0002'/>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' 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>. <strong>Note:</strong> Example taken from <link url='http://xmpp.org/extensions/xep-0166.html#howitworks'>XEP 166: Jingle</link>.
</p> </p>
<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 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. that would have been returned if the request had been made using normal HTTP over TCP.
</p> </p>
@ -1094,7 +1095,7 @@ Host: clayster.com</text>
</section2> </section2>
<section2 topic='Applications'> <section2 topic='Applications'>
<p> <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. implementing this extension.
</p> </p>
<section3 topic='Browsers'> <section3 topic='Browsers'>
@ -1112,7 +1113,7 @@ Host: clayster.com</text>
<example caption='URL syntax'> <example caption='URL syntax'>
<![CDATA[ <![CDATA[
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty hier-part = "//" authority path-abempty
/ path-absolute / path-absolute
/ path-rootless / path-rootless
@ -1139,7 +1140,7 @@ Host: clayster.com</text>
httpx_URL = "httpx:" "//" resourceless_jid [ abs_path [ "?" query ]]]]> httpx_URL = "httpx:" "//" resourceless_jid [ abs_path [ "?" query ]]]]>
</example> </example>
<p> <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. the @ character and the domain. The / separator between the resource-less JID and the following abs_path, is part of abs_path.
</p> </p>
<example caption='Examples of URLs with the httpx scheme'> <example caption='Examples of URLs with the httpx scheme'>
@ -1150,8 +1151,8 @@ Host: clayster.com</text>
</example> </example>
<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, 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, 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 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. URL's sent to the XHR object (Ajax) will automatically be directed to use the HTTP over XMPP transport instead.
</p> </p>
</section4> </section4>
@ -1180,26 +1181,26 @@ Host: clayster.com</text>
end user, if any, or rejected. end user, if any, or rejected.
</p> </p>
<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>. <link url='#rosterserver'>Roster Handling in web servers</link>.
</p> </p>
</section4> </section4>
<section4 topic='Seamless use of web applications hosted at home'> <section4 topic='Seamless use of web applications hosted at home'>
<p> <p>
Today, most people who want to host their own web applications (HTML/HTTP based applications) need to host them on a server publicly 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 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 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. home web cams) to get in the hands of people you don't want to have access to them.
</p> </p>
<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 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: in any browser also supporting this extensions, as long as friendship exists between the browser and the web server:
</p> </p>
<ul> <ul>
<li> <li>
<p> <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 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. as the principal page.
</p> </p>
@ -1218,8 +1219,8 @@ Host: clayster.com</text>
</ul> </ul>
<p> <p>
If the above rules are met, which they should under normal conditions, typing in the httpx URL in the browser (for instance when 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 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 (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. the server JID.
</p> </p>
</section4> </section4>
@ -1227,10 +1228,10 @@ Host: clayster.com</text>
<section3 topic='Web Services'> <section3 topic='Web Services'>
<p> <p>
Many applications use a Service Oriented Architecture (SOA) and use web services to communicate between clients and servers. These web services 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 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 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 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 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. solves this.
</p> </p>
<section4 topic='SOAP'> <section4 topic='SOAP'>
@ -1264,7 +1265,7 @@ Host: clayster.com</text>
</data> </data>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@example.com' from='httpserver@example.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -1283,7 +1284,7 @@ Host: clayster.com</text>
<m:Sum>30</m:Sum> <m:Sum>30</m:Sum>
</m:AddNumbersResponse> </m:AddNumbersResponse>
</soap:Body> </soap:Body>
</soap:Envelope> </soap:Envelope>
</xml> </xml>
</data> </data>
</resp> </resp>
@ -1312,7 +1313,7 @@ Host: clayster.com</text>
</headers> </headers>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' 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. technologies beyond "The Internet" while at the same time improving security and controllability of the information.
</p> </p>
<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). Things, such as &xep0324;, which would give automatic control of who (or what) can communicate with whom (or what).
</p> </p>
<section4 topic='Turtle'> <section4 topic='Turtle'>
@ -1420,7 +1421,7 @@ Host: clayster.com</text>
</headers> </headers>
<data> <data>
<xml> <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#"> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://clayster.com/xep"> <rdf:Description rdf:about="http://clayster.com/xep">
<dc:title>HTTP over XMPP</dc:title> <dc:title>HTTP over XMPP</dc:title>
@ -1462,7 +1463,7 @@ Host: clayster.com</text>
</data> </data>
</req> </req>
</iq> </iq>
<iq type='result' <iq type='result'
from='httpserver@clayster.com' from='httpserver@clayster.com'
to='httpclient@clayster.com/browser' to='httpclient@clayster.com/browser'
@ -1570,7 +1571,7 @@ Host: clayster.com</text>
<section2 topic='HTTP Headers' anchor='headers'> <section2 topic='HTTP Headers' anchor='headers'>
<p> <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>. 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. <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 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 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>
<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 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 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 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. 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. should be applied in particular on audio and video content.
</p> </p>
<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. content using Jingle.
</p> </p>
<p> <p>
@ -1608,7 +1609,7 @@ Host: clayster.com</text>
</section2> </section2>
<section2 topic='Bandwidth Limitations'> <section2 topic='Bandwidth Limitations'>
<p> <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 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, 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 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'> <section2 topic='Roster handling in web servers' anchor='rosterserver'>
<p> <p>
A web server should have different security settings available. The following subsections list possible settings for different 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. maintain a set of JIDs with different settings and restrict access to parts of the content hosted by the server per JID.
</p> </p>
<section3 topic='Public Server'> <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/sipub'/>
<xs:import namespace='http://jabber.org/protocol/ibb'/> <xs:import namespace='http://jabber.org/protocol/ibb'/>
<xs:import namespace='urn:xmpp:jingle:1'/> <xs:import namespace='urn:xmpp:jingle:1'/>
<xs:element name='req'> <xs:element name='req'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
@ -1876,14 +1877,14 @@ Host: clayster.com</text>
<xs:attribute name='jingle' type='xs:boolean' use='optional' default='true'/> <xs:attribute name='jingle' type='xs:boolean' use='optional' default='true'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name='MaxChunkSize'> <xs:simpleType name='MaxChunkSize'>
<xs:restriction base='xs:int'> <xs:restriction base='xs:int'>
<xs:minInclusive value='256'/> <xs:minInclusive value='256'/>
<xs:maxInclusive value='65536'/> <xs:maxInclusive value='65536'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name='resp'> <xs:element name='resp'>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
@ -1895,7 +1896,7 @@ Host: clayster.com</text>
<xs:attribute name='statusMessage' type='xs:string' use='optional'/> <xs:attribute name='statusMessage' type='xs:string' use='optional'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:complexType name='Data'> <xs:complexType name='Data'>
<xs:choice minOccurs='1' maxOccurs='1'> <xs:choice minOccurs='1' maxOccurs='1'>
<xs:element name='text' type='xs:string'> <xs:element name='text' type='xs:string'>
@ -1949,7 +1950,7 @@ Host: clayster.com</text>
</xs:element> </xs:element>
</xs:choice> </xs:choice>
</xs:complexType> </xs:complexType>
<xs:element name="chunk"> <xs:element name="chunk">
<xs:complexType> <xs:complexType>
<xs:simpleContent> <xs:simpleContent>
@ -1961,13 +1962,13 @@ Host: clayster.com</text>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='close'> <xs:element name='close'>
<xs:complexType> <xs:complexType>
<xs:attribute name='streamId' type='xs:string' use='required'/> <xs:attribute name='streamId' type='xs:string' use='required'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:simpleType name='Method'> <xs:simpleType name='Method'>
<xs:restriction base='xs:string'> <xs:restriction base='xs:string'>
<xs:enumeration value='OPTIONS'/> <xs:enumeration value='OPTIONS'/>
@ -1980,13 +1981,13 @@ Host: clayster.com</text>
<xs:enumeration value='PATCH'/> <xs:enumeration value='PATCH'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name='Version'> <xs:simpleType name='Version'>
<xs:restriction base='xs:string'> <xs:restriction base='xs:string'>
<xs:pattern value='\d[.]\d'/> <xs:pattern value='\d[.]\d'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema>]]> </xs:schema>]]>
</code> </code>
</section1> </section1>