moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.0.7

Browse Source
This commit is contained in:
Peter Saint-Andre 2013-07-09 22:04:15 -06:00
parent 70e38e055e
commit 8bba31a1d8
1 changed files with 247 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

303
inbox/http-over-xmpp.xml
View File

@ -53,9 +53,20 @@ TODO: Inform:
<surname>Waher</surname> <surname>Waher</surname>
<email>peter.waher@clayster.com</email> <email>peter.waher@clayster.com</email>
<jid>peter.waher@jabber.org</jid> <jid>peter.waher@jabber.org</jid>
<uri>http://se.linkedin.com/pub/peter-waher/1a/71b/a29/</uri> <uri>http://www.linkedin.com/in/peterwaher</uri>
</author> </author>
<revision> <revision>
<version>0.0.7</version>
<date>2013-07-09</date>
<initials>pw</initials>
<remark>
<p>Added remarks for the xml encoding to clarify the need to avoid creating invalid XMPP.</p>
<p>Clarification added regarding to base64 content size when using schema-aware EXI compression.</p>
<p>The name of the new proposed URI scheme has been changed from xmpp to httpx.</p>
<p>An URI Scheme Registration Template has been added, as per BCP 35.</p>
</remark>
</revision>
<revision>
<version>0.0.6</version> <version>0.0.6</version>
<date>2013-06-17</date> <date>2013-06-17</date>
<initials>pw</initials> <initials>pw</initials>
@ -169,8 +180,8 @@ TODO: Inform:
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. This document will propose a different URI scheme for HTTP-based resources &xep0147;: This informational specification proposes ways to define XMPP-actions using URL's. The xmpp URI scheme is formally defined in &rfc5122;.
over an XMPP transport. This document will propose a different URI scheme for HTTP-based resources over an XMPP transport: httpx.
</li> </li>
</ul> </ul>
</section1> </section1>
@ -539,7 +550,9 @@ WHERE { ?x dc:title ?title .
</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. (&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
jabber:client namespace. If in doubt, use another encoding mechanism.
</p> </p>
</section3> </section3>
<section3 topic='PUT' anchor='PUT'> <section3 topic='PUT' anchor='PUT'>
@ -691,7 +704,7 @@ Host: clayster.com</text>
</example> </example>
</section3> </section3>
</section2> </section2>
<section2 topic='Encoding formats'> <section2 topic='Encoding formats' anchor='encoding'>
<p> <p>
In the following sub-sections, the different data encoding formats are discussed, each with corresponding examples to illustrate how they work. In the following sub-sections, the different data encoding formats are discussed, each with corresponding examples to illustrate how they work.
The interesting part of these examples is the <strong>data</strong> element and its contents. The interesting part of these examples is the <strong>data</strong> element and its contents.
@ -735,9 +748,10 @@ 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). (&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
</p> be valid XML. This could happen for instance, if the XML contains illegal elements from the jabber:client namespace.
<p> </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 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 &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>
@ -787,9 +801,14 @@ Host: clayster.com</text>
<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% (unless EXI compression is used at the same time), since it requires it has the disadvantage to increase the size of the content by 33%, since it requires 4 bytes to encode 3 bytes of data.
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>
<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> <p>
The following example shows an image is returned using the <strong>base64</strong> encoding: The following example shows an image is returned using the <strong>base64</strong> encoding:
</p> </p>
@ -1080,43 +1099,56 @@ Host: clayster.com</text>
content is displayed in the display area. The content itself will probably contain links to other content, each such item identified 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. by an absolute or relative URL.
</p> </p>
<section4 topic='xmpp:// scheme' anchor='xmppscheme'> <section4 topic='httpx scheme' anchor='httpxscheme'>
<p> <p>
A simplified way to describe an URL is to describe it as having three parts: The syntax and format of Uniform Resource Locators (URLs) or Uniform Resource Identifiers (URIs) is defined in &rfc3986;. The basic format is
</p> defined as follows:
<ul> </p>
<li>Scheme</li> <example caption='URL syntax'>
<li>Domain</li> <![CDATA[
<li>Path</li> URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
</ul>
<p> hier-part = "//" authority path-abempty
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 / path-absolute
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 / path-rootless
many browsers, for security reasons. / path-empty]]>
</p> </example>
<p> <p>
&rfc2616; furthermore defines the format of URLs using the http URI scheme, as follows:
</p>
<example caption='HTTP (over TCP) URL syntax'>
<![CDATA[
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]]]>
</example>
<p>
&rfc2818; continues to define the https scheme for HTTP transport over SSL/TLS over TCP using the same format as for HTTP URLs, except the
https scheme is used to inform the client that HTTP over SSL/TLS is to be used.
</p>
<p>
In a similar way, this document proposes a new URI scheme: <strong>httpx</strong>, based on the HTTP URL scheme, except
<strong>httpx</strong> URLs imply the use of HTTP over XMPP instead of HTTP over TCP. URLs using the <strong>httpx</strong>
URL scheme has the following format:
</p>
<example caption='HTTP over XMPP URL syntax'>
<![CDATA[
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,
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'>
<![CDATA[
httpx://httpServer@clayster.com/index.html
httpx://httpServer@clayster.com/images/image1.png
httpx://httpServer@clayster.com/api?p1=a&p2=b]]>
</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, 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 privately behind firewalls instead, by simply switching Web Applications previously requiring web hosting on the Internet will be able to be seamlessly hosted privately and securely behind firewalls instead,
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 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
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>
<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>
<section4 topic='Friendship requests'> <section4 topic='Friendship requests'>
<p> <p>
@ -1126,7 +1158,7 @@ Host: clayster.com</text>
multiple connection is canonical. multiple connection is canonical.
</p> </p>
<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 When resolving an URL using the httpx 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. is already in the roster, the request can proceed as usual.
</p> </p>
<p> <p>
@ -1180,9 +1212,9 @@ Host: clayster.com</text>
</li> </li>
</ul> </ul>
<p> <p>
If the above rules are met, which they should under normal conditions, typing in the xmpp:// 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>
@ -1563,6 +1595,11 @@ Host: clayster.com</text>
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>
<strong>Note:</strong> According to &rfc6120; there is a smallest allowed maximum stanza size that all XMPP servers must support.
According to §13.12.4 of that document, this limit is set to 10000 bytes including all characters from the opening &lt; character
to the closing &gt; character.
</p>
</section2> </section2>
<section2 topic='Bandwidth Limitations'> <section2 topic='Bandwidth Limitations'>
<p> <p>
@ -1585,7 +1622,7 @@ Host: clayster.com</text>
(if the browser also maintains an IM client), or automatically rejected. (if the browser also maintains an IM client), or automatically rejected.
</p> </p>
<p> <p>
On the other hand, when the browser wants to access an URL using the xmpp:// scheme, an automatic friendship request to the On the other hand, when the browser wants to access an URL using the httpx scheme, an automatic friendship request to the
corresponding JID should be done, if not already in the roster. It is assumed that by entering the URL, or using the URL corresponding JID should be done, if not already in the roster. It is assumed that by entering the URL, or using the URL
of an application already displayed, this implies giving permission to add that JID as a friend to the roster of the of an application already displayed, this implies giving permission to add that JID as a friend to the roster of the
browser. browser.
@ -1639,13 +1676,167 @@ Host: clayster.com</text>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
<p> <p>
The XMPP URL scheme, as described <link url='#xmppscheme'>above</link>, must be registered. The httpx URL scheme, as described <link url='#httpxscheme'>above</link>, must be registered as a provisional URI scheme according to BCP 35 <note>
BCP 35: New URI Schemes &lt;<link url='http://tools.ietf.org/html/bcp35'>http://tools.ietf.org/html/bcp35</link>&gt;
</note>. The registration procedure is specified in <link url='http://tools.ietf.org/html/bcp35#section-5.2'>BCP 35, section 5.2</link>.
</p> </p>
<section2 topic='URI Scheme Registration Template'>
<p>
Following is an URI Scheme Registration Template, as per <link url='http://tools.ietf.org/html/bcp35#section-5.4'>BCP 35, section 5.4</link>.
</p>
<dl>
<di>
<dt>URI scheme name</dt>
<dd>
<p>
httpx
</p>
</dd>
</di>
<di>
<dt>Status</dt>
<dd>
<p>
provisional
</p>
</dd>
</di>
<di>
<dt>URI scheme syntax</dt>
<dd>
<p>
The syntax used for the httpx scheme reuses the URI scheme syntax for the http scheme, as defined in RFC 2616:
</p>
<code>
<![CDATA[
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]]]>
</code>
<p>
Instead of using host and port to define the where the HTTP server resides, the httpx scheme uses a resource-less
XMPP JID to define where the HTTP server resides, implying the use of HTTP over XMPP as defined in this document
instead of HTTP over TCP:
</p>
<code>
<![CDATA[
httpx_URL = "httpx:" "//" resourceless_jid [ abs_path [ "?" query ]]]]>
</code>
<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,
the @ character and the domain. The / separator between the resource-less JID and the following abs_path, is part of abs_path.
</p>
<code>
<![CDATA[
httpx://httpServer@clayster.com/index.html
httpx://httpServer@clayster.com/images/image1.png
httpx://httpServer@clayster.com/api?p1=a&p2=b]]>
</code>
</dd>
</di>
<di>
<dt>URI scheme semantics</dt>
<dd>
<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
URL's sent to the XHR object (Ajax) will automatically be directed to use the HTTP over XMPP transport instead.
</p>
</dd>
</di>
<di>
<dt>Encoding considerations</dt>
<dd>
<p>
Encoding is fully described in the
<link url='http://xmpp.org/extensions/inbox/http-over-xmpp.html#encoding'>Encoding section of the HTTP over XMPP XEP</link> document.
</p>
</dd>
</di>
<di>
<dt>Applications/protocols that use this URI scheme name</dt>
<dd>
<p>
This URI scheme is to be used in the same environments and by the same types of applications as the http URI scheme.
</p>
</dd>
</di>
<di>
<dt>Interoperability considerations</dt>
<dd>
<p>
Interoperability considerations is described in the
<link url='http://xmpp.org/extensions/inbox/http-over-xmpp.html#impl'>Implementation Notes section of the HTTP over XMPP XEP</link> document.
</p>
</dd>
</di>
<di>
<dt>Security considerations</dt>
<dd>
<p>
Security considerations is described in the
<link url='http://xmpp.org/extensions/inbox/http-over-xmpp.html#security'>Security considerations section of the HTTP over XMPP XEP</link> document.
</p>
</dd>
</di>
<di>
<dt>Contact</dt>
<dd>
<p>
For further information, please contact Peter Waher:
</p>
<p>
Email: <link url='mailto:peter.waher@clayster.com'>peter.waher@clayster.com</link><br/>
JabberID: <link url='xmpp:peter.waher@jabber.org'>peter.waher@jabber.org</link><br/>
URI: <link url='http://www.linkedin.com/in/peterwaher'>http://www.linkedin.com/in/peterwaher</link>
</p>
</dd>
</di>
<di>
<dt>Author/Change controller</dt>
<dd>
<p>
For concerns regarding changes to the provisional registration, please contact Peter Waher:
</p>
<p>
Email: <link url='mailto:peter.waher@clayster.com'>peter.waher@clayster.com</link><br/>
JabberID: <link url='xmpp:peter.waher@jabber.org'>peter.waher@jabber.org</link><br/>
URI: <link url='http://www.linkedin.com/in/peterwaher'>http://www.linkedin.com/in/peterwaher</link>
</p>
</dd>
</di>
<di>
<dt>References</dt>
<dd>
<p>
Following is a short list of referenced documents:
</p>
<ol>
<li>
RFC 6120: <link url='http://tools.ietf.org/html/rfc6120'>
Extensible Messaging and Presence Protocol (XMPP): Core
</link>
</li>
<li>
RFC 2616: <link url='http://tools.ietf.org/html/rfc2616'>
Hypertext Transfer Protocol -- HTTP/1.1
</link>
</li>
<li>
HTTP over XMPP XEP: <link url='http://xmpp.org/extensions/inbox/http-over-xmpp.html'>
XMPP Extension Protocol: HTTP over XMPP
</link>
</li>
</ol>
</dd>
</di>
</dl>
</section2>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<!-- TODO --> <p>
<p>REQUIRED.</p> The <link url="#schema">protocol schema</link> needs to be added to the list of <link url="http://xmpp.org/resources/schemas/">XMPP protocol schemas</link>.
</section1> </p>
</section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
<code> <code>
<![CDATA[ <![CDATA[
@ -1794,6 +1985,6 @@ Host: clayster.com</text>
</code> </code>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='ack'> <section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Peter Saint-Andre, Karin Forsell and Matthew A. Miller for all valuable feedback.</p> <p>Thanks to Peter Saint-Andre, Karin Forsell, Matthew A. Miller, Kevin Smith and Ralph Meijer for all valuable feedback.</p>
</section1> </section1>
</xep> </xep>