I still don't understand why this (and like-minded
print or FAX servers) aren't addressed according to:
pager+4159408776(_at_)pagerserver(_dot_)tpc(_dot_)int
or even just
+4159408776(_at_)pagerserver(_dot_)tpc(_dot_)int
What is pagerserver in this example? Do you mean for it to be a system that is
run by some big service provider that splits out FAXes based on private routing
information?
If this is in fact the case, then the questions to ask are:
(1) Who runs and pays for this server? It is going to have to either be huge
or highly replicated to handle the load. It sounds pretty expensive to
me...
(2) What sort of private routing information is it using? Who provides it?
What format is it in? Who keeps it up to date?
(3) What's the rationale for setting up and maintaining such a server? Why
would I want to do it?
This simple does not scale at all well. Not only does it fail the absolute test
on not being able to handle the traffic, it depends on a local nondistributed
source of information which, as far as I know, does not exist in any real
sense. (Of course you can use the DNS to provide the information. But if you do
this why not just take advantage of the fact that everyone has access to the
DNS and can do the routing for themselves with no central server involvement?)
Or perhaps you are proposing that there be lots of pagerserver.tpc.int machines
out there, each providing access to some different portion of the spectrum. But
how do you pick the right one to use? Either you do it or the servers have to
do it themselves. In either case you still have the problem of getting the
right information to do routing, and once again the DNS provides the most
viable solution. So why not use an address format that lets existing software
do the routing with no changes or enhancements?
There's certainly nothing wrong with exploiting DNS and MX to solve this
problem, but I'd like to hear from those who have considered the
alternative(s) and prefer the above scheme (or don't).
The fundamental reason for choosing this format of name is quite simple --
it is the only one that works using existing DNS-based routing technology.
(You can quibble about what the localpart should look like, but the phone
number has to be in the domain part in order for existing DNS routing to
work. And the routing has to be done on a per-digit basis, and the digits
have to be ordered the way they are.)
Once you pick the DNS and decide to use existing routing capabilities and
the existing SMTP infrastructure, you are pretty much locked into the present
scheme.
MIME taught us a lot of things, but possibly the most important is that the
installed base is a major factor to be reckoned with. Schemes that involve new
protocols and new servers are much harder to deploy than schemes that leverage
off the installed base are. As a purely practical matter it would not have been
possible for the remote printing experiment to be where it is now without
taking advantage of the installed base's existing capabilities.
New protocols are great things. New servers with complex capabilities are also
great things. But they need to give us some capability existing services lack.
Ned