D’autre part, dire que la limitation de 65 caractères est pertinente est une connerie, on code pas une information d’affichage dans le format
D’accord en théorie, mais après il faut se mettre à la place des rédacteurs du RFC 5322 (et des RFC qui l’ont précédé) : ils étaient plus ou moins obligé de tenir compte du fait qu’il existe des implémentations qui font n’importe quoi lorsqu’un message comportaient des lignes trop longues... D’où l’introduction de la recommandation, pour un émetteur, de ne pas dépasser 78 caractères par ligne :
Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
[...]
The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification.
(La limite à 65 caractères découle de cette limite à 78 caractères, pour se ménager suffisamment de niveaux de citations — mais cette limite-là n’a jamais été imposée par un quelconque standard, seulement par la Netiquette qui n’est que « pour information ».)
Ajoutons à celà qu’après cette recommandation de ne pas dépasser 78 caractères par ligne, il y a ensuite une obligation de ne pas dépasser 998 caractères (cette limite-là vient tout droit du protocole SMTP), et le « bidouillage » du format=flowed devient logique : il permet de séparer clairement les retours à la ligne qui ne sont là que pour respecter le protocole, de ceux qui sont là pour exprimer la volonté de l’auteur du message d’aller à la ligne.
Ce « bidouillage » a aussi l’avantage de permettre un affichage à peu près correct du message même avec un client qui ne prend pas en charge le format flowed, ce qui est déterminant et trop souvent oublié par ceux qui proposent une « solution » peut-être bien meilleure et plus propre techniquement mais condamnée à l’échec parce qu’elle nécessite un support de la part de tous les acteurs...
Le problème c’est que Thunderbird est capable d’éditer en HTML et envoyer en texte, mais faut préciser pour chaque courriel d’envoyer en format texte si on réponds à un courriel en HTML.
Euh, non. Edit → Account settings, rubrique Composition & Addressing, décocher Compose messages in HTML format. Peu importe que le message auquel tu réponds soit en HTML, ta réponse sera en texte brut.
[^] # Re: C'est quoi le problème ?
Posté par gouttegd . En réponse au sondage Les courriels en HTML.... Évalué à 3.
D’accord en théorie, mais après il faut se mettre à la place des rédacteurs du RFC 5322 (et des RFC qui l’ont précédé) : ils étaient plus ou moins obligé de tenir compte du fait qu’il existe des implémentations qui font n’importe quoi lorsqu’un message comportaient des lignes trop longues... D’où l’introduction de la recommandation, pour un émetteur, de ne pas dépasser 78 caractères par ligne :
(La limite à 65 caractères découle de cette limite à 78 caractères, pour se ménager suffisamment de niveaux de citations — mais cette limite-là n’a jamais été imposée par un quelconque standard, seulement par la Netiquette qui n’est que « pour information ».)
Ajoutons à celà qu’après cette recommandation de ne pas dépasser 78 caractères par ligne, il y a ensuite une obligation de ne pas dépasser 998 caractères (cette limite-là vient tout droit du protocole SMTP), et le « bidouillage » du format=flowed devient logique : il permet de séparer clairement les retours à la ligne qui ne sont là que pour respecter le protocole, de ceux qui sont là pour exprimer la volonté de l’auteur du message d’aller à la ligne.
Ce « bidouillage » a aussi l’avantage de permettre un affichage à peu près correct du message même avec un client qui ne prend pas en charge le format flowed, ce qui est déterminant et trop souvent oublié par ceux qui proposent une « solution » peut-être bien meilleure et plus propre techniquement mais condamnée à l’échec parce qu’elle nécessite un support de la part de tous les acteurs...
Euh, non.
Edit→Account settings, rubriqueComposition & Addressing, décocherCompose messages in HTML format. Peu importe que le message auquel tu réponds soit en HTML, ta réponse sera en texte brut.