[Standards-JIG] XMPP URIs was: Two questions regardingJEP-0124HTTP Binding

Mridul Muralidharan mridul at sun.com
Mon Nov 28 10:02:29 UTC 2005

Hi Ian , Peter,

  Thanks for the clarifications.
A way to specify the route host is required - another example (other 
than what has been mentioned before) is the XMPP server returning a 
streamerror with see-other-host.
More inline...


Peter Saint-Andre wrote:

> Ian Paterson wrote:
>> Peter is proposing that the 'route' attribute should be a simple
>> "host[:port]" value. Other possibilities *might* be "xmpp:host[:port]"
>> (compatible with existing JEP-0124 spec) or just "xmpp:host". The latter
>> is compatible with XMPP URI/IRIs ('route' is after all an XMPP resource
>> identifier), but perhaps it is not ideal, see
>> http://mail.jabber.org/pipermail/standards-jig/2005-June/007818.html.
> OK, so we have three options:
> 1. host[:port]
>    Pro: specifies everything we need
>    Con: not backwards-compatible with what we have now
>         doesn't support (future?) non-XMPP connections

> 2. xmpp:host[:port]
>    Pro: backwards-compatible with what we have now
>    Con: looks like an XMPP URI but isn't (confusing?)

Option 1 is sufficient for now ... but potentially limiting.
Using "xmpp:host:port" or "xmpp://host:port" (or variations thereof) 
would take care of potential future requirements from what we can 
envision now ...
Since there are already implementations of clients and 
servers/connection managers out there - the changes made should be , if 
possible , as backwardly compatible as possible.

> 3. xmpp:host
>    Pro: ?
>    Con: doesn't support ports
>         not backwards-compatible with what we have now
> I think (3) is a non-starter. I don't like the confusing aspect of (2) 
> and personally I doubt that this spec will ever be used for non-XMPP 
> connections, so I prefer (1). Have I missed any pros and cons?

This is definitely not very optimal - port can be a requirement to 
disambiguate the actual server to connect to.

> P

More information about the Standards mailing list