[JDEV] UIDs

[Jeremie]

> 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 :)

Ok, the real question here is how is just any normal Jabber user going to
know how to add their buddies using AIM or some other system, how will
they discover if they have this functionality available on the server they
are connected to?  They shouldn't have to just "know" the name or address
of the transport, and the client can't have this built in as it will
change with every server and they can all name it differently.

My thoughts have always been to use the info/query functionality to send
the server a query for the available transports, and this list could be
displayed to the client.  Each transport is required to respond to certian
common queries like help, about, register, if the user requests that
information.  There's a lot we have to figure out here yet once we get to
that point in 0.7/0.8, but we can assume that the user will be selecting
the transports from a nice list and searching those transports for buddies
to add to their list, and may never *see* the actual address representing
that entry on their list.

<tangent>I need to explore some of the thoughts here as we start having
transports to play with, such as the client can send a general query that
contains either a name and/or email address and the server will cascade
the query through all of the transports that query their respective
networks, resulting in a match or list of matches for how to access this
user(defaulting to Jabber of course if it's available), very
powerful feature for non-geeks :-)</tangent>

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.

The middle ground that I'm approaching that will encompass both is this:
Since the first blah:// is irrelevant *internally* in jabber just as
ftp:// and http:// are irrelevant internally in those protocols, it is
optional and only used in a web setting or where a URI is appropriate. The
rest of it would be structured similiar to other URI's where you have
userid at server.com/transport.  

There are quite a few operations where you don't use a userid, such as
quering the server for help, registering, and other public operations, and
you'd just have server.com/transport.

The /transport would also be optional and all operations would default to
Jabber.  If a /transport is specified, of course, all operations are
delivered to that transport.  This helps since you don't have to have a
DNS name for every public transport, just the base server, and makes more
sense that way.  Of course, you still *CAN* give any transport a DNS name
and it would just be "transport.server.com".

I think this is a happy medium, it gets rid of the kludgy fake @TRANSPORT
naming scheme, doesn't require a DNS entry for every transport, allows the
flexibility to move resources around easily and route things
appropriately, and makes me happy since for normal Jabber user ID's they
can still look like user at server.com :)  

So, in a web/URI setting you would have jabber://foo@bar.com/, and ICQ
user represented in a Jabber client would be jabber://123456@bar.com/icq,
and of course internally in Jabber a user could address another user just
as user at server.com :-)

How does this sound?  Is it the best of both worlds?  I think I can make
this all play nice with etherx and stuff too... I'm starting to like the
idea, thanks for rubbing my nose in it, *grin*.

Jer