Normes Internet reliées à la francisation

Marc Blanchet
Viagénie inc.
Version 1.2 (févrer 2018) retouchée par Claude Brière de L'Isle

Table des matières

• 1. Introduction

• 2. Normalisation des protocoles sur Internet

  • 2.1 Structure des instances

  • 2.2 Affiliation

  • 2.3 Credo de l'IETF

• 3. Qu'est qu'une norme Internet?

  • 3.1 Documents RFC

  • 3.2 Normes proposées ("Proposed standard")

  • 3.3 Normes préliminaires ("Draft standard")

  • 3.4 Normes homologuées ("Standard")

  • 3.5 Normes de pratique recommandée ("Best Current Practice")

  • 3.6 Normes informatives ("Informational")

  • 3.7 Normes expérimentales ("Experimental")

  • 3.8 Normes historiques ("Historic")

  • 3.9 Documents de travail

• 4. Processus de normalisation

  • 4.1 Comment contribuer à une norme de l'IETF

• 5. Principales normes reliées à la francisation et l'internationalisation

  • 5.1 Formats et codage des messages

  • 5.2 MIME: Multipurpose Internet Mail Extensions

  • 5.3 World-Wide Web avec HTML, HTTP et les URL

  • 5.4 Courrier électronique avec les protocoles SMTP, POP et IMAP

  • 5.5 Annuaires électroniques avec X.500, LDAP et Whois++

  • 5.6 Service de noms de domaines (Domain Name Service: DNS)

  • 5.7 Telnet

  • 5.8 FTP (File Transfer Protocol)

  • 5.9 Exigences générales des ordinateurs connectés sur Internet

• 6. Recommandations à propos du développement des logiciels

• 7. Sources d'information

• 8. Mise à jour de ce document

  • 8.1 Vérification de l'état d'un RFC

  • 8.2 Connaissance de la relation entre les RFC

  • 8.3 Connaissance du travail en cours

  • 8.4 Recherche d'un document de travail

  • 8.5 Discussions sur l'internationalisation

• 9. Conclusion

• 10. Références

• 11. Annexes

  • 11.1 Normes homologuées

• 12. Glossaire

1. Introduction

Ce rapport tente d'orienter le lecteur sur les principales normes de l'Internet reliées à la francisation. Celles-ci sont homologuées par l'équipe d'ingénieriede l'Internet (IETF, Internet Engineering Task Force) décrit dans les premiers chapitres. Il faut comprendre que dans le cadre de l'IETF, il n'y a pas de travaux spécifiques reliés à la francisation, mais plutôt sur la problématique de l'internationalisation dans son ensemble. Ainsi, nous utiliserons le mot "internationalisation" dans le contexte général et le mot "francisation" lorsque le sujet est spécifique à la francisation.

Selon la terminologie généralement acceptée, une "norme" est issue d'un organisme de normalisation reconnu, alors qu'un "standard" désigne une spécification généralement acceptée dans l'industrie, mais ne venant pas d'un organisme de normalisation reconnu. Il est aussi généralement reconnu que l'IETF joue un rôle d'organisme de normalisation, malgré un historique et un mode de fonctionnement différent des autres organismes "traditionnels" de normalisation. En ce sens, nous avons utilisé le terme "norme" dans ce document.

Dans les chapitres suivants, les normes sont décrites selon un regroupement par protocole ou service Internet.

Dans tout le document, les organismes de normalisation et de standardisation autre que l'IETF sont mentionnés lorsque leur rôle nous semble important.

Nous y avons répertorié des sources d'informations sur le sujet de la normalisation et formulé des recommandations pour l'industrie du logiciel de langue française.

Puisque les normes changent à un rythme très rapide à l'IETF, ce document deviendra désuet ou tout au moins incomplet. Nous avons tenté dans un chapitre spécifique de donner quelques pistes de solution permettant au lecteur de le remettre à jour. Ce document reflète l'état de la situation en janvier 1998.

2. Normalisation des protocoles sur Internet

Le processus de normalisation des protocoles sur Internet est une activité de l'Internet Society. Cet organisme est une association à but non-lucratif qui assure au nom des internautes les orientations de l'Internet.

2.1 Structure des instances

L'Internet Society délègue à l'Internet Architecture Board (IAB) et à l'Internet Engineering Steering Group (IESG) le processus de normalisation des protocoles. Ces deux organismes regroupent environ 10 personnes chacun, bénévoles et élus. Ces deux organismes dirigent les travaux de l'IETF (Internet Engineering Task Force)[1], celui-ci constituant le regroupement de tous les bénévoles impliqués dans la normalisation des protocoles. Il fonctionne par des groupes de travail[2] formés avec un objectif précis. Lorsque les travaux d'un groupe sont terminés, celui-ci est aboli. En ce sens, les groupes de travail apparaissent et disparaissent régulièrement. Les groupes de travail sont regroupés par domaine d'application. Il existe présentement huit domaines: "Applications Area" , "General Area", "Internet Area", "Operations and Management Area", "Routing Area", "Security Area", "Transport Area", "User Services Area". Chaque domaine d'application est supervisé par un ou plusieurs responsables. Avec le président de l'IETF, ceux-ci forment l'IESG.

