[JDEV] UIDs

[Jon Beckham]

One more concern to address:
If someone has multiple names on AOL, a couple on ICQ, maybe on or two on
yahoo, etc... are we going to send the message from the jabber client to
all those different instances of the same person?
Just another issue.  

 Jon Beckham
class of 2000
  webmaster

On Tue, 31 Aug 1999, Scott Robinson wrote:

> Interleaved response.
> 
> Scott.
> 
> * Jeremie translated into ASCII [Tue, Aug 31, 1999 at 02:45:07PM -0500][<Pine.LNX.4.10.9908311412210.30188-100000 at lor.jeremie.com>]
> > > 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.
> > 
> 
> Two issues with your "when we were moving from UUCP"-esque solution.
> 
> a) The SMTP one will conflict with current SMTP/Internet Mail addresses.
> b) It's a kludge. It was then, and it is now.
> 
> > > 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.
> > 
> 
> They use completely different "workgroup" clients which can only connect to
> the intranet ICQ server. They are not routed through the main servers.
> 
> > 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.
> > 
> 
> Which goes back to my original problem of host name conflicts.
> 
> > > 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.
> > 
> 
> I have a severe problem with this. It seems _very_ kludist. Reserve and
> "default name" keyword type solutions always run into problems later.
> 
> > 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.
> > 
> 
> Transport information is hidden in the current 0.6 protocol spec. This is a
> proposal to go into 0.7.
> 
> Personally, I would want my client to have the added information also. I
> would want to change my formatting/message content/encoding to make it
> easier for the transport/service to handle my message.
> 
> > 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.
> > 
> 
> Except IETF is leaning towards URL/URI-esque addressing schemes.
> 
> 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.
> 
> I'd note we're not the IETF. We want to release a working system, maybe
> before, maybe after the IETF finishs theirs. (I hope before) The spec I'm
> suggesting will allow for (as far as I can see) extendability to whatever
> addressing scheme any system uses.
> 
> > Jer
> > 
> [snap]
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>