This tweet pointed me toward an article on Network World, which talks about E.164 support in Cisco Unified Communication Manager…  And it got me thinking about something that has bugged me for years.  I wouldn’t go so far as to describe it as a pet peeve but it comes pretty close.  The simple fact is that most people don’t know how to communicate phone numbers.

To some extent it’s the same issue as communicating a URI, which people assume is a website (http://) if it looks like a hostname or an email address (mailto:) if it has an “@” symbol embedded.  There are so many cases in which this is ambiguous, but the popular language is largely unaware of these possibilities.  E.g. we could be discussing a management object or an IM address.  With phone numbers it is no different, except that the popular conventions are localized.  In North America it’s commonly accepted to ignore country code and just provide a 10-digit number: (NPA) NXX-NNNN.  Within a local Area Code it is common to drop the NPA entirely: NXX-NNNN.  There are localized conventions like this all over the world, because unlike web and email addresses there is a historical pattern of emphasis on local usage (i.e. calling local numbers more frequently than long-distance).  But clearly this convention ruins communication across boundaries; if I’m given a 7-digit number from outside my local area, I have no idea how to use it.

As our economy has grown to global scope, our communication of telephone numbers has not kept up.  This is where E.164 comes into play.  It is a standard agreed by the international community, which defines a common way of describing a complete telephone number.  Starting with “+” to indicate E.164 completeness, the number follows a simple allocation hierarchy from Country Code onwards.  The standard also describes acceptable separators, which are used to make the structure and groupings more clear to a human.  This could result in a number such as +1-888-225-5322 * or +44 20 7981 3040 *.  For even less ambiguity, one could represent a number in the URI form by prefixing “tel:”, as in tel:+1-888-225-5322.

Even if you don’t use this form in common day-to-day communication, it is important that everybody understands these conventions well enough to identify ambiguity and avoid it.  Not only will our global communication improve, but I’ll be happier with my almost-pet peeve.