2.2 Affiliation

Il n'y a pas d'affiliation ("membership") ou de représentation nationale à l'IETF. Chaque personne y participe en son nom personnel. Cependant, l'affiliation corporative peut jouer une certaine influence, mais les facteurs les plus déterminants d'influence sont la crédibilité, la compétence et la qualité des propositions permettant de résoudre une problématique bien identifiée.

2.3 Credo de l'IETF

Il n'y a pas de processus de votation sur les normes à l'IETF. David Clark de MIT a bien résumé le credo de l'IETF de la manière suivante: "Rough concensus and running code". Ce credo, maintes fois répété, confirme l'ambiance de l'IETF: il n'est pas nécessaire d'avoir l'accord unanime de tous, mais plutôt de refléter un certain consensus. En plus, pour parvenir à une norme homologuée, il faut démontrer deux implantations indépendantes du protocole proposé réalisant l'interopérabilité de l'ensemble du protocole. De par son fonctionnement moins rigide que d'autres organismes de normalisation et de standardisation, l'IETF est souvent plus efficace et plus rapide pour faire avancer une norme, mais apparaît parfois un peu "brouillon" dans son fonctionnement. Un participant aux ateliers de l'IETF comprend cette dynamique. Paradoxalement, ce fonctionnement assure l'excellente qualité technique des normes homologuées. L'historique et la présence actuelle et future de l'Internet le confirment.

3. Qu'est qu'une norme de l'Internet?

Une norme Internet est une spécification écrite, stable, techniquement solide, présentant plusieurs implantations indépendantes et interopérables avec une expérience réelle d'utilisation, soutenue de façon significative par la communauté, et utile pour une partie ou l'ensemble d'Internet. La norme a été homologuée par le processus de normalisation de l'IETF et possède un numéro de RFC ("Request For Comments"). La spécification est disponible sur Internet.

3.1 Documents RFC

Chaque version d'une norme est publiée sous forme d'un document appelé RFC (Request for Comments) auquel on attribue un numéro unique. Ainsi, une version plus récente d'une norme sera publiée sous un autre numéro de RFC. Les numéros sont alloués de façon séquentielle selon la date de leur dépôt. Ainsi deux versions d'une même norme auront des numéros différents et indépendants. L'IAB mandate un éditeur [3] pour gérer les RFC. Jon Postel de ISI (Information Sciences Institute [4]) jouait ce rôle depuis les débuts.

À la différence d'autres organismes de normalisation et de standardisation, l'auteur ou les auteurs de la norme sont identifiés clairement dans l'en-tête du document RFC. Les documents sont rédigés en anglais.

Un document RFC n'implique pas qu'il s'agisse d'une norme reconnue et approuvée par l'IETF. Cet état de fait est bien expliqué [5] dans la RFC 1796. En effet, il existe plusieurs niveaux de normes. Ces niveaux correspondent à la maturité de chacune des normes.

3.2 Normes proposées ("Proposed standard")

Les normes proposées ("Proposed standard") correspondent au premier niveau de maturité. Elles ont obtenu une première approbation par le groupe de travail impliqué et par l'IESG. Elles sont généralement stables, sont bien définies, ont résolu les problématiques ciblées et sont considérées adéquates par la communauté.

3.3 Normes en projet ("Draft standard")

Une norme en projet ("Draft standard") doit avoir été mise en oeuvre dans sa totalité par au moins deux logiciels distincts de sources différentes. Des tests doivent démontrer l'interopérabilité de ces logiciels. De plus, ce type de projet doit avoir été largement utilisé avant d'obtenir cette homologation. Un document de ce type doit être considéré comme une spécification complète et finale.

3.4 Normes homologuées ("Standard")

Les normes homologuées ("Standard") sont des normes décrites par une RFC et qui possèdent en plus un numéro de STD (STandarD). C'est le niveau de maturité le plus haut dans les normes de l'IETF. Elles correspondent à une norme homologuée, très bien définie, mise en pratique sur Internet et ayant atteint un haut niveau de maturité. Les normes STD adoptées à ce jour sont listées en annexe de ce document.

3.5 Bonnes pratiques actuelles ("Best Current Practice")

Certains documents RFC sont des conclusions sur la meilleure manière de faire certaines opérations ou d'exploiter certains protocoles. Ils possèdent en plus de leur numéro de RFC un numéro supplémentaire de BCP (Best Current Practice). Les bonnes pratiques actuelles ne constituent pas la spécification d'un protocole.

