Groupe de travail Réseau

Modèle de type de contenu principal
pour les extensions multi-objets de la messagerie Internet

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.

L'objet du présent mémoire est de proposer une mise à jour de la RFC2045 pour inclure un nouveau type de contenu principal sous le nom de "model". La RFC2045 [1] décrit des mécanismes pour spécifier et décrire le format des corps de message Internet via des paires de type/sous-type de contenu. Nous pensons que "model" définit un type fondamental de contenu avec des aspects uniques de présentation, de matériel et de traitement. Divers sous-types de ce type principal sont prévus dans l'immédiat mais seront traités dans des documents distincts.

Table des matières

1. Généralités 1

2. Définition d'un modèle 1

3. Mécanismes de consultation 2

4. Codage et transport 3

5. Considérations pour la sécurité 4

6. Adresse des auteurs 4

7. Sous-types attendus 4

8. Appendices 5

8.1 Appendice A -- Détails étrangers sur les sous-types attendus 5

8.2 Appendice B -- Références et citations 6

8.3 Appendice C -- Matériel 7

8.4 Appendice D -- Exemples 7

9. Remerciements 8

Le présent document va préciser ce qu'est un modèle, montrer des exemples de modèles, et exposer les avantages du regroupement de modèles. Il ne traite pas directement des sous-types prévus car ceux-ci seront traités par leurs propres enregistrements distincts. Certains des sous-types prévus immédiatement sont énumérés à la section 7.

Le présent document est un document de discussion pour une définition acceptée, destinée à former éventuellement une extension normalisée à la RFC2045. On vise les développeurs de filtres d'entrée/sortie, les logiciels de présentation et les matériels, ceux qui sont impliqués dans le transport MIME, et les décodeurs.

Un type principal de modèle MIME est une représentation de comportement ou physique échangeable électroniquement au sein d'un certain domaine. Chaque sous-type de la structure de modèle a des caractéristiques uniques, exactement comme chaque sous-type dans les autres types principaux. Le fait important est que ces divers sous-types peuvent être convertis les uns dans les autres avec moins de perte d'information que dans les autres types principaux. Ce fait groupe ces sous-types ensemble dans le type principal de modèle. Tous les sous-types attendus ont plusieurs caractéristiques en commun et ils sont uniques dans ce type principal.

Pour résumer grossièrement, les modèles sont des structures multidimensionnelles composées d'un ou plusieurs objets. Si il y a plusieurs objets, un des objets définit l'arrangement/réglage/relations avec les autres. Ces objets ont tous des systèmes de coordonnées calibrés mais ces systèmes ne sont pas nécessairement dans les mêmes unités ni dans la même dimension. Plus précisément :

1. Ils ont trois dimensions ou plus qui sont les bases du système et forment un système orthogonal (tout système orthogonal est suffisant).

Ce système est spécifiquement défini en termes d'ensemble orthogonal de fonctions de base [pour un sous-espace de l'espace de la fonction L^2] sur un système de coordonnées de dimension 3 ou plus. Noter que cela n'empêche pas des systèmes à biais régulier, des coordonnées elliptiques, différents espaces vectoriels, etc.

3. Ils ont des facteurs d'adaptation ou de calibration qui sont en rapport avec les unités physiques (force, moment, temps, vitesse, accélération, taille, etc.). Donc, un fichier IGES va spécifier une construction de taille non arbitraire, un maillage computationnel et des modèles en langage de modélisation de réalité virtuelle (VRML, Virtual Reality Modeling Language) vont avoir des unités spatiales/temporelles réelles. Cela permet que des éléments différents soient combinés de façon non arbitraire.

4. Les modèles peuvent être des objets uniques ou être composés d'une collection d'objets. Ces objets normalement indépendants sont arrangés selon un scénario maître/esclave de sorte qu'un objet agisse comme la référence, ou l'objet principal, qui définit comment les autres objets interagissent et se comportent. Cela permet la création de modèles mathématiques, physiques, économiques, comportementaux, etc. qui sont normalement composés d'éléments différents. La clé est dans la description : ces types décrivent comment quelque chose "se comporte" ; à la différence des types de données normaux qui décrivent comment quelque chose "est".

