Added remarks for the xml encoding to clarify the need to avoid creating invalid XMPP.
+Clarification added regarding to base64 content size when using schema-aware EXI compression.
+The name of the new proposed URI scheme has been changed from xmpp to httpx.
+An URI Scheme Registration Template has been added, as per BCP 35.
+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. + (<?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 + jabber:client namespace. If in doubt, use another encoding mechanism.
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 data element and its contents. @@ -735,9 +748,10 @@ Host: clayster.com 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). -
-+ (<?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. +
+If unsure how to handle XML responses using the xml encoding type, you can equally well use the text type, but encode the XML escape characters <, > and &, or use another encoding, like base64.
@@ -787,9 +801,14 @@ Host: clayster.comBase-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 - 4 bytes to encode 3 bytes of data. Care has to be taken not to send too large items using this encoding. + 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 + to encode the data only uses 6 bits of information per character, and thus compresses the data back to its original size. +
The following example shows an image is returned using the base64 encoding:
@@ -1080,43 +1099,56 @@ Host: clayster.com 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. -- A simplified way to describe an URL is to describe it as having three parts: -
-- In the HTTP over TCP case, the scheme is http:// or https://, and the domain is the name or IP address of the - web server with an optional port number. Some even allow for user credentials to be passed directly in the URL, something which is blocked in - many browsers, for security reasons. -
-
+
+ The syntax and format of Uniform Resource Locators (URLs) or Uniform Resource Identifiers (URIs) is defined in &rfc3986;. The basic format is
+ defined as follows:
+
+ &rfc2616; furthermore defines the format of URLs using the http URI scheme, as follows:
+
+ &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.
+
+ In a similar way, this document proposes a new URI scheme: httpx, based on the HTTP URL scheme, except
+ httpx URLs imply the use of HTTP over XMPP instead of HTTP over TCP. URLs using the httpx
+ URL scheme has the following format:
+
+ 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.
+
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
- from the http:// scheme to an xmpp:// scheme. All relative URL's within the application, including URL's sent to the XHR object (Ajax) will automatically
- be directed to use the HTTP over XMPP transport instead.
+ 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.
- So, this specification proposes a new transport for HTTP over XMPP, as follows:
-
- 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.
-
@@ -1126,7 +1158,7 @@ Host: clayster.com
multiple connection is canonical.
- 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.
@@ -1180,9 +1212,9 @@ Host: clayster.com
- If the above rules are met, which they should under normal conditions, typing in the xmpp:// URL in the browser (for instance when
- you're at the office) should display the application (hosted for example at home behind a firewall) in the same way as when you use http://
- (or https://) when you have access to the server (for instance when you're home), as long as friendship exists between the browser JID and
+ 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
the server JID.
+ Note: 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 < character + to the closing > character. +
@@ -1585,7 +1622,7 @@ Host: clayster.com (if the browser also maintains an IM client), or automatically rejected.
- 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
of an application already displayed, this implies giving permission to add that JID as a friend to the roster of the
browser.
@@ -1639,13 +1676,167 @@ Host: clayster.com
- The XMPP URL scheme, as described above, must be registered.
+ The httpx URL scheme, as described above, must be registered as a provisional URI scheme according to BCP 35
+ Following is an URI Scheme Registration Template, as per BCP 35, section 5.4.
+
+ httpx
+
+ provisional
+
+ The syntax used for the httpx scheme reuses the URI scheme syntax for the http scheme, as defined in RFC 2616:
+
+ 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:
+
+ 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.
+
+ 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.
+
+ Encoding is fully described in the
+ Encoding section of the HTTP over XMPP XEP document.
+
+ This URI scheme is to be used in the same environments and by the same types of applications as the http URI scheme.
+
+ Interoperability considerations is described in the
+ Implementation Notes section of the HTTP over XMPP XEP document.
+
+ Security considerations is described in the
+ Security considerations section of the HTTP over XMPP XEP document.
+
+ For further information, please contact Peter Waher:
+
+ Email: peter.waher@clayster.com
+ For concerns regarding changes to the provisional registration, please contact Peter Waher:
+
+ Email: peter.waher@clayster.com
+ Following is a short list of referenced documents:
+ REQUIRED.
+
+
+
+
+
+
+
+
+
+
+
+ JabberID: peter.waher@jabber.org
+ URI: http://www.linkedin.com/in/peterwaher
+
+ JabberID: peter.waher@jabber.org
+ URI: http://www.linkedin.com/in/peterwaher
+
+
+
+ The protocol schema needs to be added to the list of XMPP protocol schemas. +
+
Thanks to Peter Saint-Andre, Karin Forsell and Matthew A. Miller for all valuable feedback.
+Thanks to Peter Saint-Andre, Karin Forsell, Matthew A. Miller, Kevin Smith and Ralph Meijer for all valuable feedback.