3.6 Textes pour information ("Informational")

Plusieurs documents RFC ne sont ou ne seront jamais des normes homologuées et officielles. Dans ce cas, elles sont publiées avec la mention "Experimental" ou "Informational", selon le cas. L'éditeur des RFC en consultation avec l'IESG détermine cette mention.

Les textes pour information ("Informational") sont publiés pour l'intérêt général de l'Internet. Elles ne font pas nécessairement l'objet d'un consensus ou d'une recommandation. Des spécifications produites en dehors du processus de l'IETF sont souvent publiées comme "Informational".

3.7 Normes expérimentales ("Experimental")

Une norme expérimentale ("Experimental") désigne une spécification utilisée dans un travail de recherche et de développement. Elle est publiée pour l'intérêt général de l'Internet.

3.8 Normes historiques ("Historic")

Une norme peut régulièrement être révisée. Lorsqu'une révision rend désuète la version précédente, celle-ci obtient le statut de norme historique ("Historic").

3.9 Documents de travail

Durant le développement d'une spécification, des documents de travail appelés "Internet-Drafts" sont publiés aux fins de discussion. Ils sont disponibles dans un répertoire sur le serveur de l'IETF [6]. Lorsqu'un document de travail est transformé en document RFC ou est resté inchangé pendant 6 mois, le document est simplement retiré du répertoire. Il est important de comprendre que ces documents de travail n'ont aucune valeur de norme et ne sont pas homologués. Aucun appel d'offres ou document officiel ne devrait faire référence à ces documents de travail.

4. Processus de normalisation

Pour qu'un document devienne une norme, il doit en premier être écrit sous la forme d'un document de travail ("draft") et être disponible pendant un minimum de 2 semaines [7] pour révision publique par la communauté. Ensuite, sur recommandation du responsable du groupe de travail et du responsable du domaine d'application, le document est soumis à l'IESG pour approbation. Si le document satisfait aux différents critères d'une norme, le document est soumis à un appel public à commentaires. Selon les commentaires reçus et le jugement de l'IESG, le document peut être soit homologué comme norme dans la catégorie demandée ou dans une autre catégorie, soit être refusé ou retardé.

Si la norme est acceptée, l'IESG demande à l'éditeur des RFC de publier la norme.

Dans le cas d'un texte de type "Informational" ou "Experimental", le document peut être soumis directement à l'éditeur des RFC.

Un texte de type "Proposed Standard" doit rester au moins 6 mois à ce niveau avant d'avancer au niveau "Draft". De même, un texte de type "Draft" doit rester au moins 4 mois à ce niveau avant d'avancer au niveau "Standard".

Un texte n'atteignant pas le niveau "Standard" et restant au même niveau pendant 24 mois sera revu par l'IESG tous les douze mois.

Les droits de propriété intellectuelle sue les RFC sont cédés de façon perpétuelle et illimitée à l'Internet Society pour publication sans restriction. Lorsqu'une spécification fait l'objet d'un brevet ou d'une protection intellectuelle, l'IESG tentera d'obtenir un accord pour l'utilisation sans restriction de cette spécification.

Le processus de normalisation est détaillé avec toutes les modalités [8] dans la RFC 2026.

4.1 Comment contribuer à une norme de l'IETF

Pour contribuer à une norme de l'IETF, voici quelques recommandations:

• Lorsque la contribution est reliée aux travaux d'un groupe de travail existant [9], il est approprié de lire la charte du groupe, de s'abonner à la liste de discussions du groupe, de lire les archives de la liste pour connaître les discussions précédentes et de lire les RFC et les documents de travail produits par le groupe. Selon le résultat de ces démarches, on peut proposer une modification à un document ou en écrire un nouveau et le soumettre au groupe.

• Lorsque la contribution ne semble pas être reliée à un groupe de travail existant, la première étape est probablement d'écrire un document de travail, même simple et incomplet. Ensuite, il est utile de le soumettre au responsable du domaine le plus pertinent pour la formation d'un groupe de travail. Les suites des discussions pourront amener la convocation d'une réunion de travail au prochain congrès de l'IETF pour discuter sur la pertinence de la formation d'un groupe de travail sur le sujet. Un document de travail peut aussi être soumis directement à l'IESG.

• Peu importe la contribution, il est utile d'assister aux congrès de l'IETF qui ont lieu 3 fois par année. Malgré qu'une partie importante du travail et des discussions se fasse par courrier électronique, l'échange direct est encore très enrichissant, constructif et efficace.

• Un document [10] décrit la manière d'écrire un document de travail.

• La RFC 2223 donne des instructions [11] aux auteurs de documents RFC.

5. Principales normes reliées à la francisation et l'internationalisation

