scott at tranzoa.com
Tue Aug 31 14:06:07 CDT 1999
One good reason to encode transport information is the problem of address
domain conflicts and multiple transports.
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!
In fact, with the current naming structure we'd have to decide whether a
transport "name" had priority over a host name.
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".
* Thomas D. Charron translated into ASCII [Tue, Aug 31, 1999 at 06:41:21AM -0700][<FHMCEBNBJGPPDAAA at my-deja.com>]
> On Tue, 31 Aug 1999 04:40:33 Scott Robinson wrote:
> >I'd like a bit more clarification on UIDs. What is wrong with a URL/URI
> >based UID system?
> URL/URI is used to identify resources. There is no reason why our current user at domain system will not be able to HAVE a URL. Just like FTP can use:
> Notice the simularity?
> Or, in the case of passing a password along:
> URL is a way to present transport, etc information. There is no reason to use URL internal to the protocol, IMHO..
> Thomas Charron
> --== Sent via Deja.com http://www.deja.com/ ==--
> Share what you know. Learn what you don't.
> jdev mailing list
> jdev at jabber.org
More information about the JDev