A modest proposal.

[Robert McQueen]

C. Scott Ananian wrote:
> On Feb 19, 2008 7:57 PM, Robert McQueen <robert.mcqueen at collabora.co.uk> 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 name.xxx at school.etc, 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 user at hostname/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