Le 08/02/2008 18:48, Paul Gaborit a écrit :
>>>
>>> Le protocole NNTP n'est pas 8bit-free !
>>
>> Il l'est pour ce qui concerne le contenu des articles qui transitent, et
>> il me semble bien que c'est de ça que parlait Antoine. Ce groupe est
>> consacré aux problèmes 8 bits dans le format des articles (USEFOR) et
>> non dans le tuyau (NNTP).
>
> Ok pour le *contenu* de l'article. Mais, un article, c'est aussi ses
> *entêtes*. Et là, on n'est plus 8bit-free du tout.

Je ne comprends pas quelle différence tu fais entre le corps d'un
article et ses entêtes, *du point de vue de NNTP*.

> ET tout cela est indépendant du protocole de transport.

Justement : NNTP n'a pas besoin de savoir que, dans le paquet d'octets
représentant un article, ce qui est avant la première séquence CRLFCRLF
est appelé « entêtes » et le reste « contenu ». C'est USEFOR qui définit
tout cela, non ?

> Par dessus tout ça, on trouve NNTP qui assure le transport et la
> diffusion de ces articles via des tuyaux...

Je n'avais pas l'impression de dire autre chose. Serait-ce que nous
sommes d'accord malgré les apparences ? ;-)

À (at) Fri, 08 Feb 2008 19:36:04 +0100,
Olivier Miakinen <om+news***miakinen.net> écrivait (wrote):
> Le 08/02/2008 18:48, Paul Gaborit a écrit :
>>
>> Ok pour le *contenu* de l'article. Mais, un article, c'est aussi ses
>> *entêtes*. Et là, on n'est plus 8bit-free du tout.
>
> Je ne comprends pas quelle différence tu fais entre le corps d'un
> article et ses entêtes, *du point de vue de NNTP*.

NNTP se préoccupe des entêtes. Pas du contenu.

>> ET tout cela est indépendant du protocole de transport.
>
> Justement : NNTP n'a pas besoin de savoir que, dans le paquet d'octets
> représentant un article, ce qui est avant la première séquence CRLFCRLF
> est appelé « entêtes » et le reste « contenu ». C'est USEFOR qui définit
> tout cela, non ?

Mais il faut aussi qu'il puisse analyser le contenu des entêtes...

>> Par dessus tout ça, on trouve NNTP qui assure le transport et la
>> diffusion de ces articles via des tuyaux...
>
> Je n'avais pas l'impression de dire autre chose. Serait-ce que nous
> sommes d'accord malgré les apparences ? ;-)

Les tuyaux son 8bit-free. Pas NNTP.

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

Le 09/02/2008 19:20, Paul Gaborit a écrit :
>>
>> Justement : NNTP n'a pas besoin de savoir que, dans le paquet d'octets
>> représentant un article, ce qui est avant la première séquence CRLFCRLF
>> est appelé « entêtes » et le reste « contenu ». C'est USEFOR qui définit
>> tout cela, non ?
>
> Mais il faut aussi qu'il puisse analyser le contenu des entêtes...

Oui, tu as raison, et donc j'avais tort. Au temps pour moi.

Préliminaire : après avoir relu (bien obligé )) 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

À (at) Mon, 11 Feb 2008 19:05:36 +0100,
"Antoine Leca" <root***localhost.invalid> écrivait (wrote):
> Préliminaire : après avoir relu (bien obligé )) 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/>