> Hallam-Baker, Phillip wrote: > > > > Over time everyone will own their own DNS domain > > and it will form the hub of their personal > > communications system. All communication modes > will map > onto the single unified communication identifier. > > > > I don't necessarily disagree with many of your arguments, but > I wonder why — if everyone owns their own DNS domain — we > even need the user@ portion anymore? Largely that was > included because in the early days — and even today, for many > people — their addresses were [EMAIL PROTECTED]
I agree. Example.com should be default be interpreted as a first class identifier. > My primary personal email address (not the one I use for > mailing lists) is pretty redundant since the part before the > @ is the same as the part after the @ once the parent domain > has been excluded. Leaving off the user@ portion doesn't make > the address any less "mine". The main issue here is who owns the naming registry. Under what circumstances does a name change control? The ICANN infrastructure is cumbersome but essential. Trying to replicate the DNS and ignoring the needs that led to the creation of ICANN is doomed. Trying to establish a proprietary registry is the sort of dotcom nonsense everyone apart from O'Riely and his Web 2.0 types have grown out of by now. > Calling a Jabber ID an email address is a bit misleading. OK call it an RFC 822 format address then. > It's entirely possible for the email address [EMAIL PROTECTED] > and the JID [EMAIL PROTECTED] to be owned/controlled by > different people. It is not safe to assume that the two are > the same person without evidence of that. What makes a string > like "[EMAIL PROTECTED]" an email address is the fact that you > can address email to it. The fact that the two addressing > schemes use similar syntax doesn't help you much. On the contrary there is a very high degree of probability that they are the same. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
