[Standards-JIG] UPDATED: JEP-0100 (Gateway Interaction)

Richard Dobson richard at dobson-i.net
Thu Mar 11 11:50:35 UTC 2004

> On Thu, Mar 11, 2004 at 10:45:53AM -0000, Richard Dobson wrote:
> > It would be far better to have a standardised encoding scheme for
> Do you know the requirements for any possible transport? What are the
> possible identifiers (username, user number, mail-like 'user at host' are
> known, but there could be something more out there).
> For my IRC transport do I have to use the user unfriendly
> '#channel%irc.server at irc.transport' JIDs, when I prefer simple
> '#channel at irc-network.transport' JID? Or other implementations should
> change mapping to my scheme (which won't fit their architecture)?
> Let the transport implementators make the choice.

I never said implementors cannot make their own architechtural choice along
the lines of your suggestion above, but with my suggestion you would
probably have JID's in the form of:
#channel%25irc.server at irc.transport
But because it is encoded in a standard way the client can in a user
friendly way display the ID as:
#channel at irc.server
Possibly also showing an IRC icon next to it, this seems the most user
friendly option to me compared to your suggestions, as it completely hides
the fact the transports even exist, which helps make things easier to
understand for the user and makes it appear to blend in gracefully and
cleanly, a well designed client does not need to make known to the user the
complexities of using transports, things should be as transparent as
possible, which is a goal this encoding scheme helps clients obtain in a
clean and future proofed manor.

> > JID's so you dont even need to make any protocol requests, these create
> > delays, and create unneccesary server load,
> This is not an issue. There are many other protocols requests that make
> JID mapping delay/load not significant at all.

Huh?? If you can eliminate any need to make requests over the wire to
discover the ID on the remote system that the JID represents by appropriate
encoding it is very much an issue. Some people have objected to clients
disco'ing all their contacts when they log on, what do you think they are
going to think when those clients start also sending lots of requests to
find out the real legacy id of all their transport contacts when they log on
too? When this whole mess could have been prevented by having a standard
transport JID encoding mechanism eliminating the need to make all those
queries and also eliminating the delay caused by having to wait for all
those queries come back before they can render the roster in a user friendly
way, the delays and server load are a VERY significant issue especially
since there is a simple method to eliminate this entirely.


More information about the Standards mailing list