C. Scott Ananian wrote: > On Feb 19, 2008 7:57 PM, Robert McQueen <[EMAIL PROTECTED]> wrote: >> C. Scott Ananian wrote: >> Currently we use the buddy key as this unifying key, but I very much >> like the idea of providing extra information to open up the prospect of >> communicating between schools, and allowing the XOs to exist in the >> global XMPP namespace. > > Ok, what extra information are you suggesting?
The extra information provided by an XMPP identifier such as we've been discussing, versus just the hash of their buddy key, which in the case of [EMAIL PROTECTED], gives us a human-readable name, and a DNS identifier for their school where we might contact for further communications with that individual. > I really have no clue > what your phrase "global XMPP namespace" is supposed to mean. Don't > you mean "global DNS namespace", as the bits to the left of the @ sign > are supposed to be resolvable via DNS, no? XMPP doesn't have any part > in that resolution. The global XMPP namespace is a sloppy term, I apologise, but what I was alluding to is the ability to present an XMPP identifier to any XMPP client and unambiguously identify the server it belongs to and where you might contact to find the corresponding individual. It's a combination of DNS SRV lookups to find the server, and then speaking to that server to find the individual. >> Correct, but the problem here is that makes the addressing essentially >> incompatible with re-using the existing (and globally-compatible) >> namespace. > > Again, I have no idea what you're getting at here. Every laptop has an XMPP identifier already. Every school server is an XMPP server. If we namespace the identifiers and the school servers appropriately, we don't need to invent any /new/ namespace (or URI) scheme for the purposes of providing identifiers which can be used to unambiguously identify XO users. Using XMPP identifiers has benefits in terms of being far more compatible with the outside world, supporting unicode naming, having more in common with our existing architecture, as well as provoding a means to communicate with the individuals rather than merely finding their IP address. >> In general, people don't run one XMPP server each. > > Is your contention that people should run *less* than one XMPP server > each (which I strenuously disagree with), or that they typically run > *more* than one XMPP server each (and that's what the 'resource' part > of a JID is supposed to be for)? People do run *less* than one XMPP server each, yes. The hostname part of a normal [EMAIL PROTECTED]/resource JID is resolvable via SRV lookups to indicate one or a cluster of servers which are responsible for that (and many other) user's account. The resources vary as multiple clients belonging to the same user connect. There are variants of the XMPP protocol which are geared at purely peer to peer communications and rely on no server, namely link-local XMPP, which we use when the server is unavailable. >> The odd part seems to be that DNS must be involved. > > How is this odd? DNS is the second-oldest part of the internet. It's odd because I don't see what benefit is served by extending this part of the internet into an internal name resolution process which in our current architecture will take place in precisely one process. For who's benefit are you trying to emulate DNS by considering a DNS proxy per laptop? >> You don't need to mangle >> things via DNS in order to allow a higher-level component to interpret >> them and be able to make a mapping between identifiers (however they're >> derived) and local IPv6 addresses. > > The key point is that *no other server need be involved*. I also > prefer to avoid mDNS as much as possible, for reasons of scalability. Well, mDNS is something of a red herring in this discussion of naming, (but work is already under way to replace it for the purposes of mesh presence propogation, with Polychronous' Cerebro project). By "higher-level component", it could be a piece of code which takes the identifier, hashes it, and prepends a certain IPv6 network part. And indeed, no 3rd party server is involved during the Identifier -> Address "resolution" process, local or remote, DNS or otherwise. > And I've presented an existence proof that this can be done. > --scott Regards, Rob _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
