Re: NNTP et 8bit clean [Fut: In memoriam]

À (at) Mon, 11 Feb 2008 19:05:36 +0100,
"Antoine Leca" <root@localhost.invalid> écrivait (wrote):
> Préliminaire : après avoir relu (bien obligé :o)) les textes sacrés, le
> terme consacré est "8bit clean", pas "8bit-free". Désolé pour la confusion
> (qui ne semble cependant pas avoir trop gêné Paul et Olivier).

C'est vrai que "8bit clean" a plus de sens que le "8bit-free"
initial... Mais on l'avait bien compris dans le sens "8bit clean".

>> Le protocole NNTP n'est pas 8bit-free !
>
> Merci pour les précisions très précises, qui à mon avis abondent dans mon
> sens de considérer que ce forum n'est probablement pas le lieu optimum pour
> causer de NNTP.

Je ne suis pas le gardien du temple mais il me semble bien que dans un
forum s'appelant fr.usenet.8bits on doit pouvoir parler de NNTP...
Sinon, où en parler ?

> Je répond néanmoins car je ne comprends pas bien le sens de ta remarque.
[...]
> Effectivement, RFC 3977 décrit quelques contraintes supplémentaires (la
> plupart assez évidentes si on prend le temps d'y réfléchir) pour les
> en-têtes des articles, au-delà de la supposion (posée comme un axiome) que
> "NNTP is only expected to operate on 8-bit clean transport paths."

C'était là le sens de mes remarques.

>> Ensuite, l'un des apports de cette dernière RFC est le passage de
>> l'US-ASCII à l'UTF-8 (qui n'est pas 8bit-free et de loin...).
>
> Même sans vouloir jouer trop sur les mots, je ne comprend pas ta position.
> Quand bien même il n'utilise pas toutes les possibilités d'encodage
> possibles, UTF-8 *nécessite*, dans la pratique, un transport 8bit clean.

Un transport 8bit clean, certes. Mais cela n'autorise pas le transfert
de n'importe quelle suite d'octets (même si, de fait, dans le corps
des messages, NNTP ne s'en préoccupe pas vraiment car il n'en a pas
besoin). C'est d'ailleurs l'un des challenge de l'adoption de l'UTF-8
un peu partout dans les systèmes. Avant, un codage acceptait n'importe
quelle suite d'octets, quitte à afficher n'importe quoi. En UTF-8, ce
n'est plus le cas. Or la plupart des programmes n'ont pas prévu de
gérer les erreurs d'encodage (puisqu'elle ne pouvaient pas se
produire)...

> Et si par hasard on essayait de faire passer le protocole sur un transport
> utf8-clean mais pas 8bit-clean (un exemple évident serait de recoder
> brutalement les articles en UTF-16 ou UTF-32: seul un contenu UTF-8 bien
> formé pouvant alors passer), alors il me semble que les autres restrictions
> de la RFC 3977 ne pourraient être satisfaites. Et pour prendre un exemple
> lié à fr.*, il me paraît clair qu'un serveur qui recoderait «
> intelligement » (\xE9 -> \xC3\xA9) TOUS les articles iso-8859-{1,15} en
> utf-8 NE serait PAS bienvenu, au moins dans l'état actuel des choses.

C'est bien pour ça qu'actuellement, dans les parties gérées par le
protocole, ces codages sont interdits (même si certaines hiérarchies
locales ont eu des usages différents).

[...]
>> On est donc loin du 8bit-free annoncé...
>
> Encore une fois j'ai l'impression que pris au pied de la lettre, le NNTP du
> XXIe siècle requiert bien un transport 8bit clean, comme annoncé.
>
> Mais si j'essaye d'interpréter un peu plus le sens de ta remarque, j'en
> arrive à une conclusion sensiblement différente : Est-ce si loin ?
>
> À mon sens, RFC 3977 est une étape supplémentaire vers ce qui sera la mort
> de ce groupe :^), c'est-à-dire la possibilité de transmettre un texte sans
> avoir à se préoccuper de babillage annonçant l'encodage (inutile si tout le
> monde utilise UTF-8).

L'espoir fait vivre... Mais mon expérience personnelle m'amène à
penser qu'on n'a pas fini de s'amuser avec les problèmes de codages.

> Aujourd'hui, les écueils ne sont plus au niveau du protocole NNTP, mais bien
> au niveau du format des articles (USEFOR, et aussi le pas de deux avec le
> mail «internationalisé»);

Mais NNTP et le format des articles ne sont malheureusement pas
indépendants. Et la gestion de la compatibilité ascendante n'a pas
vraiment été prévue à l'origine dans NNTP. On ne peut pas faire une
migration big-bang. On s'achemine plutôt, à mon sens, vers une
migration lente comme pour le mail (combien de règle de configurations
restent présentes dans 'sendmail' uniquemnet pour gérer l'histoire ?).

> En fait (et là je crois que je rejoins Olivier), les seuls endroits où le
> fait d'être 8bit clean importe réellement, c'est le corps (décodé) des
> articles, plus les quelques élements visibles pour l'utilisateur final, au
> premier rang desquels le sujet, au second rang le nom de l'auteur, et aussi
> les noms de groupes.
> Les en-têtes internes qui ne servent qu'à la cuisine,
> ou leur format technique (noms des en-têtes, pliage), sont irrelevants. Pour
> ce qui concerne NNTP, tant le corps comme les deux premiers en-têtes sont
> essentiellement sans souci aujourd'hui, seul reste les noms de groupes, et à
> ce niveau le protocole décrit par RFC3977 est _prêt_, il est seulement
> verrouillé _temporairement_ en attente de RFC1036bis (et des notions
> développées dans la partie 10.3).

C'est un pas de plus... mais on est pas arrivé. ;-)

-- 
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>