Les principales normes de l'IETF reliées à la francisation et à l'internationalisation sont décrites dans cette section. Il faut mentionner que l'IETF a approuvé plus de 2200 documents au moment de l'écriture de ce rapport. Pour aider le lecteur à s'y retrouver, nous avons regroupé les documents par protocole ou par service Internet connu, tel que le courrier électronique, la Toile mondiale, les nouvelles, etc. Dans chaque regroupement, nous mentionnons en premier les normes principales du protocole ainsi que celles plus directement reliées à l'internationalisation. Nous listons dans une section suivante les autres rextes reliés au protocole mais moins pertinentes pour l'internationalisation. Enfin, une autre section traite des travaux en cours sur ce protocole que nous trouvons utiles pour le lecteur et valables au moment d'écrire ce rapport.

Dans les tableaux listant les normes, la première colonne indique le numéro de RFC relatif à cette norme. La deuxième colonne indique l'état de la norme. On distingue les codes suivants:

Code	État du document
S	Standard : Norme
D	Draft Standard : projet de norme (à ne pas confondre avec un projet Internet, qui est une sorte de brouillon de RFC)
P	Proposed Standard : proposition de norme
B	Best Current Practice : Bonnes pratiques actuelles
I	Informational : RFC pour information
E	Experimental : RFC expérimentale

Tableau 5.1 État des normes

Dans un contexte général, les normes de l'IETF reliées à l'internationalisation utilisent un codage binaire et un jeu de caractères précis pour véhiculer l'information textuelle. La première section sur les normes reliées à l'internationalisation porte donc sur le codage.

5.1 Formats et codage des messages

La représentation de l'information nécessite un codage particulier. Le codage utilisé largement dans les protocoles de l'IETF est l'US-ASCII, qui n'utilise que les 7 derniers bits d'un octet, bien que l'octet soit aujourd'hui le plus petit élément de données utilisé sur Internet pour véhiculer les caractères. Ce codage ne permet aucune lettre accentuée.

L'esprit de l'IETF consiste à ne pas réinventer ce qui a été bien conçu ailleurs. Ainsi, le codage utilisé du côté de la francisation est le code ISO/CEI 8859-1, normalisé par l'ISO et la CEI. Certains protocoles de l'IETF supportent ce codage, d'autres non.

Les différents codes de caractères utilisés dans les protocoles de l'IETF sont enregistrés par l'IANA (Internet Assigned Numbers Autority), selon le processus décrit dans la RFC 2278.

5.1.1 Codage ISO 10646

L'IETF envisage maintenant l'utilisation du jeu universel de caractères ISO/CEI 10646 avec le codage UTF-8 tel que mentionné dans la RFC 2130. Cette RFC de type "informational" est le résumé des travaux d'un groupe de travail sur l'internationalisation. Il existe aussi d'autres codages du jeu ISO 10646, tels que le codage UTF-7, ou encore son mode natif sur 2 ou sur 4 octets.

Au mois d'août 1997, M. Harald T. Alvestrand, responsable du domaine des applications à l'IETF, a proposé l'orientation que devrait prendre l'IETF quant à l'internationalisation. Cette proposition a été rédigée selon les conclusions de la RFC 2130 et a été homologuée sous la forme d'un "Best Current Practice", portant le numéro 2277 et intitulé " IETF Policy on Character Sets and Languages". Ce document est maintenant la pierre angulaire des efforts d'internationalisation de l'IETF. À cause de son impact potentiel par rapport au sujet de ce rapport, nous encourageons fortement le lecteur à le lire.

En résumé, la RFC 2277 établit les orientations suivantes:

• Tout protocole doit identifier le jeu de caractères utilisé

• Tout protocole doit être en mesure d'utiliser le codage UTF-8 du jeu universel de caractères ISO/CEI 10646.

• Tout protocole peut permettre d'autres jeux de caractères.

• Tout protocole qui transfère du texte doit identifier la langue du texte

• Les identifiants ne sont pas couverts par ce document. Les identifiants sont utilisés entre autres dans les noms de domaines, dans les adresses de courrier électronique et dans les adresses URL (pour le web).

Il est ainsi nécessaire de baliser la langue utilisée dans un texte quelconque. La RFC 1766 normalise les balises de langue.

5.1.2 Principales RFC

Tableau 5.2 RFC sur le codage des messages

5.1.3 Autres organismes de normalisation

Dans beaucoup de travaux sur la francisation et l'internationalisation dans les technologies de l'information, l'ISO [12] (associée à la CEI) joue un rôle clé. Les travaux de l'ISO et de la CEI ont entre autres produit les jeux de caractères ISO/CEI 8859-1 et ISO/CEI 10646. Une nouvelle partie [13] de la série de normes ISO/CEI 8859 (jeux de caractères codés sur huit bits), assurant l'inclusion du symbole euro ainsi qu'une correction par rapport à l'ISO/CEI 8859-1 pour mieux soutenir certaines langues comme le français et le finnois, est actuellement en développement, les premiers votes ayant déjà eu lieu au moment d'écrire ce rapport.

