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

Mridul Muralidharan Mridul.Muralidharan at Sun.COM
Mon Dec 5 08:56:57 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 and client reconnecting with that host 
as route attribute value.
More inline...

Thanks,
Mridul

PS : I did send an earlier response , but I guess the time on that box 
was messed up.

Peter Saint-Andre wrote On 12/02/05 22:39,:
> 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
> 

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

> 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?
> 
> P
> 




More information about the Standards mailing list