Dans son travail, l'IETF utilise énormément
les listes de diffusion. Afin de s'assurer que
le travail de normalisation soit ouvert et
transparent, ces listes sont publiquement accessibles. Mais il n'existe
pas de moyen très pratique de naviguer dans les archives de ces
listes, alors qu'il serait tentant de pouvoir le faire en utilisant le
protocole normalisé d'accès à des boîtes aux lettres,
IMAP. Ce court RFC est le cahier des charges du
projet « Accès en IMAP aux archives des listes IETF ».
Les principaux accès à ces listes actuellement se font via le
Web (qui fait l'objet d'un travail analogue
pour améliorer ce service, cf. ) ou en
travaillant sur des copies locales des boîtes (pas forcément
pratique). Bien des membres de l'IETF réclament un accès
IMAP (), chaque
liste étant représentée par une boîte IMAP. On pourra ainsi utiliser
son client IMAP favori (mutt,
Thunderbird, etc) pour accéder à ces
archives.
Les exigences les plus importantes de ce cahier des charges
(section 2) :
Même si l'archive est publique (le cas le plus fréquent) et accessible par tous, il faudra
que le système permette de se loguer (avec la base d'identité du datatracker), afin de pouvoir marquer les
messages (lu, non lu, etc). Il est souhaitable que d'autres
annotations soient possibles, comme décrit dans les
et . Pour l'accès « anonyme », le système devra
utiliser le mécanisme SASL du , ou bien un compte spécial (loginanonymous / mot de passe anonymous...)À part ces marques et ces annotations, il ne faut évidemment pas
que les utilisateurs puissent modifier ou supprimer les
messages.Il faut que les fonctions de recherche d'IMAP soient mises en
œuvre, avec les fonctions décrites dans le , de préférence en utilisant les extensions à IMAP des (le tri), (recherche multi-boîtes, depuis remplacé par le ) et (la recherche floue...)
Si vous êtes programmeur et que vous envisagez de se lancer dans ce
travail, attention, la section 3 précise que le système devra prévoir
une future extension aux adresses de courrier en Unicode.
Des problèmes de sécurité ? La section 4 en voit quelques uns. La
fonction de recherche peut être très gourmande en
CPU et en E/S. Un client méchant ou simplement avide pourrait mettre à
genoux le serveur en multipliant les requêtes. Le système doit donc
être capable de limiter la consommation de ressources par
utilisateur. Un problème analogue se pose pour les annotations, dont
il faut limiter la consommation d'espace disque.
Je n'ai pas trouvé trace d'un appel d'offres formel de l'IETF
correspondant à ce RFC. Plus tard, peut-être ?