[JDEV] UIDs

[Scott Robinson]

Interleaved response.

Scott.

* Jeremie translated into ASCII [Wed, Sep 01, 1999 at 12:26:46AM -0500][<Pine.LNX.4.10.9908312333270.32411-100000 at lor.jeremie.com>]
> > I have a severe problem with this. It seems _very_ kludist. Reserve and
> > "default name" keyword type solutions always run into problems later.
> > 
> > After discussing this IRL with a friend, I've decided instead of a
> > <transport>://<server>/<transport supplied> that a
> > "jabber://<server>/<transport>/<transport supplied>" solution would be much
> > better. This doesn't conflict with current URLs and (after arguing about the
> > order of server and transport) allows for the same extensibility. It also
> > allows for the "hidden transport" system we currently have, which I hope can
> > be a median point.
> 
> 
> Alright, I'll agree that the overloading of the naming on the right of the
> @ is a kludge, where you can have special non-DNS names like @ICQ or @AIM
> that resolve magically to a local transport on the server... 
> 
> Let's see if we can find a happy medium here :)
> 

You may notice I shoot for outrageously hideous solutions that include
everything so that we can create a beautiful one that works. :]

[snap] I'll talk about this stuff in a later post.
> That's all nice to know, but what does it have to do with anything?  I
> think the point I'm trying to get to is that each Jabber user is likely to
> know and understand their "Jabber" address but only the more
> advanced/techie ones will ever see or understand the addressing mechanism
> used to send to a transport.
> 

What I really want is an address that is simple, common, and usable. The
more information we pack in, the more an address loses these three
characteristics.

In the current implementation of transports and message routing, each server
has their own set of transports (not sharable) that bridge to the
appropriate networks. Lending from this setup, a simple addressing scheme of
<user>@<server.com/TRANSPORT> was developed and works. (kinda)

However, not everyone will want to play nice in our brave new world.
Moreover, it causes routing difficulties for future projects we have in mind
(PersonalServer comes to mind) to force local-only transports upon our
protocol. I've made a type of dual-proposal by specifying where the
transport is at: one for UR*-esqe addressing and another extended routing
for transports.

So I return your post with two more ideas. The first, an extension on your
happy median. The second, a whole different idea from a programmer-friend
IRL.

"user at server/transport"? I'd like my transport to be able to encode a bit
more information than just it's name. Reason? Because I see uses for
transports such as "guises" and special forwarders/gateways. So I suggest an
extension that looks like this: "user at server[/transport[/transport encoded]]".
It allows for our current UID system, extends for the transport, and
optionally allows for more encoded information the transport needs.

A programmer friend of mine working on an alternative IM system said, "Scott,
why are you screwing around with transports on the same machine? The DNS
system is large and cheap for what 'real' servers use. Just make all the
transports have a different DNS entry." To which grumbled something about
not having a bunch of servers and wandered away to write this e-mail. The
thing is, he's got a point. DNS is cheap and it's there, so why not use it?
scott at jabber.org? If I want to send to ICQ, 12341234 at icq.jabber.org. If
you're cheap, or can't figure out how to map servers out to the same port on
different IPs, 12341234 at icq.jabber.org:5555. These can all be on the same
machine talking the same jabber language. Heck, they could be the same
"etherx" daemon (I'm introducing a new paradigm here. ;)) passing to the
appropriate "transport" inside based off the address. Not the "transport
information" encoded within a UID.

I personally love the simplicity of the latter idea, but our current system
would work better with the first. Can I get a semi-referendum here?

[snap]
> 
> Jer
> 
[snap]