E. Wilde (UC Berkeley)A. Vaha-Sipila (Nokia)January20102010-03-09
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
plansms 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: ()
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. .)
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
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 (, 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.