Network Working Group J

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

La présente spécification établit deux paramètres (Format et DelSP) à utiliser avec le type de support Text/Plain. En présence de ces paramètres, les espaces en queue sont utilisées pour indiquer des lignes de continuation et un indicateur de guillemets canoniques est utilisé pour indiquer des lignes entre guillemets. Il en résulte un codage qui apparaît comme du Text/Plain normal dans les plus anciennes mises en œuvre, car c'est en fait un Text/Plain normal, mais qui fournit un saut à la ligne/continuation de ligne et un système de citation supérieur.

Le présent document remplace celui spécifié dans la RFC 2646, "Paramètre de format Text/Plain", et ajoute le paramètre DelSp pour s'accommoder des langages/jeux de caractères codés dans lesquels les espaces ASCII ne sont pas utilisées ou apparaissent rarement.

Table des Matières

1. Introduction

2. Conventions utilisées dans ce document

3. Le problème

3.1 Texte de paragraphe

3.2 Retours à la ligne embarrassants

3.3 Nouveaux types de supports

4. Paramètres Format et DelSp

4.1 Interprétation de Format=Flowed

4.2 Génération de Format=Flowed

4.3 Convention de signature Usenet

4.4 Bourrage d'espace

4.5 Citation

4.6 Signatures numériques et chiffrement

4.7 Exemples

5. Interopérabilité

6. ABNF

7. Modes d'échec

7.1 Corruption d'espace de queue

8. Considérations sur la sécurité

9. Considérations relatives à l'IANA

10. Considérations d'internationalisation

11. Remerciements

12. Références normatives

13. Références pour information

Appendice A. Changements par rapport à la RFC 2646

Adresse de l'auteur

Déclaration complète de droits de reproduction

Des problèmes d'interopérabilité ont été observés de textes de paragraphe étiquetés par erreur comme Text/Plain, et avec diverses formes de "retour à la ligne embarrassants". (Voir la Section 3.)

Des tentatives de déployer de nouveaux types de supports, tels que Text/Enriched [RFC1896] et Text/HTML [HTML] ont souffert d'un manque de rétro compatibilité et d'une réaction souvent hostile de la part des utilisateurs en réception.

Ce dont on a besoin est un format qui soit de toutes les façons significatif du Text/Plain, et donc convienne à l'affichage comme Text/Plain, et permette à l'envoyeur d'exprimer au receveur quelles lignes sont guillemetées et quelles lignes sont considérées comme un paragraphe logique, et donc éligible à être disposé (avec retour à la ligne et lignes jointes) comme approprié.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Le terme "paragraphe" est utilisé ici pour parler d'une série de lignes qui sont à traiter logiquement comme une unité d'affichage et sont éligibles à être disposées (avec saut à la ligne et jointes) comme approprié pour tenir dans la fenêtre d'affichage et lorsque on crée du texte pour des réponses, la transmission, etc.

Le type de support Text/Plain est le plus petit commun dénominateur de la messagerie électronique Internet, avec des lignes de pas plus de 998 caractères (par convention, généralement pas plus de 78) et où la séquence retour chariot et saut à la ligne (CRLF) représente une coupure de ligne (voir les [RFC2046] et [RFC2822]).

Text/Plain est généralement affiché comme texte préformaté, souvent dans une fonte fixée. C'est-à-dire que les caractères commencent à la marge gauche de la fenêtre d'affichage, et avancent vers la droite jusqu'à une séquence CRLF, moment auquel une nouvelle ligne commence, là encore, à la marge gauche. Lorsque une longueur de ligne excède la fenêtre d'affichage, certains clients vont revenir à la ligne, tandis que d'autres invoquent une barre de défilement horizontale.

Le texte qui répond à la présente description est défini par ce mémoire comme "fixe".

