NNTP et 8bit clean [Fut: In memoriam]

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).


Il semblerait bien que je me sois trompé, et qu'il soit possible de discuter
dans ce groupe (en restant dans la charte) de problèmes NNTP !



En news:wt9tzkjicw0.fsf@marceau.enstimac.fr, Paul Gaborit va escriure:
> À (at) Fri, 8 Feb 2008 17:58:02 +0100, Antoine Leca écrivait (wrote):
>> De NNTP ? je ne suis pas sûr. Ou alors de manière accessoire. Cela
>> fait bien longtemps qu'on a remisé les BNews qui circulaient encore,
>> aujourd'hui tout le monde considère que NNTP est 8bit-free.
>
> 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 répond néanmoins car je ne comprends pas bien le sens de ta remarque.


> La RFC 3977 (la dernière décrivant NNTP) indique qu'on peut supposer
> que le canal de communication utilisé par NNTP est 8bit-free. Mais
> c'est tout.

C'est déjà beaucoup, non ? Surtout si on se rappelle que "8bit", au moins en
suivant la définition donnée par RFC 2045 (MIME) qui me paraît
prépondérante,
signifie quelque chose de plus restreint que "binaire" : codes 0, 10 ou 13
interdits sauf quelques cas particuliers, et lignes de taille limitée.


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." Mais je
ne vois pas comment l'on pourrait implémenter le protocole en faisant
abstraction de cette contrainte (quite à la violer parfois, par exemple en
retransmettant sans changement une ligne de corps d'article de plus de 1000
caractères, faute pour le dit serveur de savoir où il est possible de mettre
une césure ; exemple typique où ce pourrait être bénéfique, les URLs... et
par ailleurs une des différences entre RFC2045 et les projets USEFOR !)


> 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.

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.


> Mais ce changement de codage s'accompagne de recommandations fortes
> concernant les en-têtes :
>
>    o The names of headers (e.g., "From" or "Subject") MUST be in
>      US-ASCII.
>
> Là, c'est impératif : le nom des chapns d'en-tête doit être de l'ASCII
> pur.

D'accord, mais cela ne change rien. Le seul effet, c'est qu'une
implémentation peut (ou devrait) rejeter comme incompréhensible un article
qui contiendrait un caractère de code >127 avant le ':', dans les en-têtes.
C'est juste une règle d'analyse, analogue à celle qui dit que la séquence
CRLFCRLF annonce la fin des en-têtes, et que par exemple U+2028 serait
ignoré à cet effet.

Qui plus est, la pratique est probablement plus restreinte ; par exemple, je
ne pense pas qu'un nom d'entête encodé avec iso-2022 (donc utilisant
seulement les caractères du jeu US-ASCII, dont les caractères ESC, SI et SO,
permettant effectivement une extension) soit accepté partout...
(et oui, j'ai lu 2. et 3.6 et je sais que la RFC précise que seuls les
caractères entre 33 et 126 sont attendus dans les noms d'en-tête... mais le
MUST est à un autre endroit.)

Dans le même ordre d'idées, le message-id aussi est contraint, et ne peut
pas contenir de caractère espace ; peut-on en déduire un quelconque effet
sur les possibilités de codage de l'espace ?


> Et pour leur valeur :
>
>    o Header values SHOULD use US-ASCII or an encoding based on it,
>      such as RFC 2047 [RFC2047], until such time as another approach
>      has been standardised. At present, 8-bit encodings (including
>      UTF-8) SHOULD NOT be used because they are likely to cause
>      interoperability problems.
>
> C'est moins impératif mais si on veut garantir l'interopérabilité,
> pour les valeurs des champs, on doit utiliser l'ASCII complété par le
> RFC 2027 (qui autorise l'encodage en ASCII des caractères autres) mais
> de 8-bit.

C'est à ma connaissance le seul endroit avec les noms de groupes où il est
précisé une limitation en deça des possibilités techniques du protocole. Et
c'est le résultat d'une *intense* discusion et d'un consensus qui fut *long*
à se former. Qui plus est, bien plus que l'interopérabilité, la cause réelle
est qu'il existe déjà dans la réalité différentes pratiques, et qu'elles
sont incompatibles à large échelle.
Par exemple, durant de longues années la pratique (tolérée mais pas
encouragée) sur fr.* a été de coder les en-têtes, et singulièrement le sujet
de l'article, avec iso-8859-1 (puis -15). Aujourd'hui, on voit bien que l'on
s'achemine vers autre chose, savoir UTF-8 ; et il me semble bien que la
solution QP à-la-RFC2047 est souvent ressentie comme un pis-aller, dont il
serait profitable qu'il disparaisse le plus tôt possible (et je sais très
bien que ce n'est pas pour demain ni même après-demain).


> 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).
Dans ce cadre, il me semble que l'actuel RFC3977 est d'abord un très grand
pas en avant par rapport à l'existant d'alors, mais aussi fort proche du
but, car il permet d'utiliser UTF-8 à pratiquement tous les niveaux du
protocole ; de plus il marque très clairement ce chemin de convergence. Pour
finaliser cette migration, au niveau du protocole il manque fort peu de
chose, essentiellement ce qui est mis en exergue dans la partie 10 de la
RFC.

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é»); récemment Jean-Marc nous disait que les choses
avancent bien de ce côté-là aussi (cf.
news:fkdovf$3e2$1@reader1.imaginet.fr, =
http://groups.google.fr/groups?selm=fkdovf$3e2$1@reader1.imaginet.fr), et
c'est tant mieux.


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).


Antoine