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., voirRFC3748) (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, voirRFC3066, 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, voirRFC2978) (Information)

[10]   F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", RFC2279, janvier 1998. (Obsolète, voirRFC3629) (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.