5.2 MIME: Multipurpose Internet Mail Extensions

La norme MIME est utilisée pour définir le format des messages multimédia sur Internet. Un message codé selon la norme MIME contient les en-têtes nécessaires pour décrire le type de données utilisé. Le contenu du message peut être composé d'un ou plusieurs des éléments suivants : texte, image, son, fichier binaire quelconque, etc.

Un message MIME contient les principaux en-têtes suivants:

Tableau 5.3 En-têtes MIME

Les messages contenant des caractères accentués ont un codage spécifié dans l'en-tête "Content-Transfer-Encoding".

Initialement prévue pour le courrier électronique, la norme MIME est aussi utilisée pour les transactions de la Toile mondiale et dans la lecture des nouvelles Usenet.

5.2.1 Principales RFC

Tableau 5.4 Documents RFC sur MIME

5.2.2 Autres RFC

Les RFC suivantes sont intégrées au protocole mais ne sont pas strictement reliés à l'internationalisation.

Tableau 5.5 Autres documents RFC sur MIME

5.2.3 Travaux en cours

Depuis plusieurs années, plusieurs groupes de travail de l'IETF ont tenté d'enrichir le protocole MIME pour assurer la sécurité des messages par les mécanismes de chiffrement et de signature. Le présent rapport n'a pas pour objet de discuter des fonctions de sécurité, mais on peut affirmer que le chiffrement est un codage supplémentaire aux autres mécanismes de codage de l'information. Ainsi, il peut avoir une influence sur le résultat final du contenu du message. Les deux principaux protocoles de sécurité, utilisés conjointement avec MIME, sont PGP-MIME décrit dans le RFC 2015 et SMIME. Ce dernier est l'objet d'un groupe de travail au moment de l'écriture de ce rapport.

Tableau 5.6 Normes de sécurité avec MIME

5.3 World-Wide Web avec HTML, HTTP et les URL

On peut décrire succintement les mécanismes fonctionnels du Web par les trois éléments suivants:

• le langage HTML permettant de décrire les pages Web,

• le protocole HTTP pour les transactions entre un logiciel client et un serveur,

• et les URL qui déterminent l'endroit où se trouve un document.

HTML ("HyperText Markup Language") est un langage pour créer des documents indépendants du logiciel ou du matériel où ils sont visualisés. Les documents HTML sont utilisés sur la Toile depuis 1990. HTML utilise présentement un alphabet basé sur le jeu de caractères ISO/CEI 8859-1. Les documents HTML utilisent la norme MIME pour décrire leur contenu.

Une norme [14] assurant l'internationalisation au-delà du jeu de caractères ISO/CEI 8859-1 a été homologuée dans le document RFC2070. Elle décrit l'utilisation du jeu de caractère ISO/CEI 10646 dans le langage HTML.

Le protocole HTTP est utilisé pour transmettre les données du Web. Ce protocole utilise la norme MIME pour décrire la nature des données qui sont transmises. Pour assurer la négociation des paramètres d'internationalisation, HTTP (v1.1) supporte les en-têtes suivants.

Tableau 5.7 En-têtes HTTP reliés à l'internationalisation

5.3.1 Principales RFC

Tableau 5.8 RFC sur les protocoles de la Toile

5.3.2 Autres organismes impliqués dans la normalisation

Il faut mentionner que le World Wide Web Consortium [15] (W3C) joue un rôle majeur dans la normalisation des protocoles du Web. Le lecteur intéressé devrait consulter attentivement les résultats des travaux du W3C. Au moment de l'écriture du rapport, plusieurs travaux sont en cours au W3C sur l'internationalisation, notamment la version 4 du langage HTML.

5.4 Courrier électronique avec les SMTP, POP et IMAP

La transmission du courrier électronique sur Internet utilise le protocole SMTP (Simple Mail Transfer Protocol, RFC 821). La définition du protocole SMTP a été publiée en 1982. À cette époque, l'utilisation de caractères autre que ceux de l'US-ASCII n'était pas une préoccupation aux États-Unis. Par conséquent, la définition du protocole SMTP prévoit que l'utilisation du jeu de caractères US-ASCII.

