I like the drift of the Pulver/Evslin proposal on emergency communications, and wish there was as vigorous a debate going on over here. I just hope we in the UK aren't jerked out of complacency by some major disaster -- although widespread use of pre-paid cellular means the problem of sunken landlines isn't as acute.
Yet I can't help but wonder why the poor public has to wait for a disaster before they're given partial control over how their number maps to different destinations and services. Why can't I get a voicemail service from someone other than my connectivity provider? Why is ENUM hostage to the telcos, whose interest lies in ensuring that new services can only come from them? Why is the telco somehow regarded as a good and neutral trustee of my identity, rather than a hopelessly biased intermediary with a priority of preventing me authenticating myself in competing services using this identifier?
I wouldn't say that DNS is a perfect technical model, ICANN a particularly enlightened overlord, or Net Solutions/Verisign an very benign power. Nonetheless, the Internet's system clearly points the way to viable alternatives where users can easily provision themselves to use their number in their IM client, photo system, blog, or whatever. Domain names have drawbacks as personal identifiers, too -- but that's a different issue. Numbers are universally understood, easy to display and enter, and we've already got the infrastructure to deal with them. Time to rescue the phone numbers from the phone companies?
By the way, one modification I'd make to the Pulver/Evslin proposal is that I'd skip the stage of getting people to reclaim their lines/numbers, or to offer privacy to the emergency voicemail system. It's just too complex. Make the voicemail of drowned lines pre-announce something like:
"This line is inactive due to emergency measures. The owner has not yet recorded a greeting or forwarding number. There are two waiting messages. Press 1 to leave a message, press 2 to check messages, press 3 to record a personal greeting including any new numbers you may be contacted on. [Presses 2.] Any message you leave will be accessible to any caller, and you should therefore take care in deciding what private or confidental information to share. Beep"
The system could also use the inbound caller ID to only offer new messages to callers; there would be no "delete" in this mailbox -- all messages would be kept. I would view the lack of privacy here as a feature, not a bug -- we want status information to be spread as fast as possible, and rather like checking a friend's blog you should be able to pry around a bit for what's going on in your community.
The claiming/authentication process would only kick in when someone wants to flick their service out of emergency mode back to "normal" mode. Allowing porting of voicemail etc I'd say is just too darn hard given the inflexible reality of the system. If you're going to do 80% of the work to enable service unbundling, why not go the whole hog and transfer complete control over the numbers and directory/routing access to the users permanently?
In summary, an emergency voicemail system is probably a good idea, but should be designed from the ground-up for emergency use, and not simply be a repurposed standard voicemail product. The assumption should be that all business processes are suspended, no back office or personnel are functioning, and all you've got running is a bunch of servers on emergency power.
UPDATE: Check out Tom's comment below. I ought to also point out why I'm squicked by claiming processes. My last project at Sprint was a particularly futile digital identity re-engineering effort. This was allegedly a prelude to integrating the customer databases of the PCS, local and long distance divisions, and to avoid duplication of effort and disjointness in service delivery to common customers. There were several solutions to matching up customer records from the different divisions, one of which was a manual claiming process. Having seen the profusion of data quality issues and exception cases, I'm wary of any such process, particularly ones which need to be executed in times of panic and turmoil. Doesn't mean it can't be done, but don't underestimate how much complexity will creep out of the woodwork when you go to implement it in reality.
Posted by Martin Geddes at 3:10 PMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/701