![[Mât'nik Brazil]](http://3.bp.blogspot.com/-w5vAnoQ0YEg/UhRlPw7Zf5I/AAAAAAAAAo0/PvMFtAu7zBM/s1600/Rio%2BDe%2BJenerio%2Bin%2Bnight.jpg)
Publié sur Mât'nik Brazill YOU "Par Wâmuffïn-R Thierry Arnaud TAREAU")
+++++++++++++++++++++
http://translate.googleusercontent.com/translate_c?depth=1&hl=fr&nv=1&rurl=translate.google.com&sl=auto&tl=fr&u=http://www.faqs.org/rfcs/rfc2046.html&usg=ALkJrhgmOcrj4S4L-0gGYw4xm_CAVqpL7w
++++++++++++++++++++++
+++++++++++++++++++++
http://translate.googleusercontent.com/translate_c?depth=1&hl=fr&nv=1&rurl=translate.google.com&sl=auto&tl=fr&u=http://www.faqs.org/rfcs/rfc2046.html&usg=ALkJrhgmOcrj4S4L-0gGYw4xm_CAVqpL7w
++++++++++++++++++++++
RFC 2046 - Mail Extensions MIME (Multipurpose Internet) Part Two
Internet Index RFC
Usenet FAQ Index
Autres questions
Documents
Outils
Rechercher
Recherche FAQ
Recherche RFC
IFC Accueil
Villes
Pays
Hôpitaux
Web Hosting Ratings
Recherche dans les archives RFC
Usenet FAQ Index
Autres questions
Documents
Outils
Rechercher
Recherche FAQ
Recherche RFC
IFC Accueil
Villes
Pays
Hôpitaux
Web Hosting Ratings
Recherche dans les archives RFC
Ou afficher le document en nombre
[ Index RFC | Usenet FAQ | Web FAQ | Documents | Villes | Dépôts SEC | Droits d'auteur | entreprises Photos et profils ]
Groupe de travail Réseau N. Freed
Request for Comments: 2046 Innosoft
Obsolètes: 1521, 1522, 1590 N. Borenstein
Catégorie: Standards Track First Virtual
Novembre 1996
Request for Comments: 2046 Innosoft
Obsolètes: 1521, 1522, 1590 N. Borenstein
Catégorie: Standards Track First Virtual
Novembre 1996
Extensions Multipurpose Internet Mail
(MIME) Deuxième partie:
Types de support
(MIME) Deuxième partie:
Types de support
Statut de ce Mémo
Ce document spécifie une voie normes de protocole Internet pour le
communauté Internet, et appelle à des discussions et suggestions pour
améliorations. S'il vous plaît se référer à l'édition actuelle de l '«Internet
Official Protocol Standards "(STD 1) pour l'état de standardisation
et le statut de ce protocole. La distribution de ce mémo est illimitée.
communauté Internet, et appelle à des discussions et suggestions pour
améliorations. S'il vous plaît se référer à l'édition actuelle de l '«Internet
Official Protocol Standards "(STD 1) pour l'état de standardisation
et le statut de ce protocole. La distribution de ce mémo est illimitée.
Résumé
STD 11, RFC 822 définit un protocole de représentation de message spécifiant
très détaillée sur-têtes de message US-ASCII, mais qui laisse
le contenu du message, ou le corps du message, sous forme de texte US-ASCII. Cette
ensemble de documents, appelés collectivement l'Internet Mail Multipurpose
Extensions, ou MIME, redéfinit le format des messages pour permettre
très détaillée sur-têtes de message US-ASCII, mais qui laisse
le contenu du message, ou le corps du message, sous forme de texte US-ASCII. Cette
ensemble de documents, appelés collectivement l'Internet Mail Multipurpose
Extensions, ou MIME, redéfinit le format des messages pour permettre
(1) le corps des messages textuels à des jeux de caractères autres que les
US-ASCII,
US-ASCII,
(2) un ensemble extensible de formats différents pour les non-textuel
le corps du message,
le corps du message,
(3) le corps des messages en plusieurs parties, et
(4) Les informations d'en-tête textuel dans les jeux de caractères autres que les
US-ASCII.
US-ASCII.
Ces documents sont basés sur des travaux antérieurs documenté dans la RFC 934 , STD
11, et RFC 1049 , mais s'étend et les révise. Parce que la RFC 822 dit
si peu sur le corps des messages, ces documents sont largement
orthogonal (plutôt qu'une révision de) RFC 822 .
11, et RFC 1049 , mais s'étend et les révise. Parce que la RFC 822 dit
si peu sur le corps des messages, ces documents sont largement
orthogonal (plutôt qu'une révision de) RFC 822 .
Le document initial dans cet ensemble, RFC 2045 , spécifie les diverses statistiques
têtes utilisés pour décrire la structure des messages MIME. Cette deuxième
document définit la structure générale de la frappe médias MIME
système et définit un ensemble initial de types de média. Le troisième document,
RFC 2047 , décrit les extensions à la RFC 822 pour permettre le texte non-US-ASCII
têtes utilisés pour décrire la structure des messages MIME. Cette deuxième
document définit la structure générale de la frappe médias MIME
système et définit un ensemble initial de types de média. Le troisième document,
RFC 2047 , décrit les extensions à la RFC 822 pour permettre le texte non-US-ASCII
données dans les champs d'en-tête de messagerie Internet. Le quatrième document, RFC 2048 ,
spécifie diverses procédures d'enregistrement de l'IANA pour liés MIME
installations. Le cinquième et dernier document RFC 2049 , décrit MIME
critères de conformité ainsi que fournir quelques exemples
des formats MIME de message, les remerciements, et la bibliographie.
spécifie diverses procédures d'enregistrement de l'IANA pour liés MIME
installations. Le cinquième et dernier document RFC 2049 , décrit MIME
critères de conformité ainsi que fournir quelques exemples
des formats MIME de message, les remerciements, et la bibliographie.
Ces documents sont des révisions des RFC 1521 et 1522, qui eux-mêmes
étaient révisions des RFC 1341 et 1342. Une annexe au RFC 2049
décrit les différences et les changements par rapport aux versions précédentes.
étaient révisions des RFC 1341 et 1342. Une annexe au RFC 2049
décrit les différences et les changements par rapport aux versions précédentes.
Table des matières
1. Introduction ......................................... 3
2. Définition d'un niveau supérieur Type de support ................. 4
3. Aperçu des types initiaux de médias de premier niveau ........ 4
4. Discrets Type de support valeurs ........................... 6
4.1 Text Type de support ..................................... 6
4.1.1 Représentation des sauts de ligne ..................... 7
4.1.2 Charset Paramètres ................................. 7
4.1.3 Sous-Plaine ..................................... 11
4.1.4 Les sous-types non reconnus ............................. 11
4.2 image Type de support .................................... 11
4.3 Audio Type de support .................................... 11
4.4 Vidéo Type de support .................................... 12
4.5 Application Type de support .............................. 12
4.5.1 Sous-octet-stream .............................. 13
4.5.2 PostScript Sous ................................ 14
4.5.3 autres sous-types d'applications ........................ 17
5. Composite Type de support valeurs .......................... 17
5.1 multipart Type de support ................................ 17
5.1.1 syntaxe commune ..................................... 19
5.1.2 Gestion des messages et Multiparts imbriquées ........... 24
5.1.3 Sous mixte ..................................... 24
5.1.4 Sous Alternative ............................... 24
5.1.5 Digest Sous .................................... 26
5.1.6 Sous parallèle .................................. 27
5.1.7 autres sous-types en plusieurs parties .......................... 28
5.2 Type de message des médias .................................. 28
5.2.1 RFC822 Sous .................................... 28
5.2.2 Sous partielle ................................... 29
5.2.2.1 message fragmentation et le réassemblage ............ 30
5.2.2.2 Fragmentation et réassemblage Exemple ............ 31
5.2.3 Sous-external-body ............................. 33
5.2.4 autres sous-types de messages ............................ 40
6. Expérimentales Type de support valeurs ....................... 40
7. Résumé .............................................. 41
8. Considérations sur la sécurité .............................. 41
9. Adresses des auteurs ................................... 42
2. Définition d'un niveau supérieur Type de support ................. 4
3. Aperçu des types initiaux de médias de premier niveau ........ 4
4. Discrets Type de support valeurs ........................... 6
4.1 Text Type de support ..................................... 6
4.1.1 Représentation des sauts de ligne ..................... 7
4.1.2 Charset Paramètres ................................. 7
4.1.3 Sous-Plaine ..................................... 11
4.1.4 Les sous-types non reconnus ............................. 11
4.2 image Type de support .................................... 11
4.3 Audio Type de support .................................... 11
4.4 Vidéo Type de support .................................... 12
4.5 Application Type de support .............................. 12
4.5.1 Sous-octet-stream .............................. 13
4.5.2 PostScript Sous ................................ 14
4.5.3 autres sous-types d'applications ........................ 17
5. Composite Type de support valeurs .......................... 17
5.1 multipart Type de support ................................ 17
5.1.1 syntaxe commune ..................................... 19
5.1.2 Gestion des messages et Multiparts imbriquées ........... 24
5.1.3 Sous mixte ..................................... 24
5.1.4 Sous Alternative ............................... 24
5.1.5 Digest Sous .................................... 26
5.1.6 Sous parallèle .................................. 27
5.1.7 autres sous-types en plusieurs parties .......................... 28
5.2 Type de message des médias .................................. 28
5.2.1 RFC822 Sous .................................... 28
5.2.2 Sous partielle ................................... 29
5.2.2.1 message fragmentation et le réassemblage ............ 30
5.2.2.2 Fragmentation et réassemblage Exemple ............ 31
5.2.3 Sous-external-body ............................. 33
5.2.4 autres sous-types de messages ............................ 40
6. Expérimentales Type de support valeurs ....................... 40
7. Résumé .............................................. 41
8. Considérations sur la sécurité .............................. 41
9. Adresses des auteurs ................................... 42
A. recueillis Grammaire .................................... 43
1. Présentation
Le premier document de cette série, RFC 2045 , définit un certain nombre d'en-tête
domaines, y compris Content-Type. Le champ Content-Type est utilisé pour
préciser la nature des données dans le corps d'une entité MIME, par
donnant le type de support et les identificateurs de sous-type, et en fournissant auxiliaire
information qui peut être nécessaire pour certains types de supports. Après l'
type et les noms de sous-type, le reste du champ d'en-tête est tout simplement un
ensemble de paramètres spécifiés dans une notation d'attribut / valeur. Le
ordre des paramètres n'est pas significative.
domaines, y compris Content-Type. Le champ Content-Type est utilisé pour
préciser la nature des données dans le corps d'une entité MIME, par
donnant le type de support et les identificateurs de sous-type, et en fournissant auxiliaire
information qui peut être nécessaire pour certains types de supports. Après l'
type et les noms de sous-type, le reste du champ d'en-tête est tout simplement un
ensemble de paramètres spécifiés dans une notation d'attribut / valeur. Le
ordre des paramètres n'est pas significative.
En général, le type de support de niveau supérieur est utilisé pour déclarer le général
type de données, tandis que le sous-type spécifie un format spécifique pour que
type de données. Ainsi, un support de type "image / xyz" est suffisant pour raconter une
agent utilisateur que les données sont d'une image, même si l'agent utilisateur n'a aucun
connaissance du format d'image spécifique "xyz". Ces informations peuvent
être utilisé, par exemple, de décider s'il faut ou non montrer un utilisateur du brut
des données d'un sous-type non reconnu - une telle action pourrait être
raisonnable pour les sous-types non reconnus de "texte", mais pas pour
sous-types non reconnus de "image" ou "Audio". Pour cette raison,
sous-types déposées de "texte", "image", "audio" et "video" devrait
ne contiennent pas d'informations intégré qui est vraiment d'un type différent.
Ces formats composés devraient être représentés en utilisant la "multipart" ou
Types "d'application".
type de données, tandis que le sous-type spécifie un format spécifique pour que
type de données. Ainsi, un support de type "image / xyz" est suffisant pour raconter une
agent utilisateur que les données sont d'une image, même si l'agent utilisateur n'a aucun
connaissance du format d'image spécifique "xyz". Ces informations peuvent
être utilisé, par exemple, de décider s'il faut ou non montrer un utilisateur du brut
des données d'un sous-type non reconnu - une telle action pourrait être
raisonnable pour les sous-types non reconnus de "texte", mais pas pour
sous-types non reconnus de "image" ou "Audio". Pour cette raison,
sous-types déposées de "texte", "image", "audio" et "video" devrait
ne contiennent pas d'informations intégré qui est vraiment d'un type différent.
Ces formats composés devraient être représentés en utilisant la "multipart" ou
Types "d'application".
Les paramètres sont des modificateurs du sous-type des médias, et en tant que tels ne sont pas
affecter fondamentalement la nature du contenu. L'ensemble d'
paramètres significatifs dépend du type de support et de sous-type. Plus
paramètres sont associés à un seul sous-type particulier. Cependant, un
étant donné le type de support de haut niveau peut définir des paramètres qui sont applicables
pour un sous-type de ce type. Les paramètres peuvent être requis par leur
définir le type de support ou sous-type ou ils peuvent être en option. MIME
mises en œuvre doivent également ignorer tous les paramètres dont les noms qu'ils font
pas reconnaître.
affecter fondamentalement la nature du contenu. L'ensemble d'
paramètres significatifs dépend du type de support et de sous-type. Plus
paramètres sont associés à un seul sous-type particulier. Cependant, un
étant donné le type de support de haut niveau peut définir des paramètres qui sont applicables
pour un sous-type de ce type. Les paramètres peuvent être requis par leur
définir le type de support ou sous-type ou ils peuvent être en option. MIME
mises en œuvre doivent également ignorer tous les paramètres dont les noms qu'ils font
pas reconnaître.
Content-Type du champ d'en-tête MIME et le mécanisme du type de support a été
soigneusement conçu pour être extensible, et il est prévu que l'ensemble
de type / sous-type paires médias et leurs paramètres associés vont grandir
au fil du temps. Plusieurs autres installations MIME, comme
encodages de transfert et "message / external-body" types d'accès, sont
susceptibles d'avoir des nouvelles valeurs définies dans le temps. Afin de s'assurer que
l'ensemble de ces valeurs est développé d'une manière ordonnée, bien spécifié,
et de manière publique, MIME met en place une procédure d'enregistrement qui utilise le
Internet Assigned Numbers Authority (IANA) comme un registre central pour
MIME ya différentes zones d'extensibilité. Le processus d'enregistrement pour
ces zones sont décrites dans un document d'accompagnement, RFC 2048 .
soigneusement conçu pour être extensible, et il est prévu que l'ensemble
de type / sous-type paires médias et leurs paramètres associés vont grandir
au fil du temps. Plusieurs autres installations MIME, comme
encodages de transfert et "message / external-body" types d'accès, sont
susceptibles d'avoir des nouvelles valeurs définies dans le temps. Afin de s'assurer que
l'ensemble de ces valeurs est développé d'une manière ordonnée, bien spécifié,
et de manière publique, MIME met en place une procédure d'enregistrement qui utilise le
Internet Assigned Numbers Authority (IANA) comme un registre central pour
MIME ya différentes zones d'extensibilité. Le processus d'enregistrement pour
ces zones sont décrites dans un document d'accompagnement, RFC 2048 .
L'initiale de sept type de support de haut niveau standard sont définis et
décrit dans la suite de ce document.
décrit dans la suite de ce document.
2. Définition d'un niveau supérieur Type de support
La définition d'un type de support de premier niveau se compose de:
(1) un nom et une description du type, y compris
critères pour déterminer si un type particulier serait admissible
sous ce type,
critères pour déterminer si un type particulier serait admissible
sous ce type,
(2) les noms et les définitions des paramètres, le cas échéant,
sont définies pour tous les sous-types de ce type (y compris
si ces paramètres sont obligatoires ou facultatives),
sont définies pour tous les sous-types de ce type (y compris
si ces paramètres sont obligatoires ou facultatives),
(3) comment un agent utilisateur et / ou de la passerelle doit gérer inconnu
les sous-types de ce type,
les sous-types de ce type,
(4) des considérations générales sur les entités gatewaying de cette
Type de haut niveau, le cas échéant, et
Type de haut niveau, le cas échéant, et
(5) toute restriction au transfert de contenu pour les encodages
entités de ce type de haut niveau.
entités de ce type de haut niveau.
3. Aperçu des types initiaux de médias de premier niveau
Les cinq types de supports de haut niveau discrètes sont:
(1) Texte - information textuelle. Le sous-type "plaine" dans
particulière indique texte brut ne contenant pas
commandes de formatage ou de directives d'aucune sorte. Plaine
texte est destiné à être affiché "en l'état". Aucune spécial
logiciel est nécessaire pour obtenir la pleine signification de la
texte, mis à part le support du caractère indiqué
définir. D'autres sous-types doivent être utilisés pour le texte enrichi en
formes où le logiciel d'application peut améliorer la
apparence du texte, mais ce logiciel ne doivent pas être
nécessaire afin d'obtenir l'idée générale de l'
contenu. Sous-types possibles de "texte" comprennent donc tout
format de traitement de texte qui peut être lu sans
recourir à un logiciel qui comprend le format. En
particulier, les formats qui emploient binaire embeddded
informations de formatage sont pas considérés comme directement
lisible. Un sous-type très simple et portable,
"Richtext", a été défini dans la RFC 1341 , avec une nouvelle
révision dans RFC 1896 sous le nom de "enrichi".
particulière indique texte brut ne contenant pas
commandes de formatage ou de directives d'aucune sorte. Plaine
texte est destiné à être affiché "en l'état". Aucune spécial
logiciel est nécessaire pour obtenir la pleine signification de la
texte, mis à part le support du caractère indiqué
définir. D'autres sous-types doivent être utilisés pour le texte enrichi en
formes où le logiciel d'application peut améliorer la
apparence du texte, mais ce logiciel ne doivent pas être
nécessaire afin d'obtenir l'idée générale de l'
contenu. Sous-types possibles de "texte" comprennent donc tout
format de traitement de texte qui peut être lu sans
recourir à un logiciel qui comprend le format. En
particulier, les formats qui emploient binaire embeddded
informations de formatage sont pas considérés comme directement
lisible. Un sous-type très simple et portable,
"Richtext", a été défini dans la RFC 1341 , avec une nouvelle
révision dans RFC 1896 sous le nom de "enrichi".
(2) image - données d'image. "Image" nécessite un dispositif d'affichage
(Comme un affichage graphique, d'une imprimante graphique, ou une
Télécopieur) pour afficher les informations. Une première
sous-type est défini pour le format d'image largement utilisé
JPEG. . sous-types sont définis pour deux image largement utilisé
formats, JPEG et GIF.
(Comme un affichage graphique, d'une imprimante graphique, ou une
Télécopieur) pour afficher les informations. Une première
sous-type est défini pour le format d'image largement utilisé
JPEG. . sous-types sont définis pour deux image largement utilisé
formats, JPEG et GIF.
(3) AUDIO - données audio. "Audio" nécessite une sortie audio
appareil (comme un haut-parleur ou un téléphone) pour "afficher"
le contenu. Un premier sous-type "de base" est défini dans
ce document.
appareil (comme un haut-parleur ou un téléphone) pour "afficher"
le contenu. Un premier sous-type "de base" est défini dans
ce document.
(4) Vidéo - données vidéo. "Vidéo" nécessite la capacité
pour afficher des images en mouvement, y compris typiquement
matériel et des logiciels spécialisés. Un premier sous-type
«MPEG» est défini dans ce document.
pour afficher des images en mouvement, y compris typiquement
matériel et des logiciels spécialisés. Un premier sous-type
«MPEG» est défini dans ce document.
(5) l'application - un autre type de données, typiquement
données binaires soit non interprétées ou renseignements devant être
traitées par une application. Le sous-type "octet-
flux "doit être utilisé dans le cas de non-interprétées
des données binaires, et dans ce cas le plus simple recommandés
l'action est d'offrir à écrire les informations dans un fichier
pour l'utilisateur. Le sous-type de «PostScript» est également définie
pour le transport de matériau en PostScript. Autre
utilisations prévues pour "application" comprennent des feuilles de calcul,
données pour les systèmes d'ordonnancement à base d'électronique et des langues
pour "active" (de calcul) de messagerie et le mot
Traiter des formats qui ne sont pas directement lisible.
Notez que les considérations de sécurité peuvent exister pour certains
types de données d'application, notamment
"Application / PostScript" et toute forme d'actif
messagerie. Ces questions sont discutées plus loin dans ce
document.
données binaires soit non interprétées ou renseignements devant être
traitées par une application. Le sous-type "octet-
flux "doit être utilisé dans le cas de non-interprétées
des données binaires, et dans ce cas le plus simple recommandés
l'action est d'offrir à écrire les informations dans un fichier
pour l'utilisateur. Le sous-type de «PostScript» est également définie
pour le transport de matériau en PostScript. Autre
utilisations prévues pour "application" comprennent des feuilles de calcul,
données pour les systèmes d'ordonnancement à base d'électronique et des langues
pour "active" (de calcul) de messagerie et le mot
Traiter des formats qui ne sont pas directement lisible.
Notez que les considérations de sécurité peuvent exister pour certains
types de données d'application, notamment
"Application / PostScript" et toute forme d'actif
messagerie. Ces questions sont discutées plus loin dans ce
document.
Les deux types de supports de haut niveau composites sont:
(1) multi-parties - données composée de plusieurs entités du
les types de données indépendantes. Quatre sous-types sont d'abord
défini, y compris le sous-type de base «mixte» en précisant
un ensemble mixte générique de pièces, «alternative» pour
représentant les mêmes données dans plusieurs formats,
«Parallèle» pour les pièces destinées à être consultés
simultanément, et "digest" pour les entités dans plusieurs parties
dont chaque partie possède un type de défaut de "message/rfc822".
les types de données indépendantes. Quatre sous-types sont d'abord
défini, y compris le sous-type de base «mixte» en précisant
un ensemble mixte générique de pièces, «alternative» pour
représentant les mêmes données dans plusieurs formats,
«Parallèle» pour les pièces destinées à être consultés
simultanément, et "digest" pour les entités dans plusieurs parties
dont chaque partie possède un type de défaut de "message/rfc822".
(2) message - un message encapsulé. Un organe de support
de type "message" est elle-même la totalité ou une partie d'une certaine sorte
d'objet de message. De tels objets peuvent ou non à son tour
contenir d'autres entités. Le " rfc822 sous-type "est utilisé
lorsque le contenu encapsulé est lui-même un RFC 822
message. Le sous-type "partielle" est défini pour partielle
RFC 822 messages, afin de permettre la transmission fragmentée
des organismes qui sont censés être trop grand pour être adopté
dans les installations de transport dans une seule pièce. Autre
sous-type, "corps externe", est défini pour la spécification
grandes étendues par référence à une source de données externe.
de type "message" est elle-même la totalité ou une partie d'une certaine sorte
d'objet de message. De tels objets peuvent ou non à son tour
contenir d'autres entités. Le " rfc822 sous-type "est utilisé
lorsque le contenu encapsulé est lui-même un RFC 822
message. Le sous-type "partielle" est défini pour partielle
RFC 822 messages, afin de permettre la transmission fragmentée
des organismes qui sont censés être trop grand pour être adopté
dans les installations de transport dans une seule pièce. Autre
sous-type, "corps externe", est défini pour la spécification
grandes étendues par référence à une source de données externe.
Il convient de noter que la liste de type de média valeurs indiquées ici peuvent
être augmenté dans le temps, via les mécanismes décrits ci-dessus, et que
est prévu l'ensemble des sous-types de croître de façon substantielle.
être augmenté dans le temps, via les mécanismes décrits ci-dessus, et que
est prévu l'ensemble des sous-types de croître de façon substantielle.
4. Discrets Type de support valeurs
Cinq des sept valeurs de type de média initiales font référence à des organes distincts.
Le contenu de ces types doit être manipulé par des mécanismes non-MIME;
ils sont opaques aux processeurs MIME.
Le contenu de ces types doit être manipulé par des mécanismes non-MIME;
ils sont opaques aux processeurs MIME.
4.1. Text Type de support
Le "texte" type de média est destiné à l'envoi de matériel qui est
principalement sous forme textuelle. Un paramètre "charset" peut être utilisé pour
indiquer le jeu de caractères du texte de corps de sous-types "texte",
avec notamment le sous-type "text / plain", qui est un générique
sous-type de texte brut. Texte brut ne prévoit pas ou permettre
commandes de formatage, les spécifications d'attributs de police, le traitement
instructions, des directives d'interprétation, ou balisage de contenu. Plaine
le texte est considéré comme une simple séquence linéaire de caractères, éventuellement
interrompu par des sauts de ligne ou les sauts de page. Texte en clair peut permettre à l'
empilement de plusieurs caractères dans la même position dans le texte.
Texte brut dans les scripts comme l'arabe et l'hébreu peut également inclure
facilitites qui permettent le mélange arbitraire de segments de texte avec
directions d'écriture opposés.
principalement sous forme textuelle. Un paramètre "charset" peut être utilisé pour
indiquer le jeu de caractères du texte de corps de sous-types "texte",
avec notamment le sous-type "text / plain", qui est un générique
sous-type de texte brut. Texte brut ne prévoit pas ou permettre
commandes de formatage, les spécifications d'attributs de police, le traitement
instructions, des directives d'interprétation, ou balisage de contenu. Plaine
le texte est considéré comme une simple séquence linéaire de caractères, éventuellement
interrompu par des sauts de ligne ou les sauts de page. Texte en clair peut permettre à l'
empilement de plusieurs caractères dans la même position dans le texte.
Texte brut dans les scripts comme l'arabe et l'hébreu peut également inclure
facilitites qui permettent le mélange arbitraire de segments de texte avec
directions d'écriture opposés.
Au-delà du texte brut, il ya beaucoup de formats pour représenter ce qui pourrait
être connu comme "texte riche". Une caractéristique intéressante de ces nombreuses
représentations, c'est qu'ils sont dans une certaine mesure lisible même sans
le logiciel qui les interprète. Il est utile, puis, à
distinguer, au plus haut niveau, à partir de ces données illisibles comme
images, audio ou texte représenté sous une forme illisible. Dans l'
absence de logiciel d'interprétation appropriée, il est raisonnable de
montrer les sous-types de "text" à l'utilisateur, alors qu'il n'est pas raisonnable de le faire
si la plupart des données non textuels. Ces données textuelles doivent être formatées
représentés en utilisant les sous-types de "text".
être connu comme "texte riche". Une caractéristique intéressante de ces nombreuses
représentations, c'est qu'ils sont dans une certaine mesure lisible même sans
le logiciel qui les interprète. Il est utile, puis, à
distinguer, au plus haut niveau, à partir de ces données illisibles comme
images, audio ou texte représenté sous une forme illisible. Dans l'
absence de logiciel d'interprétation appropriée, il est raisonnable de
montrer les sous-types de "text" à l'utilisateur, alors qu'il n'est pas raisonnable de le faire
si la plupart des données non textuels. Ces données textuelles doivent être formatées
représentés en utilisant les sous-types de "text".
4.1.1. Représentation des sauts de ligne
La forme canonique d'un sous-type "texte" MIME doit toujours représenter une
saut de ligne comme une séquence CRLF. De même, toute occurrence de CRLF dans
MIME "texte" doit représenter un saut de ligne. Utilisation de CR et LF en dehors de
séquences de saut de ligne est également interdite.
saut de ligne comme une séquence CRLF. De même, toute occurrence de CRLF dans
MIME "texte" doit représenter un saut de ligne. Utilisation de CR et LF en dehors de
séquences de saut de ligne est également interdite.
Cette règle s'applique indépendamment du format ou un ensemble de caractères ou fixe
impliqué.
impliqué.
NOTE: L'interprétation correcte des sauts de ligne quand un corps est
affichée dépend du type de support. En particulier, alors qu'il est
approprié pour traiter une coupure de ligne comme une transition vers une nouvelle ligne lorsque
l'affichage d'un corps de «text / plain», ce traitement est effectivement incorrect
pour d'autres sous-types de "texte" comme "text / enrichi» [ RFC-1896 ].
De même, si oui ou non les sauts de ligne doivent être ajoutés lors de l'affichage
opérations est également fonction du type de média. Il ne devrait pas être
nécessaire d'ajouter des sauts de ligne pour afficher "text / plain" correctement,
tandis que l'affichage correct de "text / enrichi» nécessite le cas échéant
Outre des sauts de ligne.
affichée dépend du type de support. En particulier, alors qu'il est
approprié pour traiter une coupure de ligne comme une transition vers une nouvelle ligne lorsque
l'affichage d'un corps de «text / plain», ce traitement est effectivement incorrect
pour d'autres sous-types de "texte" comme "text / enrichi» [ RFC-1896 ].
De même, si oui ou non les sauts de ligne doivent être ajoutés lors de l'affichage
opérations est également fonction du type de média. Il ne devrait pas être
nécessaire d'ajouter des sauts de ligne pour afficher "text / plain" correctement,
tandis que l'affichage correct de "text / enrichi» nécessite le cas échéant
Outre des sauts de ligne.
NOTE: Certains protocoles définit une longueur maximale de la ligne. Par exemple SMTP [RFC-
821] permet à un maximum de 998 octets avant la séquence CRLF prochaine.
Pour être transportés par ces protocoles, données qui comprend trop longtemps
segments sans séquences CRLF doivent être encodés avec une convenable
Content-Transfer-encoding.
821] permet à un maximum de 998 octets avant la séquence CRLF prochaine.
Pour être transportés par ces protocoles, données qui comprend trop longtemps
segments sans séquences CRLF doivent être encodés avec une convenable
Content-Transfer-encoding.
4.1.2. paramètre charset
Un paramètre critique qui peut être spécifiée dans le champ Content-Type
pour "text / plain" de données est le jeu de caractères. Ceci est spécifié par un
Paramètre "charset", comme dans:
pour "text / plain" de données est le jeu de caractères. Ceci est spécifié par un
Paramètre "charset", comme dans:
Content-Type: text / plain; charset = iso-8859-1
Contrairement à d'autres valeurs de paramètres, les valeurs de l'charset
paramètres ne sont pas sensibles à la casse. Le jeu de caractères par défaut qui
doivent être pris en l'absence d'un paramètre charset est US-ASCII.
paramètres ne sont pas sensibles à la casse. Le jeu de caractères par défaut qui
doivent être pris en l'absence d'un paramètre charset est US-ASCII.
La spécification pour les sous-types futurs de "texte" doit préciser
si oui ou non ils vont aussi utiliser un paramètre "charset", et peut
peut-être limiter ses valeurs. Pour les autres sous-types de "text"
que "text / plain", la sémantique du paramètre "charset" devraient être
défini comme étant identiques à celles décrites pour "text / plain",
soit le corps est entièrement constitué de caractères dans le jeu de caractères proposée.
En particulier, définisseurs des futurs sous-types "texte" devrait accorder une
attention aux implications de caractère multioctet fixe pour leur
définitions de sous-type.
si oui ou non ils vont aussi utiliser un paramètre "charset", et peut
peut-être limiter ses valeurs. Pour les autres sous-types de "text"
que "text / plain", la sémantique du paramètre "charset" devraient être
défini comme étant identiques à celles décrites pour "text / plain",
soit le corps est entièrement constitué de caractères dans le jeu de caractères proposée.
En particulier, définisseurs des futurs sous-types "texte" devrait accorder une
attention aux implications de caractère multioctet fixe pour leur
définitions de sous-type.
Le paramètre charset de sous-types de "texte" donne le nom d'un
jeu de caractères, comme «jeu de caractères» est défini dans la RFC 2045 . Les règles
concernant les sauts de ligne décrites dans la section précédente doivent également être
observée - un jeu de caractères dont la définition n'est pas conforme à
ces règles ne peuvent pas être utilisées dans un sous-type "texte" MIME.
jeu de caractères, comme «jeu de caractères» est défini dans la RFC 2045 . Les règles
concernant les sauts de ligne décrites dans la section précédente doivent également être
observée - un jeu de caractères dont la définition n'est pas conforme à
ces règles ne peuvent pas être utilisées dans un sous-type "texte" MIME.
Une première liste de noms de jeux de caractères prédéfinies peuvent être trouvées à l'
fin de cette section. Jeux de caractères supplémentaires peuvent être enregistrés
auprès de l'IANA.
fin de cette section. Jeux de caractères supplémentaires peuvent être enregistrés
auprès de l'IANA.
D'autres types de médias que sous-types de "text" pourraient choisir d'employer le
paramètre charset tel que défini ici, mais avec la pause CRLF / ligne
restriction éliminé. Par conséquent, tous les jeux de caractères qui sont conformes aux
la définition générale de «jeu de caractères» dans la RFC 2045 peut être
homologué pour utilisation MIME.
paramètre charset tel que défini ici, mais avec la pause CRLF / ligne
restriction éliminé. Par conséquent, tous les jeux de caractères qui sont conformes aux
la définition générale de «jeu de caractères» dans la RFC 2045 peut être
homologué pour utilisation MIME.
Notez que si le jeu de caractères spécifié contient des caractères 8-bits
et ces caractères sont utilisés dans le corps, un Content-Transfer-Encoding
champ d'en-tête et d'un codage correspondant à des données sont requises en
afin de transmettre au corps par l'intermédiaire des protocoles de transfert de courrier, tels que
SMTP [ RFC-821 ].
et ces caractères sont utilisés dans le corps, un Content-Transfer-Encoding
champ d'en-tête et d'un codage correspondant à des données sont requises en
afin de transmettre au corps par l'intermédiaire des protocoles de transfert de courrier, tels que
SMTP [ RFC-821 ].
Le jeu de caractères par défaut, US-ASCII, a fait l'objet d'une certaine
confusion et l'ambiguïté dans le passé. Non seulement il y avait une certaine
ambiguïtés dans la définition, il ya eu de grandes variations dans
pratique. Afin d'éliminer cette ambiguïté et les variations de la
avenir, il est fortement recommandé que les nouveaux agents utilisateurs explicitement
spécifier un jeu de caractères comme paramètre de type de support dans le Content-Type
champ d'en-tête. "US-ASCII" n'indique pas un arbitraire 7 bits
jeu de caractères, mais précise que tous les octets dans le corps doivent être
interprétés comme des caractères selon le jeu de caractères US-ASCII.
Des versions nationales et axés sur l'application de la norme ISO 646 [ISO-646] sont
généralement pas identique à US-ASCII, et dans ce cas, leur utilisation dans
messagerie Internet est fortement déconseillée. L'omission de la norme ISO 646
jeu de caractères à partir de ce document est délibéré à cet égard. Le
nom de jeu de "US-ASCII" fait explicitement référence au caractère
jeu est défini dans la norme ANSI X3.4-1986 [US-ASCII]. Le nouvel international
La version de référence (IRV) de l'édition de 1991 de la norme ISO 646 est identique
à US-ASCII. Le nom du jeu de caractères «ASCII» est réservé et ne doit pas
être utilisé pour n'importe quel but.
confusion et l'ambiguïté dans le passé. Non seulement il y avait une certaine
ambiguïtés dans la définition, il ya eu de grandes variations dans
pratique. Afin d'éliminer cette ambiguïté et les variations de la
avenir, il est fortement recommandé que les nouveaux agents utilisateurs explicitement
spécifier un jeu de caractères comme paramètre de type de support dans le Content-Type
champ d'en-tête. "US-ASCII" n'indique pas un arbitraire 7 bits
jeu de caractères, mais précise que tous les octets dans le corps doivent être
interprétés comme des caractères selon le jeu de caractères US-ASCII.
Des versions nationales et axés sur l'application de la norme ISO 646 [ISO-646] sont
généralement pas identique à US-ASCII, et dans ce cas, leur utilisation dans
messagerie Internet est fortement déconseillée. L'omission de la norme ISO 646
jeu de caractères à partir de ce document est délibéré à cet égard. Le
nom de jeu de "US-ASCII" fait explicitement référence au caractère
jeu est défini dans la norme ANSI X3.4-1986 [US-ASCII]. Le nouvel international
La version de référence (IRV) de l'édition de 1991 de la norme ISO 646 est identique
à US-ASCII. Le nom du jeu de caractères «ASCII» est réservé et ne doit pas
être utilisé pour n'importe quel but.
NOTE: RFC 821 spécifie explicitement «ASCII», et fait référence à un plus haut
La version de la norme américaine. Dans la mesure où l'un des objectifs de
spécifiant un type de média et le jeu de caractères est de permettre le récepteur
de déterminer sans ambiguïté la façon dont l'expéditeur a voulu que le message codé
être interprété, en supposant que les autres "ASCII strict" comme quelque chose
défaut risquerait modifications involontaires et incompatible à l'
la sémantique des messages en cours de transmission. Cela implique également que
La version de la norme américaine. Dans la mesure où l'un des objectifs de
spécifiant un type de média et le jeu de caractères est de permettre le récepteur
de déterminer sans ambiguïté la façon dont l'expéditeur a voulu que le message codé
être interprété, en supposant que les autres "ASCII strict" comme quelque chose
défaut risquerait modifications involontaires et incompatible à l'
la sémantique des messages en cours de transmission. Cela implique également que
les messages contenant des caractères codés selon d'autres versions de
ISO 646 à US-ASCII et l'IRV 1991 ou en utilisant le code-switching
procédures (par exemple, celles de la norme ISO 2022), ainsi que 8 bits ou multiple
codages de caractères octet devez utiliser un jeu de caractères correspondant
spécification pour être compatibles avec MIME.
ISO 646 à US-ASCII et l'IRV 1991 ou en utilisant le code-switching
procédures (par exemple, celles de la norme ISO 2022), ainsi que 8 bits ou multiple
codages de caractères octet devez utiliser un jeu de caractères correspondant
spécification pour être compatibles avec MIME.
Le jeu de caractères US-ASCII complet est répertorié dans la norme ANSI X3.4-1986.
Notez que les caractères de contrôle, y compris DEL (0-31, 127) n'ont pas
notion définie à l'exception de la combinaison CRLF (valeurs US-ASCII
13 et 10) indiquant une nouvelle ligne. Deux des personnages ont de
significations facto largement utilisées: FF (12) signifie souvent "start ultérieure
texte sur le début d'une nouvelle page ", et TAB ou HT (9) souvent (mais
pas toujours) signifie "déplacer le curseur vers la colonne suivante disponible après
la position actuelle, où le nombre de colonne est multiple de huit
(En comptant la première colonne comme colonne 0). "En dehors de ces
conventions, toute utilisation des caractères de contrôle ou des DEL dans un organisme doit
soit se produire
Notez que les caractères de contrôle, y compris DEL (0-31, 127) n'ont pas
notion définie à l'exception de la combinaison CRLF (valeurs US-ASCII
13 et 10) indiquant une nouvelle ligne. Deux des personnages ont de
significations facto largement utilisées: FF (12) signifie souvent "start ultérieure
texte sur le début d'une nouvelle page ", et TAB ou HT (9) souvent (mais
pas toujours) signifie "déplacer le curseur vers la colonne suivante disponible après
la position actuelle, où le nombre de colonne est multiple de huit
(En comptant la première colonne comme colonne 0). "En dehors de ces
conventions, toute utilisation des caractères de contrôle ou des DEL dans un organisme doit
soit se produire
(1) en raison d'un sous-type de texte autre que "plaine"
attribue expressément une signification supplémentaire, ou
attribue expressément une signification supplémentaire, ou
(2) dans le cadre d'un accord privé entre l'
expéditeur et le destinataire. Ces accords privés sont
découragé et devrait être remplacé par l'autre
les capacités de ce document.
expéditeur et le destinataire. Ces accords privés sont
découragé et devrait être remplacé par l'autre
les capacités de ce document.
NOTE: Une énorme prolifération des jeux de caractères existent au delà de nous-
ASCII. Un grand nombre de caractère partiellement ou totalement chevauchement
ensembles n'est pas une bonne chose. Un jeu de caractères unique qui peut être utilisé
universellement pour représenter toutes les langues du monde dans Internet
courrier serait préférable. Malheureusement, la pratique en vigueur dans
plusieurs communautés semble pointer à l'utilisation continue de multiple
jeux de caractères dans un proche avenir. Un petit nombre de normes
jeux de caractères sont donc définies pour l'utilisation d'Internet dans ce
document.
ASCII. Un grand nombre de caractère partiellement ou totalement chevauchement
ensembles n'est pas une bonne chose. Un jeu de caractères unique qui peut être utilisé
universellement pour représenter toutes les langues du monde dans Internet
courrier serait préférable. Malheureusement, la pratique en vigueur dans
plusieurs communautés semble pointer à l'utilisation continue de multiple
jeux de caractères dans un proche avenir. Un petit nombre de normes
jeux de caractères sont donc définies pour l'utilisation d'Internet dans ce
document.
Les valeurs de charset définies sont les suivantes:
(1) US-ASCII - tel que défini dans la norme ANSI X3.4-1986 [US-ASCII].
(2) ISO-8859-X - où «X» doit être remplacé, comme
nécessaire, pour les parties de l'ISO-8859 [ISO-8859]. Remarque
que les 646 jeux de caractères ISO ont été délibérément
omis en faveur de leurs remplaçants 8859, qui sont
le caractère désigné établit pour la messagerie Internet. Comme d'
la publication de ce document, les valeurs légitimes
pour "X" sont les chiffres de 1 à 10.
nécessaire, pour les parties de l'ISO-8859 [ISO-8859]. Remarque
que les 646 jeux de caractères ISO ont été délibérément
omis en faveur de leurs remplaçants 8859, qui sont
le caractère désigné établit pour la messagerie Internet. Comme d'
la publication de ce document, les valeurs légitimes
pour "X" sont les chiffres de 1 à 10.
Personnages dans la gamme 128-159 n'a pas de sens dans la norme ISO-8859-
X. Les personnages avec des valeurs inférieures à 128 en ISO-8859-X ont la même
attribuer une signification comme ils le font en US-ASCII.
X. Les personnages avec des valeurs inférieures à 128 en ISO-8859-X ont la même
attribuer une signification comme ils le font en US-ASCII.
Partie 6 de la norme ISO 8859 (Latin / alphabet arabe) et la partie 8 (latin / hébreu
alphabet) comprend à la fois des caractères pour lesquels l'écriture normale
direction est droite à gauche et des caractères pour lesquels il est laissé à
droit, mais ne pas définir une méthode ordre canonique pour représenter
moins bidirectionnel. Les valeurs de charset "ISO-8859-6" et "ISO-8859-
8 ", précise toutefois que la méthode visuelle est utilisée [ RFC-1556 ].
alphabet) comprend à la fois des caractères pour lesquels l'écriture normale
direction est droite à gauche et des caractères pour lesquels il est laissé à
droit, mais ne pas définir une méthode ordre canonique pour représenter
moins bidirectionnel. Les valeurs de charset "ISO-8859-6" et "ISO-8859-
8 ", précise toutefois que la méthode visuelle est utilisée [ RFC-1556 ].
Tous ces jeux de caractères sont utilisés comme 7bit purs ou des jeux 8bit
sans aucun changement ou des fonctions de secours. Le sens de déplacement et
les séquences d'échappement dans ces jeux de caractères n'est pas défini.
sans aucun changement ou des fonctions de secours. Le sens de déplacement et
les séquences d'échappement dans ces jeux de caractères n'est pas défini.
Les jeux de caractères spécifié ci-dessus sont ceux qui étaient relativement
controverse lors de la rédaction de MIME. Ce document ne
approuver l'utilisation de tout caractère particulier mettre autre que US-ASCII,
et reconnaît que l'évolution future du caractère mondial fixe
reste incertaine.
controverse lors de la rédaction de MIME. Ce document ne
approuver l'utilisation de tout caractère particulier mettre autre que US-ASCII,
et reconnaît que l'évolution future du caractère mondial fixe
reste incertaine.
Notez que le jeu de caractères utilisé, si autre que US-ASCII rien,
doit toujours être explicitement spécifié dans le champ Content-Type.
doit toujours être explicitement spécifié dans le champ Content-Type.
Aucun nom de jeu autres que ceux définis ci-dessus peut être utilisé dans
messagerie Internet sans publication d'une spécification formelle et
son enregistrement auprès de l'IANA, ou de gré à gré, dans ce cas,
le nom du jeu de caractères doit commencer par "X-".
messagerie Internet sans publication d'une spécification formelle et
son enregistrement auprès de l'IANA, ou de gré à gré, dans ce cas,
le nom du jeu de caractères doit commencer par "X-".
Les développeurs sont incités à définir de nouveaux jeux de caractères à moins que
absolument nécessaire.
absolument nécessaire.
Le paramètre "charset" a été définie principalement dans le but de
données textuelles, et est décrit dans cet article pour cette raison.
Cependant, il est concevable que les données non-textuelles peuvent également souhaiter
spécifier une valeur jeu de caractères pour un but, dans ce cas, de la même
la syntaxe et les valeurs doivent être utilisés.
données textuelles, et est décrit dans cet article pour cette raison.
Cependant, il est concevable que les données non-textuelles peuvent également souhaiter
spécifier une valeur jeu de caractères pour un but, dans ce cas, de la même
la syntaxe et les valeurs doivent être utilisés.
En général, les logiciels de composition devrait toujours utiliser le "plus petit commun
caractère dénominateur "set possible. Par exemple, si un corps contient
seuls les caractères US-ASCII, il doit être marqué comme étant dans l'US-
Jeu de caractères ASCII, pas ISO-8859-1, qui, comme tout le ISO-8859
famille de jeux de caractères, est un sur-ensemble de l'US-ASCII. Plus généralement,
si un jeu de caractères couramment utilisé est un sous-ensemble d'un autre jeu de caractères,
et un corps ne contient que des caractères dans le sous-ensemble largement utilisé, il
devraient être étiquetés comme étant dans ce sous-ensemble. Cela permettra d'accroître la
chances que le destinataire sera en mesure de voir l'entité issue
correctement.
caractère dénominateur "set possible. Par exemple, si un corps contient
seuls les caractères US-ASCII, il doit être marqué comme étant dans l'US-
Jeu de caractères ASCII, pas ISO-8859-1, qui, comme tout le ISO-8859
famille de jeux de caractères, est un sur-ensemble de l'US-ASCII. Plus généralement,
si un jeu de caractères couramment utilisé est un sous-ensemble d'un autre jeu de caractères,
et un corps ne contient que des caractères dans le sous-ensemble largement utilisé, il
devraient être étiquetés comme étant dans ce sous-ensemble. Cela permettra d'accroître la
chances que le destinataire sera en mesure de voir l'entité issue
correctement.
4.1.3. Sous-Plaine
Le sous-type le plus simple et le plus important de «texte» est «évident». Cette
indique texte clair qui ne contient pas de commandes de formatage ou
directives. Texte brut est destiné à être affiché "en l'état", c'est-à-
aucune interprétation de commandes de formatage embarqués, attribut police
spécifications, les instructions de traitement, les directives d'interprétation,
ou le balisage de contenu ne devrait être nécessaire pour un affichage correct. Le
par défaut le type de support "text / plain; charset = us-ascii" pour Internet
courrier décrit la pratique de l'Internet actuel. Autrement dit, c'est le type
de corps défini par la RFC 822 .
indique texte clair qui ne contient pas de commandes de formatage ou
directives. Texte brut est destiné à être affiché "en l'état", c'est-à-
aucune interprétation de commandes de formatage embarqués, attribut police
spécifications, les instructions de traitement, les directives d'interprétation,
ou le balisage de contenu ne devrait être nécessaire pour un affichage correct. Le
par défaut le type de support "text / plain; charset = us-ascii" pour Internet
courrier décrit la pratique de l'Internet actuel. Autrement dit, c'est le type
de corps défini par la RFC 822 .
Aucune autre sous-type "texte" est définie par le présent document.
4.1.4. Les sous-types non reconnus
Sous-types non reconnus de «texte» doivent être considérés comme sous-type "plaine"
aussi longtemps que la mise en œuvre MIME sait comment gérer le charset.
Sous-types non reconnus qui précisent aussi un jeu de caractères non reconnus
doivent être traités comme "flux application/octet-".
aussi longtemps que la mise en œuvre MIME sait comment gérer le charset.
Sous-types non reconnus qui précisent aussi un jeu de caractères non reconnus
doivent être traités comme "flux application/octet-".
4.2. Image Type de support
Un type de support de "image" indique que le corps contient une image.
Le sous-type désigne le format d'image spécifique. Ces noms ne sont pas
sensible à la casse. Un premier sous-type est "jpeg" pour le format JPEG
utilisant JFIF encodage [JPEG].
Le sous-type désigne le format d'image spécifique. Ces noms ne sont pas
sensible à la casse. Un premier sous-type est "jpeg" pour le format JPEG
utilisant JFIF encodage [JPEG].
La liste des sous-types "image" donnée ici n'est ni exclusive, ni
exhaustive, et devrait croître que plus de types sont enregistrés auprès de
IANA, comme décrit dans la RFC 2048 .
exhaustive, et devrait croître que plus de types sont enregistrés auprès de
IANA, comme décrit dans la RFC 2048 .
Sous-types non reconnus de "image" devraient au miniumum être traités comme des
"Application / octet-stream". Les implémentations peuvent éventuellement choisir de
passer sous-types de «image» qu'ils ne reconnaissent spécifiquement à un
application de visualisation image générale usage sécurisé et robuste, si une telle
une application est disponible.
"Application / octet-stream". Les implémentations peuvent éventuellement choisir de
passer sous-types de «image» qu'ils ne reconnaissent spécifiquement à un
application de visualisation image générale usage sécurisé et robuste, si une telle
une application est disponible.
REMARQUE: L'utilisation d'une application de visualisation image générique usage de cette façon
hérite des problèmes de sécurité du type le plus dangereux soutenu
par l'application.
hérite des problèmes de sécurité du type le plus dangereux soutenu
par l'application.
4.3. Audio Type de support
Un type de support de "audio" indique que le corps contient des données audio.
Bien qu'il n'y ait pas encore de consensus sur un format audio "idéal" pour
utilisation avec des ordinateurs, il ya un besoin urgent pour un format capable d'
fournissant comportement interopérables.
Bien qu'il n'y ait pas encore de consensus sur un format audio "idéal" pour
utilisation avec des ordinateurs, il ya un besoin urgent pour un format capable d'
fournissant comportement interopérables.
Le sous-type initial de "base" est spécifié pour répondre à cette exigence
en fournissant un minimum absolument plus bas audio de dénominateur commun
Format. Il est prévu que les formats les plus riches de qualité supérieure et / ou
inférieur audio large bande sera définie par un document plus tard.
en fournissant un minimum absolument plus bas audio de dénominateur commun
Format. Il est prévu que les formats les plus riches de qualité supérieure et / ou
inférieur audio large bande sera définie par un document plus tard.
Le contenu du sous-type "audio / basic" est unique canal audio
codé à l'aide 8bit RNIS mu-law [PCM] à une fréquence d'échantillonnage de 8000 Hz.
codé à l'aide 8bit RNIS mu-law [PCM] à une fréquence d'échantillonnage de 8000 Hz.
Sous-types non reconnus de "audio" devraient au miniumum être traités comme des
"Application / octet-stream". Les implémentations peuvent éventuellement choisir de
passer sous-types de "audio" qu'ils ne reconnaissent pas spécifiquement à une
l'application de lecture audio polyvalent robuste, si une telle
application est disponible.
"Application / octet-stream". Les implémentations peuvent éventuellement choisir de
passer sous-types de "audio" qu'ils ne reconnaissent pas spécifiquement à une
l'application de lecture audio polyvalent robuste, si une telle
application est disponible.
4.4. Vidéo Type de support
Un type de média "vidéo" indique que le corps contient un temps
l'image variant d'image, peut-être avec la couleur et le son coordonnée.
Le terme «vidéo» est utilisé dans son sens le plus générique, plutôt qu'avec
référence à une technologie ou un format particulier, et n'est pas destiné à
empêcher les sous-types tels que les dessins animés encodés compacte. Le
sous-type "MPEG" désigne vidéo codé selon la norme MPEG
[MPEG].
l'image variant d'image, peut-être avec la couleur et le son coordonnée.
Le terme «vidéo» est utilisé dans son sens le plus générique, plutôt qu'avec
référence à une technologie ou un format particulier, et n'est pas destiné à
empêcher les sous-types tels que les dessins animés encodés compacte. Le
sous-type "MPEG" désigne vidéo codé selon la norme MPEG
[MPEG].
Notez que bien qu'en général ce document déconseille fortement le
mélange de plusieurs médias en un seul corps, il est reconnu que de nombreux
formats vidéo dits comprennent une représentation pour synchronisée
audio, ce qui est explicitement autorisé pour les sous-types de "vidéo".
mélange de plusieurs médias en un seul corps, il est reconnu que de nombreux
formats vidéo dits comprennent une représentation pour synchronisée
audio, ce qui est explicitement autorisé pour les sous-types de "vidéo".
Sous-types non reconnus de "vidéo" devraient au minumum être traités comme des
"Application / octet-stream". Les implémentations peuvent éventuellement choisir de
passer sous-types de "vidéo" qu'ils ne reconnaissent spécifiquement à un
demande d'affichage vidéo à usage général robuste, si une telle
application est disponible.
"Application / octet-stream". Les implémentations peuvent éventuellement choisir de
passer sous-types de "vidéo" qu'ils ne reconnaissent spécifiquement à un
demande d'affichage vidéo à usage général robuste, si une telle
application est disponible.
4.5. Type d'application des médias
L '"application" type de support doit être utilisé pour des données discrètes qui ne
ne rentre pas dans l'un des autres catégories, et en particulier pour les données à
traiter par un certain type de programme d'application. C'est
informations qui doivent être traitées par une application avant qu'il ne soit
visualisable ou utilisable par un utilisateur. Usages attendus pour le "application"
type de support comprennent le transfert de fichiers, feuilles de calcul, les données de base de courrier
systèmes de planification et de langues pour "active" (de calcul)
matériau. (Celui-ci, en particulier, peut poser des problèmes de sécurité
qui doit être compris par les réalisateurs, et sont considérés dans
détail dans la discussion du "application / postscript" type de média.)
ne rentre pas dans l'un des autres catégories, et en particulier pour les données à
traiter par un certain type de programme d'application. C'est
informations qui doivent être traitées par une application avant qu'il ne soit
visualisable ou utilisable par un utilisateur. Usages attendus pour le "application"
type de support comprennent le transfert de fichiers, feuilles de calcul, les données de base de courrier
systèmes de planification et de langues pour "active" (de calcul)
matériau. (Celui-ci, en particulier, peut poser des problèmes de sécurité
qui doit être compris par les réalisateurs, et sont considérés dans
détail dans la discussion du "application / postscript" type de média.)
Par exemple, un planificateur de réunion peut définir une norme
représentation des informations sur les dates des réunions proposées. Une
agent utilisateur intelligente serait d'utiliser ces informations pour mener une boîte de dialogue
avec l'utilisateur, et peuvent ensuite envoyer du matériel supplémentaire en fonction de cette
dialogue. Plus généralement, il ya eu plusieurs messages "active"
langues développées dans les programmes d'une manière appropriée spécialisé
langue sont transportés vers un emplacement distant et d'exécuter automatiquement
dans l'environnement du destinataire.
représentation des informations sur les dates des réunions proposées. Une
agent utilisateur intelligente serait d'utiliser ces informations pour mener une boîte de dialogue
avec l'utilisateur, et peuvent ensuite envoyer du matériel supplémentaire en fonction de cette
dialogue. Plus généralement, il ya eu plusieurs messages "active"
langues développées dans les programmes d'une manière appropriée spécialisé
langue sont transportés vers un emplacement distant et d'exécuter automatiquement
dans l'environnement du destinataire.
Ces applications peuvent être définis comme des sous-types de la «demande»
type de support. Ce document définit deux sous-types:
type de support. Ce document définit deux sous-types:
octet-stream, et PostScript.
Le sous-type de «demande» sera souvent le nom ou comprendre
une partie du nom de l'application pour laquelle les données sont destinées.
Cela ne signifie pas, cependant, que le nom de programme d'application peut être
utilisé librement comme un sous-type de «demande».
une partie du nom de l'application pour laquelle les données sont destinées.
Cela ne signifie pas, cependant, que le nom de programme d'application peut être
utilisé librement comme un sous-type de «demande».
4.5.1. Sous-octet-stream
Le sous-type "octet-stream" est utilisé pour indiquer que le corps contient
données binaires arbitraires. L'ensemble des paramètres définis actuellement est:
données binaires arbitraires. L'ensemble des paramètres définis actuellement est:
(1) Type - le type général ou d'une catégorie de données binaires.
Ceci est destiné à l'information du receveur humain
plutôt que pour tout traitement automatisé.
Ceci est destiné à l'information du receveur humain
plutôt que pour tout traitement automatisé.
(2) Remplissage - le nombre de bits de remplissage qui étaient
annexée à le train de bits comprenant la véritable
contenu pour produire le clos 8bit orienté octet
données. Ceci est utile pour enfermer un flux de bits dans un
corps lorsque le nombre total de bits n'est pas un multiple de
8.
annexée à le train de bits comprenant la véritable
contenu pour produire le clos 8bit orienté octet
données. Ceci est utile pour enfermer un flux de bits dans un
corps lorsque le nombre total de bits n'est pas un multiple de
8.
Ces deux paramètres sont facultatifs.
Un paramètre supplémentaire, "conversions", a été défini dans la RFC 1341 , mais
a depuis été retiré. RFC 1341 a également défini l'utilisation d'un "NAME"
paramètre qui a donné un nom de fichier suggéré à utiliser si les données
devaient être écrites dans un fichier. Cela a été déprécié en
anticipation d'un champ d'en-tête Content-Disposition séparée, d'être
défini dans une RFC ultérieure.
a depuis été retiré. RFC 1341 a également défini l'utilisation d'un "NAME"
paramètre qui a donné un nom de fichier suggéré à utiliser si les données
devaient être écrites dans un fichier. Cela a été déprécié en
anticipation d'un champ d'en-tête Content-Disposition séparée, d'être
défini dans une RFC ultérieure.
L'action recommandée pour une mise en œuvre qui reçoit une
"Application / octet-stream" entité est simplement de proposer de mettre les données
dans un fichier, avec un Content-Transfer-Encoding défait, ou peut-être à
utiliser comme entrée à un procédé spécifié par l'utilisateur.
"Application / octet-stream" entité est simplement de proposer de mettre les données
dans un fichier, avec un Content-Transfer-Encoding défait, ou peut-être à
utiliser comme entrée à un procédé spécifié par l'utilisateur.
Pour réduire le risque de transmission de programmes malveillants, il est fortement
recommandé que les implémentations mettent pas en œuvre un chemin de recherche
mécanisme par lequel un programme arbitraire nommé dans le Content-Type
paramètre (par exemple, un paramètre "interprète =") est trouvé et exécuté
en utilisant le corps du message en entrée.
recommandé que les implémentations mettent pas en œuvre un chemin de recherche
mécanisme par lequel un programme arbitraire nommé dans le Content-Type
paramètre (par exemple, un paramètre "interprète =") est trouvé et exécuté
en utilisant le corps du message en entrée.
4.5.2. Sous PostScript
Un type de média "application / postscript" indique un fichier PostScript
programme. Actuellement, deux variantes du langage PostScript sont
permis, l'original 1 variante de niveau est décrit dans [PostScript]
et la plus récente variante de niveau 2 est décrite dans [POSTSCRIPT2].
programme. Actuellement, deux variantes du langage PostScript sont
permis, l'original 1 variante de niveau est décrit dans [PostScript]
et la plus récente variante de niveau 2 est décrite dans [POSTSCRIPT2].
PostScript est une marque déposée d'Adobe Systems, Inc. L'utilisation de
le type de support MIME "application / postscript" implique la reconnaissance de
cette marque et de tous les droits que cela implique.
le type de support MIME "application / postscript" implique la reconnaissance de
cette marque et de tous les droits que cela implique.
La définition du langage PostScript offre des facilités pour interne
l'étiquetage de la langue spécifique dispose d'une donnée utilisations du programme.
Cet étiquetage, appelé la structuration des documents PostScript
conventions ou DSC, est très générale et fournit beaucoup plus
informations que juste le niveau de langue. L'utilisation du document
conventions de structuration, tout en n'étant pas obligatoire, est fortement recommandée
comme une aide à l'interopérabilité. Les documents qui n'ont pas correcte
conventions de structuration ne peuvent pas être testés pour voir si oui ou non ils
va travailler dans un environnement donné. En tant que tel, certains systèmes peuvent assumer
le pire et refuser de traiter les documents non structurés.
l'étiquetage de la langue spécifique dispose d'une donnée utilisations du programme.
Cet étiquetage, appelé la structuration des documents PostScript
conventions ou DSC, est très générale et fournit beaucoup plus
informations que juste le niveau de langue. L'utilisation du document
conventions de structuration, tout en n'étant pas obligatoire, est fortement recommandée
comme une aide à l'interopérabilité. Les documents qui n'ont pas correcte
conventions de structuration ne peuvent pas être testés pour voir si oui ou non ils
va travailler dans un environnement donné. En tant que tel, certains systèmes peuvent assumer
le pire et refuser de traiter les documents non structurés.
L'exécution des interprètes PostScript usage général implique
les risques de sécurité graves, et les réalisateurs sont découragés de simplement
envoi corps PostScript à des interprètes "off-the-shelf". Bien qu'il
est généralement sans danger pour envoyer PostScript à une imprimante, où le potentiel
pour le préjudice est fortement contraint par les environnements d'impression typiques,
les développeurs devraient tenir compte de tous les points suivants avant qu'ils ajoutent
affichage interactif des organismes de PostScript à leurs lecteurs MIME.
les risques de sécurité graves, et les réalisateurs sont découragés de simplement
envoi corps PostScript à des interprètes "off-the-shelf". Bien qu'il
est généralement sans danger pour envoyer PostScript à une imprimante, où le potentiel
pour le préjudice est fortement contraint par les environnements d'impression typiques,
les développeurs devraient tenir compte de tous les points suivants avant qu'ils ajoutent
affichage interactif des organismes de PostScript à leurs lecteurs MIME.
Le reste de cette section présente quelques-uns, mais probablement pas tous,
des éventuels problèmes avec le transport des entités PostScript.
des éventuels problèmes avec le transport des entités PostScript.
(1) Les opérations dangereuses dans le langage PostScript
inclure, mais ne se limitent pas à, l'PostScript
opérateurs "deletefile", "RenameFile", "filenameforall»,
et "fichier". "Fichier" est seulement dangereux lorsqu'il est appliqué à
autre que l'entrée ou la sortie standard quelque chose.
Les implémentations peuvent également définir non standard supplémentaire
opérateurs de fichiers, ceux-ci peuvent également constituer une menace pour
sécurité. "Filenameforall", la recherche de fichiers joker
opérateur, peut sembler à première vue être inoffensif.
inclure, mais ne se limitent pas à, l'PostScript
opérateurs "deletefile", "RenameFile", "filenameforall»,
et "fichier". "Fichier" est seulement dangereux lorsqu'il est appliqué à
autre que l'entrée ou la sortie standard quelque chose.
Les implémentations peuvent également définir non standard supplémentaire
opérateurs de fichiers, ceux-ci peuvent également constituer une menace pour
sécurité. "Filenameforall", la recherche de fichiers joker
opérateur, peut sembler à première vue être inoffensif.
Notez, cependant, que cet opérateur a le potentiel de
révéler des informations sur les fichiers le destinataire a
l'accès à l', et cette information peut être elle-même
sensible. Expéditeurs de messages doivent éviter l'utilisation de
opérateurs de fichiers potentiellement dangereux, puisque ceux-ci
les opérateurs sont tout à fait susceptibles de ne pas être disponible dans sécurisé
implémentations PostScript. Recevoir un message et
Les logiciels affichant doit soit désactiver complètement
tous les opérateurs de fichiers potentiellement dangereux ou prendre
attention pas puisse déléguer l'autorité particulière à
leur fonctionnement. Ces opérateurs doivent être considérées comme
effectué par un organisme extérieur lors de l'interprétation
documents PostScript. Une telle désactivation et / ou le contrôle
devrait être fait complètement en dehors de la portée de la
PostScript elle-même, les soins devraient être prises pour
s'assurer que n'existe aucune méthode pour réactiver plein
versions de la fonction de ces opérateurs.
révéler des informations sur les fichiers le destinataire a
l'accès à l', et cette information peut être elle-même
sensible. Expéditeurs de messages doivent éviter l'utilisation de
opérateurs de fichiers potentiellement dangereux, puisque ceux-ci
les opérateurs sont tout à fait susceptibles de ne pas être disponible dans sécurisé
implémentations PostScript. Recevoir un message et
Les logiciels affichant doit soit désactiver complètement
tous les opérateurs de fichiers potentiellement dangereux ou prendre
attention pas puisse déléguer l'autorité particulière à
leur fonctionnement. Ces opérateurs doivent être considérées comme
effectué par un organisme extérieur lors de l'interprétation
documents PostScript. Une telle désactivation et / ou le contrôle
devrait être fait complètement en dehors de la portée de la
PostScript elle-même, les soins devraient être prises pour
s'assurer que n'existe aucune méthode pour réactiver plein
versions de la fonction de ces opérateurs.
(2) Le langage PostScript fournit des installations pour sortir
l'interpréteur normale, ou serveur, boucle. Les modifications apportées
dans cet environnement «extérieur» sont habituellement retenus
à travers des documents, et peut dans certains cas être retenu
semi-permanente dans la mémoire non volatile. Les opérateurs
associé à la sortie de la boucle de l'interpréteur ont
potentiel d'interférer avec document ultérieur
traitement. En tant que tel, leur utilisation effrénée
constitue une menace de déni de service. PostScript
opérateurs qui sortent de la boucle d'interprétation comprennent, mais
ne peut pas se limiter à, l'exitserver et startjob
opérateurs. logiciel d'envoi de message ne doit pas
générer PostScript qui dépend de la sortie de l'
boucle d'interprétation à utiliser, car la capacité de sortir
sera probablement disponible en PostScript sécurisé
implémentations. Recevoir et afficher des messages
logiciel doit désactiver complètement la capacité de faire
modifications retenues à l'environnement PostScript par
l'élimination ou la désactivation de la "startjob" et
Opérations de «exitserver". Si ces opérations ne peuvent pas être
éliminées ou complètement désactivé le mot de passe
qui leur est associé doit au moins être mis à un disque-
à deviner la valeur.
l'interpréteur normale, ou serveur, boucle. Les modifications apportées
dans cet environnement «extérieur» sont habituellement retenus
à travers des documents, et peut dans certains cas être retenu
semi-permanente dans la mémoire non volatile. Les opérateurs
associé à la sortie de la boucle de l'interpréteur ont
potentiel d'interférer avec document ultérieur
traitement. En tant que tel, leur utilisation effrénée
constitue une menace de déni de service. PostScript
opérateurs qui sortent de la boucle d'interprétation comprennent, mais
ne peut pas se limiter à, l'exitserver et startjob
opérateurs. logiciel d'envoi de message ne doit pas
générer PostScript qui dépend de la sortie de l'
boucle d'interprétation à utiliser, car la capacité de sortir
sera probablement disponible en PostScript sécurisé
implémentations. Recevoir et afficher des messages
logiciel doit désactiver complètement la capacité de faire
modifications retenues à l'environnement PostScript par
l'élimination ou la désactivation de la "startjob" et
Opérations de «exitserver". Si ces opérations ne peuvent pas être
éliminées ou complètement désactivé le mot de passe
qui leur est associé doit au moins être mis à un disque-
à deviner la valeur.
(3) PostScript fournit aux opérateurs de fixer l'échelle du système
et des paramètres spécifiques à l'appareil. Ce paramètre
paramètres peuvent être conservés entre les emplois et mai
potentiellement constituer une menace pour le bon fonctionnement de
l'interprète. Les opérateurs PostScript qui établissent
les paramètres du système et dispositif comprennent, mais ne peuvent pas être
et des paramètres spécifiques à l'appareil. Ce paramètre
paramètres peuvent être conservés entre les emplois et mai
potentiellement constituer une menace pour le bon fonctionnement de
l'interprète. Les opérateurs PostScript qui établissent
les paramètres du système et dispositif comprennent, mais ne peuvent pas être
limiter, le "setsystemparams" et "setdevparams"
opérateurs. logiciel d'envoi de message ne doit pas
générer PostScript qui dépend du réglage de
les paramètres du système ou d'un dispositif de fonctionner correctement. Le
possibilité de définir ces paramètres sera probablement
disponible dans les implémentations PostScript sécurisés.
Et recevant des messages affichant logiciel devrait
désactiver la possibilité de changer le système et le périphérique
paramètres. Si ces opérateurs ne peuvent pas être complètement
désactivé le mot de passe associé doivent à
moins être réglé à une valeur difficile à deviner.
opérateurs. logiciel d'envoi de message ne doit pas
générer PostScript qui dépend du réglage de
les paramètres du système ou d'un dispositif de fonctionner correctement. Le
possibilité de définir ces paramètres sera probablement
disponible dans les implémentations PostScript sécurisés.
Et recevant des messages affichant logiciel devrait
désactiver la possibilité de changer le système et le périphérique
paramètres. Si ces opérateurs ne peuvent pas être complètement
désactivé le mot de passe associé doivent à
moins être réglé à une valeur difficile à deviner.
(4) Certaines implémentations PostScript fournissent non standard
installations pour le chargement et l'exécution directe des
code machine. Ces installations sont bien évidemment ouvrir
à des abus considérables. logiciel d'envoi de message devrait
pas faire usage de telles caractéristiques. En plus d'être totalement
matériel spécifique, ils sont aussi susceptibles d'être
disponible dans les implémentations sécurisées de PostScript.
Logiciel de réception et l'affichage de message ne doit pas
permettent à ces opérateurs d'être utilisées si elles existent.
installations pour le chargement et l'exécution directe des
code machine. Ces installations sont bien évidemment ouvrir
à des abus considérables. logiciel d'envoi de message devrait
pas faire usage de telles caractéristiques. En plus d'être totalement
matériel spécifique, ils sont aussi susceptibles d'être
disponible dans les implémentations sécurisées de PostScript.
Logiciel de réception et l'affichage de message ne doit pas
permettent à ces opérateurs d'être utilisées si elles existent.
(5) PostScript est un langage extensible, et beaucoup, si ce n'est
plus, les implémentations de lui fournir un certain nombre de leurs
propres extensions. Ce document ne traite pas de tels
extensions explicitement car ils constituent une inconnue
facteur. logiciel d'envoi de message ne doit pas faire usage
des extensions non standard, ils sont susceptibles d'être
manquant dans certaines implémentations. Réception de message
Les logiciels affichant et doit s'assurer que toute
opérateurs PostScript non standard sont sécurisés et ne sont pas
présenter toute sorte de menace.
plus, les implémentations de lui fournir un certain nombre de leurs
propres extensions. Ce document ne traite pas de tels
extensions explicitement car ils constituent une inconnue
facteur. logiciel d'envoi de message ne doit pas faire usage
des extensions non standard, ils sont susceptibles d'être
manquant dans certaines implémentations. Réception de message
Les logiciels affichant et doit s'assurer que toute
opérateurs PostScript non standard sont sécurisés et ne sont pas
présenter toute sorte de menace.
(6) Il est possible d'écrire PostScript qui consomme énorme
différentes quantités de ressources système. Il est également
possible d'écrire des programmes PostScript qui boucle
indéfiniment. Ces deux types de programmes ont la
potentiel de causer des dommages si elle est envoyée à méfiants
destinataires. Logiciel d'envoi de message devrait éviter l'
la construction et la diffusion de ces programmes, qui
est antisocial. Recevoir et afficher des messages
logiciel devrait prévoir des mécanismes appropriés pour annuler
traitement après un certain laps de temps raisonnable
écoulé. En outre, les interprètes PostScript doivent être
limité à la seule consommation d'une quantité raisonnable
d'une ressource de système donné.
différentes quantités de ressources système. Il est également
possible d'écrire des programmes PostScript qui boucle
indéfiniment. Ces deux types de programmes ont la
potentiel de causer des dommages si elle est envoyée à méfiants
destinataires. Logiciel d'envoi de message devrait éviter l'
la construction et la diffusion de ces programmes, qui
est antisocial. Recevoir et afficher des messages
logiciel devrait prévoir des mécanismes appropriés pour annuler
traitement après un certain laps de temps raisonnable
écoulé. En outre, les interprètes PostScript doivent être
limité à la seule consommation d'une quantité raisonnable
d'une ressource de système donné.
(7) Il est possible d'inclure des informations binaires première à l'intérieur
PostScript sous diverses formes. Ce n'est pas recommandé
pour une utilisation dans le courrier Internet, à la fois parce qu'il n'est pas
soutenu par tous les interprètes PostScript et parce qu'il
complique considérablement l'utilisation d'un contenu MIME
Transfer-Encoding. (Sans une telle binaire, PostScript
peut généralement être considérée comme ligne de données orientées. Le
traitement de séquences CRLF devient extrêmement
problématique si des données binaires et orienté ligne sont mélangées
en un seul flux de données postscript.)
PostScript sous diverses formes. Ce n'est pas recommandé
pour une utilisation dans le courrier Internet, à la fois parce qu'il n'est pas
soutenu par tous les interprètes PostScript et parce qu'il
complique considérablement l'utilisation d'un contenu MIME
Transfer-Encoding. (Sans une telle binaire, PostScript
peut généralement être considérée comme ligne de données orientées. Le
traitement de séquences CRLF devient extrêmement
problématique si des données binaires et orienté ligne sont mélangées
en un seul flux de données postscript.)
(8) Enfin, des bugs peuvent exister dans certains interprètes PostScript
qui pourrait être exploitée afin de gagner non autorisée
accéder au système d'un destinataire. En plus de souligner cette
possibilité, il n'ya pas de mesures spécifiques à prendre pour
éviter cela, en dehors de la correction en temps opportun d'une telle
les bugs éventuels sont trouvés.
qui pourrait être exploitée afin de gagner non autorisée
accéder au système d'un destinataire. En plus de souligner cette
possibilité, il n'ya pas de mesures spécifiques à prendre pour
éviter cela, en dehors de la correction en temps opportun d'une telle
les bugs éventuels sont trouvés.
4.5.3. D'autres sous-types d'applications
Il est prévu que d'autres sous-types de «demande» seront
défini dans l'avenir. Implémentations MIME doit être au minimum un régal
les sous-types non reconnus comme équivalent à "application/octet-
flux ".
défini dans l'avenir. Implémentations MIME doit être au minimum un régal
les sous-types non reconnus comme équivalent à "application/octet-
flux ".
5. Composite Type de support valeurs
Les deux autres des sept valeurs initiales Content-Type se réfèrent à
entités composites. Entités composites sont traitées en utilisant MIME
mécanismes - un processeur MIME gère généralement le corps directement.
entités composites. Entités composites sont traitées en utilisant MIME
mécanismes - un processeur MIME gère généralement le corps directement.
5.1. Multipart Type de support
Dans le cas des entités en plusieurs parties, dans lequel un ou plusieurs différent
des ensembles de données sont combinés en un corps unique, un type de support "en plusieurs"
champ doit apparaître dans l'en-tête de l'entité. Le corps doit alors contenir
une ou plusieurs parties du corps, chacune précédée d'une ligne de marquage de frontière,
et la dernière, suivie par une ligne de marquage de frontière de fermeture.
Après sa ligne de marquage de frontière, chaque partie du corps est alors constitué d'un
la zone d'en-tête, une ligne vide, et une zone de corps. Ainsi, une partie du corps est
semblable à un 822 RFC message dans la syntaxe, mais différent de sens.
des ensembles de données sont combinés en un corps unique, un type de support "en plusieurs"
champ doit apparaître dans l'en-tête de l'entité. Le corps doit alors contenir
une ou plusieurs parties du corps, chacune précédée d'une ligne de marquage de frontière,
et la dernière, suivie par une ligne de marquage de frontière de fermeture.
Après sa ligne de marquage de frontière, chaque partie du corps est alors constitué d'un
la zone d'en-tête, une ligne vide, et une zone de corps. Ainsi, une partie du corps est
semblable à un 822 RFC message dans la syntaxe, mais différent de sens.
Une partie du corps est une entité et n'est donc pas être interprétée comme
effectivement être un 822 RFC message. Pour commencer, pas de champs d'en-tête
sont en fait nécessaires dans les parties du corps. Une partie du corps qui commence par un
ligne vide, par conséquent, est accueilli et est une partie du corps dont la totalité
Les valeurs par défaut doivent être pris en charge. Dans un tel cas, l'absence de
En-tête Content-Type indique généralement que le corps correspondant a
effectivement être un 822 RFC message. Pour commencer, pas de champs d'en-tête
sont en fait nécessaires dans les parties du corps. Une partie du corps qui commence par un
ligne vide, par conséquent, est accueilli et est une partie du corps dont la totalité
Les valeurs par défaut doivent être pris en charge. Dans un tel cas, l'absence de
En-tête Content-Type indique généralement que le corps correspondant a
un type de contenu «text / plain; charset = US-ASCII".
Les seuls champs d'en-tête qui ont défini ce qui signifie pour les parties du corps sont
ces dont les noms commencent par "Content-". Tout autre tête
champs peuvent être ignorés dans les parties du corps. Bien qu'ils ne devraient généralement
être conservé autant que possible, ils peuvent être éliminés par des passerelles si
nécessaire. Les autres domaines sont autorisés à apparaître dans les parties du corps
mais ne doit pas être dépendait. "X-" champs peuvent être créés pour
des fins expérimentales ou privées, avec la reconnaissance que l'
informations qu'ils contiennent peuvent être perdues à certaines passerelles.
ces dont les noms commencent par "Content-". Tout autre tête
champs peuvent être ignorés dans les parties du corps. Bien qu'ils ne devraient généralement
être conservé autant que possible, ils peuvent être éliminés par des passerelles si
nécessaire. Les autres domaines sont autorisés à apparaître dans les parties du corps
mais ne doit pas être dépendait. "X-" champs peuvent être créés pour
des fins expérimentales ou privées, avec la reconnaissance que l'
informations qu'ils contiennent peuvent être perdues à certaines passerelles.
Remarque: La distinction entre une 822 RFC message et une partie du corps est
subtile, mais importante. Une passerelle entre Internet et courrier X.400,
par exemple, doit être en mesure de faire la différence entre une partie du corps
qui contient une image et une partie du corps qui contient un encapsulée
message, dont le corps est une image JPEG. Afin de représenter
celui-ci, la partie du corps doit avoir "Content-Type: message/rfc822»,
et de son corps (après la ligne blanche) doit être le message encapsulé,
avec sa propre "Content-Type: image / jpeg" champ d'en-tête. L'utilisation d'
syntaxe similaire facilite la conversion des messages à des parties du corps,
et vice versa, mais la distinction entre les deux doivent être
compris par des réalisateurs. (Pour le cas particulier dans lequel les parties
sont en réalité des messages, un sous-type "digest" est également définie.)
subtile, mais importante. Une passerelle entre Internet et courrier X.400,
par exemple, doit être en mesure de faire la différence entre une partie du corps
qui contient une image et une partie du corps qui contient un encapsulée
message, dont le corps est une image JPEG. Afin de représenter
celui-ci, la partie du corps doit avoir "Content-Type: message/rfc822»,
et de son corps (après la ligne blanche) doit être le message encapsulé,
avec sa propre "Content-Type: image / jpeg" champ d'en-tête. L'utilisation d'
syntaxe similaire facilite la conversion des messages à des parties du corps,
et vice versa, mais la distinction entre les deux doivent être
compris par des réalisateurs. (Pour le cas particulier dans lequel les parties
sont en réalité des messages, un sous-type "digest" est également définie.)
Comme indiqué précédemment, chaque partie du corps est précédée par une frontière
délimiteur de ligne qui contient le marquage de frontière. La frontière
delimiter NE DOIT PAS apparaître à l'intérieur de l'une des parties encapsulées, sur un
La ligne elle-même ou en tant que préfixe d'une ligne. Cela implique qu'il est
crucial que l'agent composer pouvoir choisir et spécifier un
la valeur du paramètre de limite unique, qui ne contient pas la limite
valeur de paramètre d'un en plusieurs parties entourant comme préfixe.
délimiteur de ligne qui contient le marquage de frontière. La frontière
delimiter NE DOIT PAS apparaître à l'intérieur de l'une des parties encapsulées, sur un
La ligne elle-même ou en tant que préfixe d'une ligne. Cela implique qu'il est
crucial que l'agent composer pouvoir choisir et spécifier un
la valeur du paramètre de limite unique, qui ne contient pas la limite
valeur de paramètre d'un en plusieurs parties entourant comme préfixe.
Tous les sous-types actuels et futurs du type "multipart" doivent utiliser une
une syntaxe identique. Les sous-types peuvent différer dans leur sémantique, et peut
imposer des restrictions supplémentaires sur la syntaxe, mais doivent se conformer à la
nécessaire syntaxe du type "multipart". Cette exigence garantit
que tous les agents utilisateurs conformes seront au moins être capable de reconnaître
et séparer les parties d'une entité en plusieurs parties, même celles d'un
sous-type non reconnu.
une syntaxe identique. Les sous-types peuvent différer dans leur sémantique, et peut
imposer des restrictions supplémentaires sur la syntaxe, mais doivent se conformer à la
nécessaire syntaxe du type "multipart". Cette exigence garantit
que tous les agents utilisateurs conformes seront au moins être capable de reconnaître
et séparer les parties d'une entité en plusieurs parties, même celles d'un
sous-type non reconnu.
Comme indiqué dans la définition du champ Content-Transfer-Encoding
[ RFC 2045 ], aucun encodage autre que "7bit", "8bit" ou "binary" est
autorisée pour les entités de type "multipart". La frontière "multipart"
séparateurs et les champs d'en-tête sont toujours représentés comme 7bit US-ASCII
dans tous les cas (même si les champs d'en-tête peuvent coder en-tête non-US-ASCII
texte selon RFC 2047 ) et les données à l'intérieur des parties du corps peuvent être codés
sur une base partie par partie, avec des champs Content-Transfer-Encoding pour
chaque partie du corps appropriée.
[ RFC 2045 ], aucun encodage autre que "7bit", "8bit" ou "binary" est
autorisée pour les entités de type "multipart". La frontière "multipart"
séparateurs et les champs d'en-tête sont toujours représentés comme 7bit US-ASCII
dans tous les cas (même si les champs d'en-tête peuvent coder en-tête non-US-ASCII
texte selon RFC 2047 ) et les données à l'intérieur des parties du corps peuvent être codés
sur une base partie par partie, avec des champs Content-Transfer-Encoding pour
chaque partie du corps appropriée.
5.1.1. Syntaxe commune
Cette section définit une syntaxe commune pour les sous-types de "multipart".
Tous les sous-types de "multipart" doivent utiliser cette syntaxe. Un exemple simple
d'un message multipart apparaît également dans cette section. Un exemple d'une
message multipart plus complexe est donnée dans la RFC 2049 .
Tous les sous-types de "multipart" doivent utiliser cette syntaxe. Un exemple simple
d'un message multipart apparaît également dans cette section. Un exemple d'une
message multipart plus complexe est donnée dans la RFC 2049 .
Le champ Content-Type en plusieurs parties pour les entités nécessite un paramètre,
«Frontière». La ligne de marquage de frontière est alors définie comme une ligne
entièrement composé de deux traits d'union ("-", la valeur décimale 45)
suivi de la valeur du paramètre de limite à partir de l'en-tête Content-Type
terrain, les espaces linéaire en option, et un CRLF de terminaison.
«Frontière». La ligne de marquage de frontière est alors définie comme une ligne
entièrement composé de deux traits d'union ("-", la valeur décimale 45)
suivi de la valeur du paramètre de limite à partir de l'en-tête Content-Type
terrain, les espaces linéaire en option, et un CRLF de terminaison.
NOTE: Les traits d'union sont pour la compatibilité rude avec le plus tôt RFC
934 méthode d'encapsulation un message, et pour faciliter la recherche d'
les limites dans certaines implémentations. Toutefois, il convient de noter
que les messages en plusieurs parties ne sont pas complètement compatible avec RFC 934
encapsulations, en particulier, ils ne respectent pas la RFC 934 guillemets
conventions pour les lignes intégrées qui commencent par un trait d'union. Cette
mécanisme a été choisi sur la RFC 934 mécanisme parce que celui-ci
provoque des lignes de croître à chaque niveau de citer. La combinaison de
cette croissance avec le fait que les implémentations SMTP enveloppent parfois
longues lignes faites la RFC 934 mécanisme impropre à l'usage en cas
que la structuration multipart profondément imbriqué est toujours souhaitée.
934 méthode d'encapsulation un message, et pour faciliter la recherche d'
les limites dans certaines implémentations. Toutefois, il convient de noter
que les messages en plusieurs parties ne sont pas complètement compatible avec RFC 934
encapsulations, en particulier, ils ne respectent pas la RFC 934 guillemets
conventions pour les lignes intégrées qui commencent par un trait d'union. Cette
mécanisme a été choisi sur la RFC 934 mécanisme parce que celui-ci
provoque des lignes de croître à chaque niveau de citer. La combinaison de
cette croissance avec le fait que les implémentations SMTP enveloppent parfois
longues lignes faites la RFC 934 mécanisme impropre à l'usage en cas
que la structuration multipart profondément imbriqué est toujours souhaitée.
AVERTISSEMENT POUR implémenteurs: La grammaire des paramètres sur le contenu
champ de type est telle qu'il est souvent nécessaire d'entourer la limite
valeurs de paramètres entre guillemets sur la ligne Content-Type. Ce n'est pas
toujours nécessaire, mais n'a jamais fait mal. Les développeurs devraient être sûr d'
étudier soigneusement la grammaire afin d'éviter de produire invalide
Champs Content-Type. Ainsi, un en-tête Content-Type "multipart" typique
domaine pourrait ressembler à ceci:
champ de type est telle qu'il est souvent nécessaire d'entourer la limite
valeurs de paramètres entre guillemets sur la ligne Content-Type. Ce n'est pas
toujours nécessaire, mais n'a jamais fait mal. Les développeurs devraient être sûr d'
étudier soigneusement la grammaire afin d'éviter de produire invalide
Champs Content-Type. Ainsi, un en-tête Content-Type "multipart" typique
domaine pourrait ressembler à ceci:
Content-Type: multipart / mixed; boundary = gc0p4Jq0M2Yt08j34c0p
Mais ce qui suit n'est pas valide:
Content-Type: multipart / mixed; boundary = gc0pJq0M: 08jU534c0p
(En raison du côlon) et doit plutôt être représentée comme
Content-Type: multipart / mixed; boundary = "gc0pJq0M: 08jU534c0p"
Cette valeur Content-Type indique que le contenu consiste en une ou
plusieurs parties, chacune avec une structure qui est syntaxiquement identique à
un RFC 822 message, sauf que la zone d'en-tête est autorisée à être
complètement vide, et que les parties sont chacune précédées par la ligne
plusieurs parties, chacune avec une structure qui est syntaxiquement identique à
un RFC 822 message, sauf que la zone d'en-tête est autorisée à être
complètement vide, et que les parties sont chacune précédées par la ligne
- Gc0pJq0M: 08jU534c0p
La limite delimiter doit avoir lieu au début d'une ligne, c'est-à-
suite à un CRLF, et le CRLF initial est considérée comme étant fixée
à la frontière délimiteur plutôt qu'une partie de ce qui précède
partie. La frontière peut être suivie par zéro ou plusieurs caractères d'
linéaire des espaces. Il est alors résiliée par un autre CRLF et
les champs d'en-tête pour la partie suivante, ou par deux CRLF, auquel cas
il n'y a pas de champs d'en-tête pour la partie suivante. Si aucun Content-Type
champ est présente, elle est supposée être "message/rfc822" dans un
"Multipart / digest" et "text / plain" autrement.
suite à un CRLF, et le CRLF initial est considérée comme étant fixée
à la frontière délimiteur plutôt qu'une partie de ce qui précède
partie. La frontière peut être suivie par zéro ou plusieurs caractères d'
linéaire des espaces. Il est alors résiliée par un autre CRLF et
les champs d'en-tête pour la partie suivante, ou par deux CRLF, auquel cas
il n'y a pas de champs d'en-tête pour la partie suivante. Si aucun Content-Type
champ est présente, elle est supposée être "message/rfc822" dans un
"Multipart / digest" et "text / plain" autrement.
NOTE: Le CRLF qui précède la ligne de marquage de frontière est conceptuellement
fixée à la limite de sorte qu'il est possible d'avoir une partie qui
ne se termine pas par un CRLF (saut de ligne). parties du corps qui doivent être
considéré à la fin avec des sauts de ligne, donc, doit avoir deux CRLFs
précédant la ligne de marquage de frontière, le premier d'entre eux fait partie d'
la partie du corps précédente, et dont la seconde est une partie de l'
limite d'encapsulation.
fixée à la limite de sorte qu'il est possible d'avoir une partie qui
ne se termine pas par un CRLF (saut de ligne). parties du corps qui doivent être
considéré à la fin avec des sauts de ligne, donc, doit avoir deux CRLFs
précédant la ligne de marquage de frontière, le premier d'entre eux fait partie d'
la partie du corps précédente, et dont la seconde est une partie de l'
limite d'encapsulation.
séparateurs de limites ne doivent pas apparaître dans le matériau encapsulé,
et doit pas dépasser 70 caractères, sans compter les deux
menant des traits d'union.
et doit pas dépasser 70 caractères, sans compter les deux
menant des traits d'union.
La ligne de marquage de frontière à la suite de la dernière partie du corps est un
distingué delimiter qui indique qu'aucune autre partie du corps
suivra. Une telle ligne de marquage est identique à la précédente
lignes séparateur, avec l'ajout de deux traits d'union après la
la valeur du paramètre de limite.
distingué delimiter qui indique qu'aucune autre partie du corps
suivra. Une telle ligne de marquage est identique à la précédente
lignes séparateur, avec l'ajout de deux traits d'union après la
la valeur du paramètre de limite.
- Gc0pJq0M: 08jU534c0p -
NOTE AUX implémenteurs: les comparaisons de chaînes de délimitation doivent comparer l'
valeur limite au début de chaque ligne candidate. Un exacte
correspond de toute la ligne de candidat n'est pas nécessaire, il suffit
que la frontière apparaît dans son intégralité après le CRLF.
valeur limite au début de chaque ligne candidate. Un exacte
correspond de toute la ligne de candidat n'est pas nécessaire, il suffit
que la frontière apparaît dans son intégralité après le CRLF.
Il semble y avoir de la place pour plus d'informations avant l'
première ligne de marquage de frontière et en suivant la limite finale
la ligne de délimitation. Ces zones doivent généralement être laissée vide, et
implémentations doivent ignorer tout ce qui apparaît avant le premier
limite délimiteur de ligne ou après la dernière.
première ligne de marquage de frontière et en suivant la limite finale
la ligne de délimitation. Ces zones doivent généralement être laissée vide, et
implémentations doivent ignorer tout ce qui apparaît avant le premier
limite délimiteur de ligne ou après la dernière.
NOTE: Ce «préambule» et les zones «épilogue» ne sont généralement pas utilisés
en raison de l'absence de typage correct de ces pièces et le manque de
sémantique claire pour traiter ces domaines au niveau des passerelles, en particulier
Passerelles X.400. Cependant, plutôt que de quitter la zone de préambule
vierge, de nombreuses implémentations MIME ont trouvé que cela soit une pratique
en raison de l'absence de typage correct de ces pièces et le manque de
sémantique claire pour traiter ces domaines au niveau des passerelles, en particulier
Passerelles X.400. Cependant, plutôt que de quitter la zone de préambule
vierge, de nombreuses implémentations MIME ont trouvé que cela soit une pratique
endroit pour insérer une note explicative pour les bénéficiaires qui ont lu l'
message avec logiciels pré-MIME, puisque ces notes sera ignoré par
Logiciel compatible MIME.
message avec logiciels pré-MIME, puisque ces notes sera ignoré par
Logiciel compatible MIME.
NOTE: En raison des séparateurs de limites ne doivent pas apparaître dans les parties du corps
étant encapsulé, un agent utilisateur doit faire preuve de prudence pour choisir un
la valeur du paramètre de limite unique. La valeur du paramètre de limite à l'
exemple ci-dessus aurait pu être le résultat d'un algorithme conçu pour
produire des séparateurs de frontière avec une très faible probabilité de déjà
existant dans les données à encapsuler sans avoir à scrutation Le
données. Algorithmes sur deux pourrait entraîner plus de limite "lisible"
séparateurs pour un bénéficiaire avec un agent d'utilisateur vieux, mais exigerait
plus d'attention à la possibilité que le séparateur limite pourrait
apparaître au début d'une certaine ligne dans la partie encapsulée. Le
simple ligne de marquage de frontière possible est quelque chose comme "---",
avec une limite de ligne de marquage de clôture de «-----».
étant encapsulé, un agent utilisateur doit faire preuve de prudence pour choisir un
la valeur du paramètre de limite unique. La valeur du paramètre de limite à l'
exemple ci-dessus aurait pu être le résultat d'un algorithme conçu pour
produire des séparateurs de frontière avec une très faible probabilité de déjà
existant dans les données à encapsuler sans avoir à scrutation Le
données. Algorithmes sur deux pourrait entraîner plus de limite "lisible"
séparateurs pour un bénéficiaire avec un agent d'utilisateur vieux, mais exigerait
plus d'attention à la possibilité que le séparateur limite pourrait
apparaître au début d'une certaine ligne dans la partie encapsulée. Le
simple ligne de marquage de frontière possible est quelque chose comme "---",
avec une limite de ligne de marquage de clôture de «-----».
Comme un exemple très simple, le message multipart suivant a deux
parties, deux d'entre eux texte brut, l'un d'eux explicitement typé et une
d'entre eux implicitement typé:
parties, deux d'entre eux texte brut, l'un d'eux explicitement typé et une
d'entre eux implicitement typé:
De: Nathaniel Borenstein < nsb@bellcore.com >
Pour: Ned Freed < ned@innosoft.com >
Date: Sun, 21 mars 1993 23:56:48 -0800 (PST)
Sujet: Exemple de message
MIME-Version: 1.0
Content-Type: multipart / mixed; boundary = "simples frontière"
Pour: Ned Freed < ned@innosoft.com >
Date: Sun, 21 mars 1993 23:56:48 -0800 (PST)
Sujet: Exemple de message
MIME-Version: 1.0
Content-Type: multipart / mixed; boundary = "simples frontière"
C'est le préambule. Il doit être ignorée, même si elle
est un endroit pratique pour les agents de la composition pour y inclure une
note explicative aux lecteurs non-conforme MIME.
est un endroit pratique pour les agents de la composition pour y inclure une
note explicative aux lecteurs non-conforme MIME.
- Simple frontière
Ceci est typée implicitement texte brut US-ASCII.
Il ne s'arrête pas à un retour à la ligne.
- Simple frontière
Content-Type: text / plain; charset = us-ascii
Il ne s'arrête pas à un retour à la ligne.
- Simple frontière
Content-Type: text / plain; charset = us-ascii
Cela est explicitement typé texte brut US-ASCII.
Il ne se terminent par un retour à la ligne.
Il ne se terminent par un retour à la ligne.
- Simple frontière -
C'est l'épilogue. C'est aussi pour être ignoré.
L'utilisation d'un support de type "en plusieurs" dans une partie du corps à l'intérieur de l'autre
Entité "multipart" est explicitement autorisé. Dans de tels cas, pour des raisons évidentes
raisons, il faut veiller à ce que chaque imbriqué "multipart"
entité utilise un marquage de frontière différente. Voir RFC 2049 pour une
exemple des entités imbriquées "multipart".
Entité "multipart" est explicitement autorisé. Dans de tels cas, pour des raisons évidentes
raisons, il faut veiller à ce que chaque imbriqué "multipart"
entité utilise un marquage de frontière différente. Voir RFC 2049 pour une
exemple des entités imbriquées "multipart".
L'utilisation du type de support "en plusieurs" avec seulement une seule partie du corps
peut être utile dans certains contextes, et est explicitement autorisé.
peut être utile dans certains contextes, et est explicitement autorisé.
NOTE: L'expérience a montré qu'une "multipart" type de support avec un
seule partie du corps est utile pour envoyer des types de médias non textuels. Il a
l'avantage de fournir le préambule comme un lieu d'inclure
décoder des instructions. En outre, un certain nombre de passerelles SMTP déplacer
ou supprimer les en-têtes MIME, et un décodeur MIME intelligent peut prendre un bon
deviner limites multipart même en l'absence du Content-Type
tête et de ce fait décoder avec succès le message.
seule partie du corps est utile pour envoyer des types de médias non textuels. Il a
l'avantage de fournir le préambule comme un lieu d'inclure
décoder des instructions. En outre, un certain nombre de passerelles SMTP déplacer
ou supprimer les en-têtes MIME, et un décodeur MIME intelligent peut prendre un bon
deviner limites multipart même en l'absence du Content-Type
tête et de ce fait décoder avec succès le message.
Le paramètre global n'est obligatoire que pour le type de média "multipart" est
le paramètre de limite, qui est constitué de 1 à 70 caractères à partir d'une
ensemble de caractères connus pour être très robuste grâce à des passerelles de messagerie et
Ne se termine pas avec l'espace blanc. (Si une ligne de marquage de frontière semble
fin avec l'espace blanc, l'espace blanc doit être présumé avoir été
ajoutée par une passerelle, et doit être supprimé.) Il est formellement spécifié
par le BNF suivant:
le paramètre de limite, qui est constitué de 1 à 70 caractères à partir d'une
ensemble de caractères connus pour être très robuste grâce à des passerelles de messagerie et
Ne se termine pas avec l'espace blanc. (Si une ligne de marquage de frontière semble
fin avec l'espace blanc, l'espace blanc doit être présumé avoir été
ajoutée par une passerelle, et doit être supprimé.) Il est formellement spécifié
par le BNF suivant:
limite: = 0 * 69 <bchars> bcharsnospace
bchars: = bcharsnospace / ""
bcharsnospace: = DIGIT / ALPHA / "" "/" ("/") "/
"+" / "_" / "," / "-" "." / /
"/" / ":" / "=" / "?"
"+" / "_" / "," / "-" "." / /
"/" / ":" / "=" / "?"
Dans l'ensemble, le corps d'une entité "multipart" peut être spécifié comme
suit:
suit:
tableau de bord: = "-" limite
; Frontière pris à partir de la valeur de
; Paramètre de limite de l'
; Champ Content-Type.
; Frontière pris à partir de la valeur de
; Paramètre de limite de l'
; Champ Content-Type.
multipart-corps: = [préambule CRLF]
tableau de bord transport rembourrage CRLF
partie du corps * encapsulation
gros delimiter transport rembourrage
[CRLF épilogue]
tableau de bord transport rembourrage CRLF
partie du corps * encapsulation
gros delimiter transport rembourrage
[CRLF épilogue]
transport padding: = * caractère LWSP
; Compositeurs NE DOIVENT PAS générer
, Le transport de longueur non nulle
, Rembourrage, mais les récepteurs doivent
; Être capable de gérer rembourrage
, Ajouté par les transports de message.
; Compositeurs NE DOIVENT PAS générer
, Le transport de longueur non nulle
, Rembourrage, mais les récepteurs doivent
; Être capable de gérer rembourrage
, Ajouté par les transports de message.
encapsulation: = delimiter transport rembourrage
CRLF partie du corps
CRLF partie du corps
delimiter: = CRLF tableau de bord
gros delimiter: = séparateur «-»
Préambule: = discard-texte
Epilogue: = discard-texte
discard-texte: = * (* texte CRLF) * Texte
, Peuvent être ignorés ou rejetés.
, Peuvent être ignorés ou rejetés.
partie du corps: = MIME-part-en-têtes [CRLF * OCTET]
, Les lignes dans une partie du corps ne doivent pas commencer
, Avec le tableau de bord spécifique et
, Le séparateur ne doit pas apparaître n'importe où
, Dans la partie du corps. Notez que l'
; Sémantique d'une partie du corps diffèrent d'
; La sémantique d'un message, que
, Décrite dans le texte.
, Les lignes dans une partie du corps ne doivent pas commencer
, Avec le tableau de bord spécifique et
, Le séparateur ne doit pas apparaître n'importe où
, Dans la partie du corps. Notez que l'
; Sémantique d'une partie du corps diffèrent d'
; La sémantique d'un message, que
, Décrite dans le texte.
OCTET: = <any 0-255 octet value>
IMPORTANT: L'insertion libre de linéaire-white-space et RFC 822
commentaires entre les éléments figurant dans ce BNF ne sont PAS permis depuis
cette BNF ne spécifie pas un champ d'en-tête structuré.
commentaires entre les éléments figurant dans ce BNF ne sont PAS permis depuis
cette BNF ne spécifie pas un champ d'en-tête structuré.
Note: Dans certaines enclaves de transport, RFC 822 restrictions telles que
celui qui limite les organismes à caractères US-ASCII imprimables ne peut
être en vigueur. (Autrement dit, les domaines de transport peuvent exister qui ressemblent
transport de messagerie Internet standard tel que spécifié dans la RFC 821 et assumé
par la RFC 822 , mais sans certaines restrictions). L'assouplissement des
ces restrictions doivent être interprétées comme s'étendant localement l'
définition d'organes, par exemple pour y inclure octets hors de l'
Plage US-ASCII, aussi longtemps que ces extensions sont pris en charge par le
transporter et suffisamment documentées dans le Content-Transfer-Encoding
champ d'en-tête. Cependant, en aucun cas, sont têtes (soit un message
têtes ou les en-têtes de partie du corps) a permis de contenir autre chose que
Caractères US-ASCII.
celui qui limite les organismes à caractères US-ASCII imprimables ne peut
être en vigueur. (Autrement dit, les domaines de transport peuvent exister qui ressemblent
transport de messagerie Internet standard tel que spécifié dans la RFC 821 et assumé
par la RFC 822 , mais sans certaines restrictions). L'assouplissement des
ces restrictions doivent être interprétées comme s'étendant localement l'
définition d'organes, par exemple pour y inclure octets hors de l'
Plage US-ASCII, aussi longtemps que ces extensions sont pris en charge par le
transporter et suffisamment documentées dans le Content-Transfer-Encoding
champ d'en-tête. Cependant, en aucun cas, sont têtes (soit un message
têtes ou les en-têtes de partie du corps) a permis de contenir autre chose que
Caractères US-ASCII.
NOTE: Remarquablement absent de type "multipart" est une notion de
, les parties du corps liées structurés. Il est recommandé que ceux qui souhaitent
pour communiquer des messages multipart plus structurée ou intégrée
les installations devraient définir des sous-types de multipart qui sont syntaxiquement
identique, mais de définir les relations entre les différentes parties. Pour
par exemple, sous-types de multipart pourrait être définie qui incluent une
part distingué qui à son tour est utilisé pour spécifier les relations
entre les autres parties, en se référant probablement par leur
Champ Content-ID. Vieux implémentations ne reconnaissent pas le nouveau
sous-type si cette approche est utilisée, mais le traiter comme
multipart / mixed et sera donc en mesure de montrer à l'utilisateur les parties qui
sont reconnus.
, les parties du corps liées structurés. Il est recommandé que ceux qui souhaitent
pour communiquer des messages multipart plus structurée ou intégrée
les installations devraient définir des sous-types de multipart qui sont syntaxiquement
identique, mais de définir les relations entre les différentes parties. Pour
par exemple, sous-types de multipart pourrait être définie qui incluent une
part distingué qui à son tour est utilisé pour spécifier les relations
entre les autres parties, en se référant probablement par leur
Champ Content-ID. Vieux implémentations ne reconnaissent pas le nouveau
sous-type si cette approche est utilisée, mais le traiter comme
multipart / mixed et sera donc en mesure de montrer à l'utilisateur les parties qui
sont reconnus.
5.1.2. Gestion des messages et Multiparts imbriquées
Le sous-type "message/rfc822" défini dans une section ultérieure du présent
document n'a pas de condition de terminaison autre que de manquer de données.
De même, une entité "multipart" mal tronquée ne peut pas avoir
n'importe quel marqueur de limite de terminaison, et peut tourner jusqu'à opérationnel en raison d'
courrier des dysfonctionnements du système.
document n'a pas de condition de terminaison autre que de manquer de données.
De même, une entité "multipart" mal tronquée ne peut pas avoir
n'importe quel marqueur de limite de terminaison, et peut tourner jusqu'à opérationnel en raison d'
courrier des dysfonctionnements du système.
Il est essentiel que ces entités soient traitées correctement quand ils sont
eux-mêmes noyées à l'intérieur d'une autre structure "multipart". MIME
implémentations sont donc tenus de reconnaître niveau externe
bornage à n'importe quel niveau de nidification intérieure. Il ne suffit pas
pour vérifier que le marqueur attendu prochain ou autre terminaison
état.
eux-mêmes noyées à l'intérieur d'une autre structure "multipart". MIME
implémentations sont donc tenus de reconnaître niveau externe
bornage à n'importe quel niveau de nidification intérieure. Il ne suffit pas
pour vérifier que le marqueur attendu prochain ou autre terminaison
état.
5.1.3. Sous mixte
Le sous-type "mixte" de "multipart" est destiné à être utilisé lorsque le corps
parties sont indépendants et doivent être regroupés dans un ordre particulier.
Tous les sous-types "multipart" qu'une mise en œuvre ne reconnaît pas
doivent être traités comme étant de sous-type «mixte».
parties sont indépendants et doivent être regroupés dans un ordre particulier.
Tous les sous-types "multipart" qu'une mise en œuvre ne reconnaît pas
doivent être traités comme étant de sous-type «mixte».
5.1.4. Sous Alternative
Le type "multipart / alternative" est syntaxiquement identique à
"Multipart / mixed", mais la sémantique est différente. En particulier,
chacune des parties du corps est une version "alternatif" de la même
informations.
"Multipart / mixed", mais la sémantique est différente. En particulier,
chacune des parties du corps est une version "alternatif" de la même
informations.
Les systèmes doivent reconnaître que le contenu des différentes parties sont
interchangeables. Les systèmes doivent choisir le "meilleur" type basé sur la
environnement et des références locales, dans certains cas, même à travers utilisateur
interaction. Comme avec "multipart / mixed", l'ordre des parties du corps est
significative. Dans ce cas, les alternatives apparaissent dans un ordre de
fidélité croissante au contenu original. En général, l'
interchangeables. Les systèmes doivent choisir le "meilleur" type basé sur la
environnement et des références locales, dans certains cas, même à travers utilisateur
interaction. Comme avec "multipart / mixed", l'ordre des parties du corps est
significative. Dans ce cas, les alternatives apparaissent dans un ordre de
fidélité croissante au contenu original. En général, l'
meilleur choix est la dernière partie d'un type pris en charge par le destinataire
l'environnement local de système.
l'environnement local de système.
"Multipart / alternative" peut être utilisé, par exemple, pour envoyer un message
dans un format de texte de fantaisie, de telle façon qu'il puisse facilement être affichée
n'importe où:
dans un format de texte de fantaisie, de telle façon qu'il puisse facilement être affichée
n'importe où:
De: Nathaniel Borenstein < nsb@bellcore.com >
Pour: Ned Freed < ned@innosoft.com >
Date: Mon, 22 mars 1993 09:41:09 -0800 (PST)
Sujet: messagerie texte formaté
MIME-Version: 1.0
Content-Type: multipart / alternative; boundary = boundary42
Pour: Ned Freed < ned@innosoft.com >
Date: Mon, 22 mars 1993 09:41:09 -0800 (PST)
Sujet: messagerie texte formaté
MIME-Version: 1.0
Content-Type: multipart / alternative; boundary = boundary42
- Boundary42
Content-Type: text / plain; charset = us-ascii
Content-Type: text / plain; charset = us-ascii
... La version en texte brut du message est ici ...
- Boundary42
Content-Type: text / enrichi
Content-Type: text / enrichi
... RFC 1896 text / enrichi version du même message
va ici ...
va ici ...
- Boundary42
Content-Type: application / x-tout
Content-Type: application / x-tout
... La version chic du même message va ici ...
- Boundary42 -
Dans cet exemple, les utilisateurs dont les systèmes de messagerie ont compris l'
"Application / x-ce que" le format verrait seulement la version fantaisie,
tandis que les autres utilisateurs verront uniquement le enrichis ou version en texte brut,
en fonction des capacités de leur système.
"Application / x-ce que" le format verrait seulement la version fantaisie,
tandis que les autres utilisateurs verront uniquement le enrichis ou version en texte brut,
en fonction des capacités de leur système.
En général, les agents utilisateurs qui composent entités "multipart / alternative"
doivent placer les parties du corps dans l'ordre croissant de préférence, c'est-à-
avec le format préféré dernier. Le texte de fantaisie, l'expéditeur
agent doit mettre le format plus simple d'abord et le format le plus riche
dernier. Recevoir les agents utilisateurs devraient sélectionner et afficher le dernier format
elles sont capables d'afficher. Dans le cas où l'un des
alternatives lui-même est de type "multipart" et contient méconnu
sous-parties, l'agent utilisateur peut choisir de montrer cette alternative,
une alternative plus haut, ou les deux.
doivent placer les parties du corps dans l'ordre croissant de préférence, c'est-à-
avec le format préféré dernier. Le texte de fantaisie, l'expéditeur
agent doit mettre le format plus simple d'abord et le format le plus riche
dernier. Recevoir les agents utilisateurs devraient sélectionner et afficher le dernier format
elles sont capables d'afficher. Dans le cas où l'un des
alternatives lui-même est de type "multipart" et contient méconnu
sous-parties, l'agent utilisateur peut choisir de montrer cette alternative,
une alternative plus haut, ou les deux.
NOTE: Du point de vue d'un réalisateur, il pourrait sembler plus judicieux
d'inverser cet ordre, et ont le plus simple solution de rechange dernier.
Toutefois, en plaçant d'abord la plus simple alternative est le plus sympathique
option possible lorsque "multipart / alternative" entités sont considérées
en utilisant un observateur non-conforme à MIME. Bien que cette approche n'impose
un fardeau sur les téléspectateurs MIME conforme, l'interopérabilité avec les anciennes
courrier des lecteurs a été jugée plus importante dans ce cas.
d'inverser cet ordre, et ont le plus simple solution de rechange dernier.
Toutefois, en plaçant d'abord la plus simple alternative est le plus sympathique
option possible lorsque "multipart / alternative" entités sont considérées
en utilisant un observateur non-conforme à MIME. Bien que cette approche n'impose
un fardeau sur les téléspectateurs MIME conforme, l'interopérabilité avec les anciennes
courrier des lecteurs a été jugée plus importante dans ce cas.
Il peut être le cas que certains agents utilisateurs, s'ils peuvent reconnaître plus
que l'un des formats, vont préférer offrir à l'utilisateur le choix de
le format à voir. Cela est logique, par exemple, si un message
comprend à la fois une version de l'image joliment formaté et un facilement éditées
version texte. Quel est le plus important, cependant, est que l'utilisateur n'a pas
automatiquement être représenté de plusieurs versions de la même donnée. Non plus
l'utilisateur doit être affiché la dernière version de reconnaître ou devrait être
étant donné le choix.
que l'un des formats, vont préférer offrir à l'utilisateur le choix de
le format à voir. Cela est logique, par exemple, si un message
comprend à la fois une version de l'image joliment formaté et un facilement éditées
version texte. Quel est le plus important, cependant, est que l'utilisateur n'a pas
automatiquement être représenté de plusieurs versions de la même donnée. Non plus
l'utilisateur doit être affiché la dernière version de reconnaître ou devrait être
étant donné le choix.
La sémantique de Content-ID IN multipart / alternative: chaque partie d'un
"Multipart / alternative" entité représente les mêmes données, mais le
correspondances entre les deux ne sont pas nécessairement sans information
perte. Par exemple, l'information est perdue lors de la traduction de l'APD
PostScript ou texte brut. Il est recommandé que chaque partie doit
avoir une valeur Content-ID différent dans le cas où l'information
le contenu des deux parties ne sont pas identiques. Et lorsque l'information
le contenu est identique - par exemple, où plusieurs pièces d'un type
"Message / external-body" spécifier d'autres façons d'accéder à la
des données identiques - la même valeur de champ Content-ID doivent être utilisées, à
optimiser les mécanismes de mise en cache qui pourraient être présents sur le
la fin de destinataire. Toutefois, les valeurs Content-ID utilisé par les parties
ne doit pas être la même valeur Content-ID qui décrit l'
"Multipart / alternative" dans son ensemble, s'il ya une telle Content-ID
champ. Autrement dit, une valeur Content-ID se référer à la
Entité "multipart / alternative", tandis qu'un ou plusieurs autres Content-ID
Les valeurs se réfèrent aux parties à l'intérieur.
"Multipart / alternative" entité représente les mêmes données, mais le
correspondances entre les deux ne sont pas nécessairement sans information
perte. Par exemple, l'information est perdue lors de la traduction de l'APD
PostScript ou texte brut. Il est recommandé que chaque partie doit
avoir une valeur Content-ID différent dans le cas où l'information
le contenu des deux parties ne sont pas identiques. Et lorsque l'information
le contenu est identique - par exemple, où plusieurs pièces d'un type
"Message / external-body" spécifier d'autres façons d'accéder à la
des données identiques - la même valeur de champ Content-ID doivent être utilisées, à
optimiser les mécanismes de mise en cache qui pourraient être présents sur le
la fin de destinataire. Toutefois, les valeurs Content-ID utilisé par les parties
ne doit pas être la même valeur Content-ID qui décrit l'
"Multipart / alternative" dans son ensemble, s'il ya une telle Content-ID
champ. Autrement dit, une valeur Content-ID se référer à la
Entité "multipart / alternative", tandis qu'un ou plusieurs autres Content-ID
Les valeurs se réfèrent aux parties à l'intérieur.
5.1.5. Sous Digest
Ce document définit un sous-type "digest" de la "multipart" Content-
Type. Ce type est syntaxiquement identique à "multipart / mixed", mais
la sémantique sont différentes. En particulier, dans un seul, la valeur par défaut
Valeur Content-Type pour une partie du corps est changé de "text / plain" pour
"Message/rfc822". Ceci est fait pour permettre une digestion plus lisible
format qui est largement compatible (à l'exception de la convention de cotation)
avec RFC 934 .
Type. Ce type est syntaxiquement identique à "multipart / mixed", mais
la sémantique sont différentes. En particulier, dans un seul, la valeur par défaut
Valeur Content-Type pour une partie du corps est changé de "text / plain" pour
"Message/rfc822". Ceci est fait pour permettre une digestion plus lisible
format qui est largement compatible (à l'exception de la convention de cotation)
avec RFC 934 .
Remarque: Bien qu'il soit possible de spécifier une valeur Content-Type pour une
une partie de corps en un produit de digestion qui est autre que "message/rfc822", tel qu'un
Partie "text / plain" contenant une description de la matière dans l'
une partie de corps en un produit de digestion qui est autre que "message/rfc822", tel qu'un
Partie "text / plain" contenant une description de la matière dans l'
digest, réellement faire est undesireble. Le "multipart / digest"
Content-Type est destiné à être utilisé pour envoyer des messages de collections.
Si une partie "text / plain" est nécessaire, elle devrait être incluse en tant que séparée
partie d'un message "multipart / mixed".
Content-Type est destiné à être utilisé pour envoyer des messages de collections.
Si une partie "text / plain" est nécessaire, elle devrait être incluse en tant que séparée
partie d'un message "multipart / mixed".
Un condensé dans ce format pourrait alors ressembler à ceci:
De: Modérateur-Adresse
Pour: Destinataire-List
Date: Mon, 22 mars 1994 13:34:51 +0000
Sujet: Internet Digest, tome 42
MIME-Version: 1.0
Content-Type: multipart / mixed;
boundary = "---- principale limite ----"
Pour: Destinataire-List
Date: Mon, 22 mars 1994 13:34:51 +0000
Sujet: Internet Digest, tome 42
MIME-Version: 1.0
Content-Type: multipart / mixed;
boundary = "---- principale limite ----"
------ Principale limite ----
... Texte d'introduction ou la table des matières ...
------ Principale limite ----
Content-Type: multipart / digest;
boundary = "---- prochain message ----"
Content-Type: multipart / digest;
boundary = "---- prochain message ----"
------ Next un message ----
De: someone-else
Date: Fri, 26 mars 1993 11:13:32 +0200
Sujet: mon opinion
Date: Fri, 26 mars 1993 11:13:32 +0200
Sujet: mon opinion
... Corps passe ici ...
------ Next un message ----
De: someone-else-again
Date: Fri, 26 mars 1993 10:07:13 -0500
Sujet: mon opinion différente
Date: Fri, 26 mars 1993 10:07:13 -0500
Sujet: mon opinion différente
... un autre corps passe ici ...
------ Message suivant ------
------ Limite principale ------
5.1.6. Sous parallèle
Ce document définit un sous-type "parallèle" de la "multipart"
Content-Type. Ce type est syntaxiquement identique à
"Multipart / mixed", mais la sémantique est différente. En particulier,
Content-Type. Ce type est syntaxiquement identique à
"Multipart / mixed", mais la sémantique est différente. En particulier,
dans une entité parallèle, l'ordre des parties du corps n'est pas significative.
Une présentation commune de ce type est d'afficher toutes les pièces
simultanément sur le matériel et les logiciels qui sont capables de le faire.
Toutefois, les agents composition doit être conscient que de nombreux lecteurs de mail ne sera
manque cette capacité et montrera les pièces en série dans tous les cas.
simultanément sur le matériel et les logiciels qui sont capables de le faire.
Toutefois, les agents composition doit être conscient que de nombreux lecteurs de mail ne sera
manque cette capacité et montrera les pièces en série dans tous les cas.
5.1.7. D'autres sous-types en plusieurs parties
D'autres sous-types "multipart" sont attendus à l'avenir. MIME
implémentations doivent en général traiter les sous-types non reconnus du
"Multipart" comme étant équivalent à "multipart / mixed".
implémentations doivent en général traiter les sous-types non reconnus du
"Multipart" comme étant équivalent à "multipart / mixed".
5.2. Type de message médias
Il est souvent souhaitable, dans l'envoi du courrier, pour encapsuler un autre
un message de courrier électronique. Un type de support spécial, "message", est défini
faciliter ce processus. En particulier, le " rfc822 sous-type "du" message "est
utilisé pour encapsuler RFC 822 messages.
un message de courrier électronique. Un type de support spécial, "message", est défini
faciliter ce processus. En particulier, le " rfc822 sous-type "du" message "est
utilisé pour encapsuler RFC 822 messages.
NOTE: Il a été suggéré que les sous-types de "message" pourraient être
défini pour les messages transférés ou rejetés. Cependant, transmis et
messages rejetés peuvent être traités comme des messages en plusieurs parties dont l'
première partie contient aucun contrôle ni aucune information descriptive, et une
deuxième partie, de type "message/rfc822", est l'envoyé ou rejetée
message. Composer le rejet et messages de renvoi de cette manière
permettra de préserver les informations de type sur le message d'origine et permettre
qu'il soit correctement remis au récipiendaire, et est donc fortement
encouragée.
défini pour les messages transférés ou rejetés. Cependant, transmis et
messages rejetés peuvent être traités comme des messages en plusieurs parties dont l'
première partie contient aucun contrôle ni aucune information descriptive, et une
deuxième partie, de type "message/rfc822", est l'envoyé ou rejetée
message. Composer le rejet et messages de renvoi de cette manière
permettra de préserver les informations de type sur le message d'origine et permettre
qu'il soit correctement remis au récipiendaire, et est donc fortement
encouragée.
Sous-types de "message" imposent souvent des restrictions sur ce que les codages sont
permis. Ces restrictions sont décrites en conjonction avec l'
sous-type particulier.
permis. Ces restrictions sont décrites en conjonction avec l'
sous-type particulier.
passerelles de messagerie, relais et autres agents de traitement du courrier sont couramment
connu pour modifier l'en-tête de niveau supérieur d'un 822 RFC message. En
Notamment, ils ajoutent souvent, supprimer ou réorganiser les champs d'en-tête.
Ces opérations sont explicitement interdites par la encapsulée
têtes intégrés dans le corps des messages de type «message».
connu pour modifier l'en-tête de niveau supérieur d'un 822 RFC message. En
Notamment, ils ajoutent souvent, supprimer ou réorganiser les champs d'en-tête.
Ces opérations sont explicitement interdites par la encapsulée
têtes intégrés dans le corps des messages de type «message».
5.2.1. RFC822 Sous-
Un type de support de "message/rfc822" indique que le corps contient un
message encapsulé, avec la syntaxe d'une RFC 822 message.
Cependant, contrairement à haut niveau RFC 822 messages, la restriction que chaque
Corps "message/rfc822" doit inclure une "From", "Date", et au moins un
en-tête de destination est supprimé et remplacé par la condition selon laquelle
au moins l'un des "From", "sujet" ou "Date" doit être présent.
message encapsulé, avec la syntaxe d'une RFC 822 message.
Cependant, contrairement à haut niveau RFC 822 messages, la restriction que chaque
Corps "message/rfc822" doit inclure une "From", "Date", et au moins un
en-tête de destination est supprimé et remplacé par la condition selon laquelle
au moins l'un des "From", "sujet" ou "Date" doit être présent.
Il convient de noter que, malgré l'utilisation des numéros «822», un
Entité "message/rfc822" ne se limite pas à la matière dans la plus stricte
conformité aux RFC 822 , ni les sémantique de "message/rfc822"
objets limités à la sémantique définie dans la RFC 822 . Plus
Plus précisément, un message "message/rfc822" pourrait bien être un article de Nouvelles
ou un message MIME.
Entité "message/rfc822" ne se limite pas à la matière dans la plus stricte
conformité aux RFC 822 , ni les sémantique de "message/rfc822"
objets limités à la sémantique définie dans la RFC 822 . Plus
Plus précisément, un message "message/rfc822" pourrait bien être un article de Nouvelles
ou un message MIME.
Aucun codage autre que "7 bits", "8 bits", ou "binaire" est permise pour
le corps d'une entité "message/rfc822". Les champs d'en-tête du message sont
toujours US-ASCII dans tous les cas et de données dans le corps peut encore être
codé, dans ce cas, le champ d'en-tête Content-Transfer-Encoding dans
le message encapsulé va refléter cette réalité. Le texte non-US-ASCII dans le
têtes d'un message encapsulé peuvent être spécifiées en utilisant l'
mécanismes décrits dans la RFC 2047 .
le corps d'une entité "message/rfc822". Les champs d'en-tête du message sont
toujours US-ASCII dans tous les cas et de données dans le corps peut encore être
codé, dans ce cas, le champ d'en-tête Content-Transfer-Encoding dans
le message encapsulé va refléter cette réalité. Le texte non-US-ASCII dans le
têtes d'un message encapsulé peuvent être spécifiées en utilisant l'
mécanismes décrits dans la RFC 2047 .
5.2.2. Sous partiel
Le sous-type "partielle" est défini pour permettre à de grandes entités à
livré en plusieurs morceaux séparés de courrier et automatiquement
remonté par un agent utilisateur destinataire. (Le concept est similaire à IP
fragmentation et le réassemblage dans les protocoles Internet de base.) Ce
mécanisme peut être utilisé lorsque des agents intermédiaires de transport limitent l'
taille des messages individuels qui peuvent être envoyés. Le type de média
"Message / partial" indique ainsi que le corps contient un fragment d'
une entité plus grande.
livré en plusieurs morceaux séparés de courrier et automatiquement
remonté par un agent utilisateur destinataire. (Le concept est similaire à IP
fragmentation et le réassemblage dans les protocoles Internet de base.) Ce
mécanisme peut être utilisé lorsque des agents intermédiaires de transport limitent l'
taille des messages individuels qui peuvent être envoyés. Le type de média
"Message / partial" indique ainsi que le corps contient un fragment d'
une entité plus grande.
Parce que les données de type «message» ne peuvent jamais être codées en base64 ou
quoted-printable, un problème pourrait se poser si des entités "message / partial"
sont construits dans un environnement qui prend en charge binaire ou 8bit
transport. Le problème est que les données binaires seront divisés en
plusieurs messages "message / partial", chacun d'eux nécessitant binaire
transport. Si ces messages ont été rencontrés lors d'une passerelle dans un
Environnement de transport 7 bits, il n'y aurait pas moyen de coder correctement
les 7 bits pour le monde, en dehors de l'attente pour tous les fragments,
remonter le message interne, puis codant pour la remontée
données en base64 ou quoted-printable. Comme il est possible que
différents fragments pourraient passer par différentes passerelles, même cela est
pas une solution acceptable. Pour cette raison, il est précisé que
les entités de type "message / partial" doivent toujours avoir un contenu
Transfer-Encoding de 7bit (par défaut). En particulier, même en
des environnements qui favorisent binaire ou 8bit transports, l'utilisation d'un
Content-Transfer-encoding de "8bit" ou "binary" est explicitement
interdit aux entités MIME de "message / partial" de type. Ce à son tour
implique que le message interne ne doit pas utiliser "8bit" ou "binaire"
codage.
quoted-printable, un problème pourrait se poser si des entités "message / partial"
sont construits dans un environnement qui prend en charge binaire ou 8bit
transport. Le problème est que les données binaires seront divisés en
plusieurs messages "message / partial", chacun d'eux nécessitant binaire
transport. Si ces messages ont été rencontrés lors d'une passerelle dans un
Environnement de transport 7 bits, il n'y aurait pas moyen de coder correctement
les 7 bits pour le monde, en dehors de l'attente pour tous les fragments,
remonter le message interne, puis codant pour la remontée
données en base64 ou quoted-printable. Comme il est possible que
différents fragments pourraient passer par différentes passerelles, même cela est
pas une solution acceptable. Pour cette raison, il est précisé que
les entités de type "message / partial" doivent toujours avoir un contenu
Transfer-Encoding de 7bit (par défaut). En particulier, même en
des environnements qui favorisent binaire ou 8bit transports, l'utilisation d'un
Content-Transfer-encoding de "8bit" ou "binary" est explicitement
interdit aux entités MIME de "message / partial" de type. Ce à son tour
implique que le message interne ne doit pas utiliser "8bit" ou "binaire"
codage.
Parce que certains agents de transfert de messages peuvent choisir automatiquement
grand fragment de messages, et parce que ces agents peuvent utiliser très
différents seuils de fragmentation, il est possible que les pièces d'
un message partielle, lors du remontage, peut se montrer à comprennent
un message partiel. Cela est explicitement autorisée.
grand fragment de messages, et parce que ces agents peuvent utiliser très
différents seuils de fragmentation, il est possible que les pièces d'
un message partielle, lors du remontage, peut se montrer à comprennent
un message partiel. Cela est explicitement autorisée.
Trois paramètres doivent être spécifiés dans le champ Content-Type de Type
"Message / partial": Le premier, "id", est un identifiant unique, au plus près
d'un identifiant unique au monde, donc, d'être utilisé pour faire correspondre l'
fragments ensemble. (En général, l'identifiant est essentiellement une
Message-ID, s'il est placé entre guillemets, il peut être n'importe quel message-id, dans
Conformément à la BNF pour "paramètre" donnée dans la RFC 2045 ). L'
deuxième, "num", un nombre entier, le nombre de fragments, ce qui indique
où ce fragment correspond dans la séquence de fragments. Le troisième,
"Totale", un autre nombre entier, le nombre total de fragments. Cette
troisième sous-champ est requis sur le fragment final, et est en option
(Bien encouragée) sur les fragments antérieurs. Notez également que ces
paramètres peuvent être indiqués dans n'importe quel ordre.
"Message / partial": Le premier, "id", est un identifiant unique, au plus près
d'un identifiant unique au monde, donc, d'être utilisé pour faire correspondre l'
fragments ensemble. (En général, l'identifiant est essentiellement une
Message-ID, s'il est placé entre guillemets, il peut être n'importe quel message-id, dans
Conformément à la BNF pour "paramètre" donnée dans la RFC 2045 ). L'
deuxième, "num", un nombre entier, le nombre de fragments, ce qui indique
où ce fragment correspond dans la séquence de fragments. Le troisième,
"Totale", un autre nombre entier, le nombre total de fragments. Cette
troisième sous-champ est requis sur le fragment final, et est en option
(Bien encouragée) sur les fragments antérieurs. Notez également que ces
paramètres peuvent être indiqués dans n'importe quel ordre.
Ainsi, la seconde pièce d'un message 3-pièce peut avoir l'une des
suite champs d'en-tête:
suite champs d'en-tête:
Content-Type: Message / partiel, le nombre = 2; total = 3;
id = " oc = jpbe0M2Yt4s@thumper.bellcore.com "
id = " oc = jpbe0M2Yt4s@thumper.bellcore.com "
Mais la troisième pièce doit préciser le nombre total de fragments:
Content-Type: Message / partiel, le nombre = 3; total = 3;
id = " oc = jpbe0M2Yt4s@thumper.bellcore.com "
id = " oc = jpbe0M2Yt4s@thumper.bellcore.com "
Notez que fragment numérotation commence par 1 et non 0.
Lorsque les fragments d'une entité rompu de cette manière sont mises
ensemble, le résultat est toujours une entité MIME complet, qui peut avoir
son propre champ d'en-tête Content-Type, et peut donc contenir toute autre
le type de données.
ensemble, le résultat est toujours une entité MIME complet, qui peut avoir
son propre champ d'en-tête Content-Type, et peut donc contenir toute autre
le type de données.
5.2.2.1. Un message fragmentation et le réassemblage
La sémantique d'un message partiel remonté doivent être ceux de la
Message "interne", plutôt que d'un message contenant la intérieure
message. Cela permet, par exemple, d'envoyer une grande audio
message comme plusieurs messages partiels, et ai toujours apparaître à l'
destinataire sous forme de message audio simple, plutôt que comme un encapsulée
Message "interne", plutôt que d'un message contenant la intérieure
message. Cela permet, par exemple, d'envoyer une grande audio
message comme plusieurs messages partiels, et ai toujours apparaître à l'
destinataire sous forme de message audio simple, plutôt que comme un encapsulée
message contenant un message audio. Autrement dit, l'encapsulation de
le message est considéré comme "transparent".
le message est considéré comme "transparent".
Lors de la génération et de remonter les pièces d'un "message / partial"
un message, les en-têtes du message encapsulé doit être fusionnée avec
les en-têtes des entités englobant. Dans ce processus, ce qui suit
règles doivent être respectées:
un message, les en-têtes du message encapsulé doit être fusionnée avec
les en-têtes des entités englobant. Dans ce processus, ce qui suit
règles doivent être respectées:
(1) Les agents de fragmentation diviser messages à la ligne
limites seulement. Cette restriction est imposée parce que
scissions des points autres que les extrémités des lignes à son tour
dépend de transports de message étant en mesure de préserver
la sémantique des messages qui ne finissent pas par un CRLF
séquence. Beaucoup de transports sont incapables de préserver
telle sémantique.
limites seulement. Cette restriction est imposée parce que
scissions des points autres que les extrémités des lignes à son tour
dépend de transports de message étant en mesure de préserver
la sémantique des messages qui ne finissent pas par un CRLF
séquence. Beaucoup de transports sont incapables de préserver
telle sémantique.
(2) Tous les champs d'en-tête de l'enfermant initial
message, sauf celles qui commencent par "Content-" et
l'en-tête champs "Subject" spécifique "Message-ID",
"Crypté" et "MIME-Version", doit être copié,
commande, au nouveau message.
message, sauf celles qui commencent par "Content-" et
l'en-tête champs "Subject" spécifique "Message-ID",
"Crypté" et "MIME-Version", doit être copié,
commande, au nouveau message.
(3) Les champs d'en-tête dans le message ci-joint qui commencent
avec "Content-", ainsi que le "sujet", "Message-ID",
«Crypté», et les champs "MIME-Version", doit être
annexé, dans l'ordre, pour les champs d'en-tête de la nouvelle
message. Tous les champs d'en-tête dans le message ci-joint
qui ne commence pas par "Content-" (sauf pour le
"Objet", "Message-ID", "chiffré" et "MIME-
«champs de version) seront ignorées et abandonnées.
avec "Content-", ainsi que le "sujet", "Message-ID",
«Crypté», et les champs "MIME-Version", doit être
annexé, dans l'ordre, pour les champs d'en-tête de la nouvelle
message. Tous les champs d'en-tête dans le message ci-joint
qui ne commence pas par "Content-" (sauf pour le
"Objet", "Message-ID", "chiffré" et "MIME-
«champs de version) seront ignorées et abandonnées.
(4) Tous les champs d'en-tête de la deuxième et de toute
messages enfermant ultérieures sont supprimées par le
réassemblage processus.
messages enfermant ultérieures sont supprimées par le
réassemblage processus.
5.2.2.2. Fragmentation et réassemblage Exemple
Si un message audio est divisé en deux parties, la première pièce pourrait
ressembler à ceci:
ressembler à ceci:
X-étrange-header-1: Foo
De: Bill@host.com
Pour: joe@otherhost.com
Date: Fri, 26 mars 1993 12:59:38 -0500 (EST)
Sujet: mail Audio (partie 1 de 2)
Message-ID: <id1@host.com>
MIME-Version: 1.0
Content-Type: le message / partial; id = " ABC@host.com ";
De: Bill@host.com
Pour: joe@otherhost.com
Date: Fri, 26 mars 1993 12:59:38 -0500 (EST)
Sujet: mail Audio (partie 1 de 2)
Message-ID: <id1@host.com>
MIME-Version: 1.0
Content-Type: le message / partial; id = " ABC@host.com ";
number = 1; total = 2
X-étrange-header-1: Bar
X-étrange-header-2: Bonjour
Message-ID: <anotherid@foo.com>
Sujet: mail Audio
MIME-Version: 1.0
Content-Type: audio / basic
Content-Transfer-Encoding: base64
X-étrange-header-2: Bonjour
Message-ID: <anotherid@foo.com>
Sujet: mail Audio
MIME-Version: 1.0
Content-Type: audio / basic
Content-Transfer-Encoding: base64
... premier semestre de données audio codées va ici ...
et le second semestre pourrait ressembler à ceci:
De: Bill@host.com
Pour: joe@otherhost.com
Date: Fri, 26 mars 1993 12:59:38 -0500 (EST)
Sujet: mail Audio (partie 2 de 2)
MIME-Version: 1.0
Message-ID: <id2@host.com>
Content-Type: le message / partial;
id = " ABC@host.com ", number = 2; total = 2
Pour: joe@otherhost.com
Date: Fri, 26 mars 1993 12:59:38 -0500 (EST)
Sujet: mail Audio (partie 2 de 2)
MIME-Version: 1.0
Message-ID: <id2@host.com>
Content-Type: le message / partial;
id = " ABC@host.com ", number = 2; total = 2
... deuxième semestre de données audio codées va ici ...
Puis, lorsque le message fragmenté est remonté, le résultat
message qui sera affiché à l'utilisateur devrait ressembler à ceci:
message qui sera affiché à l'utilisateur devrait ressembler à ceci:
X-étrange-header-1: Foo
De: Bill@host.com
Pour: joe@otherhost.com
Date: Fri, 26 mars 1993 12:59:38 -0500 (EST)
Sujet: mail Audio
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-Type: audio / basic
Content-Transfer-Encoding: base64
De: Bill@host.com
Pour: joe@otherhost.com
Date: Fri, 26 mars 1993 12:59:38 -0500 (EST)
Sujet: mail Audio
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-Type: audio / basic
Content-Transfer-Encoding: base64
... premier semestre de données audio codées va ici ...
... deuxième semestre de données audio codées va ici ...
... deuxième semestre de données audio codées va ici ...
L'inclusion d'un domaine «Références» dans les en-têtes de la deuxième
et pièces ultérieures d'un message fragmenté que les références
Message-Id sur la pièce précédente peut être bénéfique pour les lecteurs de messagerie
qui comprennent et pistes Références. Toutefois, la génération de
ces champs "Références" est entièrement facultative.
et pièces ultérieures d'un message fragmenté que les références
Message-Id sur la pièce précédente peut être bénéfique pour les lecteurs de messagerie
qui comprennent et pistes Références. Toutefois, la génération de
ces champs "Références" est entièrement facultative.
Enfin, il convient de noter que le champ d'en-tête "crypté" a
été rendus obsolètes par Privacy Enhanced Messaging (PEM) [ RFC-1421 ,
RFC-1422 , RFC-1423 , RFC-1424 ], mais les règles ci-dessus sont néanmoins
cru pour décrire la façon correcte de traiter si elle est rencontrée
dans le cadre de la conversion vers et à partir de fragments de message "/" partielle.
été rendus obsolètes par Privacy Enhanced Messaging (PEM) [ RFC-1421 ,
RFC-1422 , RFC-1423 , RFC-1424 ], mais les règles ci-dessus sont néanmoins
cru pour décrire la façon correcte de traiter si elle est rencontrée
dans le cadre de la conversion vers et à partir de fragments de message "/" partielle.
5.2.3. Sous-external-body
Le sous-type corps externe indique que les données de corps réels ne sont pas
inclus, mais simplement référencée. Dans ce cas, les paramètres
décrire un mécanisme pour accéder aux données externes.
inclus, mais simplement référencée. Dans ce cas, les paramètres
décrire un mécanisme pour accéder aux données externes.
Lorsqu'une entité est de type MIME "message / external-body", il se compose d'
un en-tête, deux CRLF consécutifs, et l'en-tête de message pour l'
un message encapsulé. Si une autre paire de CRLFs consécutives apparaît,
Bien sûr, cela met fin à l'en-tête de message pour le message encapsulé.
Cependant, étant donné que le corps du message encapsulé est lui-même extérieur, il
n'apparaît pas dans la zone qui suit. Par exemple, considérons le
le message suivant:
un en-tête, deux CRLF consécutifs, et l'en-tête de message pour l'
un message encapsulé. Si une autre paire de CRLFs consécutives apparaît,
Bien sûr, cela met fin à l'en-tête de message pour le message encapsulé.
Cependant, étant donné que le corps du message encapsulé est lui-même extérieur, il
n'apparaît pas dans la zone qui suit. Par exemple, considérons le
le message suivant:
Content-Type: message / external-body;
access-type = fichier-local;
name = "/ u / nsb / Me.jpeg"
access-type = fichier-local;
name = "/ u / nsb / Me.jpeg"
Content-type: image / jpeg
Content-ID: < id42@guppylake.bellcore.com >
Content-Transfer-Encoding: binary
Content-ID: < id42@guppylake.bellcore.com >
Content-Transfer-Encoding: binary
Ce n'est pas vraiment du corps!
La zone à la fin, ce qui pourrait être appelé le «corps fantôme», est
ignorées pour la plupart des messages externe du corps. Cependant, il peut être utilisé pour
contenir des informations auxiliaires pour certains de ces messages, comme elle est
quand le type d'accès est "serveur de courrier". Le seul type d'accès défini
dans le présent document qui utilise le corps fantôme est "serveur de courrier», mais
d'autres types d'accès peuvent être définis à l'avenir dans d'autres
spécifications qui utilisent ce domaine.
ignorées pour la plupart des messages externe du corps. Cependant, il peut être utilisé pour
contenir des informations auxiliaires pour certains de ces messages, comme elle est
quand le type d'accès est "serveur de courrier". Le seul type d'accès défini
dans le présent document qui utilise le corps fantôme est "serveur de courrier», mais
d'autres types d'accès peuvent être définis à l'avenir dans d'autres
spécifications qui utilisent ce domaine.
Les en-têtes encapsulées dans toutes les entités "message / external-body" doit
inclure un champ d'en-tête Content-ID à envoyer un identifiant unique par
qui pour référencer les données. Cet identificateur peut être utilisé pour la mise en mémoire cache
des mécanismes, et pour la reconnaissance de la réception des données lorsque l'
type d'accès est "serveur de courrier".
inclure un champ d'en-tête Content-ID à envoyer un identifiant unique par
qui pour référencer les données. Cet identificateur peut être utilisé pour la mise en mémoire cache
des mécanismes, et pour la reconnaissance de la réception des données lorsque l'
type d'accès est "serveur de courrier".
Notez que, comme indiqué ici, les jetons qui décrivent externe du corps
données, telles que les noms de fichiers et des commandes du serveur de messagerie, sont tenus d'être
dans le jeu de caractères US-ASCII.
données, telles que les noms de fichiers et des commandes du serveur de messagerie, sont tenus d'être
dans le jeu de caractères US-ASCII.
Si cela s'avère problématique dans la pratique, un nouveau mécanisme peut être
requis comme une extension future à MIME, soit selon la nouvelle définition
types d'accès pour "message / external-body" ou par un autre mécanisme.
requis comme une extension future à MIME, soit selon la nouvelle définition
types d'accès pour "message / external-body" ou par un autre mécanisme.
Comme avec "message / partial", MIME entités de type "message/external-
corps "doit avoir une teneur-Transfer-Encoding de 7bit (par défaut).
En particulier, même dans des environnements qui favorisent binaire ou 8bit
le transport, l'utilisation d'un Content-Transfer-encoding de "8bit" ou
«Binaire» est explicitement interdit pour les entités de type
"Message / external-body".
corps "doit avoir une teneur-Transfer-Encoding de 7bit (par défaut).
En particulier, même dans des environnements qui favorisent binaire ou 8bit
le transport, l'utilisation d'un Content-Transfer-encoding de "8bit" ou
«Binaire» est explicitement interdit pour les entités de type
"Message / external-body".
5.2.3.1. Paramètres généraux corps externe
Les paramètres qui peuvent être utilisés avec n'importe quel «corps message/external-"
sont les suivants:
sont les suivants:
(1) ACCESS-TYPE - Un mot indiquant l'accès soutenu
mécanisme par lequel le fichier ou les données peuvent être obtenues.
Ce mot n'est pas sensible à la casse. Les valeurs comprennent, mais
ne sont pas limités à, "FTP", "anon-FTP", "TFTP", "LOCAL-
Fichier "," serveur de courrier ". Valeurs futurs, sauf pour
valeurs expérimentales commençant par "X-", doivent être
enregistré auprès de l'IANA, tel que décrit dans la RFC 2048 .
Ce paramètre est inconditionnellement obligatoire et doit être
présent sur tous les "message / external-body".
mécanisme par lequel le fichier ou les données peuvent être obtenues.
Ce mot n'est pas sensible à la casse. Les valeurs comprennent, mais
ne sont pas limités à, "FTP", "anon-FTP", "TFTP", "LOCAL-
Fichier "," serveur de courrier ". Valeurs futurs, sauf pour
valeurs expérimentales commençant par "X-", doivent être
enregistré auprès de l'IANA, tel que décrit dans la RFC 2048 .
Ce paramètre est inconditionnellement obligatoire et doit être
présent sur tous les "message / external-body".
(2) EXPIRATION - La date (dans la RFC 822 "date-heure"
syntaxe, tel que prorogé par la RFC 1123 pour permettre à 4 chiffres en
les espaces an), après quoi l'existence de l'
données externes ne sont pas garanties. Ce paramètre peut être
utilisé avec n'importe quel type d'accès et est toujours facultative.
syntaxe, tel que prorogé par la RFC 1123 pour permettre à 4 chiffres en
les espaces an), après quoi l'existence de l'
données externes ne sont pas garanties. Ce paramètre peut être
utilisé avec n'importe quel type d'accès et est toujours facultative.
(3) TAILLE - La taille (en octets) de données. L'intention
de ce paramètre est d'aider le destinataire décider
ou de ne pas dépenser les ressources nécessaires pour
récupérer les données externes. Notez que cela décrit
la taille des données dans sa forme canonique, c'est-à-dire,
avant toute Content-Transfer-Encoding a été appliquée
ou après les données ont été décodés. Ce paramètre
peut être utilisé avec n'importe quel type d'accès et est toujours
en option.
de ce paramètre est d'aider le destinataire décider
ou de ne pas dépenser les ressources nécessaires pour
récupérer les données externes. Notez que cela décrit
la taille des données dans sa forme canonique, c'est-à-dire,
avant toute Content-Transfer-Encoding a été appliquée
ou après les données ont été décodés. Ce paramètre
peut être utilisé avec n'importe quel type d'accès et est toujours
en option.
(4) Autorisation - Un champ insensible à la casse qui indique
si oui ou non il est prévu que les clients pourraient aussi
tenter d'écraser les données. Par défaut, ou si
autorisation est «lu», l'hypothèse est qu'ils sont
pas, et que, si les données sont extraites une fois, il n'est
jamais eu besoin de nouveau. Si la permission est "lecture-écriture",
si oui ou non il est prévu que les clients pourraient aussi
tenter d'écraser les données. Par défaut, ou si
autorisation est «lu», l'hypothèse est qu'ils sont
pas, et que, si les données sont extraites une fois, il n'est
jamais eu besoin de nouveau. Si la permission est "lecture-écriture",
cette hypothèse n'est pas valide, et toute copie locale doit être
considéré pas plus d'une mémoire cache. "Lire" et "Read-
Ecrire "sont les seules valeurs définies de permission. Cette
paramètre peut être utilisé avec n'importe quel type d'accès et
Toujours facultative.
considéré pas plus d'une mémoire cache. "Lire" et "Read-
Ecrire "sont les seules valeurs définies de permission. Cette
paramètre peut être utilisé avec n'importe quel type d'accès et
Toujours facultative.
La sémantique précise des types d'accès définies ici sont décrits
dans les sections qui suivent.
dans les sections qui suivent.
5.2.3.2. Le «ftp» et «tftp types d'accès
Un type d'accès de FTP ou TFTP indique que le corps du message est
accessible en tant que fichier en utilisant le FTP [ RFC-959 ] ou TFTP [ RFC-783 ]
protocoles, respectivement. Pour ces types d'accès, ce qui suit
paramètres supplémentaires sont obligatoires:
accessible en tant que fichier en utilisant le FTP [ RFC-959 ] ou TFTP [ RFC-783 ]
protocoles, respectivement. Pour ces types d'accès, ce qui suit
paramètres supplémentaires sont obligatoires:
(1) Nom - Le nom du fichier qui contient le réel
les données de corps.
les données de corps.
(2) SITE - Une machine à partir de laquelle le fichier peut être obtenu,
en utilisant le protocole donné. Ce doit être entièrement
nom de domaine complet, pas un surnom.
en utilisant le protocole donné. Ce doit être entièrement
nom de domaine complet, pas un surnom.
(3) Avant les données sont récupérées, en utilisant FTP, l'utilisateur
ont généralement besoin d'être invité à fournir un identifiant et un
le mot de passe pour le nom de la machine par le paramètre de site.
Pour des raisons de sécurité, un tel identifiant et mot de passe ne sont pas
précisé que les paramètres de type de contenu, mais doit être
obtenue à partir de l'utilisateur.
ont généralement besoin d'être invité à fournir un identifiant et un
le mot de passe pour le nom de la machine par le paramètre de site.
Pour des raisons de sécurité, un tel identifiant et mot de passe ne sont pas
précisé que les paramètres de type de contenu, mais doit être
obtenue à partir de l'utilisateur.
En outre, les paramètres suivants sont facultatifs:
(1) REPERTOIRE - Un répertoire à partir duquel les données citées par
NOM doivent être récupérées.
NOM doivent être récupérées.
(2) MODE - Une chaîne insensible à la casse indiquant le mode
à utiliser lors de la récupération des informations. L'valide
Les valeurs d'accès de type "TFTP" sont "NETASCII», «octet»,
et "MAIL", tel que spécifié par le protocole TFTP [RFC-
783]. Les valeurs valides pour l'accès de type "FTP" sont
"ASCII", "EBCDIC", "image", et "localn" où "n" est un
décimal entier, typiquement 8. Ceux-ci correspondent à la
types de représentation "A" "E" "I" et "L n" comme spécifié
par le protocole FTP [ RFC-959 ]. Notez que "binaire" et
"TENEX" ne sont pas des valeurs valides pour le mode et que «octet»
ou "IMAGE" ou "LOCAL8" doivent être utilisés à la place. Si le mode
n'est pas spécifié, la valeur par défaut est "NETASCII" pour
TFTP et "ASCII" autrement.
à utiliser lors de la récupération des informations. L'valide
Les valeurs d'accès de type "TFTP" sont "NETASCII», «octet»,
et "MAIL", tel que spécifié par le protocole TFTP [RFC-
783]. Les valeurs valides pour l'accès de type "FTP" sont
"ASCII", "EBCDIC", "image", et "localn" où "n" est un
décimal entier, typiquement 8. Ceux-ci correspondent à la
types de représentation "A" "E" "I" et "L n" comme spécifié
par le protocole FTP [ RFC-959 ]. Notez que "binaire" et
"TENEX" ne sont pas des valeurs valides pour le mode et que «octet»
ou "IMAGE" ou "LOCAL8" doivent être utilisés à la place. Si le mode
n'est pas spécifié, la valeur par défaut est "NETASCII" pour
TFTP et "ASCII" autrement.
5.2.3.3. Le «anon-ftp 'Type-Accès
Le "anon-ftp" type d'accès est identique au type d'accès "ftp",
sauf qu'il n'est pas nécessaire de demander à l'utilisateur de fournir un nom et un mot de passe
pour le site spécifié. Au lieu de cela, le protocole FTP sera utilisé avec
login "anonyme" et un mot de passe qui correspond à la messagerie de l'utilisateur
adresse.
sauf qu'il n'est pas nécessaire de demander à l'utilisateur de fournir un nom et un mot de passe
pour le site spécifié. Au lieu de cela, le protocole FTP sera utilisé avec
login "anonyme" et un mot de passe qui correspond à la messagerie de l'utilisateur
adresse.
5.2.3.4. Le «fichier-local" Type-Accès
Un type d'accès de "fichier-local" signifie que le corps proprement dit est
accessible dans un fichier sur la machine locale. Deux paramètres supplémentaires
sont définies pour ce type d'accès:
accessible dans un fichier sur la machine locale. Deux paramètres supplémentaires
sont définies pour ce type d'accès:
(1) Nom - Le nom du fichier qui contient le réel
les données de corps. Ce paramètre est obligatoire pour l'
"Fichier-local" type d'accès.
les données de corps. Ce paramètre est obligatoire pour l'
"Fichier-local" type d'accès.
(2) SITE - un spécificateur de domaine pour une machine ou un ensemble de
les machines qui sont connus pour avoir accès aux données
image. Ce paramètre optionnel est utilisé pour décrire la
localisation de référence pour les données, qui est, le site
ou des sites dans lesquels on prévoit que le fichier soit visible.
Les astérisques peuvent être utilisées pour des jokers à une partie
d'un nom de domaine, tel que «*. bellcore.com", pour indiquer
un ensemble de machines sur lesquelles les données doivent être directement
visibles, tandis qu'un seul astérisque peut être utilisé pour
indiquer un fichier qui devrait être universellement
disponible, par exemple, par l'intermédiaire d'un système de fichier global.
les machines qui sont connus pour avoir accès aux données
image. Ce paramètre optionnel est utilisé pour décrire la
localisation de référence pour les données, qui est, le site
ou des sites dans lesquels on prévoit que le fichier soit visible.
Les astérisques peuvent être utilisées pour des jokers à une partie
d'un nom de domaine, tel que «*. bellcore.com", pour indiquer
un ensemble de machines sur lesquelles les données doivent être directement
visibles, tandis qu'un seul astérisque peut être utilisé pour
indiquer un fichier qui devrait être universellement
disponible, par exemple, par l'intermédiaire d'un système de fichier global.
5.2.3.5. Le «mail-server 'Type-Accès
Le "serveur de courrier" type d'accès indique que le corps réel est
disponible à partir d'un serveur de messagerie. Deux autres paramètres sont définis
pour ce type d'accès:
disponible à partir d'un serveur de messagerie. Deux autres paramètres sont définis
pour ce type d'accès:
(1) SERVER - Le addr-spec du serveur de messagerie à partir de laquelle
les données réelles du corps peuvent être obtenus. Ce paramètre
est obligatoire pour le "serveur de courrier" type d'accès.
les données réelles du corps peuvent être obtenus. Ce paramètre
est obligatoire pour le "serveur de courrier" type d'accès.
(2) Sous - L'objet qui doit être utilisé dans le courrier
qui est envoyé pour obtenir les données. Notez que le courrier de saisie
serveurs sur les lignes sujet n'est pas recommandé, mais une telle
serveurs de messagerie sont connues pour exister. Il s'agit d'une option
paramètre.
qui est envoyé pour obtenir les données. Notez que le courrier de saisie
serveurs sur les lignes sujet n'est pas recommandé, mais une telle
serveurs de messagerie sont connues pour exister. Il s'agit d'une option
paramètre.
Parce que les serveurs de messagerie acceptent une variété de syntaxes, dont certains sont
plusieurs lignes, la commande complète à être envoyés à un serveur de messagerie n'est pas
incluse en tant que paramètre dans le champ d'en-tête de type de contenu. Au lieu de cela,
il est prévu en tant que "corps fantôme" lorsque le type de support est
"Message / external-body" et le type d'accès est serveur de courrier.
plusieurs lignes, la commande complète à être envoyés à un serveur de messagerie n'est pas
incluse en tant que paramètre dans le champ d'en-tête de type de contenu. Au lieu de cela,
il est prévu en tant que "corps fantôme" lorsque le type de support est
"Message / external-body" et le type d'accès est serveur de courrier.
Notez que MIME ne définit pas une syntaxe de serveur de messagerie. Au contraire, il
permet l'inclusion de commandes du serveur de messagerie arbitraires dans le fantôme
corps. Les implémentations doivent inclure le corps fantôme dans le corps de
le message, il envoie à l'adresse du serveur de messagerie pour extraire le
les données pertinentes.
permet l'inclusion de commandes du serveur de messagerie arbitraires dans le fantôme
corps. Les implémentations doivent inclure le corps fantôme dans le corps de
le message, il envoie à l'adresse du serveur de messagerie pour extraire le
les données pertinentes.
Contrairement à d'autres types d'accès, l'accès serveur de courrier est asynchrone et
qui va arriver à un moment imprévisible à l'avenir. Pour cette raison,
il est important qu'il y ait un mécanisme par lequel les données renvoyées
peut être jumelés avec l'entité d'origine "message / external-body".
Serveurs de messagerie MIME doivent utiliser le même champ Content-ID sur le revenu
message qui a été utilisé dans le "message / external-body" original
entités, afin de faciliter cette adaptation.
qui va arriver à un moment imprévisible à l'avenir. Pour cette raison,
il est important qu'il y ait un mécanisme par lequel les données renvoyées
peut être jumelés avec l'entité d'origine "message / external-body".
Serveurs de messagerie MIME doivent utiliser le même champ Content-ID sur le revenu
message qui a été utilisé dans le "message / external-body" original
entités, afin de faciliter cette adaptation.
5.2.3.6. Problèmes de sécurité corps externe
Entités "message / external-body" donnent lieu à deux importantes sur la sécurité
questions:
questions:
(1) Accès aux données via un "message / external-body" de référence
efficacement les résultats du destinataire du message l'exécution
une opération qui a été spécifié par le message
donneur d'ordre. Il est donc possible pour le message
auteur de tromper le destinataire en faisant quelque chose
ils n'auraient pas fait autrement. Par exemple, un
auteur peut spécifier une action qui tente
récupération de matériel que le destinataire n'est pas
autorisée à obtenir, ce qui provoque le destinataire à
involontairement violer certaines règles de sécurité. Pour cette
agents raison, l'utilisateur capables de résoudre externe
références doivent toujours prendre des mesures pour décrire la
des mesures qu'elles doivent prendre pour le bénéficiaire et demander
permisssion explicite avant de l'exécuter.
efficacement les résultats du destinataire du message l'exécution
une opération qui a été spécifié par le message
donneur d'ordre. Il est donc possible pour le message
auteur de tromper le destinataire en faisant quelque chose
ils n'auraient pas fait autrement. Par exemple, un
auteur peut spécifier une action qui tente
récupération de matériel que le destinataire n'est pas
autorisée à obtenir, ce qui provoque le destinataire à
involontairement violer certaines règles de sécurité. Pour cette
agents raison, l'utilisateur capables de résoudre externe
références doivent toujours prendre des mesures pour décrire la
des mesures qu'elles doivent prendre pour le bénéficiaire et demander
permisssion explicite avant de l'exécuter.
Le «mail-server 'type d'accès est particulièrement
vulnérables, en ce qu'elle provoque le destinataire pour envoyer un
nouveau message dont le contenu est précisé par le
L'instigateur du message original. Étant donné le potentiel de
abus, de tels messages de demande qui sont construits
doit contenir une indication claire qu'ils étaient
généré automatiquement (par exemple dans un Commentaires: tête
domaine) dans une tentative de résoudre un MIME
vulnérables, en ce qu'elle provoque le destinataire pour envoyer un
nouveau message dont le contenu est précisé par le
L'instigateur du message original. Étant donné le potentiel de
abus, de tels messages de demande qui sont construits
doit contenir une indication claire qu'ils étaient
généré automatiquement (par exemple dans un Commentaires: tête
domaine) dans une tentative de résoudre un MIME
"/ External-body message" référence.
(2) MIME seront parfois utilisées dans des environnements qui
fournir une garantie de l'intégrité des messages et
authenticité. Le cas échéant, ces garanties peuvent s'appliquer
seulement le contenu réel direct de messages - ils
peut ou ne peut pas s'appliquer aux données accessibles via MIME de
"Message / external-body" mécanisme. En particulier, il
peut-être possible de contourner certains mécanismes d'accès
même lorsque le système de messagerie sécurisée est lui-même.
fournir une garantie de l'intégrité des messages et
authenticité. Le cas échéant, ces garanties peuvent s'appliquer
seulement le contenu réel direct de messages - ils
peut ou ne peut pas s'appliquer aux données accessibles via MIME de
"Message / external-body" mécanisme. En particulier, il
peut-être possible de contourner certains mécanismes d'accès
même lorsque le système de messagerie sécurisée est lui-même.
Il convient de noter que ce problème existe, soit avec
ou sans la disponibilité de mécanismes MIME. A
référence occasionnelle à un site FTP contenant un document
dans le texte d'un message sécurisé fait apparaître semblable
questions - la seule différence est que MIME prévoit
récupération automatique d'un tel matériel, et les utilisateurs peuvent
endroit confiance injustifiée est telle récupération automatique
des mécanismes.
ou sans la disponibilité de mécanismes MIME. A
référence occasionnelle à un site FTP contenant un document
dans le texte d'un message sécurisé fait apparaître semblable
questions - la seule différence est que MIME prévoit
récupération automatique d'un tel matériel, et les utilisateurs peuvent
endroit confiance injustifiée est telle récupération automatique
des mécanismes.
5.2.3.7. Des exemples et des explications supplémentaires
Lorsque le mécanisme externe du corps est utilisée en conjonction avec l'
"Multipart / alternative" type de média, il étend les fonctionnalités de
"Multipart / alternative" pour inclure le cas où une même entité est
prévu dans le même format, mais par des mécanismes différents de acccès.
Lorsque cela est fait à l'origine du message doit commander les pièces
d'abord en termes de formats préférés, puis par un accès privilégié
des mécanismes. Le spectateur du destinataire doit ensuite évaluer la liste
à la fois en termes de mécanismes de format et d'accès.
"Multipart / alternative" type de média, il étend les fonctionnalités de
"Multipart / alternative" pour inclure le cas où une même entité est
prévu dans le même format, mais par des mécanismes différents de acccès.
Lorsque cela est fait à l'origine du message doit commander les pièces
d'abord en termes de formats préférés, puis par un accès privilégié
des mécanismes. Le spectateur du destinataire doit ensuite évaluer la liste
à la fois en termes de mécanismes de format et d'accès.
Avec la possibilité émergente des systèmes très étendu fichiers, il
devient très difficile de savoir à l'avance l'ensemble des machines où un fichier
volonté et ne sera pas accessible directement à partir du système de fichiers.
Par conséquent, il peut être judicieux de fournir à la fois un nom de fichier, pour être jugé
directement, et le nom d'un ou plusieurs sites à partir de laquelle le fichier est
connu pour être accessible. Une mise en œuvre peut essayer de récupérer à distance
des fichiers via FTP ou tout autre protocole, en utilisant la récupération de fichiers anonyme
ou demander à l'utilisateur le nom et le mot de passe nécessaire. Si une
organisme externe est accessible via de multiples mécanismes, l'expéditeur peut
inclure plusieurs entités de type "message / external-body" au sein de la
parties du corps d'une entité englobant "multipart / alternative".
devient très difficile de savoir à l'avance l'ensemble des machines où un fichier
volonté et ne sera pas accessible directement à partir du système de fichiers.
Par conséquent, il peut être judicieux de fournir à la fois un nom de fichier, pour être jugé
directement, et le nom d'un ou plusieurs sites à partir de laquelle le fichier est
connu pour être accessible. Une mise en œuvre peut essayer de récupérer à distance
des fichiers via FTP ou tout autre protocole, en utilisant la récupération de fichiers anonyme
ou demander à l'utilisateur le nom et le mot de passe nécessaire. Si une
organisme externe est accessible via de multiples mécanismes, l'expéditeur peut
inclure plusieurs entités de type "message / external-body" au sein de la
parties du corps d'une entité englobant "multipart / alternative".
Cependant, le mécanisme externe du corps n'est pas destiné à être limité à
la récupération du fichier, comme illustré par l'accès de type serveur de courrier. Au-delà
cela, on peut imaginer, par exemple, en utilisant un serveur vidéo pour externe
références à des clips vidéo.
la récupération du fichier, comme illustré par l'accès de type serveur de courrier. Au-delà
cela, on peut imaginer, par exemple, en utilisant un serveur vidéo pour externe
références à des clips vidéo.
Les champs d'en-tête de message intégrés qui apparaissent dans le corps du
Données "message / external-body" doivent être utilisés pour déclarer le type de support
du corps externe si elle est différente de plaine US-ASCII rien
moins, puisque le corps externe ne possède pas de section d'en-tête à
déclarer son type. De même, toute Content-Transfer-Encoding autre
que "7bit" doivent également être déclarés ici. Ainsi, une complète
Un message "message / externe du corps", en se référant à un objet en PostScript
Format, pourrait ressembler à ceci:
Données "message / external-body" doivent être utilisés pour déclarer le type de support
du corps externe si elle est différente de plaine US-ASCII rien
moins, puisque le corps externe ne possède pas de section d'en-tête à
déclarer son type. De même, toute Content-Transfer-Encoding autre
que "7bit" doivent également être déclarés ici. Ainsi, une complète
Un message "message / externe du corps", en se référant à un objet en PostScript
Format, pourrait ressembler à ceci:
De: Quiconque
Pour: Quelqu'un
Date: Chaque fois que
Sujet: quel que soit
MIME-Version: 1.0
Message-ID: <id1@host.com>
Content-Type: multipart / alternative; boundary = 42
Content-ID: < id001@guppylake.bellcore.com >
Pour: Quelqu'un
Date: Chaque fois que
Sujet: quel que soit
MIME-Version: 1.0
Message-ID: <id1@host.com>
Content-Type: multipart / alternative; boundary = 42
Content-ID: < id001@guppylake.bellcore.com >
- 42
Content-Type: message / external-body; name = "BodyFormats.ps";
Site = "thumper.bellcore.com"; mode = "image";
access-type = ANON FTP; directory = "pub";
expiration = "Vendredi, 14 juin 1991 19:13:14 -0400 (EDT)"
Content-Type: message / external-body; name = "BodyFormats.ps";
Site = "thumper.bellcore.com"; mode = "image";
access-type = ANON FTP; directory = "pub";
expiration = "Vendredi, 14 juin 1991 19:13:14 -0400 (EDT)"
Content-Type: application / postscript
Content-ID: < id42@guppylake.bellcore.com >
Content-ID: < id42@guppylake.bellcore.com >
- 42
Content-Type: message / external-body; accès de type = fichier-local;
name = "/ u / nsb / écriture / RFC / RFC-MIME.ps";
Site = "thumper.bellcore.com";
expiration = "Vendredi, 14 juin 1991 19:13:14 -0400 (EDT)"
Content-Type: message / external-body; accès de type = fichier-local;
name = "/ u / nsb / écriture / RFC / RFC-MIME.ps";
Site = "thumper.bellcore.com";
expiration = "Vendredi, 14 juin 1991 19:13:14 -0400 (EDT)"
Content-Type: application / postscript
Content-ID: < id42@guppylake.bellcore.com >
Content-ID: < id42@guppylake.bellcore.com >
- 42
Content-Type: message / external-body;
access-type = serveur de courrier
server = "listserv@bogus.bitnet";
expiration = "Vendredi, 14 juin 1991 19:13:14 -0400 (EDT)"
Content-Type: message / external-body;
access-type = serveur de courrier
server = "listserv@bogus.bitnet";
expiration = "Vendredi, 14 juin 1991 19:13:14 -0400 (EDT)"
Content-Type: application / postscript
Content-ID: < id42@guppylake.bellcore.com >
Content-ID: < id42@guppylake.bellcore.com >
obtenir RFC-MIME.DOC
- 42 -
Notez que dans les exemples ci-dessus, la valeur par défaut Content-Transfer-
codage du "7 bits" est supposé que les données postscript externes.
codage du "7 bits" est supposé que les données postscript externes.
Comme le type "message / partial", les médias le "message / external-body"
type est destiné à être transparente, c'est-à transmettre le type de données
dans le corps extérieur, plutôt que de transmettre un message avec un corps de
ce type. Ainsi les têtes sur les parties extérieures et intérieures doivent être
fusionnés en utilisant les mêmes règles que pour "message / partial". En particulier,
cela signifie que le type de contenu et domaines sont remplacées,
mais le champ est préservée.
type est destiné à être transparente, c'est-à transmettre le type de données
dans le corps extérieur, plutôt que de transmettre un message avec un corps de
ce type. Ainsi les têtes sur les parties extérieures et intérieures doivent être
fusionnés en utilisant les mêmes règles que pour "message / partial". En particulier,
cela signifie que le type de contenu et domaines sont remplacées,
mais le champ est préservée.
Notez que, depuis les organismes externes ne sont pas transportés avec
la référence externe du corps, ils n'ont pas besoin de se conformer à transporter
limitations qui s'appliquent à la référence elle-même. En particulier,
transports de messagerie Internet peuvent imposer des limites de longueur 7 bits et la ligne, mais
celles-ci ne s'appliquent pas automatiquement à des références externes du corps binaires.
Ainsi, un Content-Transfer-Encoding n'est généralement pas nécessaire, mais
il est permis.
la référence externe du corps, ils n'ont pas besoin de se conformer à transporter
limitations qui s'appliquent à la référence elle-même. En particulier,
transports de messagerie Internet peuvent imposer des limites de longueur 7 bits et la ligne, mais
celles-ci ne s'appliquent pas automatiquement à des références externes du corps binaires.
Ainsi, un Content-Transfer-Encoding n'est généralement pas nécessaire, mais
il est permis.
Notez que le corps d'un message de type "message / external-body" est
régie par la syntaxe de base pour un 822 RFC message. En particulier,
rien avant la première paire consécutive de CRLFs est-tête
l'information, tout en quoi que ce soit après que de l'information du corps, qui est
ignorées pour la plupart des types d'accès.
régie par la syntaxe de base pour un 822 RFC message. En particulier,
rien avant la première paire consécutive de CRLFs est-tête
l'information, tout en quoi que ce soit après que de l'information du corps, qui est
ignorées pour la plupart des types d'accès.
5.2.4. D'autres sous-types de messages
Implémentations MIME doivent en général traiter les sous-types non reconnus du
"Message" comme étant équivalent à "application / octet-stream".
"Message" comme étant équivalent à "application / octet-stream".
Future sous-types de "message" destinés à être utilisés avec email devraient être
limité à l'encodage "7bit". Un autre type que «message» devrait être
utilisé si la restriction à "7 bits" n'est pas possible.
limité à l'encodage "7bit". Un autre type que «message» devrait être
utilisé si la restriction à "7 bits" n'est pas possible.
6. Expérimentales Type de support valeurs
Une valeur de type de média en commençant par les caractères "X-" est un organisme privé
valeur, d'être utilisé par les systèmes consentants d'un commun accord. Tout
Format absence d'une définition rigoureuse et public doit être nommé avec un
"X-" préfixe et les valeurs spécifiées au public ne doivent jamais commencer
"X". (Les anciennes versions du système Andrew largement utilisé utilisent le "X-
BE2 "nom, afin que les nouveaux systèmes devraient probablement choisir un autre nom.)
valeur, d'être utilisé par les systèmes consentants d'un commun accord. Tout
Format absence d'une définition rigoureuse et public doit être nommé avec un
"X-" préfixe et les valeurs spécifiées au public ne doivent jamais commencer
"X". (Les anciennes versions du système Andrew largement utilisé utilisent le "X-
BE2 "nom, afin que les nouveaux systèmes devraient probablement choisir un autre nom.)
En général, l'utilisation de "X-" types de niveau supérieur est fortement déconseillée.
Les développeurs devraient inventer des sous-types des types existants dans la mesure du
possible. Dans de nombreux cas, un sous-type de «demande» sera plus
approprié qu'un nouveau type de haut niveau.
Les développeurs devraient inventer des sous-types des types existants dans la mesure du
possible. Dans de nombreux cas, un sous-type de «demande» sera plus
approprié qu'un nouveau type de haut niveau.
7. Résumé
Les cinq types de supports discrets fournissent fournissent un système standardisé
mécanisme pour les entités de marquage comme "audio", "image", ou plusieurs autres
les types de données. Le «message» types de médias "multipart" et composites
permettre la structuration de mélange et hiérarchique des entités de différentes
types dans un seul message. Une syntaxe du paramètre distingué permet
plus de précisions sur les détails du format des données, en particulier l'
spécification des jeux de caractères de remplacement. Supplémentaire en option
champs d'en-tête fournissent des mécanismes pour certaines extensions jugées
souhaitable par de nombreux réalisateurs. Enfin, un certain nombre de médias utiles
types sont définis pour une utilisation générale par consentants agents utilisateurs, notamment
"Message / partial" et "message / external-body".
mécanisme pour les entités de marquage comme "audio", "image", ou plusieurs autres
les types de données. Le «message» types de médias "multipart" et composites
permettre la structuration de mélange et hiérarchique des entités de différentes
types dans un seul message. Une syntaxe du paramètre distingué permet
plus de précisions sur les détails du format des données, en particulier l'
spécification des jeux de caractères de remplacement. Supplémentaire en option
champs d'en-tête fournissent des mécanismes pour certaines extensions jugées
souhaitable par de nombreux réalisateurs. Enfin, un certain nombre de médias utiles
types sont définis pour une utilisation générale par consentants agents utilisateurs, notamment
"Message / partial" et "message / external-body".
9. Considérations sur la sécurité
Les problèmes de sécurité sont abordés dans le contexte de la
Type "application / postscript", du type "message / corps externe", et
dans la RFC 2048 . Les développeurs devraient accorder une attention particulière à la
implications pour la sécurité de tous les types de médias qui peuvent causer la télécommande
l'exécution des actions dans l'environnement du destinataire. Dans un tel
cas, la discussion du type "application / postscript" peuvent servir
comme un modèle pour envisager d'autres types de supports avec l'exécution à distance
capacités.
Type "application / postscript", du type "message / corps externe", et
dans la RFC 2048 . Les développeurs devraient accorder une attention particulière à la
implications pour la sécurité de tous les types de médias qui peuvent causer la télécommande
l'exécution des actions dans l'environnement du destinataire. Dans un tel
cas, la discussion du type "application / postscript" peuvent servir
comme un modèle pour envisager d'autres types de supports avec l'exécution à distance
capacités.
9. Adresses des auteurs
Pour plus d'informations, les auteurs de ce document sont les mieux contactés
via la messagerie Internet:
via la messagerie Internet:
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue Sud
West Covina, CA 91790
USA
Innosoft International, Inc.
1050 East Garvey Avenue Sud
West Covina, CA 91790
USA
Nathaniel S. Borenstein
Premières Holdings virtuels
25 Washington Avenue
Morristown, NJ 07960
USA
Premières Holdings virtuels
25 Washington Avenue
Morristown, NJ 07960
USA
MIME est le résultat des travaux du Groupe de travail de l'Internet Engineering
Groupe de travail sur la RFC 822 extensions. Le président de ce groupe,
Greg Vaudreuil, peut être contacté à:
Groupe de travail sur la RFC 822 extensions. Le président de ce groupe,
Greg Vaudreuil, peut être contacté à:
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
Courriel: Greg.Vaudreuil @ Octel.Com
Annexe A - Collected Grammaire
Cette annexe contient la grammaire BNF complet pour toute la syntaxe
spécifiée par ce document.
spécifiée par ce document.
En soi, cependant, cette grammaire est incomplète. Il se réfère par nom
plusieurs règles syntaxiques qui sont définis par la RFC 822 . Plutôt que de
reproduire ces définitions ici, et risquer des différences non intentionnelles
entre les deux, ce document se réfère simplement le lecteur à RFC 822
pour les définitions restantes. Chaque fois qu'un terme est indéfini, il
se réfère à la RFC 822 définition.
plusieurs règles syntaxiques qui sont définis par la RFC 822 . Plutôt que de
reproduire ces définitions ici, et risquer des différences non intentionnelles
entre les deux, ce document se réfère simplement le lecteur à RFC 822
pour les définitions restantes. Chaque fois qu'un terme est indéfini, il
se réfère à la RFC 822 définition.
limite: = 0 * 69 <bchars> bcharsnospace
bchars: = bcharsnospace / ""
bcharsnospace: = DIGIT / ALPHA / "" "/" ("/") "/
"+" / "_" / "," / "-" "." / /
"/" / ":" / "=" / "?"
"+" / "_" / "," / "-" "." / /
"/" / ":" / "=" / "?"
partie du corps: = <"message" tel que défini dans la RFC 822 , avec tous
les champs d'en-tête optionnel, non à partir de l'
spécifiée au tableau de bord limite, et avec l'
delimiter pas se produire n'importe où dans le
partie du corps. Notez que la sémantique d'un
une partie différente de la sémantique d'un message,
comme décrit dans le texte.>
les champs d'en-tête optionnel, non à partir de l'
spécifiée au tableau de bord limite, et avec l'
delimiter pas se produire n'importe où dans le
partie du corps. Notez que la sémantique d'un
une partie différente de la sémantique d'un message,
comme décrit dans le texte.>
gros delimiter: = séparateur «-»
tableau de bord: = "-" limite
; Frontière pris à partir de la valeur de
; Paramètre de limite de l'
; Champ Content-Type.
; Frontière pris à partir de la valeur de
; Paramètre de limite de l'
; Champ Content-Type.
delimiter: = CRLF tableau de bord
discard-texte: = * (* CRLF de texte)
, Peuvent être ignorés ou rejetés.
, Peuvent être ignorés ou rejetés.
encapsulation: = delimiter transport rembourrage
CRLF partie du corps
CRLF partie du corps
Epilogue: = discard-texte
multipart-corps: = [préambule CRLF]
tableau de bord transport rembourrage CRLF
partie du corps * encapsulation
tableau de bord transport rembourrage CRLF
partie du corps * encapsulation
gros delimiter transport rembourrage
[CRLF épilogue]
[CRLF épilogue]
Préambule: = discard-texte
transport padding: = * caractère LWSP
; Compositeurs NE DOIVENT PAS générer
, Le transport de longueur non nulle
, Rembourrage, mais les récepteurs doivent
; Être capable de gérer rembourrage
, Ajouté par les transports de message.
; Compositeurs NE DOIVENT PAS générer
, Le transport de longueur non nulle
, Rembourrage, mais les récepteurs doivent
; Être capable de gérer rembourrage
, Ajouté par les transports de message.
Contributions des utilisateurs:
Commentaire sur cette RFC, poser des questions, ou ajouter de nouvelles informations sur ce sujet:
Nom: E-mail:
Afficher mon email publiquement
Tapez le code affiché:
Commentaire du public: (50-4000 caractères)
Commentaire sur cette RFC, poser des questions, ou ajouter de nouvelles informations sur ce sujet:
Nom: E-mail:
Afficher mon email publiquement
Tapez le code affiché:
Commentaire du public: (50-4000 caractères)
Précédent: RFC 2045 - Extensions Multipurpose Internet Mail (MIME) Part One: Format des corps de message Internet
Suivant: RFC 2047 - MIME (Extensions Multipurpose Internet Mail) Troisième partie: Les extensions d'en-tête de message pour texte non-ASCII
[ Index RFC | Usenet FAQ | Web FAQ | Documents | Villes | Comtés ]
Certaines parties © 2013 Advameg, Inc. | Conditions d'utilisation
Texte Anglais original:
set of documents, collectively called the Multipurpose Internet Mail
Proposer une meilleure traduction
set of documents, collectively called the Multipurpose Internet Mail
Proposer une meilleure traduction
