From 75ffbfe77428933305eb08375aa9b34810d98b76 Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Wed, 8 Oct 2014 10:27:34 -0600 Subject: [PATCH] XEP-332 - Start of Last Call --- xep-0332.xml | 159 ++++++++++++++++++++++++++------------------------- 1 file changed, 80 insertions(+), 79 deletions(-) diff --git a/xep-0332.xml b/xep-0332.xml index 2b294ff6..0d5c45b4 100644 --- a/xep-0332.xml +++ b/xep-0332.xml @@ -10,7 +10,8 @@ This specification defines how XMPP can be used to transport HTTP communication over peer-to-peer networks. &LEGALNOTICE; 0332 - Experimental + Proposed + 2014-10-21 Standards Track Standards Council @@ -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.

@@ -180,7 +181,7 @@ for encoding headers into XMP defined by this XEP will be re-used in this XEP.

  • - &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.
    • @@ -299,9 +300,9 @@ If the content consists of a file, sipub should be used.

    - 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.

    @@ -325,8 +326,8 @@ or base64 mechanisms.

    - The client can disable the use of sipub by the server, by including a sipub='false' attribute in the request. - sipub 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 sipub by the server, by including a sipub='false' attribute in the request. + sipub 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.

    @@ -367,7 +368,7 @@

    - Note: Content encoded using chunkedBase64 encoding method can be terminated, either by the receptor going off-line, or by + Note: Content encoded using chunkedBase64 encoding method can be terminated, either by the receptor going off-line, or by sending a close command to the sender. The transfer methods sipub, ibb and jingle have their own mechanisms for aborting content transfer.

    @@ -392,7 +393,7 @@ - + - + - + - + ]]>

    - Note: If using xml encoding of data, care has to be taken to avoid including the version and encoding information + Note: If using xml 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.

    @@ -576,7 +577,7 @@ WHERE { ?x dc:title ?title .     - + - + - + - + XML is a convenient way to return XML embedded in the XMPP response. This can be suitable for MIME Types of the form .*/(.*[+])?xml (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.

    @@ -756,9 +757,9 @@ Host: clayster.com encode the XML escape characters <, > and &, or use another encoding, like base64.

    - The advantage of xml instead of text or base64 encodings is when used in conjunction with - EXI compression. 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 xml instead of text or base64 encodings is when used in conjunction with + EXI compression. 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.

    @@ -800,13 +801,13 @@ Host: clayster.com

    - 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.

    - Note: 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 + Note: 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.

    @@ -865,14 +866,14 @@ Host: clayster.com - + iVBORw0KGgoAAAANSUhEUgAAASwAAAGQCAYAA ... - + ... - + ... 2uPzi9u+tVWJd+e+y1AAAAABJRU5ErkJggg== @@ -880,7 +881,7 @@ Host: clayster.com

    Note: Chunked encoding assumes the content to be finite. If content is infinite (i.e. for instance live streaming), - the ibb or jingle transfer encodings must be used instead. If the sender is unsure if the content is + the ibb or jingle transfer encodings must be used instead. If the sender is unsure if the content is finite or infinite, ibb or jingle must be used.

    @@ -901,7 +902,7 @@ Host: clayster.com

    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 XEP 0137: Publishing Stream Initiation Requests. This is done using the sipub element.

    @@ -928,7 +929,7 @@ Host: clayster.com name='Kermit.png' size='221203' date='2013-03-06T16:47Z'/> - +     ]]> @@ -942,8 +943,8 @@ Host: clayster.com example.

    - Such content must use the ibb transfer mechanism, if used (or the jingle transfer machanism). - The ibb transfer mechanism uses In-Band Bytestreams + Such content must use the ibb transfer mechanism, if used (or the jingle transfer machanism). + The ibb transfer mechanism uses In-Band Bytestreams to transfer data from the server to the client. It starts by sending an a ibb element containing a sid attribute identifying the stream. Then the server sends an ibb:open IQ-stanza to the client according to XEP-0047. The client can choose to reject, negotiate or acceopt the request @@ -964,7 +965,7 @@ Host: clayster.com - + - + sid='Stream0002' stanza='message'/> - + - + ... - + ... - + - + Note: Example taken from XEP 166: Jingle.

    - Note2: Using Jingle in this way makes it possible for an intelligent server to return multiple streams the client + Note2: 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.

    @@ -1094,7 +1095,7 @@ Host: clayster.com

    - 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.

    @@ -1112,7 +1113,7 @@ Host: clayster.com httpx_URL = "httpx:" "//" resourceless_jid [ abs_path [ "?" query ]]]]>

    - 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.

    @@ -1150,8 +1151,8 @@ Host: clayster.com

    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.

    @@ -1180,26 +1181,26 @@ Host: clayster.com end user, if any, or rejected.

    - For more information, see Roster Handling in web clients and + For more information, see Roster Handling in web clients and Roster Handling in web servers.

    - 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.

    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:

    • - 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.

      @@ -1218,8 +1219,8 @@ Host: clayster.com

    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.

    @@ -1227,10 +1228,10 @@ Host: clayster.com

    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.

    @@ -1264,7 +1265,7 @@ Host: clayster.com - + 30 - + @@ -1312,7 +1313,7 @@ Host: clayster.com - + technologies beyond "The Internet" while at the same time improving security and controllability of the information.

    - 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).

    @@ -1420,7 +1421,7 @@ Host: clayster.com - HTTP over XMPP @@ -1462,7 +1463,7 @@ Host: clayster.com     - +

    HTTP Headers are serialized to and from XML using the XEP-0131 Stanza Headers and Internet Metadata. - 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 XEP-0131, 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 Header Definitions or @@ -1578,7 +1579,7 @@ Host: clayster.com

    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 should be applied in particular on audio and video content.

    - 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.

    @@ -1608,7 +1609,7 @@ Host: clayster.com

    - 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

    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.

    @@ -1860,7 +1861,7 @@ Host: clayster.com - + @@ -1876,14 +1877,14 @@ Host: clayster.com - + - + @@ -1895,7 +1896,7 @@ Host: clayster.com - + @@ -1949,7 +1950,7 @@ Host: clayster.com - + @@ -1961,13 +1962,13 @@ Host: clayster.com - + - + @@ -1980,13 +1981,13 @@ Host: clayster.com - + - + ]]>