Un groupe de travail a été mis en place à l'IETF (Internet Engineering Task Force) il y a plusieurs années pour moderniser le courrier électronique de manière à ce qu'il supporte les caractères accentués, les pièces jointes et les éléments multimédias. Les travaux de ce groupe de travail ont été très lents à produire des résultats. Pendant ce temps, sous la pression des clients, plusieurs producteurs de logiciels et de systèmes d'exploitation ont dévié de la norme SMTP à 7 bits pour supporter intégralement les 8bits de chaque octet, assurant ainsi l'usage des caractères accentués avec le codage implicite ISO/CEI 8859-1. Les utilisateurs européens, québécois et autres ont donc utilisé ces extensions non-normalisées puisqu'elles leur permettaient d'échanger du courrier électronique dans leur langue. À posteriori, le mode 8 bits a été normalisé en prévoyant une négociation préalable entre le logiciel client et le logiciel serveur, avec le mode "Extended SMTP" décrit dans les documents RFC 1869,1652 et 1428. Plusieurs problèmes que nous vivons aujourd'hui avec le courrier électronique accentué tirent leur origine du cours de ces événements.

La norme MIME prévoit un codage des messages au delà du jeu de caractères US-ASCII (ISO/CEI 646). Il permet de contourner les contraintes imposées par le protocole SMTP et d'assurer l'usage de caractères accentués dans le courrier électronique.

L'utilisation de MIME avec un code à 7bits pour les caractères accentués (souvent appelé mode QP (Quoted Printable) dans les logiciels de courrier électronique) ou l'utilisation du codage à 8 bits avec le mode "Extended SMTP" constituent les seules façons de garantir l'acheminement des caractères accentués sur Internet.

Les protocoles POP3 ou IMAP4 sont utilisés pour permettre à un utilisateur de télécharger ses messages de courrier électronique à partir d'un serveur. IMAP4 offre en plus des fonctions de gestion de boîte de courrier à distance.

5.4.1 Principales RFC

Tableau 5.9 Documents RFC sur le courrier électronique

5.4.2 Autres documents RFC

Tableau 5.10 Autres documents RFC sur le courrier électronique

5.4.3 Autres organismes impliqués dans la normalisation et la standardisation

Le consortium IMC (Internet Mail Consortium [16]), fondé par deux experts dans ce domaine, constitue un point de coordination pour le développement et l'implantation des normes reliées au courrier électronique sur Internet. Par la représentation de ses membres, il contribue de façon importante aux activités de normalisation de l'IETF autant dans la phase de conception que dans la phase d'implantation et de tests d'interopérabilité. Le lecteur intéressé devrait consulter attentivement les travaux de l'IMC.

5.5 Annuaires électroniques avec X.500, LDAP et Whois++

Les annuaires électroniques permettent aux usagers d'Internet d'interroger une base de données et ainsi de trouver de l'information sur un individu, une entité ou un objet du réseau. Historiquement, pour les besoins de gestion du réseau, la base de données Whois était utilisée. Depuis, plusieurs protocoles différents ont été testés ou utilisés, tels que X.500, ph/qi, whois++. L'orientation courante est d'utiliser le protocole d'accès aux annuaires LDAP (Lightweight Directory Access Protocol).

La base de données Whois est un répertoire électronique accessible sur Internet qui permet la recherche d'individus, de noms de domaines, de noms de machines clés et d'autres informations d'intérêt pour les internautes. Ce service est maintenu par le Network Information Center (NIC). Whois++ est une revision du service Whois ajoutant un niveau d'information plus structuré, ainsi que la possibilité d'utiliser différents langages et alphabets.

Ph/Qi est un protocole simple et un logiciel permettant l'accès à un seul annuaire. Plusieurs logiciels de courrier électronique, tels qu'Eudora, utilisent ce protocole. Il a été documenté à posteriori dans un document de travail [17]. Il est limité quant à sa capacité de gérer l'accès à de multiples annuaires, sans connaissance préalable du serveur. Quant à l'internationalisation, les implémentations initiales ne supportaient que les caractères US-ASCII, mais le document de travail propose des extensions pour soutenir le codage ISO/CEI 8859-1.

LDAP (Lightweight Directory Access Protocol) se veut une alternative plus simple au protocole DAP (Directory Access Protocol) de la norme ISO X.500 pour offrir un annuaire électronique sur Internet. Plusieurs manufacturiers soutiennent déjà LDAP. Ce protocole correspond à l'orientation courante de l'IETF en matière d'annuaires électroniques. La version 3 de LDAP, tout récemment homologuée, utilise le codage UTF-8 du jeu universel de caractères ISO/CEI 10646.

5.5.1 Principaux documents RFC

Tableau 5.11 Documents RFC sur les annuaires

5.5.2 Autres documents RFC

Tableau 5.12 Autres documents RFC sur les annuaires

5.5.3 Travaux en cours

Les travaux du groupe de travail LDAPEXT proposent présentement une extension pour supporter les balises identifiant la langue utilisée dans le contenu.

5.5.4 Autres organismes impliqués dans la normalisation

