In this section, we describe how MPA fits into the overall picture of networking and argue that MPA, or something like it, is a logical extension of the current model of networking.
Networking systems are traditionally organized using a layering model composed of Application, Transport/Network, and Link layers (Figure 1). This model is useful in clearly defining the responsibilities and restrictions of software that exists at each level.
For a layer to be fully implemented, it needs a naming scheme, a way to resolve those names, and a way to route communications. The Name Types column of Figure 1 shows the naming scheme that Internet email uses at each layer. Some examples of names are shown in the Packet Headers column. These naming schemes usually mandate that the names are unique and change infrequently. In addition, each layer in the figure has a protocol to map its names to lower layer names (the Name Lookup column in Figure 1). This mapping facilitates routing a communication to its destination.
There is one key problem with the traditional layering model: it does not explicitly include people. It seems odd that a communication model would not model people when probably the most important communication is from one person to another.
To model the full process of personal communication, we need to extend the model to include people (the new People layer is shown in Figure 1). Although the layer is new in the model, it is not new in reality. As a result, it is currently implemented in an ad hoc, non-unified way. People are not always named in a unique way, although a name or nickname is often unique among those with whom a person communicates frequently. These names (e.g., Jane Mobile) are resolved into application-specific names (e.g., jane16@yahoo.com) using a directory service (e.g., LDAP [WKH97]), an address book, or simply from a person's memory. By directing messages to application-specific addresses, it is the sender who controls their ultimate destination rather than the recipient.
As a result, messaging applications (and therefore their users) have difficulty delivering messages to people who move from one application-specific address to another. For example, if Jane Mobile's email address changes because she travels between home and work, Dan Sender's mail client (and therefore Dan) cannot reliably send email to her. Even worse, if Jane is temporarily unavailable by email, but is reachable by phone, Dan cannot communicate with her until she is available by email. The problem is that Dan cannot identify Jane in a way that is independent of how she is reachable.
The solution is to create a unified implementation for the People layer. Such an implementation needs to name people, map people's names to application-specific addresses, and route communications between people (which we refer to as people-level routing). Although the first two functions are partially implemented today, no implementation exists for a people-level router.
The role of a people-level router is similar to that of an IP router: it takes communication from a variety of interfaces and directs it out one or more interfaces, based on the recipient's preferences and on characteristics of the communication itself. The closest current approximation is a human assistant who answers Jane's phone, reads her email and forwards her messages by calling, emailing, or paging her. Aside from wasting the assistant's time, this implementation would have difficulty forwarding real-time communication (e.g., forwarding an IP telephony call to her cell phone).
The people-level router is a necessary component of any implementation of the People layer. The People layer is a logical extension of the traditional layering model which is the basis of current networking architectures. Therefore, the people-level router is also a logical extension of traditional networking architectures. The MPA implementation of the people-level router is the Personal Proxy, which we describe in greater detail in Section V.