Mon blog

Il existe des plans d'URI pour tout. Alors, pourquoi pas pour les SMS ? C'est ce que prévoit notre RFC qui ajoute la possibilité d'avoir des liens hypertexte dont la sélection déclenche l'envoi d'un SMS...

D'abord, avec la section 1 du RFC, révisons : le réseau GSM est un réseau de téléphonie mobile très répandu dans certaines parties du monde (en Europe, par exemple), et fonctionnant sur des fréquences comme 900 Mhz, 1800 Mhz, etc. SMS est un service des réseaux GSM qui permet d'envoyer de courts messages texte. Son succès social a été tel que des réseaux non-GSM comme le RNIS l'ont également adopté, et un service de microblogging comme Identi.ca a emprunté bien des points au SMS, comme la longueur maximale d'un message.

Le SMS a en effet une taille maximale, fixée selon des critères un peu complexes (section 1.2.1 du RFC). La norme dit « 160 caractères » mais, limités à sept bits, ce ne sont pas des caractères Unicode. La vraie limite est en fait de 140 octets. Il existe diverses méthodes (typiquement non-standards) pour stocker dans ces 140 octets de l'UTF-16 ou bien des choses rigolotes comme les émoticons.

La délivrance des SMS se fait via un, et parfois plusieurs, serveur, le SMSC (Short Message Service Center).

La section 1.2.4 explique ensuite l'intérêt de spécifier un plan sms pour le Web. Ce dernier est aujourd'hui l'interface principale d'accès à l'information, notamment grâce à l'invention des URI. Parmi les URI, mailto: (RFC 6068) est devenu très populaire, en permettant d'envoyer un message « depuis » une page Web. L'idée est donc de faire pour les SMS ce que mailto: a permis pour le courrier. (Il existe aussi un tel: pour le téléphone, cf. RFC 3966.)

Le RFC note toutefois que, si la plupart des navigateurs permettent d'associer un programme externe à un contenu de type MIME inconnu (sans toucher au code source du navigateur), cette possibilité n'existe en général pas pour les plans d'URI inconnus. Ceux-ci nécessitent en général de modifier le navigateur, ou bien d'utiliser ses fonctions d'accueil de greffons (c'est le cas de Firefox).

Bref, venons en maintenant à la vraie normalisation ; la section 2 définit ce nouveau plan sms. Il s'appuie sur le RFC 3966 pour la syntaxe des numéros de téléphone (en incluant l'erratum 203). La syntaxe formelle des nouveaux URI figure en section 2.2. Un exemple simple est sms:+15105550101. Un exemple plus complexe est sms:+15105550101?body=hello%20there (d'autres exemples figurent en section 2.5). Ce second exemple illustre l'utilisation de champs (ici, un seul champ, body, qui indique le contenu du message) permettant d'étendre l'URI. Pour que l'ajout de champs ultérieurs soit possible, le RFC impose que les champs inconnus soient ignorés.

Pendant qu'on parle du champ body, la section 2.2 précise également son encodage : de l'UTF-8 avec le surencodage pour-cent, comme l'illustre le %20 ci-dessus.

Un RFC décrivant un plan d'URI n'est pas complet sans le formulaire d'enregistrement formel (RFC 4395, section 5.4), qui figure en section 3. sms: est donc désormais dans le registre IANA.

Et naturellement, le RFC se conclus par la section sur la sécurité (section 4), qui rappelle notamment que, l'envoi d'un SMS étant souvent payant pour l'abonné, le navigateur ne doit pas déclencher cet envoi sur un simple clic, il doit demander confirmation ! D'autre part, cette section attire l'attention des utilisateurs sur le fait que le SMS ne présente aucune confidentialité et aucun mécanisme d'authentification, contrairement au courrier électronique.