De nombreux programmes modernes utilisent une police à espacement proportionnel, et utilisent le CRLF pour représenter les coupures de paragraphes. Les coupures de ligne sont "douces", survenant quand nécessaire pour l'affichage. C'est-à-dire que les caractères sont groupés en un paragraphe jusqu'à ce qu'une séquence CRLF soit rencontrée, moment auquel un nouveau paragraphe commence. Chaque paragraphe est affiché, en commençant à la marge gauche (ou un retrait de paragraphe) et continue vers la droite jusqu'à ce que soit rencontré un mot qui ne tient pas dans la largeur d'affichage restante. Ce mot est affiché à la marge gauche de la ligne suivante. Cela continue jusqu'à la fin du paragraphe (on voit un CRLF). Un espace vertical supplémentaire est laissé entre les paragraphes.

Le texte qui répond à cette description est défini par le présent mémoire comme "fluant".

De nombreux produits logiciels marquent à tort ce format comme Text/Plain, d'où un certain inconfort de l'utilisateur.

Lorsque des messages Text/Plain sont cités dans des réponses ou des messages retransmis, chaque ligne augmente graduellement en longueur, étant éventuellement coupée d'un saut à la ligne arbitraire, résultant en "sauts à la ligne embarrassants". Cela produit du texte qui est, au mieux, difficile à lire, et souvent confond les attributions.

De plus, comme les appareils avec des largeurs d'affichage de moins de 79 ou 80 caractères deviennent plus répandus, les sauts à la ligne embarrassants deviennent de plus en plus fréquents, même avec du texte non guillemeté.

Les tentatives de déployer de nouveaux types de supports, comme Text/Enriched [RFC1896] et Text/HTML [HTML] ont souffert d'un manque de rétrocompatibilité et d'une réaction souvent hostile des usagers en réception.

En particulier, Text/Enriched exige que les chevrons ("<") et les coupures de ligne dures soient doublés, avec pour résultat le mécontentement de l'usager quand il le voit comme du Text/Plain. Text/HTML exige encore plus d'altérations du texte, avec un accroissement correspondant des plaintes des usagers.

Une proposition de définir un nouveau type de support pour représenter explicitement la forme de paragraphe a souffert d'un manque d'interopérabilité avec les logiciels couramment déployés. Certains programmes traitent les sous types inconnus de TEXT comme une pièce jointe.

Ce qu'on souhaite est un format qui soit du Text/Plain de toutes les façons significatives, et donc soit assez convenable pour être affiché comme Text/Plain, et permette quand même à l'envoyeur d'exprimer au receveur quelles lignes peuvent être considérées comme un paragraphe logique, et donc s'écouler (avec retour à la ligne de lignes jointes) comme approprié.

La présente spécification définit deux paramètres MIME à utiliser avec Text/Plain :

Si Format n'est pas spécifié, ou si sa valeur n'est pas reconnue, une valeur de Fixed est supposée. La sémantique de la valeur Fixed est celle habituellement associée à Text/Plain [RFC2046].

Une valeur de Format de Flowed indique que la définition de texte fluant (comme spécifié dans le présent mémoire) a été utilisée à sa génération, et PEUT être utilisée à réception.

Noter que parce que Format est un paramètre du type de contenu de Text/Plain, tout codage de transfert de contenu utilisé n'est pas pertinent pour le traitement du texte fluant.

Si DelSp n'est pas spécifié, ou si sa valeur n'est pas reconnue, une valeur de Non est supposée. L'utilisation de DelSp sans une valeur de Format de Flowed est indéfinie. Lors de la création de messages, DelSp NE DEVRAIT PAS être spécifié dans des types de contenu de Text autres que Text/Plain avec Format = Flowed. À la réception de messages, DelSp DEVRAIT être ignoré si il est utilisé dans un type de contenu Text autre que Text/Plain avec Format = Flowed.

La présente section discute des textes fluants ; la section 6 donne une définition formelle. La Section 5 discute de l'interopérabilité.

Noter que le présent mémoire décrit un format sur le réseau. Il ne traite pas des formats de mémorisation locale de fichiers.

Si le premier caractère d'une ligne est un chevron (">"), la ligne est considérée comme guillemetée (voir le paragraphe 4.5). Logiquement, tous les chevrons sont comptés et supprimés, résultant en une ligne avec une profondeur de guillemets non zéro , et un contenu. (L'agent a bien sûr toute liberté pour afficher le contenu avec des chevrons ou des guillemets ou n'importe quoi d'autre.) Logiquement, cette vérification de lignes guillemetée est faite avant toute autre vérification (c'est-à-dire, avant de vérifier si il y a un bourrage d'espaces et la fluance du texte).