Le consortium IMC joue aussi un rôle de coordination pour le développement et l'implantation des normes reliées aux annuaires sur Internet. Le lecteur intéressé devrait consulter attentivement les travaux de l'IMC (http://www.imc.org).

Concomitant aux annuaires, le protocole vCard [18] a été proposé par le consortium Versit et est présentement maintenu par le consortium IMC. Ce protocole permet de créer l'équivalent de la carte d'affaires sur Internet. Une version normalisée par l'IETF est en cours de développement.

5.6 Service de noms de domaines (Domain Name Service: DNS)

Le DNS est un service de base de données distribuée sur Internet. Ce service permet en outre d'établir une correspondance entre l'adresse internet et le nom d'une machine.

Différentes restrictions existent quant au choix des noms de machines. Le nom d'une machine ne doit pas dépasser 63 caractères et doit être composé de certains caractères codés en US-ASCII, limités aux lettres, aux chiffres et au caractère '-' seulement. Ainsi, pour le moment, aucune francisation intégrale ou internationalisation des noms de domaines n'est possible.

Voici les principaux documents relatifs au DNS.

5.6.1 Principales RFC

Tableau 5.13 Documents RFC sur les noms de domaine

5.6.2 Autres documents RFC

Tableau 5.14 Autres documents RFC sur les noms de domaine

5.7 Telnet

Le protocole Telnet permet l'accès à un ordinateur par l'entremise d'un terminal distant. La plupart des implantations supportent différents émulateurs de terminaux. Si leurs caractéristiques le permettent, ceux-ci soutiennent correctement les caractères accentués.

5.7.1 Principales RFC

Tableau 5.15 RFC sur Telnet

5.8 FTP (File Transfer Protocol)

Le protocole FTP assure le transfert de fichiers d'un ordinateur à un autre. Les fichiers peuvent être de format quelconque, ce qui permet le format binaire et les caractères accentués. Ainsi, le transfert de fichiers en français ne cause pas de problèmes. Cependant, les noms des fichiers doivent être strictement en ASCII, restreignant ainsi l'utilisation du français dans les noms de fichiers.

5.8.1 Principales RFC

Tableau 5.16 Documents RFC sur FTP

5.8.2 Travaux en cours

Des travaux sont en cours par le groupe de travail FTPEXT pour internationaliser le protocole FTP. Un document de travail[19] propose une extension pour soutenir le codage UTF-8 du jeu de caractères ISO/CEI 10646 dans les noms de fichiers.

5.9 Exigences générales des ordinateurs connectés sur Internet

Les RFC suivantes définissent les exigences générales auxquelles doivent adhérer les machines sur Internet. Ces RFC concernent les applications et les protocoles.

5.9.1 Principales RFC

Tableau 5.17 Documents RFC sur les exigences générales

6. Recommandations à propos du développement des logiciels

Selon les orientations tracées par l'IETF récemment, il nous semble clair que le support du jeu de caractères ISO/CEI 10646 à l'aide du codage UTF-8 doit être prévu dès la conception d'un logiciel qui sera utilisé sur Internet. Il doit aussi être prévu de prendre en charge ISO/CEI 8859-1 pour le français. La norme ISO/CEI 8859-15 serait aussi à considérer, bien que son homologation ne soit pas terminée.

Considérant les efforts très importants pour étiqueter la langue utilisée dans le texte lorsque cela est fait à posteriori, il nous semble clair que la conception d'un logiciel devrait intégrer l'inclusion des balises de langue selon la RFC 1766 et prévoir un usage multilingue.

Enfin, tout balisage de document et de codage devrait utiliser la norme MIME.

7. Sources d'informations

Il existe de multiples sources d'informations au sujet des normes de l'Internet. Nous n'en nommerons que quelques-unes.

Tableau 7.1 Sources d'information

8. Mise à jour de ce document

Nous avons fait tous les efforts possibles pour que le présent document soit exact au moment de sa rédaction. Cependant, considérant l'évolution très rapide des normes de l'IETF et l'évolution de l'IETF elle-même, ce document deviendra tôt ou tard incomplet. Cette section donne au lecteur quelques suggestions pour s'assurer d'avoir accès à l'information la plus récente.

8.1 Vérification de l'état d'une RFC

Pour vérifier l'état d'une RFC, on peut consulter l'index des RFC [20]. Cet index est toujours mis à jour par le responsable de l'édition des RFC. Il permet d'identifier l'état de la RFC ainsi que les modifications subséquentes du protocole documentées à l'intérieur d'autres RFC.

8.2 Connaissance de la relation entre les RFC

Une RFC peut avoir été mise à jour partiellement par une autre RFC. L'index des RFC mentionné plus haut précise les relations entre les RFC.

8.3 Connaissance du travail en cours

Il est important de connaître les travaux en cours à l'IETF. En effet, un protocole peut à tout moment être soumis à une révision par un groupe de travail. Le fait de consulter la RFC adéquate assure seulement la connaissance du protocole normalisé, mais pas nécessairement des prochaines versions. La liste des groupes de travail actifs devrait être consultée [21].

8.4 Recherche d'un document de travail

Les documents de travail ("drafts") ne sont conservés que 6 mois sur le serveur [22] de l'IETF. Ainsi, il est possible que la référence à un document "draft" ne soit plus valide. Généralement, les documents ont toujours un numéro de version dans le titre. Il est important de vérifier si une version plus récente existe. Un document de travail peut aussi avoir été converti en RFC. On peut aussi se référer à la page du groupe de travail[ 23] auquel est assigné ce document de travail.

8.5 Discussions sur l'internationalisation

Au moment d'écrire ce rapport, les deux listes de courrier électronique suivantes servent aux discussions sur l'internationalisation.

ietf-charsets-request@innosoft.com

ietf-languages-request@apps.ietf.org

Tableau 8.1 Listes de discussion de l'IETF sur l'internationalisation

On peut s'abonner à ces listes en envoyant un message ayant comme contenu le mot "subscribe" à l'adresse mentionnée au tableau précédent.

9. Conclusion

Ce rapport tente d'orienter le lecteur sur les principales normes de l'Internet reliées à la francisation et l'internationalisation. Il faut comprendre que le fait qu'une norme soit homologuée ne constitue pas nécessairement une preuve qu'elle est utilisée sur Internet. Au lieu de donner une liste exhaustive de toutes les normes homologuées par l'IETF, nous avons tenté de lister les plus importantes et les plus pertinentes. Cet exercice est nécessairement imparfait, mais nous le croyons beaucoup plus utile. Sachant que ce document est sujet à l'obsolescence, nous donnons au lecteur certaines pistes pour le remettre à jour.

Nous désirons remercier M. Alain Labonté pour ses suggestions très pertinentes sur ce document.

10. Références

Les RFC sont disponibles à l'adresse http://www.rfc-editor.org/. Les documents de travail (drafts) sont disponibles à l'adresse ftp://ftp.ietf.org/internet-drafts.

11. Annexes

11.1 Normes homologuées

Le tableau suivant liste les normes homologuées ("Standard") lors de la rédaction de ce rapport. Cette homologation ne signifie pas nécessairement qu'elles sont toutes utilisées sur Internet, mais atteste plutôt de leur haut degré de maturité et de la reconnaissance par la communauté. Cette liste est disponible dans la RFC 2200. (Voir la liste à jour à https://www.rfc-editor.org/standards)

Tableau 11.1 Liste des STD

12. Glossaire

Tableau 12.1 Liste des acronymes

[1] URL : http://www.ietf.org/ .
[2] URL : http://www.ietf.org/html.charters/wg-dir.html .
[3] URL : http://www.isi.edu/rfc-editor
[4] URL : http://www.isi.edu. L'ISI est un institut rattaché à l'université de la Californie du Sud (USC).
[5] URL : http://ds.internic.net/rfc/rfc1796.txt
[6] URL : http://www.ietf.org/internet-drafts
[7] En pratique, ce processus est généralement beaucoup plus long.
[8] URL : http://ds.internic.net/rfc/rfc2026.txt
[9] voir liste des groupes à l'adresse http://www.ietf.org/html.charters/wg-dir.html .
[10] URL : ftp://ftp.ietf.org/ietf/1id-guidelines.txt
[11] URL : http://ds.internic.net/rfc/rfc2223.txt
[12] URL : http://www.iso.ch
[13] À ce titre, il nous faut mentionner la contribution importante d'un Québécois: M. Alain LaBonté du Gouvernement du Québec, qui est l'auteur ou un contributeur important de plusieurs normes de l'ISO sur les jeux de caractères, sur le tri et les configurations de claviers.
[14] Cette RFC a été écrite par un Québécois : M. François Yergeau.
[15] ou W3C: http://www.w3c.org
[16] URL : http://www.imc.org
[17] URL : ftp://ftp.ietf.org/internet-drafts/draft-ietf-ids-ph-04.txt
[18] URL : http://www.imc.org/pdi/
[19] URL : ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext-intl-ftp-03.txt
[20] URL : ftp://ftp.isi.edu/in-notes/rfc-index.txt
[21] URL : http://www.ietf.org/html.charters/wg-dir.html
[22] URL : ftp://ftp.ietf.org/internet-drafts
[23] URL : http://www.ietf.org/html.charters/wg-dir.html

Accueil | Qui sommes-nous ? | Bibliothèque virtuelle | Événements à signaler | Vitrine VOIL
Normes et standards | Francisation des inforoutes | IETF et W3C | Nos coordonnées | Courriel | Recherche