John Day talks about this a fair bit: what people want to do is naming of applications, in a way that makes it independent of addressing (i.e. where the application is running). DNS still names the machine — it's just a one-step abstracted machine addressing scheme, not an application naming scheme per se. Then we designed an ad-hoc protocol on top that associates applications with specific machine names (and port numbers): if you go to facebook.com:443 (a.k.a. https) you expect to find an instance of the Facebook application, not a webmail client or an SSH server.

This isn't how any of this was really supposed to work. Back in the day the application identifier was the _port number_, according to a big list maintained by ICANN. The idea was that you could go to a machine (identified by IP or more conveniently by DNS) and see if it was running an instance of the ‘Facebook’ application, i.e. you'd find Facebook not at facebook.com:https but at meta.com:facebook. The end goal was to eliminate the need for the former part at some point, and come up with a better way of looking up applications than distributing a list by email. Instead the application ID is now used for transport and the host name instead encodes application ID, which it was never meant for, and that's why we can't have nice things (like device mobility).