Ce rapport tente d'orienter le lecteur sur les principales normes de
l'Internet reli?s la francisation. Celles-ci sont homologu?s par le
processus de normalisation de l'IETF (Internet Engineering Task Force) d?rit
dans les premiers chapitres. Il faut comprendre que dans le cadre de l'IETF, il
n'y a pas de travaux sp?ifiques reli? la francisation, mais plut? sur la
probl?atique de l'internationalisation dans son ensemble. Ainsi, nous
utiliserons le mot "internationalisation" dans le contexte g??al et le mot
"francisation" lorsque le sujet est sp?ifique la francisation.
Selon
la terminologie g??alement accept?, une "norme" est issue d'un organisme de
normalisation reconnu, alors qu'un "standard" d?igne une sp?ification
g??alement accept? dans l'industrie, mais ne venant pas d'un organisme de
normalisation reconnu. Il est aussi g??alement reconnu que l'IETF joue un r?e
d'organisme de normalisation, malgr un historique et un mode de fonctionnement
diff?ent 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?rites 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? lorsque leur r?e nous
semble important.
Nous y avons r?ertori des sources d'informations sur
le sujet de la normalisation et formul des recommandations pour l'industrie du
logiciel de langue fran?ise.
Puisque les normes changent un rythme
tr? rapide l'IETF, ce document deviendra d?uet ou tout au moins incomplet.
Nous avons tent dans un chapitre sp?ifique de donner quelques pistes de
solution permettant au lecteur de le remettre jour. Ce document refl?e l'?at
de la situation en janvier 1998.
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.
L'Internet Society d??ue 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??oles et ?us. Ces deux organismes dirigent les travaux de l'IETF (Internet Engineering Task Force)[1], celui-ci constituant le regroupement de tous les b??oles impliqu? dans la normalisation des protocoles. Il fonctionne par des groupes de travail[2] form? avec un objectif pr?is. Lorsque les travaux d'un groupe sont termin?, celui-ci est aboli. En ce sens, les groupes de travail apparaissent et disparaissent r?uli?ement. Les groupes de travail sont regroup? par domaine d'application. Il existe pr?entement 8 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?ident de l'IETF, ceux-ci forment l'IESG.
Il n'y a pas d'affiliation ("membership") ou de repr?entation 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?erminants d'influence sont la cr?ibilit? la comp?ence et la qualit des propositions permettant de r?oudre une probl?atique bien identifi?.
Il n'y a pas de processus de votation sur les normes l'IETF. David Clark de MIT a bien r?um le credo de l'IETF de la mani?e suivante: "Rough concensus and running code". Ce credo, maintes fois r??? confirme l'ambiance de l'IETF: il n'est pas n?essaire d'avoir l'accord unanime de tous, mais plut? de refl?er un certain consensus. En plus, pour parvenir une norme homologu?, il faut d?ontrer deux implantations ind?endantes du protocole propos r?lisant l'interop?abilit 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? parfois un peu "brouillon" dans son fonctionnement. Une participant aux ateliers de l'IETF comprend cette dynamique. Paradoxalement, ce fonctionnement assure l'excellente qualit technique des normes homologu?s. L'historique et la pr?ence actuelle et future de l'Internet le confirment.
Une norme Internet est une sp?ification ?rite, stable, techniquement solide, pr?entant plusieurs implantations ind?endantes et interop?ables avec une exp?ience r?lle d'utilisation, support? de fa?n significative par la communaut? et utile pour une partie ou l'ensemble d'Internet. La norme a ? homologu? par le processus de normalisation de l'IETF et poss?e un num?o de RFC ("Request For Comments"). La sp?ification est disponible sur Internet.
Chaque version d'une norme est publi? sous forme d'un document appel RFC
(Request for Comments) auquel on attribue un num?o unique. Ainsi, une version
plus r?ente d'une norme sera publi? sous un autre num?o RFC. Les num?os sont
allou? de fa?n s?uentielle selon la date de leur d??. Ainsi deux versions
d'une m?e norme auront des num?os diff?ents et ind?endants. L'IAB mandate un
?iteur[3] pour g?er les RFC. Jon Postel de ISI (Information Sciences
Institute[4]) joue ce r?e depuis les d?uts.
? la diff?ence
d'autres organismes de normalisation et de standardisation, l'auteur ou les
auteurs de la norme sont identifi? clairement dans l'en-t?e du document RFC.
Les documents sont r?ig? en anglais.
Un document RFC n'implique pas
qu'il s'agisse d'une norme reconnue et approuv? par l'IETF. Cet ?at de fait
est bien expliqu?A
href="normes.html#fn4"
name=fnB4>[5] dans le RFC 1796. En effet, il existe plusieurs niveaux de
normes. Ces niveaux correspondent la maturit de chacune des normes.
Les normes propos?s ("Proposed standard") correspondent au premier niveau de maturit? Elles ont obtenu une premi?e approbation par le groupe de travail impliqu et par l'IESG. Elles sont g??alement stables, sont bien d?inies, ont r?olu les probl?atiques cibl?s et sont consid??s ad?uates par la communaut?
Une norme pr?iminaire ("Draft standard") doit avoir ? mise en oeuvre dans sa totalit par au moins deux logiciels distincts de sources diff?entes. Des tests doivent d?ontrer l'interop?abilit de ces logiciels. De plus, ce type de norme doit avoir ? largement utilis avant d'obtenir cette homologation. Une norme de ce type doit ?re consid?? comme une sp?ification compl?e et finale.
Les normes homologu?s ("Standard") sont des normes d?rites par un RFC et qui poss?ent en plus un num?o STD (STandarD). C'est le niveau de maturit le plus haut dans les normes de l'IETF. Elles correspondent une norme homologu?, tr? bien d?inie, mise en pratique sur Internet et ayant atteint un haut niveau de maturit? Les normes STD sont list?s en annexe de ce document.
Certains documents RFC sont des conclusions sur la meilleure mani?e de faire certaines op?ations ou d'exploiter certains protocoles. Ils poss?ent en plus de leur num?o RFC un num?o suppl?entaire BCP (Best Current Practice). Les normes de pratique recommand? ne constituent pas la sp?ification d'un protocole.
Plusieurs documents RFC ne sont ou ne seront jamais des normes homologu?s et
officielles. Dans ce cas, elles sont publi?s avec la mention "Experimental" ou
"Informational", selon le cas. L'?iteur des RFC en consultation avec l'IESG
d?ermine cette mention.
Les normes informatives ("Informational")
sont publi?s pour l'int?? g??al de l'Internet. Elles ne font pas
n?essairement l'objet d'un consensus ou d'une recommandation. Des
sp?ifications produites en dehors du processus de l'IETF sont souvent publi?s
comme "Informational".
Une norme exp?imentale ("Experimental") d?igne une sp?ification utilis? dans un travail de recherche et de d?eloppement. Elle est publi? pour l'int?? g??al de l'Internet.
Une norme peut r?uli?ement ?re r?is?. Lorsqu'une r?ision rend d?u?e la version pr??ente, celle-ci obtient le statut de norme historique ("Historic").
Durant le d?eloppement d'une sp?ification, des documents de travail appel? "Internet-Drafts" sont publi? pour fin de discussion. Ils sont disponibles dans un r?ertoire 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?ertoire. Il est important de comprendre que ces documents de travail n'ont aucune valeur de norme et ne sont pas homologu?. Aucun appel d'offres ou document officiel ne devrait faire r??ence ces documents de travail.
Pour qu'un document devienne une norme, il doit en premier ?re ?rit sous la
forme d'un document de travail ("draft") et ?re disponible pendant un minimum
de 2 semaines[7] pour r?ision 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 les diff?ents crit?es d'une norme, le document est soumis un avis
public de commentaires. Selon les commentaires re?s et le jugement de l'IESG,
le document peut ?re soit homologu comme norme dans la cat?orie demand? ou
dans une autre cat?orie, soit ?re refus ou retard?
Si la norme est
accept?, l'IESG demande l'?iteur des RFC de publier la norme.
Dans
le cas d'une norme de type "Informational" ou "Experimental", le document peut
?re soumis directement l'?iteur des RFC.
Une norme de type "Proposed
Standard" doit rester au moins 6 mois ce niveau avant d'avancer au niveau
"Draft". De m?e, une norme de type "Draft" doit rester au moins 4 mois ce
niveau avant d'avancer au niveau "Standard".
Une norme n'atteignant pas
le niveau "Standard" et restant au m?e niveau pendant 24 mois sera r?is? par
l'IESG tous les douze mois subs?uents.
Les contributions
intellectuelles aux normes sont c??s de fa?n perp?uelle et illimit?
l'Internet Society pour publication sans restriction. Lorsqu'une sp?ification
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?ification.
Le processus de normalisation est d?aill avec toutes les
modalit?[8] dans le RFC 2026.
Pour contribuer une norme de l'IETF, voici quelques
recommandations:
Les principales normes de l'IETF reli?s la francisation et
l'internationalisation sont d?rites dans cette section. Il faut mentionner que
l'IETF a approuv plus de 2200 normes au moment de l'?riture de ce rapport.
Pour aider le lecteur se retrouver, nous avons regroup les normes par
protocole ou par service Internet connu, tel que le courrier ?ectronique, le
web, les nouvelles, etc. Dans chaque regroupement, nous mentionnons en premier
les normes principales du protocole ainsi que celles plus directement reli?s
l'internationalisation. Nous listons dans une section suivante les autres normes
reli?s au protocole mais moins pertinentes 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'?rire ce rapport.
Dans
les tableaux listant les normes, la premi?e colonne indique le num?o du
document RFC relatif cette norme. La deuxi?e colonne indique l'?at de la
norme. On distingue les codes suivants:
| Code | ?tat de la norme |
| S | "Standard" |
| D | "Draft" |
| P | "Proposed" |
| B | "Best Current Practice" |
| I | "Informational" |
| E | "Experimental" |
Dans un contexte g??al, les normes de l'IETF reli?s
l'internationalisation utilisent un codage binaire et un jeu de caract?es
pr?is pour v?iculer l'information textuelle. La premi?e section sur les
normes reli?s l'internationalisation porte donc sur le codage.
La repr?entation de l'information n?essite 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 ??ent de donn?s utilis sur Internet pour v?iculer les caract?es. Ce
codage ne permet aucune lettre accentu?.
L'esprit de l'IETF consiste
ne pas r?nventer ce qui a ? bien con? ailleurs. Ainsi, le codage utilis du
c? 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?ents codes de caract?es utilis? dans les protocoles de
l'IETF sont enregistr? par l'IANA (Internet Assigned Numbers Autority), selon
le processus d?rit dans le RFC 2278.
L'IETF envisage maintenant sur l'utilisation du jeu universel de caract?es
ISO/CEI 10646 avec le codage UTF-8 tel que mentionn dans le RFC 2130. Ce RFC de
type "informational" est le r?um 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? 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 ? r?ig? selon les conclusions
du RFC 2130 et a ? homologu? sous la forme d'un RFC "Best Current Practice",
portant le num?o 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 invitons fortement le lecteur le lire.
En
r?um? le document RFC 2277 ?ablit les orientations suivantes:
Il est ainsi n?essaire de baliser la langue utilis? dans un texte
quelconque. Le RFC 1766 normalise les balises de langue.
| Num?o du RFC | ?tat | Titre |
| 1766 | P | Tags for Language names |
| 2130 | I | Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 |
| 2152 | I | UTF-7 A Mail-Safe Transformation Format of Unicode |
| 2277 | B | IETF Policy on Character Sets and Languages |
| 2278 | IANA Charset Registration Procedures | |
| 2279 | I | UTF-8, a Transformation Format of ISO 10646 |
Dans beaucoup de travaux sur la francisation et l'internationalisation dans les technologies de l'information, l'ISO[12] (associ? avec la CEI) joue un r?e cl? Les travaux de l'ISO et de la CEI ont entre autres produit les jeux de caract?es ISO/CEI 8859-1 et ISO/CEI 10646. Une nouvelle partie[13] de la s?ie de normes ISO/CEI 8859 (jeux de caract?es cod? 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?is et le finnois, est actuellement en d?eloppement, les premiers votes ayant d? eu lieu au moment d'?rire ce rapport.
La norme MIME est utilis? pour d?inir le format des messages multim?ia sur
Internet. Un message cod selon la norme MIME contient les en-t?es n?essaires
pour d?rire le type des donn?s utilis? Le contenu du message peut ?re
compos d'un ou plusieurs des ??ents suivants : texte, image, son, fichier
binaire quelconque, etc.
Un message MIME contient les principaux
en-t?es suivants:
| Nom de l'en-t?e | Description |
| MIME-Version | indique que le message est de type MIME et identifie la version du protocole MIME |
| Content-Type | identifie le type de contenu, comme par exemple que le contenu est du texte, une image gif, un fichier Word, etc. Le nom des balises est normalis? |
| Content-Transfer-Encoding | identifie le codage du contenu. |
Les messages contenant des caract?es accentu? ont un codage
sp?ifi dans l'en-t?e "Content-Transfer-Encoding".
Initialement pr?ue
pour le courrier ?ectronique, la norme MIME est aussi utilis? pour les
transactions du Web et dans la lecture des nouvelles Usenet.
| Num?o du RFC | ?tat | Titre |
| 2045 | D | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies |
| 2046 | D | Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types |
| 2047 | D | MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text |
| 2048 | B | Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures |
| 2049 | D | Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples |
| 2183 | P | Communicating Presentation Information in Internet Messages: The Content-Disposition Header |
| 2110 | P | MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) |
| 2231 | P | MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations |
Les documents RFC suivants sont int?r? au protocole mais ne sont pas strictement reli? l'internationalisation.
| Num?o du RFC | ?tat | Titre |
| 1896 | I | The text/enriched MIME Content-type |
| 1740 | P | MIME Encapsulation of Macintosh Files - MacMIME |
| 1741 | I | MIME Content Type for BinHex Encoded Files |
| 1767 | P | MIME Encapsulation of EDI Objects |
| 2017 | P | Definition of the URL MIME External-Body Access-Type |
Depuis plusieurs ann?s, plusieurs groupes de travail de l'IETF ont tent d'enrichir le protocole MIME pour assurer la s?urit des messages par les m?anismes de chiffrement et de signature. Le pr?ent rapport n'a pas pour objet de discuter des fonctions de s?urit? mais on peut affirmer que le chiffrement est un codage suppl?entaire aux autres m?anismes de codage de l'information. Ainsi, il peut avoir une influence sur le r?ultat final du contenu du message. Les deux principaux protocoles de s?urit? utilis? conjointement avec MIME, sont PGP-MIME d?rit dans le RFC 2015 et SMIME. Ce dernier est l'objet d'un groupe de travail au moment de l'?riture de ce rapport.
| Num?o du RFC | ?tat | Titre |
| 2015 | P | MIME Security with Pretty Good Privacy (PGP) |
On peut d?rire succintement les m?anismes fonctionnels du Web par
les trois ??ents suivants:
HTML ("HyperText Markup Language") est un langage pour cr?r des
documents ind?endants du logiciel ou du mat?iel o ils sont visualis?. Les
documents HTML sont utilis? sur le Web depuis 1990. HTML utilise pr?entement
un alphabet bas sur le jeu de caract?es ISO/CEI 8859-1. Les documents HTML
utilisent la norme MIME pour d?rire leur contenu.
Une norme[14] assurant l'internationalisation au-del du jeu de caract?es
ISO/CEI 8859-1 a ? homologu? dans le document RFC2070. Elle d?rit
l'utilisation du jeu de caract?e ISO/CEI 10646 dans le langage HTML.
Le
protocole HTTP est utilis pour transmettre les donn?s du Web. Ce protocole
utilise la norme MIME pour d?rire la nature des donn?s qui sont transmises.
Pour assurer la n?ociation des param?res d'internationalisation, HTTP (v1.1)
supporte les en-t?es suivants.
| En-t?e | Description |
| Accept-Charset | Permet un client d'informer le serveur des jeux de caract?es qu'il peut accepter. |
| Accept-Encoding | Permet un client d'informer le serveur de l'encodage qu'il peut accepter. |
| Accept-Language | Permet un client d'informer le serveur des langues pr???s lors de la r?onse. |
| Content-Encoding | Identifie le codage utilis dans la transmission d'un document ou d'un message. |
| Content-Language | Identifie la langue utilis? dans la transmission d'un document ou d'un message. |
| Num?o du RFC | ?tat | Titre |
| 2068 | P | Hypertext Transfer Protocol -- HTTP/1.1 |
| 1866 | P | Hypertext Markup Language - 2.0 |
| 1738 | P | Uniform Resource Locators (URL) |
| 2070 | P | Internationalization of the Hypertext Markup Language |
| 2141 | P | URN Syntax |
Il faut mentionner que le World Wide Web Consortium[15] (W3C) joue un r?e majeur dans la normalisation des protocoles du Web. Le lecteur int?ess devrait consulter attentivement les r?ultats des travaux du W3C. Au moment de l'?riture du rapport, plusieurs travaux sont en cours au W3C sur l'internationalisation, notamment la version 4 du langage HTML.
La transmission du courrier ?ectronique sur Internet utilise le protocole
SMTP (Simple Mail Transfer Protocol, RFC 821). La d?inition du protocole SMTP a
? publi? en 1982. ? cette ?oque, l'utilisation de caract?es autre que ceux
de l'US-ASCII n'?ait pas une pr?ccupation aux ?tats-Unis. Par cons?uent, la
d?inition du protocole SMTP pr?oit que l'utilisation du jeu de caract?es
US-ASCII.
Un groupe de travail a ? mis en place l'IETF (Internet
Engineering Task Force) il y a plusieurs ann?s pour moderniser le courrier
?ectronique de mani?e ce qu'il supporte les caract?es accentu?, les pi?es
jointes et les ??ents multim?ias. Les travaux de ce groupe de travail ont ?
tr? lents produire des r?ultats. Pendant ce temps, sous la pression des
clients, plusieurs producteurs de logiciels et de syst?es d'exploitation ont
d?i de la norme SMTP 7 bits pour supporter int?ralement les 8bits de chaque
octet, assurant ainsi l'usage des caract?es accentu? avec le codage implicite
ISO/CEI 8859-1. Les utilisateurs europ?ns, qu??ois et autres ont donc utilis
ces extensions non-normalis?s puisqu'elles leur permettaient d'?hanger du
courrier ?ectronique dans leur langue. ? posteriori, le mode 8 bits a ?
normalis en pr?oyant une n?ociation pr?lable entre le logiciel client et le
logiciel serveur, avec le mode "Extended SMTP" d?rit dans les documents RFC
1869,1652 et 1428. Plusieurs probl?es que nous vivons aujourd'hui avec le
courrier ?ectronique accentu tirent leur origine du cours de ces
??ements.
La norme MIME pr?oit un codage des messages au del du jeu
de caract?es US-ASCII (ISO/CEI 646). Il permet de contourner les contraintes
impos?s par le protocole SMTP et d'assurer l'usage de caract?es accentu? dans
le courrier ?ectronique.
L'utilisation de MIME avec un code 7bits
pour les caract?es accentu? (souvent appel mode QP (Quoted Printable) dans
les logiciels de courrier ?ectronique) ou l'utilisation du codage 8 bits avec
le mode "Extended SMTP" constituent les seules fa?ns de garantir l'acheminement
des caract?es accentu? sur Internet.
Les protocoles POP3 ou IMAP4 sont
utilis? pour permettre un utilisateur de t??harger ses messages de courrier
?ectronique partir d'un serveur. IMAP4 offre en plus des fonctions de gestion
de bo?e de courrier distance.
| Num?o du RFC | ?tat | Titre |
| 821 | S | Simple Mail Transfer Protocol (SMTP) |
| 822 | S | Format of mail messages |
| 1869 | S | SMTP Service Extensions |
| 1652 | D | SMTP Service Extension for 8bit-MIMEtransport |
| 1428 | I | Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME |
| 1939 | D | Post Office Protocol (POP3) |
| 2060 | P | Internet Message Access Protocol (IMAP4) |
| 1049 | S | Content type headers |
| 2076 | I | Common Internet Message Headers |
| Num?o du RFC | ?tat | Titre |
| 1891 | P | SMTP Service Extension for Delivery Status Notifications |
| 1892 | P | The Multipart/Report Content Type for the Reporting of Mail
System Administrative Messages |
| 1893 | P | Enhanced Mail System Status Codes |
| 1894 | P | An Extensible Message Format for Delivery Status Notifications |
| 2034 | P | SMTP Service Extension for Returning Enhanced Error Code |
| 2095 | P | IMAP/POP AUTHorize Extension for Simple Challenge/Response |
| 2192 | P | IMAP URL Scheme |
Le consortium IMC (Internet Mail Consortium[16]), fond par deux experts dans ce domaine, constitue un point de coordination pour le d?eloppement et l'implantation des normes reli?s au courrier ?ectronique sur Internet. Par la repr?entation de ses membres, il contribue de fa?n importante aux activit? de normalisation de l'IETF autant dans la phase de conception que dans la phase d'implantation et de tests d'interop?abilit? Le lecteur int?ess devrait consulter attentivement les travaux de l'IMC.
Les annuaires ?ectroniques permettent aux usagers d'Internet d'interroger
une base de donn?s et ainsi de trouver de l'information sur un individu, une
entit ou un objet du r?eau. Historiquement, pour les besoins de gestion du
r?eau, la base de donn?s Whois ?ait utilis?. Depuis, plusieurs protocoles
diff?ents ont ? test? ou utilis?, tels que X.500, ph/qi, whois++.
L'orientation courante est d'utiliser le protocole d'acc? aux annuaires LDAP
(Lightweight Directory Access Protocol).
La base de donn?s Whois est un
r?ertoire ?ectronique accessible sur Internet qui permet la recherche
d'individus, de noms de domaines, de noms de machines cl? et d'autres
informations d'int?? 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?ents langages et alphabets.
Ph/Qi est un protocole
simple et un logiciel permettant l'acc? un seul annuaire. Plusieurs logiciels
de courrier ?ectronique, tels qu'Eudora, utilisent ce protocole. Il a ?
document posteriori dans un document de travail[17]. Il est limit quant sa capacit de g?er l'acc? de
multiples annuaires, sans connaissance pr?lable du serveur. Quant
l'internationalisation, les impl?entations initiales ne supportaient que les
caract?es 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 ?ectronique sur
Internet. Plusieurs manufacturiers soutiennent d? LDAP. Ce protocole
correspond l'orientation courante de l'IETF en mati?e d'annuaires
?ectroniques. La version 3 de LDAP, tout r?emment homologu?, utilise le
codage UTF-8 du jeu universel de caract?es ISO/CEI 10646.
| Num?o du RFC | ?tat | Titre |
| 1777 | D | Lightweight Directory Access Protocol (LDAP) |
| 1959 | P | LDAP URL Format |
| 1834 | I | Whois and Network Information Lookup Service (Whois++) |
| Num?o du RFC | ?tat | Titre |
| 1778 | D | String Representation of Standard Attribute Syntaxes |
| 1960 | P | String Representation of LDAP Search Filters |
| 1835 | P | Architecture of the Whois++ Service |
| 1913 | P | Architecture of the Whois++ Index Service |
| 2079 | P | Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) |
| 2218 | P | A Common Schema for the Internet White Pages Service |
Les travaux du groupe de travail LDAPEXT proposent pr?entement une extension pour supporter les balises identifiant la langue utilis? dans le contenu.
Le consortium IMC joue aussi un r?e de coordination pour le d?eloppement et
l'implantation des normes reli?s aux annuaires sur Internet. Le lecteur
int?ess devrait consulter attentivement les travaux de l'IMC
(http://www.imc.org).
Concomitant aux annuaires, le protocole vCard[18] a ? propos par le consortium Versit et est pr?entement
maintenu par le consortium IMC. Ce protocole permet de cr?r l'?uivalent de la
carte d'affaires sur Internet. Une version normalis? par l'IETF est en cours de
d?eloppement.
Le DNS est un service de base de donn?s distribu? sur Internet. Ce service
permet en outre d'?ablir une correspondance entre l'adresse internet et le nom
d'une machine.
Diff?entes restrictions existent quant au choix des noms
de machines. Le nom d'une machine ne doit pas d?asser 63 caract?es et doit
?re compos de certains caract?es cod? en US-ASCII, limit? aux lettres, aux
chiffres et au caract?e '-' seulement. Ainsi, pour le moment, aucune
francisation int?rale ou internationalisation des noms de domaines n'est
possible.
Voici les principaux documents relatifs au DNS.
| Num?o du RFC | ?tat | Titre |
| 974 | S | Mail Routing and the Domain System |
| 1034 | S | Domain names - concepts and facilities |
| 1035 | S | Domain Names--Implementation and Specification |
| 1155 | S | Structure and identification of management information for TCP/IP-based internets |
| Num?o du RFC | ?tat | Titre |
| 1912 | I | Common DNS Operational and Configuration Errors |
| 2181 | P | Clarifications to the DNS Specification |
| 2219 | B | Use of DNS Aliases for Network Services |
| 1995 | P | Incremental Zone Transfer in DNS |
| 1464 | E | Using the Domain Name System To Store Arbitrary String Attributes |
| 1178 | I | Choosing a Name for Your Computer |
| 1101 | DNS Encoding of Network Names and Other Types |
Le protocole Telnet permet l'acc? un ordinateur par l'entremise d'un terminal distant. La plupart des implantations supportent diff?ents ?ulateurs de terminaux. Si leurs caract?istiques le permettent, ceux-ci soutiennent correctement les caract?es accentu?.
| Num?o du RFC | ?tat | Titre |
| 854 | S | Telnet Protocol specification |
| 855 | S | Telnet option specifications |
Le protocole FTP assure le transfert de fichiers d'un ordinateur un autre. Les fichiers peuvent ?re de format quelconque, ce qui permet le format binaire et les caract?es accentu?. Ainsi, le transfert de fichiers en fran?is ne cause pas de probl?es. Cependant, les noms des fichiers doivent ?re strictement en ASCII, restreignant ainsi l'utilisation du fran?is dans les noms de fichiers.
| Num?o du RFC | ?tat | Titre |
| 959 | S | File Transfer Protocol |
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?es ISO/CEI 10646 dans les noms de fichiers.
Les RFC suivants d?inissent les exigences g??ales auxquelles
doivent adh?er les machines sur Internet. Ces RFC concernent les applications
et les protocoles.
| Num?o du RFC | ?tat | Titre |
| 1122 | S | Requirements for Internet Hosts - Communication Layers |
| 1123 | S | Requirements for Internet Hosts - Application and Support |
Selon les orientations trac?s par l'IETF r?emment, il nous semble clair que
le support du jeu de caract?es ISO/CEI 10646 l'aide du codage UTF-8 doit ?re
pr?u d? la conception d'un logiciel qui sera utilis sur Internet. Il doit
aussi ?re pr?u de supporter ISO/CEI 8859-1 pour le fran?is. La norme ISO/CEI
8859-15 serait aussi consid?er, malgr que son homologation n'est pas
termin?.
Consid?ant les efforts tr? importants pour baliser la langue
utilis? dans le texte lorsque cela est fait posteriori, il nous semble clair
que la conception d'un logiciel devrait int?rer le balisage de la langue selon
le RFC 1766 et pr?oir un usage multilingue.
Enfin, tout balisage de
document et de codage devrait utiliser la norme MIME.
Il existe de multiples sources d'information au sujet des normes de l'Internet. Nous n'en nommerons que quelques-unes.
| Titre | Adresse | Description |
| IETF | http://www.ietf.org | Site web de l'IETF |
| IESG | http://www.ietf.org/iesg.html | Site web de l'IESG |
| RFC Editor | http://www.isi.edu/rfc-editor | Site web du responsable des RFC. |
| Index des RFC | ftp://ftp.isi.edu/in-notes/rfc-index.txt | Liste officielle des RFC courants avec leur ?at. |
| Internet Monthly Report | Ce rapport mensuel liste tous les nouveaux RFC, les nouveaux documents de travail, les activit? de normalisation et d'enregistrement. Tr? complet. | |
| Liste IETF | ietf-request@ietf.org | Liste de discussions ouverte regroupant les personnes impliqu?s l'IETF. |
| Liste d'annonces de l'IETF | ietf-announce-request@ietf.org | Liste de courrier annon?nt les nouveaux RFC, les documents de travail, les prochains ateliers, les actions de l'IESG, ... |
| World Wide Web Consortium | http://www.w3c.org | Site web du W3C. |
Nous avons fait tous les efforts possibles pour que le pr?ent document soit exact au moment de sa r?action. Cependant, consid?ant l'?olution tr? rapide des normes de l'IETF et l'?olution de l'IETF lui-m?e, ce document deviendra t? ou tard incomplet. Cette section donne au lecteur quelques suggestions pour s'assurer d'avoir acc? l'information la plus r?ente.
Pour v?ifier l'?at d'un RFC, on peut consulter l'index des RFC[20]. Cet index est toujours mis jour par le responsable de l'?ition des RFC. Il permet d'identifier l'?at du RFC ainsi que les modifications subs?uentes du protocole document?s l'int?ieur de d'autres RFC.
Un RFC peut avoir ? mis jour partiellement par un autre RFC. L'index des RFC mentionn plus haut liste les relations entre les RFC.
Il est important de conna?re les travaux en cours l'IETF. En effet, un protocole peut tout moment ?re soumis une revision par un groupe de travail. Le fait de consulter le RFC ad?uat assure seulement la connaissance du protocole normalis? mais pas n?essairement des prochaines versions. La liste des groupes de travail actifs devrait ?re consult?[21].
Les documents de travail ("drafts") ne sont conserv? que 6 mois sur le serveur[22] de l'IETF. Ainsi, il est possible que la r??ence un document "draft" ne soit plus valide. G??alement, les documents ont toujours un num?o de version dans le titre. Il est important de v?ifier si une version plus r?ente existe. Un document de travail peut aussi avoir ? converti en RFC. On peut aussi se r??er la page du groupe de travail[23] auquel est assign ce document de travail.
Au moment d'?rire ce rapport, les deux listes de courrier ?ectronique suivantes servent aux discussions sur l'internationalisation.
| ietf-charsets-request@innosoft.com |
| ietf-languages-request@apps.ietf.org |
On peut s'abonner ces listes en envoyant un message ayant comme contenu le mot "subscribe" l'adresse mentionn? au tableau pr??ent.
Ce rapport tente d'orienter le lecteur sur les principales normes de
l'Internet reli?s la francisation et l'internationalisation. Il faut
comprendre que le fait qu'une norme soit homologu? ne constitue pas
n?essairement une preuve qu'elle soit utilis? sur Internet. Au lieu de donner
une liste exhaustive de toutes les normes homologu?s par l'IETF, nous avons
tent de lister les plus importantes et les plus pertinentes. Cet exercice est
n?essairement 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?irons remercier M. Alain Labont pour
ses suggestions tr? pertinentes sur ce document.
Les RFC sont disponibles l'adresse http://ds.internic.net/rfc. Les documents de travail (drafts) sont disponibles l'adresse ftp://ftp.ietf.org/internet-drafts.
Le tableau suivant liste les normes homologu?s ("Standard") lors de la r?action de ce rapport. Cette homologation ne signifie pas n?essairement qu'ils sont tous utilis? sur Internet, mais atteste plut? de leur haut degr de maturit et de la reconnaissance par la communaut? Cette liste est disponible dans le RFC 2200.
| Num?o | Titre | Auteur | Date | RFC correspondant |
| 1 | INTERNET OFFICIAL PROTOCOL STANDARDS | J. Postel | Juin 1997 | RFC2200 |
| 2 | Assigned Numbers | J. Reynolds, J. Postel |
October 1994 | RFC1700 |
| 3 | Host Requirements | R. Braden | October 1989 | RFC1122, RFC1123 |
| 4 | Gateway Requirements | R. Braden, J. Postel |
June 1987 | RFC1009 |
| 5 | Internet Protocol | J. Postel | September 1981 | RFC0791, RFC0950, RFC0919, RFC0922, RFC792, RFC1112 |
| 6 | User Datagram Protocol | J. Postel | August 1980 | RFC0768 |
| 7 | Transmission Control Protocol | J. Postel | September 1981 | RFC0793 |
| 8 | Telnet Protocol | J. Postel, J. Reynolds |
May 1983 | RFC0854, RFC0855 |
| 9 | File Transfer Protocol | J. Postel, J. Reynolds |
October 1985 | RFC0959 |
| 10 | SMTP Service Extensions | J. Klensin, N.Freed, M. Rose, E. Stefferud D. Crocker |
November 1995 | RFC821, RFC1869 |
| 11 | SMTP Service Extension for Message Size Declaration | J. Klensin, N. Freed, K. Moore |
November 1995 | RFC1870 |
| Standard for the format of ARPA Internet text messages | D. Crocker | August 1982 | RFC0822 | |
| 12 | Network Time Protocol | D. Mills | September 1989 | RFC1119 |
| 13 | Domain Name System | P.Mockapetris | November 1987 | RFC1034, RFC1035 |
| 14 | Mail Routing and the Domain System | C. Partridge | January 1986 | RFC0974 |
| 15 | Simple Network Management Protocol | J. Case, M. Fedor, M. Schoffstall, J. Davin |
May 1990 | RFC1157 |
| 16 | Structure of Management Information | M. Rose, K. McCloghrie |
May 1990 | RFC1155, RFC1212 |
| 17 | Management Information Base | K.McCloghrie, M. Rose | March 1991 | RFC1213 |
| 18 | Exterior Gateway Protocol | D. Mills | April 1984 | RFC0904 |
| 19 | NetBIOS Service Protocols | NetBIOS Working Group | March 1987 | RFC1001, RFC1002 |
| 20 | Echo Protocol | J. Postel | May 1983 | RFC0862 |
| 21 | Discard Protocol | J. Postel | May 1983 | RFC0863 |
| 22 | Character Generator Protocol | J. Postel | May 1983 | RFC0864 |
| 23 | Quote of the Day Protocol | J. Postel | May 1983 | RFC0865 |
| 24 | Active Users Protocol | J. Postel | May 1983 | RFC0866 |
| 25 | Daytime Protocol | J. Postel | May 1983 | RFC0867 |
| 26 | Time Server Protocol | J. Postel | May 1983 | RFC0868 |
| 27 | Binary Transmission Telnet Option | J. Postel, J. Reynolds |
May 1983 | RFC0856 |
| 28 | Echo Telnet Option | J. Postel, J. Reynolds |
May 1983 | RFC0857 |
| 29 | Suppress Go Ahead Telnet Option | J. Postel, J. Reynolds |
May 1983 | RFC0858 |
| 30 | Status Telnet Option | J. Postel, J. Reynolds |
May 1983 | RFC0859 |
| 31 | Timing Mark Telnet Option | J. Postel, J. Reynolds |
May 1983 | RFC0860 |
| 32 | Extended Options List Telnet Option | J. Postel, J. Reynolds |
May 1983 | RFC0861 |
| 33 | Trivial File Transfer Protocol | K. Sollins | July 1992 | RFC1350 |
| 34 | Routing Information Protocol | C. Hedrick | June 1988 | RFC1058 |
| 35 | ISO Transport Service on top of the TCP (Version: 3) | M. Rose, D. Cass |
May 1978 | RFC1006 |
| 36 | Transmission of IP and ARP over FDDI Networks | D. Katz | January 1993 | RFC1390 |
| 37 | An Ethernet Address Resolution Protocol | David C. Plummer | November 1982 | RFC0826 |
| 38 | A Reverse Address Resolution Protocol | Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer | June 1984 | RFC0903 |
| 39 | Interface Message Processor: Specifications for the Interconnection of a Host and an IMP (Revised) | BBN | December 1981 | |
| 40 | Host Access Protocol specification | Bolt Beranek and Newman | August 1993 | RFC1221 |
| 41 | Standard for the transmission of IP datagrams over Ethernet networks | C. Hornig | April 1984 | RFC0894 |
| 42 | Standard for the transmission of IP datagrams over experimental Ethernet networks | J. Postel | April 1984 | RFC0895 |
| 43 | Standard for the transmission of IP datagrams over IEEE 802 networks | J. Postel, J.K. Reynolds |
August 1993 | RFC1042 |
| 44 | DCN Local-Network Protocols | D.L. Mills | August 1993 | RFC0891 |
| 45 | Internet Protocol on Network System's HYPERchannel: Protocol Specification | K. Hardwick, J. Lekashman |
August 1993 | RFC1044 |
| 46 | Transmitting IP traffic over ARCNET networks | D. Provan | August 1993 | RFC1201 |
| 47 | Nonstandard for transmission of IP datagrams over serial lines: SLIP | J.L. Romkey | August 1993 | RFC1055 |
| 48 | Standard for the transmission of IP datagrams over NetBIOS networks | L.J. McLaughlin | August 1993 | RFC1088 |
| 49 | Standard for the transmission of 802.2 packets over IPX networks | L.J. McLaughlin | August 1993 | RFC1132 |
| 50 | Definitions of Managed Objects for the Ethernet-like Interface Types | F. Kastenholz | July 1994 | RFC1643 |
| 51 | The Point-to-Point Protocol (PPP) | W. Simpson, Editor | July 1994 | RFC1661, RFC1662 |
| 52 | The Transmission of IP Datagrams over the SMDS Service | D. Piscitello J. Lawrence |
March 1991 | RFC1209 |
| 53 | Post Office Protocol - Version 3 | J. Myers M. Rose |
May 1996 | RFC1939 |
| Titre | Description |
| ANSI | American National Standards Institute |
| ARPA | Advanced Research Projects Agency |
| AS | Applicability Statement |
| FTP | File Transfer Protocol |
| ASCII | American Standard Code for Information Interchange |
| ITU-T | International Telecommunication Union |
| IAB | Internet Architecture Board |
| IANA | Internet Assigned Numbers Authority |
| IEEE | Institute of Electrical and Electronics Engineers |
| ICMP | Internet Control Message Protocol |
| IESG | Internet Engineering Steering Group |
| IETF | Internet Engineering Task Force |
| IP | Internet Protocol |
| IRSG | Internet Research Steering Group |
| IRTF | Internet Research Task Force |
| ISO | International Organization for Standardization |
| ISOC | Internet Society |
| MIB | Management Information Base |
| OSI | Open Systems Interconnection |
| RFC | Request for Comments |
| TCP | Transmission Control Protocol |
| TS | Technical Specification |
| WWW | World Wide Web |
Accueil | Qui sommes-nous ? | Biblioth?ue virtuelle | ?v?ements signaler | Vitrine VOIL
Normes et standards | Francisation des inforoutes | IETF et W3C | Nos coordonn?s | Courriel | Recherche