[Standards] XMPP URI usage in "HTTP over XMPP"

Dave Cridland dave at cridland.net
Wed Jul 10 20:27:44 UTC 2013


On 10 Jul 2013 10:37, "Peter Waher" <Peter.Waher at clayster.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130710/601b9475/attachment.html>


More information about the Standards mailing list