FR 2838268 A1 20031010 FR 0204248 A 20020405 de communication qui doit être fournie à un utilisateur du terminal. L'invention concerne les outils de compression de données à la volée utilisés sur les réscaux, et en particulier sur Internet. Ces outils visent à optimiser le flux ou " bande passante " et augmenter ainsi la vitesse d'affichage des informations au niveau du client internaute. Pour le client, ces outils permettent une réduction du temps de chargement des contenus, c'est à dire une meilleure perception de la qualité de service (QoS) et également une réduction des coûts lorsque la connexion est facturée au volume. Il existe à ce jour plusieurs solutions d'accélération de flux sur le réseau internet, appelées Booster Web, qui répondent à cette problématique, mais aucune ne correspond à une réelle offre en c_ur de réseau, applicable de manière simple à différents types d 'utilisateurs. Les Booster avec client nécessitent l'installation d'un module particulier sur ie poste du client. Ce module local on plug'in va en fait modifier la structure des messages échangés entre le client et le booster. A la communication selon le protocole habituel HTTP (Hypertext Transport Protocol) se substitue un protocole propriétaire. Les Booster " TCP " modifient la structure des messages, d'autres se contentent de modifier la logique de reprise d'envoi TCP en l'adaptant au temps de réponse du réseau comme les téléphones mobiles par exemple. Les Booster sans client ne modifient pas les messages http port 80, ils utilisent des entêtes classiques. Mais il est alors indispensable de les déclarer dans les propriétés des navigateurs comme on le ferait pour un cache classique. De plus, certains boosters possèdent aussi une fonction " cache " et d'autres annoncent étre conformes au protocole ICP (protocole de communication entre caches). Ces solutions nécessitent donc d'intervenir sur les logiciels installés au niveau de l'ordinateur de l'internaute et sont donc loin d'être transparentes pour l'utilisateur. On se propose selon l'invention de résoudre cet inconvénient, c'est à dire de proposer un outil et un procédé de compression de données à la volée qui soit transparent pour l'internaute, c'est à dire qui ne nécessite pas d'intervention sur l'ordinateur ou le réscau local de celui-ci. Ce but est atteint selon l' invention grâce à u n procédé de compression à la volée de données fournies par un serveur d'un réseau collectif tel qu'internet en réponse à une requête d'un terminal de consultation, dans lequel procédé on fournit un module de compression de données, et un module de redirection prévu pour recevoir des donnces fournies par le serveur et les rediriger vers le module de compression, ce module de redirection étant également prévu pour recevoir des données depuis le module de compression et les rediriger vers le terminal de consultation, procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal et on effectue dans le module de compression, sur les donnces demandées par la requête et fournies par le serveur une compression qui est adaptée aux indications d'aptitude contenues dans la requête. On propose également selon l'invention un dispositif de compression de données à la volée dans un réscau collectif tel que le réseau Internet, comprenant un module de compression et un module de redirection, ce module de redirection étant prévu pour recevoir des données fournies par un serveur en réponse à une requête de consultation émise par un terminal de consultation, et rediriger ces données vers le module de compression, ce module de redirection étant également prévu pour recevoir des données fournies en retour par le module de compression et les rediriger vers le terminal de consultation, ce dispositif incluant en outre des moyens pour examiner, dans une requête de consultation de donnces émise par un terminal, une indication concernant une aptitude à la décompression du terminal considéré, et des moyens pour commander une compression par le module de compression qui est adaptée à l'indication d'aptitude à la décompression contenue dans la requête. D'autres caractéristiques7 buts et avantages de l'invention appara^tront mieux à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles: - la figure 1 est un schéma simplifié d'un ensemble de compression de donnces selon l'invention; - la figure 2 est un autre schéma simplifié d'un ensemble selon l'invention; - la figure 3 représente de manière détaillée ce même ensemble selon l'invention; - la figure 4 représente de manière détaillée un serveur iCAP conforme à une variante de l'invention; - la figure 5 est un organigramme représentatif d'un procédé selon une variante de l'invention; - la figure 6 est un organigramme de donnces et d'instructions selon une variante de l'invention. Le dispositif décrit ci-après utilise un protocole d'échange de données destiné à permettre des modifications de contenus sur l'internet, protocole appelé iCAP - Internet Content Adaptation Protocol -. Le dispositif de la figure 1 est architecturé autour de deux modules 10 et 20 de type iCAP, à savoir un cache 10 du type iCAP client et un serveur 20 de modification de contenu, du type serveur iCAP à " modification de réponse " selon la terminologie énoncée par le protocole iCAP. Lorsqu'un utilisateur demande, par l'intermédiaire d'un logiciel navigateur fonctionnant sur son ordinateur personnel 30, à accéder à une page Web, les étapes suivantes sont mis en _uvre dans le dispositif de la figure 1. D'abord une requête HTTP est envoyée vers le cache 10, également appelé transparent dans le cadre d'un ISP - Internet Service Provider -). Le cache 10 envoie alors une requête HTTP à un serveur Web d'origine 40, contenant cette page. Le serveur Web 40 renvoie la page demandée au cache 10. Le cache 10 agissant maintenant comme client iCAP redirige cette réponse vers le serveur iCAP 20 précédemment mentionné, en lui faisant passer la page complète. Le serveur iCAP 20 traite alors cette demande en faisant appel à un service de modifications de contenus intégré au serveur, puis répond au cache 10 en renvoyant le résultat du traitement: la page modifiée (ou non comme on le verra par la suite). Enfin, le cache 10 retourne à l'utilisateur final 30 ia réponse du serveur iCAP 10 et stocke également cette réponse. Le scénario que nous décrivons ici se déroule lorsque le cache 10 ne possède pas déjà le document demandé en mémoire, dans le cas contraire il répond immédiatement à l'utilisateur en renvoyant la page qu'il a précédemment stockée (c'est à dire soit la page originale, soit la page modifiée si la modification de celle-ci s'est avérée opportune). Le cache 10 de type " client iCAP " est à ce jour disponible sur le marché dans une version industrielle. Le principe du protocole iCAP repose sur une base simple: à toute requête HTTP correspond une réponse provenant d'un serveur Web ou d'un cache: il suffit donc de transformer soit la requête, soit la réponse pour offrir un service de transformation de contenu. iCAP propose deux modes principaux (" Request Modification " et " Response Modification ") qui sont basés sur le protocole HTTP. Le rôle d'iCAP n'est pas d'effectuer lui-même la transformation de contenu. Il se limite juste à relier des " iCAP clients " (caches Web, routeurs....) avec des " iCAP serveurs ", ces derniers étant responsables de la transformation. Le iCAP forum (http://www.i-cap.orq) a été créé en décembre 1999 sous l'impuision des sociétés Network Appliance et Akamai. Son objectif est de standardiser, au travers du protocole iCAP (Internet Content Adaptation, Protocol), les échanges entre les équipements représentatifs des architectures du Web (serveurs Web, caches, load balancers, routeurs...) et les systèmes de transformation de contenu. s La spécification ICAP 1.25 est la plus récente. Elle a déjà fait l'objet de plusieurs implémentations dans le cadre des services à valeur ajoutée de transformation de fichiers dont voici quelques exemples: - filtrage de virus - filtrage de contenu Le protocole iCAP a aussi été soumis le 27 novembre 2000 à l'IETF (Internet-Draft " iCAP the internet content adaptation protocol " hitp:/lwww.ietf.orq/internet-drafts/draftelson-opes-icap-00.txt) dans le Working Group (groupe de travail) Open Proxy Extensible Services. 11 n'existe pas beaucoup d'implémentations techniques de services utilisant le protocole iCAP. Seuis les éditeurs de logiciel d'Anti-virus bénéficiant de leur savoir-faire en solutions réseaux s'installant sur des FireWall (rideau de feu) ou des proxies (mandataire) proposent un portage de leurs services sur iCAP. On voit aussi l'apparition de nouveaux intervenants commerciaux dans le domaine du filtrage de contenu. Mais pour toutes les autres applications éventuellement envisagées, I'investissement de départ reste lourd et coûteux. Ceci explique encore pourquoi les services à valeur ajoutée utilisant iCAP tardent à sortir. Utilisant ici le protocole ICAP et notamment le fait de récupérer des flux provenant des serveurs WEB via un module de redirection iCAP, ici constitué par le cache 10, on met en _uvre un procédé de compression à la volée particulièrement avantageux. Le fonctionnement du présent outil de compression iCAP, ou " ICAP Zipper ", peut se représenter simplement par le schéma générique de la figure 2. Les étapes principales du service de compression sont les suivantes: a) le client 30 émet une requête à destination d'un serveur Web 40. Cette requête passe éventuellement par un équipement de redirection, ici le cache 10. b) le serveur 40 transmet sa réponse au client 30 par l'intermédiaire du cache 10. c) le service de redirection 10 (client iCAP) redirige la réponse vers le serveur iCAP 20. On dénommera ci-après ce serveur par l'expression plus générale " module de compression 20 " afin de qualifier la fonction principale de ce serveur. d) la réponse du serveur 40 est si possible compressée et/ou optimisoe par le module de compression 20. e) le module de compression 20 renvoie la requête au module de redirection 10. f) le module de redirection 10 renvoie la réponse au client 30. g) le navigateur client 30 décompresse automatiquement le document reçu avant de l'afficher. La décompression automatique des données du côté client est une fonctionnalité définie dans le protocole HTTP 1.1 (Standard IETF défini par la RFC 2616). Cette fonctionnalité se retrouve ainsi dans la majorité des navigateurs actuels qui intègrent un mécanisme de décompression de type gzip (Internet Explorer - marque déposée - de Microsoft, version 4 et supérieures, Netscape Communicator (marque déposée) de Netscape, version 4 et supérieures). Ce système de compression (sans client spécifique ni module local ou plug'in -) offre l'avantage de ne pas intervenir sur les logiciels installés au niveau de l'ordinateur 30 de l'internaute (ou au niveau du téléphone mobile ou de tout autre terminal de consultation utilisé). Ce service de compression ne modifie pas non plus les couches réseaux et protocolaires, ce qui évite les incompatibilités éventuelles avec d'autres types de services ou d'équipements qui seraient situés entre le service de compression et l'utilisateur final. Les figures 3 et 4 représentent de manière plus détaillée le dispositif préférentiel décrit ici. Sur ces figures, le module de compression 20 (ou module iCAP de transformation de contenu), se décompose en un module administrateur 22, un module adaptateur de flux 23, et un module de service ou sous-module 25 dédié spécifiquement aux tâches de compression des données. L'adaptateur de flux 23 a pour fonction d'adapter les contenus entre le module de redirection (client iCAP 10) et le module de service 25. Un tel adaptateur de flux 23 est préférentiellement prévu pour adapter les flux de données également pour une série d'autres modules de services supplémentaires, mettant en _uvre des services autres que la compression, ces modules pouvant par exemple être des modules de filtrage de contenu ou des modules de filtrage anti-virus. L'adaptateur 23 est situé dans le module de compression 20, pour d'une part, dans le sens client 10 - serveur 20, adapter les fichiers pour qu'ils puissent être directement utilisés pour les services de transformation de fichier, et d'autre part, dans le sens serveur 20 client 10, assurer un contrôle d'intégrité du fichier transformé et éventuellement sa reconstitution. L'adaptateur 23 permet de formaliser les échanges entre le module de redirection 10 (client iCAP) et le module de service 25 (service de transformation de fichier) grâce à une adaptation des flux iCAP pour les rendre compatibles avec le module de service de compression 25, ainsi qu'avec d'autres modules correspondant à des services de transformation de fichier, sans qu'il soit nocessaire de développer une couche iCAP au niveau de ces services. Ceci permet alors de définir des services de transformation de fichiers, modulaires, évolutifs et indépendants des couches iCAP. Ainsi, on récupère les flux provenant des serveurs Web via un adaptateur de contenus iCAP et on les convertit ensuite au format Zip, qui est un format de décompression habituel. On voit ciairement sur la figure 4 que le module de service 25 est structurellement intégré à la couche iCAP, ce qui signifie que le module de service 25, c'est à dire la partie spécifique au service de compression, est ici très simple à réaliser, notamment en adoptant l'architecture fonctionnelle d'un adaptateur de flux iCAP tel que précédemment décrit. Le service ou procédé général décrit ici va donc permettre de compresser les contenus http, par exemple les objets encodés au format htm, html, pour optimiser les taux de transfert et ce en c_ur de réseau et de manière transparente pour le client. Pour mettre en _uvre ce service, on met en place une détection des capacités du navigateur 30 à décoder un contenu compressé. La connaissance de ces propriétés différentie particulièrement le présent compresseur iCAP (ou l'iCAP Zipper) des autres systèmes de Booster, qui ne sont valables que pour un type de client donné ou une configuration réseau particulière. Le présent ensemble de compression est de ce fait capable de prendre dynamiquement en compte les particularités des clients et ainsi d'adapter la compression à la volée. Lors de l'envoi d'une requête http vers un serveur Web 40, le navigateur 30 annonce, dans l'entête de cette requête, I'ensemble des caractéristiques qualifiant ce navigateur. Le module de compression 20 (serveur iCAP) va alors tester l'existence d'une ligne " Accept-encoding " dans la requête http. Si cette ligne n'existe pas, cela signifie que le navigateur 30 n'accepte aucune page compressée. Le module de compression 20 doit alors renvoyer les pages sans les modifier. Si cette ligne existe, le serveur 20 doit regarder la valeur des types d'éléments compressés qui sont acceptés par les navigateurs pour choisir un bon encodeur ou sous-module de compression. Le module de service 25 modifie alors le contenu de l'entête à retourner au client 30, compresse les données, et les retourne au navigateur 30 via le moduie de redirection 10. Le module de service 25 réailsant spécifiquement la compression de contenus, fonctionne donc ici nativement en mode " modification de réponse ". La procédure de compression exécutée dans ce dispositif d'ensemble, mise en _uvre selon une méthode " Data Analysis " de la classe CicapServiceZip, est la suivante, ici détaillée selon une série d'étapes A) à 1) également représentées sur le diagramme de la figure 6. La procédure décrite ici est réalisée à l'aide d'un module de compression 20 conforme à l'architecture représentée sur la figure 4, mais comportant plusieurs modules de service 25 intogrés dans le même serveur iCAP 20, ces différents modules de service 25 correspondant chacun à une compression d'un type d'objet différent. On fait abstraction ici des étapes relatives à la préparation des différents objets passés au module de compression 20. On précise simplement que l'entête de la requête de consultation initialement émise par le terminal 30 se voit transmise au module de compression 20, par le module de redirection 10, associée aux donnces fournies par le serveur 40 en réponse à une telle requête. Les objets pa ssés sont, p lu s gén é ra l em ent, des objets correspond ant aux différentes entêtes http relatives au client 10, au serveur 20, et au contenu fourni. A) Le module de compression 20 recherche dans l'entête de requête client la chane " Accept Encoding >>, permettant de savoir si le contenu peut être compressé. Si la valeur n'est pas égale à " gzip " ou " deflate " ou si la chane n'existe pas, aucune compression n'est effectuce (passage au point I ci-après). B) Le module de compression 20 recherche dans cette même entête une chane " User-Agent ?) permettant de conna^tre la version minimale de navigateur utilisé par le client. Si la valeur extraite n'est pas au moins égale à 4 (numéro de version majeure des navigateurs), aucune compression n'est effectuce (passage au point 1). C) Cette opération remplit une fonction de module d'aiguillage. En fonction de l'entête de réponse http (renseignée par le serveur Web d'origine) et plus précisément de la chane " Content-Type ", on redirige le flux vers un sous-module de compression 25 le plus adapté pour le type de contenu déclaré. Par exemple, une indication " Content-Type:text.html " dans les données renvoyées par le serveur, permet de savoir que le contenu est de type HTML - Hypertext Markup Language - (texte). D) Cette opération est rénlisée au niveau du module de service 25 (sousmodule de compression): on recherche dans l'entête de réponse http la chane " Content-Encoding ", permettant de savoir si le contenu est déjà compressé. La compression ne se fait pas si cette chane est présente et si une de ces deux valeurs (" gzip " ou " deflate ") est présente (dans ce cas passage au point 1). E) on compare les premiers octets du contenu avec les octets suivants: il se peut qu'une mauvaise implémentation d'un serveur Web 40 introduise des erreurs de codage et il faut alors s'assurer que le contenu est bien du texte. Si le contenu n'est pas de type HTML, il n'est pas modifié (passage au point I ci-après). F) On appelle une fonction de compression " compress " qui retourne le contenu compressé dans un tampon (buffer) auquel il est nécessaire d'ajouter les octets suivants: 1F 8B 08 00 00 00 00 00, qui définissent le début d'entête d'une compression de type gzip. Il est également nécessaire alors de modifier les deux premiers octets 00 03 à la fin de l'entête de compression gzip. G) On remplace le contenu dans un objet picapSocketDataResponseContent par le contenu de ce buffer. H) On modifie et on ajoute, en fin de l'entête de réponse, la ligne " Content-Encoding: gzip ". I) On envoi la réponse (modifiée ou non) au client iCAP 10. Le diagramme de classes de la figure 6 montre les liens de généralisation et de dépendance entre les classes du serveur et les classes spécifiques du service. Le diagramme de classe complet d'un compresseur iCAP (iCAP Zipper) préférentiel est la fusion logique de ce diagramme avec celui d'un adaptateur de flux iCAP tel que décrit précédemment. La classe ClcapServiceZip est la classe fille de la classe de services iCAP ClcapService. Elle contient les fonctionnalités utilisées pour la compression des objets. La classe CicapGlobalsService est la classe abstraite fille de la classe de définitions de constantes et de variables communes aux classes d u service. El le n'est pas instanciable. La classe ClcapErrorService définit les constantes d'erreur spécifiques pour le service. Elle n'est pas instanciable. Les mécanismes de compression fournis par le service décrit ici peuvent agir différemment en fonction des contenus à traiter. Ces mécanismes peuvent agir pour rébuire le volume des données échangées (compression des données) avec ou sans pertes. 11s peuvent également optimiser les donnces échangées par réorganisation des données. Pour favoriser l'essor d'iCAP et étendre la gamme de services de transformation de contenus en c_ur de réseau, on propose donc ici un service de compression à la volée en c_ur de réseau qui se traduit par une accélaration du téléchargement de pages Web et généralement de contenus sur http. Ce service trouve une application immédiate pour toute connectivité à Internet depuis des terminaux mobiles (un PC - ordinateur personnel - ou un PDA - assistant digital de poche - via un terminal GPRS - Generai Packet Radio Service - ou CSD - Circuit Switched Data). Il n'est cependant pas limité aux seuis opérateurs mobiles et peut être applicable à tout fournisseur d'accès Internet (FAI). Il permet alors non seulement d'augmenter la qualité de service perçue par l'utilisateur final, mais aussi d'optimiser la bande passante du FAI sur la portion la plus critique: entre le point d'accès internet et l'utilisateur. Ce service trouve également son efficacité dans les connections d'utilisateurs nomades avec leur Intranet d'entreprise. En effet, c'est au travers de connexions de type RTC (Réseau Téléphonique Commuté) qu'ils récupèrent des donnces d'lntranet, et, à ce titre, la compression à la volée offre un gain en bande passante relative et une rébuction du temps de téléchargement des nouvelles informations non négligeables. Enfin, du point de vue d'un fournisseur de service, le compresseur iCAP ou iCAP Zipper décrit ici présente l'intérêt primordial d'une économie en bande passante et d'une amélioration de la qualité de service offerte. REVENDICATIONS 1. Procédé de compression à la volée de donnces fournies par un serveur (40) d'un réseau collectif tel qu'internet en réponse à une requête d'un terminai de consultation (30), dans lequel procédé on fournit un module de compression de données (20), et un module de redirection (10) prévu pour recevoir des données fournies par le serveur (40) et les rediriger vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données depuis le module de compression (20) et les rediriger vers le terminal de consuitation (30), procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal (30) et on effectue dans le module de compression (20), sur les données demandées par la requête et fournies par le serveur (40), une compression qui est adaptée à l'indication d'aptitude contenue dans la requête. 2. Procédé selon la revendication 1, caractérisé en ce qu'on ne met en _uvre aucune compression dans le cas o itindication de la requête révèle une inaptitude du terminal (30) à la décompression. 3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que l'on recherche dans la requête une indication d'aptitude concernant l'un quelconque de plusieurs types de décompression, et on met en _uvre celui des types de compression qui correspond spécifiquement à l'indication d'aptitude contenue dans la requête. 4. Procédé selon la revendication 3, caractérisé en ce que le module de compression (20) comporte des moyens pour mettre en _uvre lesdits plusieurs types de compressions, et en ce que la recherche d'indications concernant les différents types de compressions est effectuée par le module de compression (20). 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le module de compression (20) et le module de redirection (10) sont prévus pour échanger des donnces selon le protocole ICAP - Internet Content Adaptation Protocol. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le module de redirection (10) est un module de mémorisation de masse prévu pour fournir plusieurs fois des donnces mémorisoes dans ce module (20) en réponse à plusieurs requêtes demandant ces mêmes données, sans avoir à interroger, entre ces requêtes, un serveur (40) ayant initialement fourni ces données. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le module de compression (20) inclut plusieurs sous- modules dédiés chacun à la compression d'un type d'objet différent, et en ce qu'on identifie dans les donnces à compresser la présence d'objets ayant l'un quelconque de ces différents types, puis on dirige chaque objet ainsi identifié vers un module spécifiquement dédié à la compression du type de l'objet considéré. 8. Procédé selon i'une quelconque des revendications précédentes, caractérisé en ce que la requête de consultation est une requête du type HTTP - HyperText Transport Protocol. 9. Dispositif de compression de données à la volée dans un réseau collectif tel que le réseau Internet, comprenant un module de compression (20) et un module de redirection (10), ce module de redirection (10) étant prévu pour recevoir des donnces fournies par un serveur (40) en réponse à une requête de consultation émise par un terminal de consultation (30), et rediriger ces données vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données fournies en retour par le module de compression (20) et les rediriger vers le terminal de consultation (30), ce dispositif incluant en outre des moyens (20) pour examiner, dans une requête de consultation de données émise par un terminal (30), une indication concernant une aptitude à la décompression du terminal considéré (30), et des moyens (20) pour commander une compression par le module de compression (20) qui est adaptée à I'indication d'aptitude à la décompression contenue dans la requête. 10. Dispositif selon la revendication 9, caractérisé en ce que les moyens (20) prévus pour examiner une indication d'aptitude à la décompression dans la requête sont prévus pour ne commander aucune compression dans le cas o cette indication révèle une inaptitude du terminal (30) à la décompression. 11. Dispositif selon la revendication 9 ou la revendication 10, caractérisé en ce que les moyens (20) prévus -pour examiner une indication d'aptitude à la décompression dans la requête sont prévus pour rechercher dans la requête des indications d'aptitude concernant plusieurs types de décompression, et commander celui des types de compression qui correspond spécifique ment à i' ind ication d 'aptitude co nte n u e da ns la requête. 12. Dispositif selon la revendication 11, caractérisé en ce que le module de compression (20) comporte des moyens pour mettre en _uvre lesUits plusieurs types de compressions, et en ce que la recherche d'indications concernant plusieurs types de compression est effectuée par le module de compression (20). 13. Dispositif selon l'une quelconque des revendications 9 à 12, caractérisé en ce que le module de compression (20) et le module de redirection (10) sont prévus pour échanger des donnces selon le protocole ICAP - Internet Content Adaptation Protocol. 14. Dispositif selon l'une quelconque des revendications 9 à 13, caractérisé en ce que le module de redirection (10) est un module de mémorisation de masse prévu pour fournir plusieurs fois des données mémorisoes dans ce module (20) en réponse à plusieurs requêtes demandant ces mêmes données, sans avoir à interroger, entre ces requêtes, un serveur ayant initialement fourni ces données. 15. Dispositif selon l'une quelconque des revendications 9 à 14, caractérisé en ce que le module de compression (20) inclut plusieurs sous modules dédiés chacun à la compression d'un type d'objet différent, et en ce qu'il comprend des moyens pour identifier dans les donnces à compresser la présence d'objets ayant l'un quelconque de ces différents types, puis pour diriger chaque objet ainsi identifié vers un module spécifiqueme nt déd ié à la compress ion d u type d 'objet considéré. 16. Disposes seen rune quelconque des nevenddons g 1 5, carac16dsh en ce quill es1 pave pour 1raiter des requA1es du type HOP Hypee Trnspod PFotocoL