A FQDN is NOT useable as an EID. The host is not the endpoint.

Ok. FQDN + port number. The endpoint does not have to be *named*, btw. It is quite enough to disallow TCP sessions to survice change of source or destination TLA (which is more than enough to cover the change of service providers) or to keep track of address changes the same way the post service does (i.e. forward and ask the addressee to notify the sender).

Consider process migration.

Any commercial OS out there which does process migration? Most OS people became quite convinced that process migration does not pay for itself. Process migration is a lame excuse for building a whole new level of indirection and doing a hell lot of changes everywhere. And, magic cookie EID is *not necessary* for process migration (you may want to read rationale for TRAP). It can (and should) be done w/o it. No matter how you jump, the migration requires dynamical rebinding of EID->TLA, and the complexity of the task does not depend on the nature of EID. So why bother with extra level of indirection? It does not simplify anything, and like any extra layer anywhere only makes for a lot of headache (why do i think of ATM?). And then, there's a document describing how to do process migration w/o magic cookie EIDs, and so far nobody found a fundamental fault (or inherent inefficiency) in it. As i discussed that with Noel the aforementioned "architect's sense" came up :) The statement that migration is impossible w/o magic cookie EIDs amounts to the denial of the existance of the postal service. It does the two-level addressing (the EID is the identity of the addressee, the TLA is the postal address). When you move your magazines keep coming to you, right? Even if the "host" (i.e. home) didn't move with you. --vadim PS Computer science is the formalized branch of general bureaucratology.