Groupe de travail Réseau	G. Zorn	
Request for Comments : 2484	Microsoft Corporation	
Catégorie : En cours de normalisation	janvier 1999	
RFC mises à jour : 2284, 1994, 1570	Traduction Claude Brière de L'Isle	

Option Configuration d'internationalisation de LCP en PPP

Statut du présent mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (1999). Tous droits réservés.

1.	Résumé

Le protocole point à point (PPP) [1] fournit une méthode standard pour le transport de datagrammes multi protocoles sur des liaisons point à point. PPP définit aussi un protocole de contrôle de liaison extensible (LCP, Link Control Protocol) qui permet la négociation d'un protocole d'authentification pour authentifier son homologue avant de permettre aux protocoles de couche réseau de transmettre sur la liaison.

Les paquets LCP et de protocole d'authentification peuvent tous deux contenir du texte qui est destiné au lecteur humain [2,3,4]. Le présent document définit une option de configuration LCP pour la négociation du jeu de caractères et du langage d'utilisation, selon les prescriptions de la RFC 2277 [5].

2.	Spécification des exigences

Dans le présent document, les mots clés "PEUT, "DOIT, "NE DOIT PAS", "facultatif", "recommandé", "DEVRAIT", et "NE DEVRAIT PAS" sont à interpréter comme décrit dans [6].

3.	Option supplémentaire de configuration LCP

Le format de l'option de configuration et des options de base sont déjà définis pour LCP [1].

Les valeurs à jour du champ Type d'option LCP sont spécifiées dans la STD 2 [7]. Le présent document concerne la valeur suivante :

28	Internationalisation

L'option Internationalisation décrite ici PEUT être négociée indépendamment dans chaque direction.

Une seule instance de cette option DEVRAIT être envoyée par une mise en œuvre, représentant son langage et jeu de caractères préférés.

Si l'option Internationalisation est rejetée par l'homologue, le langage et jeu de caractères par défaut DOIVENT être utilisés pour construire tous les messages lisibles par l'homme envoyés par l'homologue.

4.1	Internationalisation

Description
Cette option de configuration donne une méthode pour qu'une mise en œuvre indique à l'homologue à la fois le langage dans lequel devraient être composés les messages destinés au lecteur humain qu'il envoie ainsi que le jeu de caractères dans lequel ce langage devrait être représenté.

Un résumé du format de l'option Internationalisation est donné ci-dessous. Les champs sont transmis de gauche à droite.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Longueur   |          MIBenum
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             MIBenum (suite)       | Étiquette-de-langue...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 28

Longueur  : ≥ 7

MIBenum
Le champ MIBenum est long de quatre octets. Il contient une valeur unique d'entier qui identifie un jeu de caractères [5,11].

Cette valeur DOIT représenter un des jeux de caractères dont la liste figure dans le registre des jeux de caractères de l'IANA [7].

La procédure d'enregistrement des jeux de caractères est décrite dans la RFC 2278 [9].

La valeur du jeu de caractères par défaut est UTF-8 [10]. La valeur de MIBenum pour les jeux de caractères UTF-8 est 106.

Étiquette-de-langue
Le champ Étiquette-de-langue est une chaîne ASCII qui contient une étiquette de langage, comme défini dans la RFC 1766 [8].

Les étiquettes de langue sont en principe insensibles à la casse ; cependant, comme la mise en majuscules d'une étiquette n'a aucune signification, les mises en œuvre DEVRAIENT seulement envoyer des champs Étiquette en minuscules.

La valeur par défaut de Étiquette est "i-default" [8].

4.	Références

[1]	W. Simpson, éditeur, "Protocole point à point (PPP)", RFC1661, STD 51, juillet 1994. (MàJ par la RFC 2153)
[2]	W. Simpson, "Protocole d'authentification par mise en cause de la prise de contact en PPP (CHAP)", RFC1994, août 1996.
[3]	W. Simpson, "Extensions LCP pour PPP", RFC1570, janvier 1994. (P.S., MàJ par 2484)
[4]	L. Blunk, J. Vollbrecht, "Protocole extensible d'authentification (EAP) en PPP", RFC2284, mars 1998. (Obs., voir RFC3748) (P.S.)
[5]	H. Alvestrand, "Politique de l'IETF en matière de jeux de caractères et de langages", RFC2277, BCP 18, janvier 1998.
[6]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", RFC2119, BCP 14, mars 1997.
[7]	J. Reynolds et J. Postel, "Numéros alloués", RFC1700, STD 2, octobre 1994. (Historique, voir http://www.iana.org/numbers.html
[8]	H. Alvestrand, "Étiquettes pour l'identification des langues", RFC1766, mars 1995. (Obsolète, voir RFC3066, RFC3282) (P.S.)
[9]	N. Freed, J. Postel, "Procédures d'enregistrement des jeux de caractères par l'IANA", RFC2278, janvier 1998. (Obsolète, voir RFC2978) (Information)
[10]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", RFC2279, janvier 1998. (Obsolète, voir RFC3629) (D.S.)
[11]	R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog "MIB d'imprimante", RFC1759, mars 1995. (P.S., obsolète, remplacée par la RFC3805)

5.	Considérations pour la sécurité

Il est possible qu'un attaquant puisse manipuler l'option de telle façon que les messages affichables deviennent inintelligibles pour le lecteur.

6.	Remerciements

Merci à Craig Fox (fox@cisco.com), James Carlson (carlson@ironbridgenetworks.com), Harald Alvestrand (Harald.Alvestrand@maxware.no), Kevin Smith (kevin@ascend.com), Karl Fox (karl@ascend.com), Thomas Narten (narten@raleigh.ibm.com) and Narendra Gidwani (nareng@microsoft.com) pour leurs suggestions utiles et leur relecture.

7.	Adresse du président

Karl Fox
Ascend Communications
3518 Riverside Drive
Suite 101
Columbus, OH 43221
téléphone : +1 614 326 6841
mél : karl@ascend.com

8.	Adresse de l'auteur

Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052
téléphone : +1 425 703 1559
Fax :   +1 425 936 7329
mél : glennz@microsoft.com

9.	Déclaration de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.