Si le premier caractère d'une ligne est une espace, la ligne a été bourrée d'espaces (space-stuffed) (voir le paragraphe 4.4). Logiquement, cette espace en tête est supprimée avant d'examiner le reste de la ligne (c'est-à-dire, avant de vérifier si elle est fluante).

Si la ligne se termine par une espace, la ligne est fluante. Autrement, elle est fixe. L'exception à cette règle est une ligne de séparateur de signature, décrite au paragraphe 4.3. De telles lignes se finissent pas une espace mais ne sont ni fluantes ni fixes.

Si la ligne est fluante et si DelSp est "oui", l'espace en queue immédiatement avant le CRLF de la ligne est supprimé logiquement. Si le paramètre DelSp est "non" (ou non spécifié, ou réglé à une valeur non reconnue) l'espace en queue n'est pas supprimée.

Toutes les espaces en queue restantes font partie du contenu de la ligne, mais pas le CRLF d'une coupure de ligne douce.

Une série d'une ou plusieurs lignes fluantes suivies par une ligne fixe est considérée comme un paragraphe, et PEUT être fluante (avec ou sans retour à la ligne) comme approprié à l'affichage et dans la construction de nouveaux messages (voir le paragraphe 4.5).

Un agent qui interprète DEVRAIT permettre trois exceptions à la règle que les paragraphes se terminent par une ligne fixe. Ces exceptions sont les messages construits de façon inappropriée : une ligne fluante DEVRAIT être considérée comme terminant le paragraphe si elle est suivie par une ligne d'une profondeur de chevrons différente (voir le paragraphe 4.5) ou par un séparateur de signature (voir le paragraphe 4.3) ; la fin du corps termine aussi le paragraphe.

