Hello Ralph Thanks for your comments.
> I agree with Peter (Saint-Andre). Just introducing a new scheme doesn't feel > right to me. At the very least I'd like to see a rational for not using the > xmpp scheme, which should be able to handle the use cases, that goes beyond > the lack of character-by-character equivalence after the scheme component, > compared to HTTP(S) URIs. 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. 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. 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. Does that answer your concern? Note also, that I propose the registration of a provisional URI scheme, not a permanent one. This allows for modifications. It can later be advanced to a permanent URI scheme, when the XEP moves to draft (and everybody are convinced this is a good idea). Sincerely, Peter Waher
