On 10 Jul 2013 10:37, "Peter Waher" <[email protected]> wrote: > Regarding why the existing xmpp scheme cannot be used, and maintain compatibility, especially as you suggested a new query type needs to be defined, is because of the desire to be able to create seamless transitions of existing web applications from HTTP/TCP to HTTP/XMPP, without having to change any code or links.
This I agree with. > As you know, a web page contains embedded URLs that use the base URL of the web page to refer to content within the page. The new URI scheme has to be compatible with this. The problem arises for example, if the page contains say an image <img src="/img/img1.png"/>. It will remove any query type and parameter from the base URI, and create an URL that is invalid according to the existing xmpp URI scheme. Equally this; relative reference rules will simply not work in a way that's expected. > 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? 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). Dave.
