Groupe de travail Réseau	G. Parsons, Nortel Networks	
Request for Comments : 3302	J. Rafferty, Brooktrout Technology	
RFC rendue obsolète : 2302 	septembre 2002	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Format de fichier d'image étiquetée (TIFF) 
– enregistrement du sous-type MIME image/tiff

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

Copyright
Copyright (C) The Internet Society (2002). Tous droits réservés.

Résumé
Le présent document décrit l’enregistrement du sous-type MIME image/tiff. Il précise l’enregistrement antérieur du sous-type par la {RFC1528].

Le présent document rend obsolète la [RFC2302].

1.	Conventions utilisées dans le document

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

2.	Généralités

Le présent document décrit l’enregistrement du sous-type MIME image/tiff. Le codage de base de TIFF (Format de fichier d'image étiquetée) est défini dans [TIFF].

3.	Groupe de travail Télécopie Internet

Le présent document a été produit par le groupe de travail Télécopie Internet de l’IETF. Tous les commentaires sur le présent document devraient être transmis à la liste de diffusion du groupe à < ietf-fax@imc.org >.

4.	Définition de TIFF

La révision 6.0 du format de fichier d'image étiquetée (TIFF, Tag Image File Format) est définie en détails par Adobe dans [TIFF]. La documentation peut être obtenue d’Adobe à :

Adobe Developers Association
Adobe Systems Incorporated
345 Park Avenue
San Jose, CA 95110-2704
USA
téléphone : 408-536-6000
Fax :   408-537-6000

On peut aussi trouver une copie de cette spécification à : http://partners.adobe.com/asn/developer/PDFS/TN/TIFF6.pdf 

Bien qu’une brève description de la portée et des caractéristiques soit fournie dans cette section à titre d’informations sur les fondements, le lecteur est invité à consulter la spécification TIFF originale [TIFF] pour obtenir les détails complets des caractéristiques techniques.

4.1	Portée de TIFF

TIFF décrit des données d’image qui viennent normalement de scanneurs, de captures de trames, et de programmes de retouche de peintures et photographies. TIFF n’est pas un langage d’imprimante ou de description de pages. L’objet de TIFF est de décrire et mémoriser des données de trames d’images. Un des buts principaux de TIFF est de fournir un environnement riche au sein duquel les applications puissent échanger des données d’images. Cette richesse est nécessaire pour tirer parti de diverses capacités des scanneurs et autres appareils d’imagerie. Bien que TIFF ait un format riche, il peut aisément être utilisé pour de simples scanneurs et applications et aussi parce que le nombre de champs requis est faible.

4.2	Caractéristiques de TIFF

Certaines des caractéristiques de TIFF (d’après [TIFF]) sont :
-	TIFF est capable de décrire des données d’image à deux niveaux, une échelle de gris, une palette de couleurs, et de pleine couleurs dans plusieurs espaces de couleurs.
-	TIFF comporte un certain nombre de schémas de compression qui permettent aux développeurs de choisir le meilleur compromis entre espace et temps pour leurs applications.
-	TIFF est conçu pour être extensible et pour évoluer en douceur lorsque apparaissent de nouveaux besoins.
-	TIFF permet d’inclure une quantité illimitée d’informations privées ou d’objet particulier.

5.	Définition MIME
5.1	image/tiff

Le type de contenu image/tiff a été défini précédemment dans la [RFC1528] comme contenant des données d’images codées en TIFF 6.0, avec une référence spécifique à un sous-ensemble appelé TIFF classe F. Le présent document redéfinit la définition originale image/tiff pour se référer aux données d’image codées en TIFF 6.0 [TIFF], cohérente avec la pratique existante pour les applications Internet à capacité TIFF. Cette définition est encore améliorée en introduisant le nouveau "paramètre d’application" (paragraphe 5.2) pour permettre l’identification d’un sous-ensemble spécifique de TIFF et les extensions TIFF pour les données d’image codées.

5.2	Paramètres d’application

Il y a des cas où il peut être utile d’identifier l’application applicable au contenu d’un corps d’image/tiff. Normalement, ce serait utilisé pour aider le receveur à répartir un paquetage de rendu convenable pour traiter l’affichage ou le traitement d’un fichier d’image. Il en résulte qu’un paramètre "application" facultatif est défini pour image/tiff pour identifier un sous-ensemble d’une application particulière de TIFF et d’extensions TIFF pour les données d’image codées, si il est connu. Aucune valeur n’est définie dans le présent document.

Exemple : Content-type : image/tiff; application=foo

Il n’y a pas de valeur par défaut pour application, car l’absence du paramètre application indique que l’image TIFF codée est du TIFF de base ou qu’il n’est pas nécessaire d’identifier l’application. Il appartient à la mise en œuvre du receveur de déterminer l’application (si nécessaire) et de rendre l’image à l’usager.

Les nouvelles valeurs pour le paramètre d’application image/tiff devront être approuvées par l’IESG avant enregistrement. Il en résulte que la publication d’une description de valeurs de paramètre dans une RFC est requise.

Les lignes directrices sur la rédaction dans les RFC des considérations relatives à l’IANA se trouvent dans la [RFC2434].

Un paramètre d’application est un conseil au receveur. Il NE DOIT PAS être utilisé comme une demande d’exécution aveugle d’un programme arbitraire.

Il devrait plutôt être vu comme une indication de la sorte d’application qui serait capable de traiter le contenu de la façon la plus appropriée.

6.	Enregistrement par l’IANA

To : ietf-types@iana.org
Objet : Enregistrement du type de support standard MIME image/tiff
Nom de type de support MIME : image
Nom de sous-type MIME : tiff
Paramètres exigés : aucun
Paramètre facultatif : application

Il n’y a pas de format spécifié pour la valeur de ce paramètre en plus de celui spécifié par la [RFC2045]. Diverses applications de TIFF peuvent définir des valeurs en tant que nécessaire pour donner des indications au receveur. Il n’y a pas de valeur par défaut pour application, car l’absence du paramètre application indique que l’image TIFF codée suit la spécification TIFF de base ou qu’il n’est pas nécessaire d’identifier l’application. Il appartient à la mise en œuvre de déterminer l’application (si nécessaire) et de rendre l’image à l’usager.

Considérations de codage : Ce type de support consiste en données binaires. Le codage base64 devrait être utilisé sur les transports qui ne peuvent pas s’accommoder directement de données binaires.

Considérations sur la sécurité : TIFF utilises une structure qui peut mémoriser les données et les attributs d’image de ces données d’image. Les champs définis dans la spécification TIFF sont de nature descriptive et fournissent des informations qui sont utiles pour faciliter le visionnage et le rendu des images par un receveur. À ce titre, les champs actuellement définis dans la spécification TIFF ne créent pas par eux-mêmes de risque de sécurité supplémentaire, car ces champs ne sont pas utilisés pour induire un comportement particulier de la part de l’application receveuse.
TIFF a une structure extensible, de sorte qu’il est théoriquement possible que des champs soient définis à l’avenir qui pourraient être utilisés pour induire des actions particulières de la part du receveur, et donc présenter des risques de sécurité supplémentaires, mais ce type de capacités n’est pas pris en charge dans la spécification TIFF référencée. Bien sûr, la définition des champs qui pourraient inclure de telles instructions de traitement n’est pas cohérente avec les buts et l’esprit de la spécification TIFF telles que définie aujourd’hui.

Considérations d’interopérabilité : La capacité des mises en œuvre à traiter toutes les applications (ou profils au sein des applications) définies de TIFF peut n’être pas générale. Il en résulte que les mises en œuvre peuvent décoder et tenter d’afficher l’image TIFF codée pour déterminer seulement que l’image ne peut pas être rendue. La présence du paramètre d’application peut aider à cette détermination avant répartition pour le rendu. Cependant, on devrait noter que la valeur du paramètre n’est pas destinée à porter des niveaux de capacités pour une application particulière.

Spécification publiée : TIFF (format de fichier d’image étiquetée (Tag Image File Format)) est défini dans : 
TIFF (TM) révision 6.0 – Finale, 3 juin 1992.
Adobe Developers Association
Adobe Systems Incorporated
345 Park Avenue
San Jose, CA 95110-2704
téléphone : 408-536-6000
Fax :   408-537-6000

On peut trouver une copie de cette spécification à : http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf 

Applications qui utilisent ce type de support : Imagerie, télécopie, messagerie et multimédia.

Informations supplémentaires :
Numéros magiques :
              II (petit boutien) :  49 49 2A 00 hex
              MM (gros boutien) :     4D 4D 00 2A hex
Extensions de fichier : .TIF
Code de type de fichier Macintosh : TIFF

Adresse de la personne & de messagerie à contacter pour d’autres informations :
Glenn W. Parsons  : gparsons@nortelnetworks.com 
James Rafferty :          jraff@brooktrout.com 

Utilisation prévue : COURANTE
Contrôleur des changements : James Rafferty

7.	Considérations sur la sécurité

TIFF utilise une structure qui peut mémoriser des données d’image et des attributs de ces données d’image. Les champs définis dans la spécification TIFF sont de nature descriptive et fournissent des informations qui sont utiles pour faciliter le visionnage et le rendu des images par un receveur. À ce titre, les champs actuellement définis dans la spécification TIFF ne créent pas par elles-mêmes de risque de sécurité supplémentaire, car les champs ne sont pas utilisés pour induire un comportement particulier par l’application receveuse.

TIFF a une structure extensible, de sorte qu’il est théoriquement possible que des champs puissent être définis à l’avenir qui pourraient être utilisés pour induire des actions particulières de la part du receveur, présentant donc des risques accrus pour la sécurité, mais ce type de capacités n’est pas pris en charge dans la spécification TIFF référencée. Bien sûr, la définition de champs qui incluraient de telles instructions de traitement ne serait pas en cohérence avec les objectifs et l’esprit de la spécification TIFF telle que définie aujourd’hui.

8.	Changements depuis la RFC 2302

* Correction du numéro magique.
* Amélioration des considérations sur la sécurité.
* Changement du contrôleur des modifications.
* Divers corrections rédactionnelles pour améliorer la clarté.

9.	Références

[RFC1528]	C. Malamud et M. Rose, "Principes de fonctionnement du sous-domaine TPC.INT : Impression à distance ; procédures techniques", octobre   1993. (Expérimental)

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2048]	N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-4289)

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

[RFC2302]	G. Parsons, J. Rafferty, S. Zilles, "Format de fichier d'image étiquetée (TIFF) – Enregistrement de sous-type d'image/tiff MIME", mars 1998. (Obsolète, voir RFC3302) (P.S.)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[TIFF]	Adobe Developers Association, TIFF (TM) Revision 6.0 - Final, 3 juin 1992.

10.	Adresse des auteurs

Glenn W. Parsons	James Rafferty	
Nortel Networks	Brooktrout Technology	
P.O. Box 3511, Station C	410 First Avenue	
Ottawa, ON  K1Y 4H7	Needham, MA  02494	
Canada	USA	
téléphone : 613-763-7582	téléphone : 781-433-9462	
Fax:   613-763-2697	Fax:   781-433-9268	
mél : gparsons@nortelnetworks.com 	mél : jraff@brooktrout.com 	

11.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

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

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