[standards-jig] Version 0.6 of JEP-0045 (Multi-User Chat)

Richard Dobson richard at dobson-i.net
Thu Sep 26 14:27:54 UTC 2002

> The only thing we need to know in JEP-0045 is the maximum URI length,
> and that seems to be set already. The rest could be left to the
> implementation, couldn't it? Besides, it's easy to recommend a wide
> hierarchy instead of a deep one. We think we would have to really
> provoke to even come close to 256 characters. Try it yourself.
> If a server would come close to having too long URIs then one solution
> for the implementors would be to use shortcuts to jump to other servers.
> A bit like symbolic links between different file systems. That system
> seems to work fine with the web and ftp. Using links could also tie
> large numbers of conferences together into one chat environment, like
> IRC networks. But links are matters for the implementation.

JEP-0045 does not define the URI length, that is what JEP-0032 does, but it
is not simply a limit to the entire URI, the limits are defined to the parts
of the URI, there is a 256 BYTE limit not CHAR limit, since the node can be
unicode text a character could be represented as multiple bytes, hence the
BYTE and not CHAR limit.

Ok they could be hosted on different server browsed through the heirarchy,
read up on browse, its not really anything to do with symbolic links, its
more like a hyperlink, but you need to properly define error conditions when
someone tries to create a room with a node that is too long. But linking to
other servers all over the place throughout the heirarchy instead of just
setting up a proper structure would be very messy IMHO, e.g. it would be
better to browse like this:

1) company.com - Company Jabber
company.com/conf - Company Conference Center
company.com/trans - Company Transports

2) company.com/conf - Company Conference Center - (A list of conference
servers for each dept)
marketing.gc.company.com - Marketing
sales.gc.company.com - Sales
dev.gc.company.com - Dev
support.gc.company.com - Support

3) dev.gc.company.com - Dev
ms at dev.gc.company.com - Microsoft
linux at dev.gc.company.com - Linux
osx at dev.gc.company.com - MacOSX

4) linux at dev.gc.company.com - Linux
jabber.linux at dev.gc.company.com - Jabber Dev
kde.linux at dev.gc.company.com - KDE Dev

Having links to different servers at anything after level 2 as you suggest
will be messy and become unmanageble IMHO, this is a much better pattern for

> > > compare these:
> > > #channel%jabber.eu.openprojects.net at irc.jabber.org/username
> NOTE! channel\jabber\eu\openprojects\net at irc.jabber.org

What about it? it is actually:

room%server at irc.jabber.org

you cant compare it because it will never end up being:
room.room.room.room%server at irc.jabber.org
since IRC does not support it.

> > Rooms in a row, where? in the browse?
> Sorry, but i forgot... In jabber at c.j.o we call it a row to differentiate
> from hierarchies. What would you call a one-dimensional collection of
> rooms? A corridor?

Calling it a list is much more understandable.

> When interacting with a chat system such as IRC or conferences, we tend
> to think that we are talking to a room when in fact we are talking to
> the server controlling the room. Although we have two ways of
> interacting with IRC (rooms and servers), it's is in fact the server
> that answers in both cases. The same can be said about the hiearchical
> jabber conference server that we are working on. We probably need two
> ways of talking to the conference, but we don't have to decide how in
> this JEP.
> We see no need to hinder the progress only because of one word. The
> current scope applies (and works well) if we believe "room" to mean
> "chat system". We can live with that.

Well you are always interacting with the conference service if you are going
down that line of thinking (thinking too much into it), when creating and
destroying rooms the room is addressed, not the base service and that is
that, read the spec.

When creating a room you address:
room at server.com


So you ARE interacting with the room thats how it works.


More information about the Standards mailing list