Ça fait une paye que je ne me sers plus de gnus aussi régulièrement
que par le passé. J'avais donc décidé de dégager ma configuration en
vu de la remettre au propre.
Aujourd'hui je ne me sers plus de Gnus que comme lecteur Usenet et
bien évidemment, sur la hiérarchie fr.*, c'est une
catastrophe. Pratiquement à chaque coup, je me fais jeté avec une
erreur 441 pour une histoire de 8bits dans les entêtes. À chaque fois,
il s'agit de caractères accentués dans le champ ´Sujet´.
Pourriez-vous me rafraîchir la mémoire sur la manipulation à effectuer
pour que tout ceci rentre dans l'ordre ?
La limite du problème ici est celui de _Usenet_ (et donc de nntp) : ce protocole ne sait *pas* gérer autre chose que de l'ASCII dans les champs subject:
Du moins, la dernière fois que j'avais regardé... s'il existe une RFC récente qui a mis à jour ce problème, je serai tout à fait d'accord pour mettre des accents dans ce champ-là désormais.
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Moi, je ne sais pas quelle RFC c'est, mais quand on a des accents dans les en-tête, ils sont « remplacés » par du quoted-printable, et dans la plupart des cas, ça se passe bien (mais j'ai déjà vu un Outlook Express remplacer un caractère accentué par un idéogramme chinois dans un followup, je ne nie pas que ça casse de temps en temps).
-- Matthieu
Erwan David <erwan@rail.eu.org> writes:
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
La limite du problème ici est celui de _Usenet_ (et donc de nntp) : ce
protocole ne sait *pas* gérer autre chose que de l'ASCII dans les
champs subject:
Du moins, la dernière fois que j'avais regardé... s'il existe une RFC
récente qui a mis à jour ce problème, je serai tout à fait d'accord
pour mettre des accents dans ce champ-là désormais.
Vous serez certainement comblé par la RFC 2047 qui traite
explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Moi, je ne sais pas quelle RFC c'est, mais quand on a des accents dans
les en-tête, ils sont « remplacés » par du quoted-printable, et dans
la plupart des cas, ça se passe bien (mais j'ai déjà vu un Outlook
Express remplacer un caractère accentué par un idéogramme chinois dans
un followup, je ne nie pas que ça casse de temps en temps).
La limite du problème ici est celui de _Usenet_ (et donc de nntp) : ce protocole ne sait *pas* gérer autre chose que de l'ASCII dans les champs subject:
Du moins, la dernière fois que j'avais regardé... s'il existe une RFC récente qui a mis à jour ce problème, je serai tout à fait d'accord pour mettre des accents dans ce champ-là désormais.
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Moi, je ne sais pas quelle RFC c'est, mais quand on a des accents dans les en-tête, ils sont « remplacés » par du quoted-printable, et dans la plupart des cas, ça se passe bien (mais j'ai déjà vu un Outlook Express remplacer un caractère accentué par un idéogramme chinois dans un followup, je ne nie pas que ça casse de temps en temps).
La limite du problème ici est celui de _Usenet_ (et donc de nntp) : ce protocole ne sait *pas* gérer autre chose que de l'ASCII dans les champs subject:
Du moins, la dernière fois que j'avais regardé... s'il existe une RFC récente qui a mis à jour ce problème, je serai tout à fait d'accord pour mettre des accents dans ce champ-là désormais.
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
La limite du problème ici est celui de _Usenet_ (et donc de nntp) : ce
protocole ne sait *pas* gérer autre chose que de l'ASCII dans les
champs subject:
Du moins, la dernière fois que j'avais regardé... s'il existe une RFC
récente qui a mis à jour ce problème, je serai tout à fait d'accord
pour mettre des accents dans ce champ-là désormais.
Vous serez certainement comblé par la RFC 2047 qui traite
explicitement de cette question.
La limite du problème ici est celui de _Usenet_ (et donc de nntp) : ce protocole ne sait *pas* gérer autre chose que de l'ASCII dans les champs subject:
Du moins, la dernière fois que j'avais regardé... s'il existe une RFC récente qui a mis à jour ce problème, je serai tout à fait d'accord pour mettre des accents dans ce champ-là désormais.
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
À (at) Wed, 27 Sep 2006 15:34:19 +0200, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Non pas remplacée mais juste complétée. Petit extrait de la RFC 2231 :
[...] This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [...]
Et, à ma connaissance, bien peu de logiciels utilisent cette possibilité d'indiquer la langue utilisée dans un entête...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 27 Sep 2006 15:34:19 +0200,
Erwan David <erwan@rail.eu.org> écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite
explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Non pas remplacée mais juste complétée. Petit extrait de la RFC 2231 :
[...]
This memo also defines an extension to the encoded words defined in
RFC 2047 to allow the specification of the language to be used for
display as well as the character set.
[...]
Et, à ma connaissance, bien peu de logiciels utilisent cette
possibilité d'indiquer la langue utilisée dans un entête...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Wed, 27 Sep 2006 15:34:19 +0200, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Non pas remplacée mais juste complétée. Petit extrait de la RFC 2231 :
[...] This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [...]
Et, à ma connaissance, bien peu de logiciels utilisent cette possibilité d'indiquer la langue utilisée dans un entête...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Matthieu Moy
Patrice Karatchentzeff writes:
nntp = Network news transfer protocol
Oui, m'enfin le NNTP est aux news ce que le SMTP est au mail, et je ne crois pas que SMTP dise quoi que ce soit sur l'encodage des en-têtes. Et la RFC que tu cites ne dit rien sur l'encodage du corps (à part que ça doit être 7 bits).
Oui, m'enfin le NNTP est aux news ce que le SMTP est au mail, et je ne
crois pas que SMTP dise quoi que ce soit sur l'encodage des en-têtes.
Et la RFC que tu cites ne dit rien sur l'encodage du corps (à part que
ça doit être 7 bits).
Oui, m'enfin le NNTP est aux news ce que le SMTP est au mail, et je ne crois pas que SMTP dise quoi que ce soit sur l'encodage des en-têtes. Et la RFC que tu cites ne dit rien sur l'encodage du corps (à part que ça doit être 7 bits).
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Dîtes, les gars, vous savez lire :
nntp = Network news transfer protocol
AKA RFC 977
Et alors ? L'usage de MIME est adopté depuis longtemps pour les News (ou d'un sous-ensemble pour la plupart des forums). Cela ne nécessite aucune adaptation du protocole de diffusion sous-jacent (NNTP - RFC 977). C'est d'ailleurs l'intérêt majeur de MIME.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite
explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Dîtes, les gars, vous savez lire :
nntp = Network news transfer protocol
AKA RFC 977
Et alors ? L'usage de MIME est adopté depuis longtemps pour les News
(ou d'un sous-ensemble pour la plupart des forums). Cela ne nécessite
aucune adaptation du protocole de diffusion sous-jacent (NNTP - RFC
977). C'est d'ailleurs l'intérêt majeur de MIME.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Dîtes, les gars, vous savez lire :
nntp = Network news transfer protocol
AKA RFC 977
Et alors ? L'usage de MIME est adopté depuis longtemps pour les News (ou d'un sous-ensemble pour la plupart des forums). Cela ne nécessite aucune adaptation du protocole de diffusion sous-jacent (NNTP - RFC 977). C'est d'ailleurs l'intérêt majeur de MIME.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Dîtes, les gars, vous savez lire :
nntp = Network news transfer protocol
AKA RFC 977
Et alors ? L'usage de MIME est adopté depuis longtemps pour les News (ou d'un sous-ensemble pour la plupart des forums). Cela ne nécessite aucune adaptation du protocole de diffusion sous-jacent (NNTP - RFC 977). C'est d'ailleurs l'intérêt majeur de MIME.
Sauf que dans la RFC 977, ils parlent de 7 bits et que, puisque ce n'est pas clair, beaucoup l'appliquent strictement *sur* les en-têtes... et comme par définition, ton message est relayé par une tonne de serveurs différents, il en suffit d'un qui applique stricto sensu la définition pour casser toute la machine...
Je suis d'accord que tout ceci est discutable mais tant qu'il n'y aura pas une révision de la RFC 977 statuant clairement le traitement des en-têtes, on n'avancera pas...
Mais, bon, comme qui dirait, les news, cela n'intéresse que les dinos¹ donc pas sûr d'un changement avant longtemps...
Encore une fois, je déplore la situation actuelle. Pour moi, le titre fait partie intégralement du message et cela m'écorche la g... d'écorcher mes titres à cause d'une RFC mal foutue.
PK
¹ : il semblerait que les p'tits jeunes préfèrent les forums web... tant pis pour les archives.
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite
explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Dîtes, les gars, vous savez lire :
nntp = Network news transfer protocol
AKA RFC 977
Et alors ? L'usage de MIME est adopté depuis longtemps pour les News
(ou d'un sous-ensemble pour la plupart des forums). Cela ne nécessite
aucune adaptation du protocole de diffusion sous-jacent (NNTP - RFC
977). C'est d'ailleurs l'intérêt majeur de MIME.
Sauf que dans la RFC 977, ils parlent de 7 bits et que, puisque ce
n'est pas clair, beaucoup l'appliquent strictement *sur* les
en-têtes... et comme par définition, ton message est relayé par une
tonne de serveurs différents, il en suffit d'un qui applique stricto
sensu la définition pour casser toute la machine...
Je suis d'accord que tout ceci est discutable mais tant qu'il n'y
aura pas une révision de la RFC 977 statuant clairement le traitement
des en-têtes, on n'avancera pas...
Mais, bon, comme qui dirait, les news, cela n'intéresse que les dinos¹
donc pas sûr d'un changement avant longtemps...
Encore une fois, je déplore la situation actuelle. Pour moi, le titre
fait partie intégralement du message et cela m'écorche la g... d'écorcher
mes titres à cause d'une RFC mal foutue.
PK
¹ : il semblerait que les p'tits jeunes préfèrent les forums web...
tant pis pour les archives.
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Dîtes, les gars, vous savez lire :
nntp = Network news transfer protocol
AKA RFC 977
Et alors ? L'usage de MIME est adopté depuis longtemps pour les News (ou d'un sous-ensemble pour la plupart des forums). Cela ne nécessite aucune adaptation du protocole de diffusion sous-jacent (NNTP - RFC 977). C'est d'ailleurs l'intérêt majeur de MIME.
Sauf que dans la RFC 977, ils parlent de 7 bits et que, puisque ce n'est pas clair, beaucoup l'appliquent strictement *sur* les en-têtes... et comme par définition, ton message est relayé par une tonne de serveurs différents, il en suffit d'un qui applique stricto sensu la définition pour casser toute la machine...
Je suis d'accord que tout ceci est discutable mais tant qu'il n'y aura pas une révision de la RFC 977 statuant clairement le traitement des en-têtes, on n'avancera pas...
Mais, bon, comme qui dirait, les news, cela n'intéresse que les dinos¹ donc pas sûr d'un changement avant longtemps...
Encore une fois, je déplore la situation actuelle. Pour moi, le titre fait partie intégralement du message et cela m'écorche la g... d'écorcher mes titres à cause d'une RFC mal foutue.
PK
¹ : il semblerait que les p'tits jeunes préfèrent les forums web... tant pis pour les archives.
À (at) Wed, 27 Sep 2006 15:34:19 +0200, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Non pas remplacée mais juste complétée. Petit extrait de la RFC 2231 :
[...] This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [...]
Et, à ma connaissance, bien peu de logiciels utilisent cette possibilité d'indiquer la langue utilisée dans un entête...
Elle ne fait pas que ça. SOn utilité principale est de pouvoir couper les mots encodés en plusieurs en-têtes. C'ets par exemple ce qu'il faut lorsque l'encodage d'un nom de pièce jointe dépasse les 64 octets.
-- Erwan
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
À (at) Wed, 27 Sep 2006 15:34:19 +0200,
Erwan David <erwan@rail.eu.org> écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite
explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Non pas remplacée mais juste complétée. Petit extrait de la RFC 2231 :
[...]
This memo also defines an extension to the encoded words defined in
RFC 2047 to allow the specification of the language to be used for
display as well as the character set.
[...]
Et, à ma connaissance, bien peu de logiciels utilisent cette
possibilité d'indiquer la langue utilisée dans un entête...
Elle ne fait pas que ça. SOn utilité principale est de pouvoir couper
les mots encodés en plusieurs en-têtes. C'ets par exemple ce qu'il
faut lorsque l'encodage d'un nom de pièce jointe dépasse les 64
octets.
À (at) Wed, 27 Sep 2006 15:34:19 +0200, Erwan David écrivait (wrote):
Paul Gaborit écrivait :
Vous serez certainement comblé par la RFC 2047 qui traite explicitement de cette question.
Remplacé depuis près de 10 ans par le RFC 2231.
Non pas remplacée mais juste complétée. Petit extrait de la RFC 2231 :
[...] This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [...]
Et, à ma connaissance, bien peu de logiciels utilisent cette possibilité d'indiquer la langue utilisée dans un entête...
Elle ne fait pas que ça. SOn utilité principale est de pouvoir couper les mots encodés en plusieurs en-têtes. C'ets par exemple ce qu'il faut lorsque l'encodage d'un nom de pièce jointe dépasse les 64 octets.
-- Erwan
Matthieu Moy
Patrice Karatchentzeff writes:
Sauf que dans la RFC 977, ils parlent de 7 bits
Si tu suis la RFC 977 à la lettre, pourquoi met-tu des accents dans le corps de ton message ?
,---- | 2.2. Character Codes | | Commands and replies are composed of characters from the ASCII | character set. When the transport service provides an 8-bit byte | (octet) transmission channel, each 7-bit character is transmitted | right justified in an octet with the high order bit cleared to | zero. `----
et que, puisque ce n'est pas clair, beaucoup l'appliquent strictement *sur* les en-têtes...
Si tu suis la RFC 977 à la lettre, pourquoi met-tu des accents dans le
corps de ton message ?
,----
| 2.2. Character Codes
|
| Commands and replies are composed of characters from the ASCII
| character set. When the transport service provides an 8-bit byte
| (octet) transmission channel, each 7-bit character is transmitted
| right justified in an octet with the high order bit cleared to
| zero.
`----
et que, puisque ce n'est pas clair, beaucoup l'appliquent
strictement *sur* les en-têtes...
Si tu suis la RFC 977 à la lettre, pourquoi met-tu des accents dans le corps de ton message ?
,---- | 2.2. Character Codes | | Commands and replies are composed of characters from the ASCII | character set. When the transport service provides an 8-bit byte | (octet) transmission channel, each 7-bit character is transmitted | right justified in an octet with the high order bit cleared to | zero. `----
et que, puisque ce n'est pas clair, beaucoup l'appliquent strictement *sur* les en-têtes...
Sauf que dans la RFC 977, ils parlent de 7 bits et que, puisque ce n'est pas clair, beaucoup l'appliquent strictement *sur* les en-têtes... et comme par définition, ton message est relayé par une tonne de serveurs différents, il en suffit d'un qui applique stricto sensu la définition pour casser toute la machine...
Mais, c'est justement tout l'intérêt de MIME. Coder tout ce qu'on veut en n'utilisant que de l'ACSII pur et dur ! Il n'y a donc *aucun* risque. Ou, plutôt, le risque est reporté sur le client final et non sur les serveurs intermédiaires. C'est donc l'application directe d'un très vieux principe d'internet : l'intelligence n'est pas dans le réseau mais aux extrémités.
C'est d'ailleurs là la cause de l'erreur de gnus (pour revenir au sujet): croire qu'on a le droit de poster directement en iso-8859-1 (en-têtes compris) sur les forums fr.* et no.*.
Je suis d'accord que tout ceci est discutable mais tant qu'il n'y aura pas une révision de la RFC 977 statuant clairement le traitement des en-têtes, on n'avancera pas...
Cette modification est inutile ! Tout marche déjà très bien avec MIME...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Sauf que dans la RFC 977, ils parlent de 7 bits et que, puisque ce
n'est pas clair, beaucoup l'appliquent strictement *sur* les
en-têtes... et comme par définition, ton message est relayé par une
tonne de serveurs différents, il en suffit d'un qui applique stricto
sensu la définition pour casser toute la machine...
Mais, c'est justement tout l'intérêt de MIME. Coder tout ce qu'on veut
en n'utilisant que de l'ACSII pur et dur ! Il n'y a donc *aucun*
risque. Ou, plutôt, le risque est reporté sur le client final et non
sur les serveurs intermédiaires. C'est donc l'application directe d'un
très vieux principe d'internet : l'intelligence n'est pas dans le
réseau mais aux extrémités.
C'est d'ailleurs là la cause de l'erreur de gnus (pour revenir au
sujet): croire qu'on a le droit de poster directement en iso-8859-1
(en-têtes compris) sur les forums fr.* et no.*.
Je suis d'accord que tout ceci est discutable mais tant qu'il n'y
aura pas une révision de la RFC 977 statuant clairement le traitement
des en-têtes, on n'avancera pas...
Cette modification est inutile ! Tout marche déjà très bien avec
MIME...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Sauf que dans la RFC 977, ils parlent de 7 bits et que, puisque ce n'est pas clair, beaucoup l'appliquent strictement *sur* les en-têtes... et comme par définition, ton message est relayé par une tonne de serveurs différents, il en suffit d'un qui applique stricto sensu la définition pour casser toute la machine...
Mais, c'est justement tout l'intérêt de MIME. Coder tout ce qu'on veut en n'utilisant que de l'ACSII pur et dur ! Il n'y a donc *aucun* risque. Ou, plutôt, le risque est reporté sur le client final et non sur les serveurs intermédiaires. C'est donc l'application directe d'un très vieux principe d'internet : l'intelligence n'est pas dans le réseau mais aux extrémités.
C'est d'ailleurs là la cause de l'erreur de gnus (pour revenir au sujet): croire qu'on a le droit de poster directement en iso-8859-1 (en-têtes compris) sur les forums fr.* et no.*.
Je suis d'accord que tout ceci est discutable mais tant qu'il n'y aura pas une révision de la RFC 977 statuant clairement le traitement des en-têtes, on n'avancera pas...
Cette modification est inutile ! Tout marche déjà très bien avec MIME...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Rakotomandimby (R12y)
On Wed, 27 Sep 2006 16:04:19 +0200, Paul Gaborit wrote:
Et, à ma connaissance, bien peu de logiciels utilisent cette possibilité d'indiquer la langue utilisée dans un entête...
Le fameux X-accept-langage positionné en fr? ;-)
On Wed, 27 Sep 2006 16:04:19 +0200, Paul Gaborit wrote:
Et, à ma connaissance, bien peu de logiciels utilisent cette
possibilité d'indiquer la langue utilisée dans un entête...
