today, the W3C published the first draft for The Messaging API, which specifies a simple API for sending and receiving email, SMS, and MMS messages. the document was published by the Device APIs and Policy (DAP) Working Group, and it now has been added to the HTML5 API Overview (and yes, i know that formally this is not part of HTML5). apparently, earlier drafts were more complex in their functionality (for example supporting folder management operations), but before going public, the working group decided to split the functionality and publish a basic API first.
in terms of security and privacy, it is of course a very big deal if scripting code on a web page can receive email, SMS, and MMS messages. the security section currently states that the overall architecture for addressing privacy in DAP is still under construction. As it is finalized, there may be changes made to this API to reflect requirements or support for privacy-related functionality.
it will be very interesting to see how this general framework for security and privacy is designed.
many browser today already support messaging my supporting mailto
(very popular), tel
(sort of popular), and sms
(not so popular) URIs. while the API certainly addresses a different use case (access from scripting code), it would be very useful to describe how the URI-initiated messaging is different or equivalent to the API-initiated messaging. for example, should browsers make sure that the user experience is always consistent across these two methods of messaging? or is it acceptable if URI-based messaging uses an external user agent whereas API-based messaging uses a browser's internal capabilities?
at the very least, it would be useful to point out that URI-based messaging exists, and that page authors have the option of using URIs instead of having to write scripting code. in terms of accessibility and platform robustness, it will be quite a while until page authors could rely on the API alone; at least as a fallback solution, messaging URIs probably always are a good idea.
Comments