Objects with no public IP address
Many computers today are located behind some kind of firewall or NAT devices. While they can connect to the Internet, they cannot be actively connected from the Internet. Objects hosted on these computers do not have the same visibility as others. For example, the meso:lib.Blog object above is hosted behind a firewall. Assume that a programmer want to pass the object by reference as an argument to the Directory.add(IBulletin) method (shown in the previous example). This is reasonable because the object does implement the method argument's type imop:api.org/service.IBulletin, but first we need to make the object accessible from the Internet.
IMOP provides a solution by using indirect host names with persistent connections. As in the figure above, a computer behind a firewall can connect to a remove host and ask for an private node name (1). Assume that the name returned is h001 (2). Combing it with the remote host's name results in an indirect name email@example.com, meaning that "the node h001 currently connecting to the host search.com". The Meso runtime can then use the indirect address to construct a public UTL for the Blog object behind the firewall (3). As long as the TCP connection between h001 and search.com is maintained, the objects can be accessed indirectly via search.com.
The beauty of a UTL like imop:firstname.lastname@example.org/lib.Blog is that it can be passed around the GPG without loosing its specificity. Anyone gets a hold of it can treat it as a regular UTL and send IMOP messages to search.com, where the messages will be relayed to the private host behind. This is a simple and effective way to overcome firewall boundaries. The following figure illustrates how a random host reflects the definition of the UTL imop:email@example.com/lib.Blog.