[JDEV] Discussion of transports?

maqi at jabberstudio.org maqi at jabberstudio.org
Mon Sep 22 03:38:25 CDT 2003

On Mon, 22 Sep 2003, Jacek Konieczny wrote:

>> 1. Transports often don't treat the JID case-insensitive leading to the
>> problem that the transport does not login when logging in as user at host but
>> having registered with USER at host.
> Transports with treat JID case-insensitive are simply broken. JID should
> be processed using nodeprep profile as described in XMPP drafts or at
> least case-fold characters in ASCII range (as it was defined in the
> legacy protocol).

That's right. I wanted to keep the notice short and understandable.

>> 2. With most legacy networks, the transport should auto-import the legacy
>> system's contact list to the Jabber roster.
> Possibility to populate someones roster with <presence type=subscribed>
> is a security issue and I hope it is not present in jabberd2.

This has been discussed before. Using jabber:x:roster is not user
friendly, does not really reflect the things happening (no, we don't *add*
*new* contacts, we *import* *existing* contacts) and finally is not
supported by every client.

As for "security issue", this can be resolved. For example, the server can
be patched to not let "unauthorized" components push contacts (no
"transport.host" in my roster - no contacts can be pushed by it).

A JEP should be written on this. That would be a feature not only nice for
transports but also for many other applications.

>> 3. The transport has to create a list of contacts that must be handled.
> GaduGadu transport keeps its own roster updated with presence type
> subscribe/unsubscribe and this work well.

Well just read what I wrote. This way the rosters *can* get out of sync,
they do for example if you add a contact while the transport is down (not
running on the server or s2s failed) or probably even when you are not
logged in to the transport (depending on the transport's implementation).
Or they get out of sync for example if one server gets restored from a

While this may be rarely the case, it is an issue that must be addressed.


More information about the JDev mailing list