Hello Dave Thanks for your feedback. Regarding your concerns, I'll answer them in sequence:
>> So, to be able to create such a seamless transition (which is also important >> in semantic web scenarios) >> we need an URI scheme that works in a syntactically identical manner as the >> already existing http URI >> scheme. Now, there exists another such URI scheme, which shows how this is >> best done: the https >> URI scheme. Basically it's the same problem: How to create a new transport >> of HTTP messages, but >> maintaining URI syntax logic available in clients. > > I wonder, though, what other options would satisfy. > > Given http://example.org/, could we have a browser which understood HTTP/XMPP > transition seamlessly > to fetching from an XMPP entity instead? Well, you could create a browser (or other type of client) that understood http://... to mean fetch using HTTP over XMPP. But then you would not be able to mix schemes/protocols. Consider the following two examples: 1) A web page that embedded content from other servers on the Internet (video, image or audio content, RSS/ATOM feeds, etc.). 2) A SPARQL 1.1 endpoint supporting federated queries (based on URLs) and semantic data graph retrieval (also Based on URL's). One of the main goals of the Semantic web is to be able to link to any data item. Many data sources lie on the Internet using normal HTTP. But we want to extend the semantic web and related technologies to private domains, such as home networks, etc. In these instances, you want to host the data or federated SPARQL endpoints using HTTP over XMPP instead. In these cases, SPARQL queries will contain a mix of data from a set of URLs with mixed schemas, and the engine needs to know how to handle each scheme separately. A simple example might be to join data from your private sensors to complementary information found on DBpedia (or other online database) in a query, for example. How would you differ from content URLs that require HTTP over XMPP and other content that is HTTP over normal TCP? When HTTP is done over TLS, this is shown by switching to a separate URI scheme: https. The same would be the logical solution to the HTTP over XMPP case as well. It's proven to be a very efficient way to solve the problem, and existing implementations (like browsers, web servers, etc.) already support an architecture with pluggable URI schemas. However, they do not support an architecture that chooses between different protocols based on specific URI syntax beyond the scheme. > Also, my impression based around a quick read rather than detailed review is > that this is a simple mapping > of HTTP/1.1 to an XMPP transport; I wonder if this should be examined in the > light of the advances present > in HTTP/2.0 (AKA SPDY). The protocol includes a version number in the request, making it possible to state protocol version. HTTP/2.0 is supposed to be fully backwards compatible with HTTP/1.1. It adds features including multiplexing, etc., which has no direct parallel in this case. But, it doesn't mean the XEP cannot be extended when new features such as these appear and become standardized. However, any HTTP/x request using a method, headers and possibly a content type encoded data block can be done using this proposal. The methods, headers and content types are not limited in the proposal, so any extensions in these areas will not require updating the proposed XEP. I hope these answers answer your concerns. Sincerely, Peter Waher
