[JDEV] UIDs

[Jeremie]

> One good reason to encode transport information is the problem of address
> domain conflicts and multiple transports.

This is a limitation of the current user at server simple addressing
mechanism, but one that can be worked around easily(not pretty) for each
transport or in a more general sense: embed the routing information in the
user field such as "user%server at ROUTER".  The ROUTER then decodes the user
and server fields.  Like I said, not pretty, but it works.  In fact, you
*used* to be able to route email all over the world this way before spam
blockers:  jeremie%jabber.org%sun.com%microsoft.com%aol.com at isp.net would
be routed through all of the server back to me, in a day or so :)

The only *immediate* needs I can see for this would be for an SMTP and IRC
transport, where you could gateway to email via email%address.com at SMTP or
IRC via nick%server at IRC.

> Example: ICQ has the main ICQ network (we'll call it icq.com because I don't
> know it's real address) however they've also released a "Workgroup"-esque
> server package. If we have transports connecting to both places, or better
> yet, a transport at a different server on my local Jabber network connected
> to a different ICQ network I'd want a way to specify them. 12341234 at ICQ
> should goto the main network. However, how should I specify the alternative
> network? 12341234 at ROBHOME? Hold on, "robhome" is the name of a server here!

These "workgroup"-esque ICQ servers either have to be completly seperate
from the rest of the ICQ world, or routed to automagically via the ICQ
main servers.  ICQ has no built in means of identifying other ICQ servers
that I know about, it's all just UINs.

If that is the case that they are completely seperate, then how can we
expect Jabber to magically bridge with just the UIN what ICQ doesn't even
bridge? All you would have to do is have two instances of the ICQ
transport installed, each defaulting to a different server, so yes, you
would have 12341234 at ICQ and 12341234 at ROBHOME since they are completely
seperate environments.

> In fact, with the current naming structure we'd have to decide whether a
> transport "name" had priority over a host name.

Yes, with the current naming structure a local transport can provide
default names that are resolved to first in a case sensitive way.  This
allows you the flexibility in naming a large number of private transports,
without having to create DNS names for each one individually.

Of course, if your domain is foo.com, you can also just give them DNS
names and use @icq.foo.com and @robhome.foo.com.

> Proposed solution: icq://12341234, icq://icq.com/12341234, or even
> icq://jabber.localdomain/icq.com/12341234 can be used to differenciate
> between the UIDs. (which one we used depends on how we'll finally end up
> implementing routing and how abstracted we want UIDs) icq://robhome/12341234
> or icq://jabber.localdomain/robhome/12341234 should then transport to the
> independent ICQ network "robhome".

The "icq://" is completly useless information since the transports are
identified by their name and there is no inherent knowledge of what type
of transport they are, so all you end up with is the user id and server id
again.

You could have a scheme such as jabber://foo.com/robhome/userid, but to me
that makes just as little sense as userid%robhome at foo.com, neither of
which I really like.  I'd much rather wait and see how the IETF approaches
this issue and go from there, for what it's worth we could easily support
both forms since they represent the same thing just vary in syntax.

Jer