Une ligne consistant en une ou plusieurs espaces (après suppression de l'espace qui sert de bourrage) est considérée comme une ligne fluante.

Noter que, pour le texte Unicode, [Annex-14] donne des conseils pour choisir sur quels caractères faire un retour à la ligne.

Lors de la génération d'un texte Format=Flowed, les lignes DEVRAIENT faire 78 caractères ou moins, incluant toute espace en queue et incluant aussi toute espace ajoutée au titre du bourrage (voir le paragraphe 4.4). Comme valeurs suggérées, tout paragraphe de plus de 78 caractères de longueur totale pourrait sauter à la ligne en utilisant des lignes de 72 caractères ou moins. Bien que la longueur de ligne utilisée soit une affaire d'esthétique et de préférence, des lignes plus longues ont plus de chances d'exiger un redécoupage de ligne et de rencontrer des difficultés avec de plus anciens messageurs. (Il a été suggéré que les lignes de 66 caractères étaient les plus lisibles.)

La restriction à 78 caractères ou moins entre les CRLF sur le réseau est pour se conformer à la [RFC2822].

(En plus de la conformité à la [RFC2822], il y a un besoin historique que toutes les lignes, même lorsque elles sont affichées par un programme qui n'a pas la capacité de fluance, tiennent dans un écran standard de 79 ou 80 colonnes sans avoir à revenir à la ligne. La limite est 78, pas 79 ou 80, parce que bien que 79 ou 80 tiennent sur une ligne, la dernière colonne est souvent réservée pour un indicateur de retour à la ligne.)

Lors de la création d'un texte fluant, l'agent générateur revient à la ligne, c'est-à-dire, insère des coupures de lignes 'douces' comme nécessaire. Les coupures de lignes douces sont ajoutées aux points de retour à la ligne naturels, comme entre les mots. Une coupure de ligne douce est une séquence SP CRLF.

Il y a deux techniques pour insérer des coupures de lignes douces. L'ancienne technique, établie par la RFC 2646, crée une coupure de ligne douce en insérant un CRLF après l'occurrence d'une espace. Avec cette technique, les coupures de lignes douces ne sont possible que là où des espaces surviennent déjà. Quand cette technique est utilisée, le paramètre DelSp DEVRAIT être utilisé ; si il est utilisé, il DOIT être réglé à "non".

La nouvelle technique, qui convient pour être utilisée même avec des jeux de caractères codés/langages dans lesquels le caractère espace ASCII est rare ou non utilisé, crée une coupure de ligne douce en insérant une séquence SP CRLF. Lorsque cette technique est utilisée, le paramètre DelSp DOIT être utilisé et DOIT être réglé à "oui". Noter que parce que il y a un bourrage d'espace (voir le paragraphe 4.4) lorsque cette technique est utilisée et qu'une coupure de ligne douce est insérée à un point où un SP existe déjà (comme entre des mots) si la séquence SP CRLF est ajoutée immédiatement avant le SP, le SP préexistant passe en tête et exige donc un bourrage. Il est RECOMMANDÉ que les agents évitent cela en insérant la séquence SP CRLF à la suite du SP existant.

Les agents générateurs PEUVENT utiliser l'une ou l'autre méthode au sein de chaque partie de corps Text/Plain.

Sans considération de la technique utilisée, un agent générateur NE DEVRAIT PAS insérer d'espace dans une localisation non naturelle, comme dans un mot (une séquence de caractères imprimables, ne contenant pas d'espaces, dans un jeu de caractères codé/langage dans lequel les espaces sont courantes). Si on est en présence d'un tel mot qui excède 78 caractères (mais moins que 998 caractères, la limite de la [RFC2821] sur la longueur de ligne) l'agent DEVRAIT envoyer le mot tel quel et dépasser la limite de 78 caractères de longueur de ligne.

o s'assurer que toutes les lignes (fixe et fluantes) sont de 78 caractères ou moins, en comptant toutes espaces en queue ainsi que les espaces ajoutées comme bourrage, mais sans le CRLF, sauf si un mot excède par lui-même les 78 caractères.

o émonder les espaces avant les coupures de ligne dures insérées par l'usager.

o bourrer avec des espaces les lignes qui commencent par une espace, "From ", ou ">".

Afin de créer des messages qui n'exigent pas de bourrage d'espace, et sont donc esthétiquement plus plaisants à la vue comme Format=Fixed, un agent générateur PEUT éviter le retour à la ligne immédiatement avant ">", "From ", ou espace.

(Voir aux paragraphes 4.4 et 4.5 plus d'informations sur respectivement le bourrage d'espace et le guillemetage.)

Un message de Format=Flowed consiste en zéro, un ou plusieurs paragraphes, contenant chacun une ou plusieurs lignes fluantes suivies par une ligne fixe. Le cas usuel est une série de lignes de texte fluantes avec des lignes blanches (vides) fixes entre elles.

Lorsque on place des coupures de ligne douces dans un paragraphe, les agents générateurs NE DOIVENT PAS les placer d'une façon qui soit cause qu'une ligne du paragraphe soit une ligne de séparateur de signature, parce que les paragraphes ne peuvent pas contenir de lignes de séparateur de signature (voir les paragraphes 4.3 et 6).

Le codage de la [RFC2045] NE DEVRAIT PAS être utilisé avec Format=Flowed sauf si absolument nécessaire (par exemple, des caractères non US-ASCII (à 8 bits) sur un transport strictement à 7 bits comme dans la [RFC2821] non étendue). En particulier, un message NE DEVRAIT PAS être codé en Quoted-Printable dans le seul but de protéger l'espace de fin sur les lignes fluantes sauf si la partie de corps est signée cryptographiquement ou chiffrée (voir le paragraphe 4.6).

L'intention de Format=Flowed est de permettre aux agents d'utilisateur de générer du texte fluant qui ne soit pas répugnant à voir comme pur Text/Plain brut (sans aucun décodage) ; l'utilisation de Quoted-Printable empêche cela et peut être cause que Format=Flowed est rejeté par l'utilisateur final.

Il existe une convention établie depuis longtemps dans les nouvelles Usenet qui apparaît aussi couramment dans la messagerie Internet d'utiliser "-- " comme ligne de séparation entre le corps et la signature d'un message. Lorsque on génère un message Format=Flowed qui contient un séparateur de style Usenet avant la signature, la ligne de séparation est envoyée telle quelle. C'est un cas particulier ; une ligne (facultativement guillemetée et bourrée) consistant en DASH DASH SP n'est ni fixe ni fluante.

Les agents générateurs NE DOIVENT PAS terminer un paragraphe avec une telle ligne de signature.

Un agent receveur n'a pas besoin de vérifier si il y a une ligne de signature avant de vérifier qu'il y a une ligne guillemetée (voir le paragraphe 4.5) et aussi après le compte logique et la suppression des chevrons et du bourrage (voir le paragraphe 4.4) d'une ligne guillemetée.

Afin de permettre les lignes non guillemetés qui commencent par ">", et pour protéger contre les systèmes qui "From-munge" les messages en transit (en modifiant toute ligne qui commence par "From " en ">From ") Format=Flowed fournit le bourrage d'espace.

Le bourrage d'espace ajoute une seule espace au début de toute ligne qui a besoin d'une protection lorsque le message est généré. À réception, si le premier caractère d'une ligne est une espace, il est logiquement supprimé. Cela se produit après la vérification qu'une ligne est guillemetée (ce qui compte logiquement et supprime tous les chevrons) et avant la vérification qu'une ligne est fluante.

À la génération, toute ligne non guillemetée qui commence par ">", et toute ligne qui commence par une espace ou "From " DOIT être bourrée d'une espace. D'autres lignes PEUVENT être bourrées d'une espace si désiré.

(Noter que le bourrage d'espace est conceptuellement similaire au bourrage de point comme spécifié dans la [RFC2821].)

En Format=Flowed, l'indicateur canonique de citation (ou marque de citation) est un ou plusieurs caractères chevron (">"). Les lignes qui commencent par l'indicateur de citation sont considérées comme guillemetées. Le nombre de caractères ">" au début de la ligne spécifie la profondeur de citation. Les lignes fluantes qui sont aussi guillemetées peuvent exiger un traitement spécial à l'affichage et lorsque elles sont copiées dans de nouveaux messages.

Lors de la création de lignes fluantes guillemetées, chacune de ces lignes commence par l'indicateur de citation.

sont sémantiquement identiques ; toutes deux ont une profondeur de citation de deux, et un contenu de "Exit, Stage Left".

Lorsque il génère des lignes fluantes guillemetées, un agent doit faire attention aux changements de profondeur de citation. Toutes les lignes d'un paragraphe DOIVENT être sans guillemets, ou alors elles DOIVENT toutes être guillemetées et avoir la même profondeur de citation. Donc, chaque fois qu'il y a un changement de profondeur de citation, ou un changement de guillemeté à non guillemeté, la ligne qui précède immédiatement le changement NE DOIT PAS être une ligne fluante.

Si un agent receveur souhaite reformater des lignes fluantes guillemetées (en les joignant et/ou les faisant revenir à la ligne) à l'affichage ou en générant de nouveaux messages, les lignes DEVRAIENT être "déguillemetées", reformatées, et ensuite "reguillemetées". Pour déguillemeter, on compte le nombre de chevrons dans l'indicateur de citation au début de chaque ligne. Pour reguillemeter après reformatage, un indicateur de citation contenant le même nombre de chevrons que présents à l'origine est mis en tête de chaque ligne.

À réception, si un changement de profondeur de citation se produit sur une ligne fluante, c'est que le message est improprement formaté. Le receveur DEVRAIT traiter cette erreur en utilisant la règle "la profondeur de citation l'emporte", qui est de considérer que le paragraphe se termine avec la ligne fluante qui précède immédiatement le changement de profondeur de citation.

En d'autres termes, chaque fois que deux lignes adjacentes ont des profondeurs de citation différentes, les envoyeurs DOIVENT s'assurer que la première ligne n'est pas fluante (qu'elle ne se termine pas sur une espace) et les receveurs qui trouvent là une ligne fluante DEVRAIENT la traiter comme la dernière ligne d'un paragraphe.

Par exemple, considérons la séquence de lignes suivante (en utilisant '*' pour indiquer une coupure de ligne douce, c'est-à-dire, SP CRLF, et '#' pour indiquer une coupure de ligne dure, c'est-à-dire, CRLF) :

>>>> application de façon stricte, y compris l'utilisation exclusive de majuscules.#

La seconde ligne se termine par une coupure de ligne douce, bien que ce soit la dernière ligne du bloc de profondeur de citation un. La question qui se pose alors est celle de l'interprétation de cette ligne, en considérant que la ligne suivante est la première du bloc de profondeur de citation deux.

Le texte de l'exemple ci-dessus, lorsque traité conformément à la règle que la profondeur de citation l'emporte, résulte en ce que les deux premières lignes sont considérées comme une section de citation fluante, avec une profondeur de citation de 1 ; les troisième et quatrième lignes deviennent une section de citation fluante, avec une profondeur de citation de 2.

Un agent générateur NE DOIT PAS créer cette situation ; un agent receveur DEVRAIT la traiter en donnant la préférence à la profondeur de citation.

Si un message est signé ou chiffré numériquement, il est important que le traitement cryptographique utilise le même texte pour la vérification et/ou déchiffrement de signature qu'utilisé pour la génération et/ou chiffrement de la signature. Comme l'utilisation de format=flowed permet que le texte soit altéré (en ajoutant ou supprimant des coupures de ligne et des espaces en queue) entre la composition et la transmission, et entre la réception et l'affichage, des problèmes d'interopérabilité ou des faiblesses de sécurité peuvent survenir si l'origine et le receveur n'utilisent pas tous deux le format du réseau pour le traitement cryptographique.

Les implications de l'interaction entre format=flowed et tout processus cryptographique spécifique dépend des détails du traitement cryptographique et devrait être compris avant d'utiliser format=flowed en conjonction avec des messages signés et/ou chiffrés.

Noter que la [RFC2440] spécifie (au paragraphe 7.1) que "toute espace blanche (espace, et tabulation, 0x09) en queue à la fin d'une ligne est ignorée lors du calcul de la signature en clair."

Donc, il serait possible d'ajouter, en transit, un en-tête format=flowed à un message signé régulier, format=fixed PGP ordinaire (pas [RFC2015]) et d'ajouter des caractères arbitraires d'espace en queue sans que cet ajout soit détecté. Cela changerait le rendu de l'article par un client qui prend en charge format=flowed.

Donc, l'utilisation de la [RFC2440] dans des messages format=flowed est fortement déconseillée. On recommande plutôt celle de la [RFC2015].

"Prenez encore un peu de thé," dit le Lièvre de mars à Alice, très sérieusement.

"Je n'en ai pas encore pris," répliqua Alice sur un ton offensé, "donc je ne peux en avoir plus."

"Vous voulez dire que vous ne pouvez en avoir MOINS," dit le Chapelier : "il est très facile de prendre PLUS que rien."

Ceci pourrait être codé comme suit (en utilisant '*' pour indiquer une coupure de ligne douce, c'est-à-dire, une séquence SP CRLF, et '#' pour indiquer une coupure de ligne dure, c'est-à-dire, CRLF):

"Prenez encore un peu de thé," dit le Lièvre de mars à Alice, très* sérieusement.#

"Je n'en ai pas encore pris," répliqua Alice sur un ton offensé, "donc* je ne peux en avoir plus."#

"Vous voulez dire que vous ne pouvez en avoir MOINS," dit le Chapelier : "il est très* facile de prendre PLUS que rien."#

Pour donner un exemple de citation, nous avons ici le même échange, présenté comme une série de citations en style direct :

>Vous voulez dire que vous ne pouvez en avoir MOINS, il est très facile de prendre*

Parce que les lignes fluantes sont presque indistinguables des lignes fixes, les logiciels qui ne reconnaissent pas Format=Flowed traitent les lignes fluantes comme du Text/Plain normal (ce qu'elles sont). Donc, Format=Flowed interopère avec les vieux clients, bien que les lignes fluantes aient des espaces insérées en queue.

Si un message à bourrage d'espace est reçu par un agent qui traite Format=Flowed, le bourrage d'espace est inversé et donc le message apparaît inchangé. Un agent qui ne sait pas traiter Format=Flowed ne va bien sûr pas défaire de bourrages d'espace; et donc les messages Format=Flowed peuvent apparaître avec une espace en tête sur certaines lignes (celles qui commencent par une espace, ">" qui n'est pas un indicateur de citation, ou "From "). Comme les lignes qui exigent un bourrage d'espace se produisent rarement, et que les conséquences esthétiques d'un bourrage d'espace non inversé sont minimes, on pense que cela ne pose pas de problème significatif.

Si certaines lignes commencent par une ou plusieurs espaces, l'agent générateur PEUT bourrer d'espace toutes les lignes, pour conserver le retrait relatif des lignes vues par les clients qui ne savent pas traiter Format=Flowed.

Les messages générés avec DelSp=oui et reçus par des clients qui ne savent pas traiter Format=Flowed mais ne connaissent pas le paramètre DelSp auront une espace supplémentaire restant après la suppression des coupures de ligne douces. Donc, lors de la génération d'un texte dans des langages/jeux de caractères codés dans lesquels les espaces sont courantes, l'agent générateur PEUT toujours utiliser la méthode DelSp=no.

Le texte aligné à la main, comme les tableaux ASCII, le code source, etc., DEVRAIT être envoyé comme lignes fixes, et non comme lignes fluantes.

Les constructions utilisées dans les parties de corps Text/Plain, Format=Flowed, sont décrites en utilisant le format Backus-Naur augmenté RFC2234], incluant le cœur des règles définies dans l'Appendice A.

Noter que les caractères SP (espace) et ">" sont codés conformément au paramètre de jeu de caractères.

; toutes les lignes d'un paragraphe DOIVENT être non guillemetées ou avoir la même profondeur de citation

stuffing = SP ; bourrage d'espace, ajouté à la génération si nécessaire, supprimé à réception

; si DelSp=oui, une espace a été ajoutée à la génération et est supprimée à réception.

C'est-à-dire qu'un corps de message Format=Flowed consiste en un nombre quelconque de paragraphes et/ou de lignes fixes et/ou de lignes de séparateur de signature ; les paragraphes doivent avoir au moins une ligne fluante et sont terminés par une ligne fixe ; la ligne fixe qui termine le paragraphe fait partie du paragraphe. (Il y a des exceptions qui sont décrites dans le texte.)

Sans au moins une ligne fluante, il y a une série de lignes fixes, chacune étant indépendante. Ce n'est pas un paragraphe.

Avec au moins une ligne fluante, c'est un paragraphe, et les lignes reçues peuvent être reformées et s'enchaîner pour tenir dans la taille de fenêtre d'affichage. Cela ne peut être fait que si les lignes font partie d'un groupement logique, le paragraphe.

Noter que les définitions de ligne fluante et de sig-sep sont potentiellement ambiguës : une ligne de séparateur de signature satisfait aux deux, mais est traitée comme une ligne de séparateur de signature et non comme une ligne fluante.

Il existe des systèmes qui altèrent les espaces blanches en queue sur les messages qui passent à travers eux. De tels systèmes peuvent supprimer, ou dans de plus rares cas, ajouter des espaces blanches en queue, en violation de la [RFC2821] paragraphe 4.5.2.

Supprimer les espaces blanches en queue a pour effet de convertir des lignes fluantes en lignes fixes, d'où résulte un message qui est comme si Format=Flowed n'avait pas été utilisé.

Ajouter des espaces blanches en queue à un message Format=Flowed peut résulter en un affichage ou une réponse malformés.

Comme la plupart des systèmes qui ajoutent des espaces blanches en queue le font pour créer une ligne qui remplisse un format d'enregistrement interne, le résultat est presque toujours une ligne qui contient un nombre pair de caractères (en comptant l'espace blanche de queue).

Un moyen possible de l'éviter serait donc de définir des lignes Format=Flowed comme utilisant soit un ou deux caractères espace pour indiquer une ligne fluante, afin que la longueur de ligne totale soit impaire. Cependant, en considérant la rareté de tels systèmes aujourd'hui, la complexité supplémentaire n'en vaut pas la peine.

Toute considération de sécurité qui s'applique à Text/Plain s'applique aussi à Text/Plain avec Format=Flowed.

Le paragraphe 4.6 discute des interactions entre Format=Flowed et les signatures ou chiffrement numériques.

L'IANA a ajouté une référence à la présente spécification dans l'enregistrement du type de support Text/Plain.

Les spécifications de retour à la ligne et de guillemets de Format=Flowed peuvent ne pas convenir pour certains jeux de caractères, comme les caractères arabes et hébreux qui se lisent de droite à gauche. Il faut faire attention lors de l'application de format=flowed dans ces cas, car format=fixed combiné avec le codage de la [RFC2045] peut être plus convenable.

Le paramètre DelSp a été ajouté spécifiquement pour permettre d'utiliser Format=Flowed avec des langages/jeux de caractères codés dans lesquels le caractère espace ASCII est rarement utilisé, ou pas utilisé du tout.

Le paramètre DelSp a été développé durant une série de discussions avec un certain nombre de gens, parmi lesquels Harald Alvestrand, Grant Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed, Alexey Melnikov, John Myers, et Pete Resnick.

Des corrections et des précisions à la RFC 2646 et aux versions antérieures du présent document ont été apportées par plusieurs personnes, incluant Adam Costello, Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, Ragho Mahalingam, Keith Moore, Greg Troxel, et Dan Wing.

On me dit que l'application de messagerie de NeXT utilisait un mécanisme très similaire (sans prise en charge des langues non occidentales) en 1992.

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC1896] P. Resnick, A. Walker, "Le type de contenu texte/MIME enrichi", février 1996. (Information)

