From: "deny" deny@monaco.net
Bonjour je reviens pleurer pour une traduction malhabile :
Similarly, if we have the address of that header, the address of the structure after it is the address of that header plus the length of that header. The IP header, unlike the Ethernet header, does not have a fixed length; its length is given as a count of 4-byte words by the 'header length' field of the IP header; this means that it must be multiplied by 4 to give the size in bytes. The minimum length of that header is 20 bytes.
De même, si nous avons l'adresse de cet en-tête, l'adresse de la structure qui suit est l'adresse de cet en-tête plus sa longueur. L'en-tête <application><acronym>IP</acronym></application>, contrairement à l'en-tête <application>Ethernet</application>, ne posséde pas de longueur fixe ; sa longueur est indiquée en mots de 4 octets par le champ de longueur d'en-tête de l'en-tête d'<application><acronym>IP</acronym></application> ; cela signifie qu'il doit être multiplié par 4 pour donner sa taille en octets. La longueur minimum de cet en-tête est de 20 octets.
La traduction n'est pas si mauvaise que ça, même si elle ajoute:
* quelques ambiguïtés: ** "sa longueur" (la longueur de l'adresse dont on vient juste de parler ou la longueur de l'entête? pour clarifier les choses, avant de répondre il vaut mieux consulter à nouveau les RFC)
* et quelques fôôtes: ** "posséde" -> "possède" (accent incorrect)
Autres interrogations:
* Doit-on baliser à la fois <acronym> et <application> pour "IP"?
* Écrit-on encore "en-tête" (forme lourde) alors que l'orthographe réformée supprime la plupart des traits d'union inutile au sens, comme ici "entête" en un seul mot que tout le monde comprend très bien et ne nuit pas aux règles orthographiques habituelles du français: plus personne ne voit une préposition "en" ici, formé de la locution adverbiale extraite de "venir en tête", mais un préfixe "en" qu'on peut fort bien attacher pour former un nom commun normal; cf. "emprise", "emplâtre", "entrée", "entêtement" (aucune confusion de sens n'étant possible avec le verbe "entêter", ce qui semble être à l'origine de l'introduction pédante du trait d'union, mais non justifiée par l'usage des deux termes).
* est-ce nécessaire de mettre des espaces insécables avant les nombres? (à la limite je veux bien une fine insécable entre un nombre et l'unité qui suit, mais pas avant... donc "multiplié par 4" et "de 20 octets."
* Ensuite c'est vrai que le style est un peu lourd en français du fait d'une traduction trop mot-à-mot (la concision des termes en anglais permet ce style).
Je ferais donc une réécriture du paragraphe, éventuellement coupé en deux parties pour en améliorer la clarté, ou reformulé, et certaines formes de style un peu lourdes (cela signifie que...) pourrait être évitées car elles sont inutilement longuettes et font perdre le fil de l'idée.
De même, l'adresse du contenu qui suit l'entête IP est l'adresse de début de cet entête IP, décalée de la longueur totale de cet entête. Mais au contraire de l'entête Ethernet, l'entête IP n'est pas de longueur fixe : sa longueur effective (en mots de 4 octets) est indiquée dans le champ de longueur dans la partie fixe de l'entête IP, et qui indique non seulement la taille de la partie fixe de l'entête mais aussi les parties variables optionnelles. la longueur totale de l'entête est indiquée dans un mot ce champ, dont la valeur doit être multipliée par 4 avant de l'ajouter à l'adresse de l'entête IP et déterminer ainsi l'adresse de la structure contenue transporté par la trame IP.
Personnellement je préfère parler de "contenu transporté" (qui correspond à la notion de "payload" en anglais) plutôt que de parler de "structure qui suit l'entête IP", étant donné qu'il n'y a pas forcément de structure à proprement parler dans ce contenu, même si la plupart du temps on utilise une structure de transport (ICMP ou TCP ou UDP, mais ce n'est pas obligatoire quand la liaison établit un protocole par défaut et permet la compression ou l'élimination totale des entêtes de transport, et c'est particulièrement vrai pour les liaisons établissant un flux sécurisé de type VPN, toute négociation ultérieure de protocole étant exclue, le flux étant dédié à un seul type de transport, soit en mode paquet soit en mode flux, et que la liaison établit déjà un transport fiable où TCP serait redondant, ou un découpage des datagrammes basé sur une protocole spécifique à l'application et qui suit d'autres règles que la classique élimination de trames incorrecte en UDP et qui se base sur une détection à postériori des trames manquantes, pas idéal pour les applications temps réel: par exemple une liaison ATM peut déjà effectuer le contrôle de priorité QoS ou la retransmission de trames manquantes, comme c'est le cas sur l'ADSL, pour la téléphonie ou la télévision sur IP et qui transite par des flux ATM séparés ne nécessitant pas des transports TCP, UDP ou ICMP multiples, puisque le contrôle de liaison passe par un autre canal ATM lui aussi dédié).
Mais bon, je cause, et je ne sais pas de quel Howto tu extrais cette traduction...