Mon blog

Ce RFC est simplement le compte-rendu (fort tardif) d'un séminaire que l'IAB a organisé en octobre 2004 pour examiner, de haut, le statut des solutions de messagerie sur Internet et les recherches souhaitables pour l'améliorer.

Le séminaire associait à la messagerie par courrier électronique les techniques de messagerie instantanée et, même, dans une certaine mesures, certains aspects des blogs.

En effet, la messagerie, comme les autres applications de l'Internet, n'a pas été conçue en chambre : elle a évolué dans le monde réel, s'ajustant, s'étendant, se modifiant, sans schéma directeur bien précis. D'un côté, c'est ce qui a permis son succès, alors que les schémas géniaux d'organisations plus rigides que l'IETF ne connaissaient aucun succès. De l'autre, l'état actuel de la messagerie est celui d'un empilement de diverses techniques, avec peu de principes d'architecture, et qui est menacé par des phénomènes anti-sociaux comme le spam.

Le spam n'était pas un sujet de ce séminaire en tant que tel : les sujets couverts étaient de plus haut niveau, portant sur des principes d'architecture et cherchant à savoir dans quelle direction la recherche devrait se porter. Les sujets étaient :

• Autorisation : comment un destinataire peut-il simplement et de façon sûre autoriser les envois vers sa boîte ? Les systèmes de réputation sont-ils l'avenir ? Les participants au séminaire ont recommandé leur étude.
• Multiplicité des canaux de communication : si une conversation commence par courrier et se termine en Jabber, comment marquer les deux échanges pour voir qu'il s'agit de la même conversation ? Par exemple, dans le RFC 2822, les références au sein d'un fil de discussion sont uni-directionnelles, il faudrait étudier des systèmes plus riches.
• Négociation: par exemple comment décider des options de vie privée avant une conversation (enregistrement ou pas) ?
• Contrôle par l'utilisateur : un exemple typique est le filtrage du courrier. Que peut apporter l'architecture de la messagerie pour rendre ce filtrage plus efficace et plus simple ? Le langage Sieve est cité comme base possible pour des règles plus puissantes.
• Transport des messages : transport fiable ou non-fiable mais avec réémission ? Les participants souhaitent le développement de techniques permettant de faire voyager les différentes parties d'un message sur des transports différents. Par exemple, la vidéo contenue dans un message pourrait passer sur un transport moins fiable mais moins coûteux.
• Identité : notamment comment associer des clés cryptographiques à une identité ? DNSSEC semble l'outil préféré pour cette distribution.

La question des identifiants est souvent revenue dans le séminaire : toutes ces techniques nécessiteront des identifiants uniques et stables.