L'inclusion de ce système "collectif" fonctionne de façon similaire à celle du type multipart/related du système de messagerie qui définit les actions des parties individuelles. Il appartient aux auteurs de sous-types de faire une spécification plus approfondie des sous-types model/* qui utilisent ces propriétés.

a. La dimension par défaut sera spatiale et temporelle (mais toutes sont admises).

b. On suppose que les modèles contiendront la structure sous-jacente qui peut ou non être immédiatement disponible à l'utilisateur (champs de vecteurs dynamiques fluides, propagation électromagnétique, spécificateurs dimensionnels IGES en inter relation, matériels et opérateurs VRML, etc.)

c. On suppose que la conversion d'ensemble de base entre domaines modèles est sans perte. L'interprétation des données peut changer mais pas la spécification, c'est-à-dire convertir le modèle des U.S.A. "Produit national brut" en un modèle VRML et naviguer à travers lui pour explorer la variances et les inter relations. Le modèle a de nombreuses dimensions mais aussi des "passages" et des "corridors" reliant ses différentes parties. Une situation similaire est vraie pour les maillages et les fichiers de conception assistée par ordinateur (CAD, computer-aided design). La clé est d'identifier la conversion d'ensemble de base qui a un sens.

d. Les modèles sont groupés pour assurer MOINS de perte d'information entre les sous-types du modèle que des sous-types aux autres types principaux. (C'est-à-dire, convertir un modèle chimique en une image introduit plus de pertes que de le concerter en un modèle VRML).

Les éléments c et d ci-dessus définissent le groupement pour les modèles de façon similaire à celle dont les "images" et les "vidéos" sont groupées ensemble ; pour assurer moins de pertes d'information. Il est évident que convertir d'une image GIF en image JPEG perd moins d'information que de convertir d'une image GIF en un fichier audio AU.

Avant de proposer un sous-type pour le type principal model/*, il est suggéré que l'auteur du sous-type examine la définition (ci-dessus) de ce qu'est un model/* et la liste (ci-dessous) de ce qu'un model/* n'est pas. Des consultations supplémentaires avec les auteurs des sous-types existants de model/* sont aussi suggérées.

De même, la liste de discussion VRML a été archivée à : http://vrml.wired.com/arch/ et des discussions sur le groupe comp.mail.mime peuvent présenter un certain intérêt. Des résumés de la discussion sur les sous-types model/* existants peuvent être référencées dans ces documents respectifs.

La communauté du maillage a actuellement de nombreuses géométries de maillage différentes au titre de différents paquetages. Les bibliothèques en accès libre doivent être annoncées plus qu'elles ne l'ont été par le passé pour stimuler le développement de paquetages interopérables. On espère qu'en suivant l'exemple de la communauté VRML et en créant une bibliothèque librement accessible de fonctions d'entrée/sortie pour les maillages [11] ce problème sera atténué pour la communauté du maillage. Un visionneur de maillage en accès libre se conformant à ces standards est disponible actuellement pour diverses plateformes. La consultation des auteurs du système de maillage, à http://www-dsed.llnl.gov/documents/tests/mesh.html sera bénéfique.

La communauté IGES a une suite d'essais et d'utilitaires de conformité pour jauger la conformité aux spécifications et les auteurs de logiciels sont invités à les consulter auprès du NIST [14].

a. Les sous-types de modèles non reconnus devraient au minimum être traités comme des "flux d'application/octet". Les mises en œuvre peuvent choisir de passer des sous-types de modèle qu'elles ne reconnaissent pas spécifiquement à une application de visionnage de modèle robuste d'utilisation générale, si une telle application est disponible.

b. Différents sous-types de modèle peuvent être codés comme des représentations textuelles ou comme des données binaires. Sauf notation contraire dans l'enregistrement de sous-type, les sous-types de modèle devraient être supposés contenir des données binaires, ce qui implique un codage de contenu en base64 pour les transferts par messagerie électronique et binaires pour ftp et http.

c. La syntaxe formelle pour les sous-types du type principal de modèle devraient ressembler à ceci :

Considérations de codage : le codage en base64 est recommandé lors de la transmission de documents model/* par messagerie électronique MIME.

Spécification publiée : Ce document. Voir à l'Appendice B des références à certains des sous-types attendus.

Les paramètres facultatifs comportent les conditions de démarrage et les valeurs des variables utilisées au titre des sous-types. Un ensemble de base est décrit ici pour les seuls besoins de l'illustration et seront décrits en détail au titre de leurs sous-types respectifs :

Ceci est utilisé comme "conseil" pour choisir les programmes de visionnage applicables.

état : = chaîne ; "statique" ou "dynamique". En "statique", l'observateur peut se déplacer, effectuant donc des translations, rotations, pans, zooms, etc. mais les données ne changent pas. En "dynamique", les données elles-mêmes sont manipulées via des développements hélicoïdaux, des élongations, des changements d'échelles, etc. Noter que l'évolution du temps est une opération statique car elle est juste une translation le long d'une des principales dimensions alors que l'élongation d'un cube ou la déformation d'un objet sont des opérations dynamiques.

Noter que cette liste de paramètre dynamiques ne constitue pas une limite pour ceux spécifiés par les divers sous-types.

d. Les questions spécifiques se rapportant aux divers sous-types sont traitées au titre de la description de ces sous-types spécifiques. Ce qui suit est un exemple d'un en-tête MIME typique utilisé pour les besoins du transport de messagerie :

Noter que les fichiers de données sont en "lecture-seule" et ne contiennent pas de modificateur de système de fichiers ou de commandes batch/macro. Les données transportées ne sont pas auto modifiantes mais peuvent contenir des interrelations. Les fichiers de données peuvent cependant contenir une "vue par défaut" qui est ajoutée par l'auteur au moment de la création du fichier. Cette "vue par défaut" peut manipuler des variables de visionnage, l'angle de vue par défaut, l'éclairage, les options de visualisation, etc. Cette visualisation peut aussi impliquer le calcul de variables ou valeurs pour l'affichage sur la base de certaines données brutes. Pour des équipements motorisés, cela peut changer la position à partir de l'état du matériel au repos en fonction de l'orientation de démarrage de l'objet.

La structure interne des fichiers de données peut conduire les agents à accéder à des données supplémentaires à partir du réseau (c'est-à-dire, des inclusions) dont les limites de sécurité ne peuvent être prévues. Les actions fondées sur ces inclusions relèvent des définitions de sécurité des inclusions. D'autres commentaires sur les considérations de sécurité pour les sous-types seront contenues dans chaque enregistrement de sous-type.

Le tableau 1 fait la liste de certains noms de sous-type de modèle attendus. Des suggestions d'extensions de trois lettres sont également fournies pour la compatibilité avec le DOS mais leur besoin est heureusement diminué par l'utilisation de systèmes d'exploitation plus robustes sur les plates-formes de PC. L'extension "silo" est donnée pour la rétro compatibilité. Mesh a un longue liste de conseils car la diversité actuelle est immense. À l'avenir, le besoin de ces conseils va diminuer car les fichiers se décrivent d'eux-mêmes. Le présent document n'enregistre pas ces sous-types ; ils seront traités dans des documents distincts.

On espère que model/mesh utilisera aussi un certain nombre de paramètres qui vont aider l'utilisateur final à déterminer le type des données sans avoir à les examiner. Cependant, on notera que les fichiers mesh se décrivent tout seuls.

Les sous-types énumérés ci-dessus sont quelques un des types prévus qui sont déjà utilisés. On remarquera que le type IGES est déjà enregistré comme "application/iges" et que cette RFC déclare qu'un type plus approprié est désiré. Noter que l'auteur de "application/iges" est un des auteurs de cette soumission de "model" et que application/iges sera réenregistré sous model/iges au moment approprié.

Le type VRML obtient une large acceptation et a de nombreux efforts de développement en parallèle pour différentes plates-formes. Ces efforts sont alimentés par la livraison de la bibliothèque QvLib pour lire les fichiers VRML ; sans elle, l'effort VRML serait moins avancé. Cela a permis un type de données cohérent et a établi un ensemble de standards de facto. D'autres efforts VRML incluent des interfaces vers d'autres sortes de matériels (au delà du simple affichage visuel) et les personnes impliquées dans l'effort VRML pensent plus solliciter les cinq sens. À la différence d'autres schémas de "modélisation de la réalité", VRML n'est la propriété d'aucun fabricant et devrait connaître une croissance similaire à celle des autres standards ouverts.

Le type mesh est un rejeton des efforts de maillage computationnel existants et, comme VRML, s'appuie sur une bibliothèque en accès libre. Aussi comme VRML, il y a d'autres systèmes de maillage brevetés mais il y a des convertisseurs qui transposent de ces systèmes fermés au type mesh. Les maillages en général ont un dispositif d'association qui maintient la connexité entre les nœuds. On notera que la plupart des maillages modernes sont dérivés de fichiers CAD solides.

Les communautés de la modélisation en 3D et de CAD utilisent un certain nombre de formats de fichier pour représenter des modèles en 3D ; ces formats sont largement utilisés pour échanger des informations, et il existe des convertisseurs pleins ou à pertes, entre les formats, soit indépendants soit intégrés dans des applications largement utilisées. Le format VRML est en train de devenir rapidement un standard pour l'affichage d'informations en 3D sur la Toile mondiale.

Pendant de nombreuses décennies, des éléments finis et des codes de domaines à différence de temps finies ont généré des structures de maillage qui tentent d'utiliser la géométrie physique des structures en connexion avec divers paquetages physiques pour générer des simulations d'événements du monde réel incluant la propagation d'ondes électromagnétiques, la dynamique des fluides, des concepts de moteur, etc. Les données qui en résultent sont alors post traitées pour examiner le résultat dans diverses formes. Le sous-type de maillage proposé inclura à la fois la géométrie et des données résultantes de scalaires/vecteurs/tenseurs. Un point important à noter est que beaucoup de maillages modernes sont générés à partir de constructions de solides utilisant des paquetages CAD.

La motivation pour le maillage est venue de discussions avec d'autres communautés sur leurs exigences en matière de concepts. De nombreuses descriptions de CAD ou de scènes sont composées d'un petit nombre d'objets complexes alors que les maillages computationnels sont composés de grands nombres d'objets simples. Un maillage 3D d'un million d'éléments est petit. Un maillage structuré en 3D de 100 000 000 d'éléments est grand. Chaque objet peut aussi avoir une quantité arbitraire de données associées et les informations de connexité du maillage sont importantes pour optimiser l'utilisation du maillage. Aussi, le maillage lui-même est usuellement sans intérêt mais les paquetages de post traitement peuvent agir sur les données sous-jacentes ou un moteur de calcul peut traiter les données comme des entrées.

Les maillages diffèrent principalement des autres sortes de scènes en ce qu'ils sont composés d'un grand nombre d'objets simples qui peuvent contenir des paramètres non spatiaux arbitraires, dont tous n'ont pas besoin d'être visibles, et qui ont une connexité implicite et une liste de voisins. Ce dernier point est la caractéristique clé d'un maillage. On notera que la plupart des maillages sont générés cependant à partir de fichiers CAD. Le type mesh a des fonctions d'association parce que la physique sous-jacente a été utilisée pour calculer les interactions (si vous écraser une voiture contre un poteau téléphonique, vous obtenez une voiture abîmée et un poteau plié). Les maillages computationnels les plus intéressants sont en 4D avec des composantes de résultats multidimensionnels supplémentaires.

(Le texte suivant, qui n'est reproduit que pour servir de référence, est tiré de "U.S. Product Data Association and IGES/PDES Organization Reference Manual," juin 1995 ; avec la permission de l'auteur.)

IGES (Initial Graphics Exchange Specification) la spécification d'échange graphiques initiaux, définit un format de données neutre qui permet l'échange d'informations numériques entre des systèmes de conception assistée par ordinateur (CAD, computer-aided design).

Les systèmes de CAD sont de plus en plus utilisés de nos jours pour des applications dans toutes les phases de la conception, de l'analyse, de la fabrication et des essais des produits. Comme le concepteur peut utiliser le système d'un fournisseur alors que le fabricant ou le sous-traitant peut utiliser d'autres systèmes, il est nécessaire d'être capable d'échanger des données numériques entre tous les systèmes de CAD.

Les bases de données des systèmes de CAD des différents fabricants représentent souvent différemment les mêmes constructions de CAD. Un arc circulaire sur un système peut être défini par un point central, par son point de départ et de fin, alors que sur un autre, il est défini par son centre, son diamètre et son angle de début et de fin. IGES permet l'échange de telles données, en fournissant, dans le domaine public, une définition et un format neutres pour l'échange de telles données.

En utilisant IGES, l'usager peut échanger des modèles de données de produit sous la forme de canevas, de surface, ou de représentations solides aussi bien que de représentations de surface. Les traducteurs convertissent le format de la base de données interne propriétaire d'un fabricant en format neutre IGES et du format IGES en une base de données interne d'un autre fabricant. Les traducteurs, appelés pré- et post-traitements, sont usuellement disponibles auprès des fabricants au titre de leurs lignes de produits.

Les applications prises en charge par IGES incluent des dessins traditionnels d'ingénierie aussi bien que des modèles pour l'analyse et/ou diverses fonctions de fabrication. En plus de la spécification générale, IGES comporte aussi des protocoles d'application dans lesquels le standard est interprété pour satisfaire aux exigences spécifiques d'une discipline.

La technologie IGES suppose qu'une personne est disponible du côté réception pour interpréter la signification des données du modèle de produit. Par exemple, une personne est nécessaire pour déterminer combien de trous sont dans une partie car le trou lui-même n'est pas défini. Il est représenté en IGES par son composant géométrique et donc, ne peut pas se distinguer des bords circulaires d'une tige.

Le format IGES a été enregistré auprès de l'autorité d'allocation des numéros de l'Internet (IANA) comme le type d'extension multi objet de messagerie Internet (MIME) "application/iges". L'utilisation du type/sous-type de message dans les messages Internet facilite la reconnaissance uniforme d'un fichier IGES pour son acheminement sur une visionneuse ou un traducteur.

La version 1.0 de la spécification a été adoptée comme norme nationale américaine (ANS Y14.26M-1981) en novembre 1981. Les versions 3.0 et 4.0 de la spécification ont ensuite été approuvées par l'ANSI. La version actuelle de IGES 5.2 a été approuvée par l'ANSI sous les nouvelles lignes directrices de la U.S. Product Data Association. Selon ces lignes directrices, l'organisation IGES/PDES (IPO, IGES/PDES Organization) est devenue l'organisme de normalisation accrédité pour les normes d'échange de données de produits. Cette dernière norme est USPRO/IPO-100-1993.

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

[2] Fitzgerald P., "Molecules-R-Us Interface to the Brookhaven Data Base", Computational Molecular Biology Section, National Institutes of Health, USA ; voir de plus amples détails à http://www.nih.gov/htbin/pdb ; Peitsch M.C, Wells T.N.C., Stampf D.R., Sussman S. J., "The Swiss-3D Image Collection And PDP-Browser On The Worldwide Web", Trends In Biochemical Sciences, 1995, 20, 82.

[3] "Proceedings of the First Electronic Computational Chemistry Conference", Eds. Bachrach, S. M., Boyd D. B., Gray S. K, Hase W., Rzepa H.S, ARInternet: Landover, 7 novembre, 2 décembre 1994, sous presse ; Bachrach S. M, J. Chem. Inf. Comp. Sci., 1995, sous presse.

[4] Richardson D.C., and Richardson J.S., Protein Science, 1992, 1, 3; D. C. Richardson D. C., and Richardson J.S., Trends in Biochem. Sci.,1994, 19, 135.

[5] Rzepa H. S., Whitaker B. J., and Winter M. J., "Chemical Applications of the World-Wide-Web", J. Chem. Soc., Chem. Commun., 1994, 1907; Casher O., Chandramohan G., Hargreaves M., Murray-Rust P., Sayle R., Rzepa H.S., and Whitaker B. J., "Hyperactive Molecules and the World-Wide-Web Information System", J. Chem. Soc., Perkin Trans 2, 1995, 7; Baggott J., "Biochemistry On The Web", Chemical & Engineering News, 1995, 73, 36 ; Schwartz A.T, Bunce D.M, Silberman R.G, Stanitski C.L, Stratton W.J, Zipp A.P, "Chemistry In Context - Weaving The Web", Journal Of Chemical Education, 1994, 71, 1041.

[6] Rzepa H.S., "WWW94 Chemistry Workshop", Computer Networks and ISDN Systems, 1994, pages 27, 317 et 328.

[7] S.D. Nelson, "Email MIME test page", Lawrence Livermore National Laboratory, 1994. Voir à http://www-dsed.llnl.gov/documents/WWWtest.html et à http://www-dsed.llnl.gov/documents/tests/email.html

[8] C. Parks, "Registration of new Media Type application/iges", ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ application/iges, 1995.

[9] G. Bell, A. Parisi, M. Pesce, "The Virtual Reality Modeling Language", http://sdsc.edu/SDSC/Partners/vrml/Archives/vrml10-3.html, 1995.

[10] S.D. Nelson, "Registration of new Media Type model/mesh", ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/model/ mesh, 1997.

[11] "SILO User's Guide", Lawrence Livermore National Laboratory, University of California, UCRL-MA-118751, 7 mars 1995,

[12] E. Brugger, "Mesh-TV: a graphical analysis tool", Lawrence Livermore National Laboratory, University of California, UCRL-TB-115079-8, http://www.llnl.gov/liv_comp/meshtv/mesh.html

De nombreux types de matériels existent déjà pour traiter certains des types de données des modèles attendus ; ils ne figurent ici que pour illustrer notre propos :

les verres stéréo, les machines de lithographie en 3D, les systèmes de fabrication automatisés, les gants numériques (avec retour), les machines à moudre, les aromascopes, les fouloirs.

Ce paragraphe rassemble une collection de pointeurs pour illustrer ce que recouvre le type de modèle :

Nos remerciements vont à Henry Rzepa (h.rzepa@ic.ac.uk), Peter Murray-Rust (pmr1716@ggr.co.uk), Benjamin Whitaker (B.J.Whitaker@chemistry.leeds.ac.uk), Bill Ross (ross@cgl.ucsf.EDU), et aux autres membres de la communauté de la chimie qui sont à la base du projet initial de ce document. Celui-ci met à jour un projet Internet de l'IETF dans lequel était formulée la contribution initiale du monde de la chimie, et il incorpore les suggestions reçues durant la période de discussion qui a suivi, qui a indiqué le soutien de la communauté scientifique. Elles ont abouti à entreprendre un document d'un niveau supérieur incorporant les sciences physiques [2] à [7]. La proposition de ce modèle a tiré un grand parti du travail de base antérieur et de l'intérêt soutenu de ces communautés.

Les auteurs tiennent de plus à remercier Keith Moore (moore@cs.utk.edu), lilley (lilley@afs.mcc.ac.uk), Wilson Ross (ross@cgl.ucsf.EDU), Hansen (hansen@pegasus.att.com), Alfred Gilman (asg@severn.wash.inmet.com), et Jan Hardenbergh (jch@nell.oki.com) sans lesquels ce document n'aurait pas été possible. Nos remerciements également à Mark Crispin (MRC@CAC.Washington.EDU) pour ses commentaires sur la précédente version et à Cynthia Clark (cclark@ietf.org) qui a édité les différentes versions.

Groupe de travail Réseau	S. Nelson, LLNL
Request for Comments : 2077	C. Parks, NIST
Catégorie : En cours de normalisation	Mitra, WorldMaker
Traduction Claude Brière de L'Isle	janvier 1997

S. D. Nelson	C. Parks	Mitra
Lawrence Livermore National Laboratory,	National Institute of Standards & Technology	WorldMaker
7000 East Ave., L-153,	Bldg 220, Room B-344	1056 Noe
Livermore CA 94550, USA.	Gaithersburg, MD 20899, USA.	San Francisco, CA 94114
mél : nelson18@llnl.gov	mél : parks@eeel.nist.gov	mél : mitra@earth.path.net

Principal/sous-type	extensions suggérées	Référence
model/iges	igs, iges	[8]
model/vrml	wrl	[9]
model/mesh	msh, mesh, silo	[10]