o Ajout du paramètre DelSp pour traiter les langages et jeux de caractères codés dans lesquels l'espace est peu courant ou pas utilisé.

o Mise à jour du texte sur la génération et l'interprétation pour s'accommoder du paramètre DelSp.

o Ajout du texte sur la génération pour préciser que la limite de 78 caractères inclut les espaces blanches en queue et le bourrage.

o Déplacement de texte du Résumé à une nouvelle Introduction ; nouvelle rédaction du résumé.

o Déplacement du texte sur l'interopérabilité dans une nouvelle section, et mise à jour.

o Le texte sur les signatures numériques explique maintenant que OpenPGP ignore les espaces blanches en queue.

o Réécriture des règles ABNF pour supprimer la plupart des ambiguïtés et note sur le cas restant.

o Ajout d'une note que c-t-e n'est pas pertinent pour le traitement d'un texte fluant.

o Changement de certains DEVRAIT en DOIT (bourrage d'espace, paragraphes de citation).

o Ajout d'une note à l'ABNF sur le fait que espace et ">" sont codés conformément au jeu de caractères.

o Précision du traitement des lignes de séparateur de signature pour le rendre cohérent.

o Déplacement de la section sur l'interprétation avant la section sur la génération.

Le paramètre DelSp a été ajouté spécifiquement pour permettre d'utiliser Format=Flowed avec les langages/jeux de caractères codés dans lesquels le caractère espace ASCII est rarement utilisé, ou pas utilisé du tout. Le mécanisme DelSp a été choisi en dépit du fait qu'il avait été initialement rejeté comme ayant trop l'air d'un bricolage, parce que parmi les nombreuses techniques différentes proposées, il permet un maximum d'interopérabilité entre les clients qui ne prennent en charge ni cette spécification ni la RFC2646, ceux qui prennent en charge la RFC2646 mais pas cette spécification, et ceux qui prennent en charge cette spécification ; cet ensemble est multiplié par ceux qui traitent les langages/jeux de caractères codés dans lesquels les espaces sont courantes, et ceux dans lesquels ils sont rares ou pas utilisés.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	R. Gellens, Qualcomm
Request for Comments : 3676
RFC rendue obsolète : 2646	février 2004
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle