Résumé

  • Le RFC 1740, publié en décembre 1994, décrivait l’envoi des fichiers Macintosh par MIME. AppleSingle plaçait contenus et attributs dans un seul flux; AppleDouble séparait les informations propres au Mac de la branche de données.
  • Pour la plupart des fichiers demandant un emballage spécial, le document privilégiait multipart/appledouble : une partie application/applefile pour les ressources et renseignements du bureau, une autre partie identifiée par le type MIME des données.

Un dossier à deux compartiments

Sur beaucoup de machines, le mot « fichier » évoque une suite de données. Le Macintosh classique y rangeait aussi des éléments dans une seconde branche. La branche de données contenait ce qu’un autre ordinateur pouvait généralement exploiter. La branche de ressources pouvait porter des segments de programme, des images d’icônes et d’autres attributs. Les informations conservées par le Finder ajoutaient encore une pièce au dossier. Quand ce dossier devait traverser une messagerie conçue pour des systèmes très différents, il fallait décider qui porterait chaque pièce.

Les auteurs du RFC 1740, Patrik Faltstrom, Dave Crocker et Erik E. Fair, disposaient déjà du langage de MIME défini par le RFC 1521. Un message pouvait contenir plusieurs éléments dotés chacun de son type. Leur problème était concret : un destinataire sans Macintosh voulait ouvrir le contenu utile; un destinataire équipé d’un Mac devait retrouver la totalité du fichier. La compatibilité se jouait dans la manière de compartimenter le paquet.

AppleSingle proposait la valise fermée. Un flux continu enfermait contenus et attributs et voyageait sous le type application/applefile. La valise conservait les objets ensemble, au prix d’une tâche supplémentaire pour celui qui cherchait simplement la branche de données. Il fallait comprendre l’emballage AppleSingle avant d’en extraire le document. Pour une simple image reçue sur un autre système, ce détour ressemblait à une visite obligatoire au service des bagages.

AppleDouble ouvrait une poche extérieure. Son en-tête réunissait la branche de ressources et les informations du bureau; la branche de données restait séparée. Le tout prenait la forme multipart/appledouble, avec exactement deux sous-parties. La première, application/applefile, transportait les éléments propres au Mac. La seconde recevait le type approprié à ses données : image/gif dans l’exemple du RFC, application/octet-stream lorsqu’aucun type enregistré ne convenait. Le destinataire pouvait saisir la seconde partie sans apprendre toute l’anatomie du Macintosh. Le Mac, lui, gardait accès aux deux.

Le texte évitait d’emballer par principe tout ce qui sortait d’un Mac. Un document doté d’un type MIME bien connu et d’une branche de ressources absente ou insignifiante pouvait partir comme élément MIME ordinaire. À l’autre extrême, un document sans branche de données devait employer AppleSingle. AppleDouble était le choix habituel pour les autres cas, notamment les ressources substantielles ou des données sans type MIME reconnu. La règle suivait la forme réelle du fichier plutôt qu’un rituel imposé à chaque pièce jointe.

Les contraintes du transport réapparaissaient dans les détails. Les éléments binaires d’AppleSingle ou de l’en-tête AppleDouble pouvaient avoir besoin d’un codage de transfert; le RFC indiquait Base64 comme choix le plus sûr pour les canaux restrictifs. Il recommandait aussi un paramètre name afin de donner un indice sur le nom du fichier, mais la syntaxe héritée de MIME limitait cette valeur à l’US-ASCII sur sept bits. La messagerie savait désormais préserver une architecture de fichier complexe, tandis que la petite étiquette du colis restait attachée aux anciennes habitudes du courrier.

Le résultat était une décision de répartition. Les détails propres au Mac ne disparaissaient pas au profit du plus petit dénominateur commun. Les données utiles à un autre système ne restaient pas prisonnières d’un bloc opaque. Les deux publics recevaient le même message, avec des gestes d’ouverture différents. Une bonne partie de l’interopérabilité consiste justement à choisir à quel endroit placer le travail de déballage.

Ce courriel de 1994 n’avait rien d’un miracle graphique. C’était une enveloppe divisée intelligemment. Dans la poche avant, le document qu’un voisin pouvait lire. Dans l’autre, les pièces qui donnaient au fichier Macintosh sa vie complète. AppleDouble permettait à chacun d’ouvrir sa poche sans jeter l’autre à la corbeille.