Groupe de travail Réseau	H. Schulzrinne, Columbia U.
Request for Comments : 4776	novembre 2006
RFC rendue obsolète : 4676	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Option du protocole de configuration dynamique d'hôte (DHCPv4 et DHCPv6) pour les informations de configuration d'adresses civiles

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de 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 Trust (2006).

Note de l'éditeur des RFC
La RFC 4776 est publiée pour corriger une erreur d'allocation de la valeur numérique du code d'option DHCPv6 au paragraphe 3.2 de la RFC 4676. Le présent document rend obsolète la RFC 4676.

Résumé
Le présent document spécifie une option du protocole de configuration dynamique d'hôte (DHCP, Dynamic Host Configuration Protocol) (DHCPv4 et DHCPv6) contenant la localisation civile du client ou du serveur DHCP. Les informations de configuration de localisation (LCI, Location Configuration Information) incluent des informations sur le pays, les unités administratives comme les états, provinces, et villes, ainsi que les informations d'adresses de rues, de noms de communautés postales, et de bâtiments. L'option permet de multiples rendus de la même adresse dans différentes écritures et langages.
Table des matières
1. Introduction	1
2. Terminologie	3
3. Format de l'option DHCP Localisation civile	3
3.1. Format général pour DHCPv4	3
3.2 Format général pour DHCPv6	4
3.3 Format des éléments	4
3.4 Composants d'adresse civile	4
4. Adresses postales	7
5. Exemple	7
6. Considérations sur la sécurité	8
7. Considérations relatives à l'IANA	8
8. Références	9
8.1 Références normatives	9
8.2 Références pour information	9
Remerciements	10
Adresse de l'auteur	10
Déclaration complète de droits de reproduction	10

 	1.	Introduction

De nombreux services de système d'extrémité peuvent tirer parti de la connaissance de la localisation approximative de l'appareil d'extrémité. En particulier, les appareils de téléphonie IP ont besoin de savoir leur localisation pour contacter l'agence de réponse d'urgence appropriée et être trouvés par la réponse du service d'urgence.

Il y a deux façons courantes d'identifier la localisation d'un objet, soit par ses coordonnées géospatiales, soit par ce qu'on appelle des adresses civiles. Les coordonnées géospatiales indiquent la longitude, la latitude, et l'altitude, tandis que les adresses civiles indiquent une adresse de rue.

L'adresse civile (CA, Civic Address) est couramment, mais pas nécessairement, étroitement liée à l'adresse postale, utilisée par le service postal local pour livrer le courrier. Cependant, toutes les adresses postales ne correspondent pas à des adresses de rue. Par exemple, l'adresse de l'auteur est une adresse postale qui n'apparaît sur aucune rue ou signe de bâtiment. Naturellement, les boîtes postales des bureau de poste ne conviendraient pas pour les besoins décrits ici. Le terme "adresse civile" ou "adresse juridictionnelle" est parfois aussi utilisé au lieu de adresse civile. Le présent document prend principalement en charge les adresses civiles, mais permet que le nom de la communauté postale soit indiqué si il diffère du nom civil.

Un document en rapport avec celui-ci [RFC3825] décrit une option DHCPv4 [RFC2131] pour porter les informations géospatiales à un appareil. Le présent document décrit comment DHCPv4 et DHCPv6 [RFC3315] peuvent être utilisés pour porter l'adresse civile et postale aux appareils. Les deux formats géospatial et civil peuvent être utilisés simultanément, augmentant les chances de livrer des informations de localisation précises et en temps utile aux services d'urgence. Le lecteur devrait aussi être familiarisé avec les concepts de la [RFC4589], car beaucoup des éléments du protocole ci-dessous sont conçus pour s'assembler avec les éléments PIDF-LO.

Le présent document définit seulement la livraison des informations de localisation du serveur DHCP au client, du fait des problèmes de sécurité relatifs à l'utilisation de DHCP pour mettre à jour la base de données. Dans l'architecture GEOPRIV telle que définie par la [RFC3693], le mécanisme défini dans le présent document pour porter les informations initiales de localisation est appelé une fonction de "pointage". Les fonctions de pointage ne sont pas obligées d'avoir des capacités de sécurité et sont seulement destinées à être configurées dans des environnements de confiance contrôlés. (Un exemple classique de la fonction de pointage est un système de positionnement mondial raccordé directement à un nœud du réseau.) Une discussion plus approfondie des protections qui doivent être fournies conformément à la [RFC3694] figure dans les considérations sur la sécurité (Section 6).

Les systèmes d'extrémité qui obtiennent des informations de localisation via le mécanisme décrit ici utilisent ensuite d'autres mécanismes de protocole pour communiquer ces informations à un centre d'appels d'urgence ou pour les porter au titre d'informations de présence.

Les informations civiles sont utiles car elles fournissent souvent des informations supplémentaires lisibles par l'homme, en particulier dans les bâtiments. Aussi, comparées aux informations géospatiales, elles sont directement obtenues pour la plupart des structures occupées et peuvent souvent être interprétées même si elles sont incomplètes. Par exemple, pour de nombreux grands campus universitaires ou d'entreprises, des informations géocodées à la granularité du bâtiment et de la pièce ne peuvent pas être directement disponibles.

À la différence des informations géospatiales, le format des informations civiles et postales diffère d'un pays à l'autre. L'ensemble initial de champs de données est dérivé des standards publiés par l'association des numéros d'urgence des États Unis (NENA, United States National Emergency Number Association) [NENA] et prend en compte les conventions d'adressage d'un certain nombre de pays dans différentes zones du monde. Il est prévu que d'autres pays puissent réutiliser de nombreux éléments de données, mais le document établit aussi un registre de l'IANA pour définir des champs supplémentaires de données de localisation civile.

Les mêmes informations d'adresse civiles et postales peuvent souvent être rendues dans de multiples langages et écritures. Par exemple, les adresses coréennes sont souvent écrites en hangul, latin, et kanji, tandis que certaines des plus anciennes villes ont de multiples variantes de langage (par exemple, Munich, Muenchen, et Monaco). Comme DHCPv4 et DHCPv6 ne prennent actuellement pas en charge de mécanisme pour interroger sur une écriture ou langage spécifique, le serveur DHCP DEVRAIT fournir tous les rendus courants au client et DOIT fournir au moins le rendu dans le langage et l'écriture appropriés pour la localisation indiquée. Par exemple, pour l'utilisation dans les informations de présence, la cible peut être en visite dans un pays étranger et vouloir porter les informations dans un format convenable pour les observateurs de son pays d'origine. Pour les services d'urgence, le rendu dans le langage local est probablement le plus approprié. Pour fournir des rendus multiples, le serveur répète des séquences d'éléments d'adresse, préfixant chacun d'un élément 'langage' et/ou 'script' (voir au paragraphe 3.3). Le langage et l'écriture restent en effet pour les éléments suivants jusqu'à être outrepassés par un autre élément de langage ou d'écriture. Comme le client DHCP a peu de chances d'être le consommateur final des informations de localisation, le serveur DHCP doit fournir toutes les versions appropriées de langage et écriture que le client passe ensuite via un autre protocole utilisant GEOPRIV, normalement codé dans un format d'objet de localisation GEOPRIV fondé sur la présence [RFC4119].

Le serveur DHCP PEUT fournir des informations de localisation pour plusieurs localisations relatives à la cible, par exemple, à la fois l'élément de réseau et le circuit de réseau lui-même. Ceci est utile pour aider à déboguer des problèmes de réseau, par exemple.

Le présent document appelle à diverses décisions de fonctionnement. Par exemple, un administrateur doit décider quand fournir la localisation du serveur DHCP ou d'autres éléments de réseau même si ils peuvent être à une grande distance du client. L'administrateur doit aussi considérer si il va inclure les deux informations civiles et géospatiales si elles peuvent différer. Le document ne spécifie pas les critères à utiliser pour faire ces choix, car ils dépendent probablement fortement de circonstances locales et doivent se fonder sur une connaissance humaine locale.

Un système qui fonctionne avec des informations de localisation configurées par DHCP est dépendant de la vigilance des administrateurs des systèmes DHCP sur un certain nombre de fronts, comme :
-	si les informations sur la localisation sont fournies sous plusieurs formes (par exemple, dans plusieurs langues), sont-elles cohérentes ?
-	l'administrateur est-il certain que les informations de localisation sont configurées seulement sur les systèmes auxquels elles s'appliquent (par exemple, pas aux systèmes topologiquement proches, mais géographiquement loin) ?
-	si la localisation configurée n'est pas celle de la cible mais celle d'un nœud de réseau "du voisinage" ou du serveur DHCP, en dépit de la recommandation contre cette pratique au paragraphe 3.1, l'administrateur est-il certain que cette configuration est géographiquement valide ?

Il y a de nombreuses autres considérations pour s'assurer que les informations de localisation sont traitées en toute sécurité et rapidement en particulier pour un service d'urgence. Ce sont le domaine des applications qui utilisent les informations de localisation configurées, et cela sort du domaine d'application du présent document. La configuration DHCP NE DEVRAIT PAS être utilisée pour des services d'urgence sans des lignes directrices sur ces considérations. Des travaux sur ce sujet sont en cours dans le groupe de travail ECRIT de l'IETF au moment de la publication du présent document.

De plus, si un réseau fournit des informations civiles de localisation via DHCPv4 et DHCPv6, les informations convoyées par les deux protocoles DOIVENT être les mêmes.

Comme discuté dans les considérations sur la sécurité (Section 6) l'option GEOCONF_CIVIC NE DEVRAIT être retournée par les serveurs DHCPv4 QUE quand le client DHCPv4 a inclus cette option dans sa "liste des paramètres demandés" (paragraphe 3.5 de la [RFC2131]). De même, l'option OPTION_GEOCONF_CIVIC DEVRAIT être retournée par les serveurs DHCPv6 dans les seuls cas où le client DHCPv6 a inclus cette option dans son OPTION_ORO.

Le mécanisme DHCPv4 d'options longues décrit dans la [RFC3396] DOIT être utilisé si l'option Adresse civile excède la taille maximum d'option DHCPv4 de 255 octets.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

 	3.	Format de l'option DHCP Localisation civile
 	3.1.	Format général pour DHCPv4
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GEOCONF_CIVIC |       N       |      Quoi     |    Pays       |
+---------------+---------------+---------------+---------------+
|    Code       |        Éléments d'adresse civile            ...
+---------------+---------------+---------------+---------------+

Code GEOCONF_CIVIC : le code de cette option DHCP est 99.

N : la longueur de cette option est variable. La longueur minimum est 3 octets.

Quoi : l'élément "Quoi" décrit à quoi l'entrée de localisation DHCP se réfère. Actuellement, trois options sont définies : la localisation du serveur DHCP (valeur de 0) ; la localisation de l'élément de réseau estimé le plus proche du client (valeur de 1) ; ou la localisation du client (valeur de 2). L'option (2) DEVRAIT être utilisée, mais peut n'être pas connue. Les options (0) et (1) NE DEVRAIENT PAS être utilisées à moins qu'il soit connu que le client DHCP est physiquement proche du serveur ou de l'élément de réseau.

Code de pays : code de pays de deux lettres de la norme ISO 3166 en caractères ASCII majuscules, par exemple, DE ou US. (Les adresses civiles contiennent toujours la désignation du pays, suggérant l'utilisation d'un champ de format fixé pour économiser l'espace.)

Éléments d'adresse civile : zéro, un, ou plusieurs éléments qui composent l'adresse civile et/ou postale, dans le format décrit ci-dessous (paragraphe 3.3).

 	3.2	Format général pour DHCPv6
L'option adresse civile DHCPv6 [RFC3315] se réfère généralement au client comme à un tout.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      OPTION_GEOCONF_CIVIC     |         Longueur d'option     |
+---------------+---------------+---------------+---------------+
|      Quoi     |        Code de pays           |               .
+---------------+---------------+---------------+               .
.                    Éléments d'adresse civile                  .
.                              ...                              .
+---------------+---------------+---------------+---------------+

Code d'option : OPTION_GEOCONF_CIVIC (36)

Longueur d'option : longueur des champs Code de pays, Quoi et Éléments d'adresse civile en octets.

Quoi : voir au paragraphe 3.1.

Code de pays : voir au paragraphe 3.1.

Éléments d'adresse civile : voir au paragraphe 3.1.

 	3.3	Format des éléments
Pour DHCPv4 comme DHCPv6, chaque élément d'adresse civile (CA, Civic Address) a le format suivant :

 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 de CA   | Longueur de CA|    Valeur de CA             ...
+---------------+---------------+---------------+---------------+

Type de CA : descripteur d'un octet de la valeur des données d'adresse civile.

Longueur de CA : longueur, en octets, de la CAvalue, non inclus le champ CAlength lui-même.

Valeur de CA : valeur de l'adresse civile, comme décrit en détails ci-dessous.

 	3.4	Composants d'adresse civile
Comme chaque pays a des hiérarchies administratives différentes, avec souvent les mêmes noms (en anglais) la présente spécification adopte une notation hiérarchique simple qui est ensuite instanciée pour chaque pays. On suppose que cinq niveaux sont suffisants pour les divisions sous nationales au dessus du niveau de la rue.

Tous les éléments sont FACULTATIFS et peuvent apparaître dans n'importe quel ordre.

Les valeurs des composants DOIVENT être codées en UTF-8 [RFC3629]. Elles DEVRAIENT être écrites en casse mixte, suivant l'orthographe courante. L'indication de l'écriture (type de CA 128) DOIT être écrite en casse mixte, avec la première lettre en majuscule.

Les abréviations NE DOIVENT PAS être utilisées sauf comme indiqué pour chaque élément. Les abréviations n'ont pas besoin d'un point à la fin.

Il est RECOMMANDÉ que tous les éléments dans un script (CAtype 128) et langage (CAtype 0) particuliers soient groupés, car cela réduit le nombre d'identifiants d'écritures et langages nécessaires.

Pour chaque écriture et langage, les éléments DEVRAIENT être inclus en ordre numérique du plus faible au plus grand de leur type de CA. En général, un élément est étiqueté dans son langage et écriture par le plus récent élément "étiquette de langue" (CAtype 128) qui le précède. Comme tous les éléments ne dépendant pas de l'écriture et du langage, un client accumule les éléments par CAtype et ensuite choisit le rendu le plus désirable de langage et d'écriture si il y a plusieurs éléments pour le même CAtype.

Type CA	Étiquette	Description
1	A1	subdivisions nationales (état, canton, région, province, préfecture)
2	A2	comté, paroisse, gun (JP), district (IN)
3	A3	ville, cité, shi (JP)
4	A4	division de ville, bourg, district, arrondissement, chou (JP) 
5	A5	quartier, bloc
6	A6	groupe de rues en dessous du niveau quartier

Tableau 1

Pour des pays spécifiques, les subdivisions administratives sont décrites ci-dessous.

CA (Canada) : la transposition en désignations NENA est donnée entre parenthèses. A1 désigne la province (STA), A2 le comté (CNA), A3 la cité, ville, ou le nom de communauté MSAG (MCN).

DE (Allemagne) : A1 représente l'état (Bundesstaat), A2 le comté (Regierungsbezirk), A3 la ville (Stadt, Gemeinde), A4 le district (Bezirk). Les suffixes de rues (STS) ne sont utilisés que pour les désignations qui sont un mot distinct (par exemple, Marienthaler Strasse).

JP (Japon) : A1 représente la métropole (To, Fu) ou préfecture (Ken, Do), A2 la ville (Shi) ou zone rurale (Gun), A3 le quartier (Ku) ou village (Mura), A4 la ville (Chou ou Machi), A5 le district urbain (Choume), et A6 le bloc (Banchi ou Ban).

KR (Corée) : A1 représente la province (Do), A2 le comté (gun), A3 la ville ou village (ri), A4 le district urbain (gu), A5 le quartier (dong).

US (United States) : la transposition en désignations NENA est donnée entre parenthèses. A1 désigne l'état (STA) en utilisant les abréviations d'état et possessions de deux lettres recommandées par la publication 28 du service postal des États Unis [USPS], Appendice B. A2 désigne le comté, paroisse (Louisiane), ou bourg (Alaska) (CNA). A3 désigne le nom de la communauté civile, par exemple, cité ou ville. Il est aussi connu comme la juridiction municipale ou nom de communauté MSAG (MCN). Le nom de communauté civile (A3) reflète des limites politiques. Ces limites peuvent différer des allocations de livraison postale, du nom de communauté postale (PCN), pour des raisons historiques ou pratiques. L'élément facultatif A4 contient le nom de lieu de la communauté, comme "Communauté du nouvel espoir" ou "Urbanisation" à Puerto Rico.

Les transpositions et considérations provenant de pays supplémentaires peuvent être collectées de façon informelle de temps en temps dans des documents indépendants publiés par l'IETF. Ils devraient être intitulés "Considérations d'adresses civiles pour [Pays]" et devraient contenir des informations similaires à celles des exemples qu'on donne ici. Lorsque elles seront publiées par l'IETF, elles seront non normatives et purement descriptives, comme les exemples donnés ici, et ne prétendront pas parler au nom d'une autorité d'aucun pays, mais plutôt être offertes pour information. Si les auteurs choisissent de marquer le document avec un code de pays, cela n'empêche pas son utilisation pour marquer un futur document coexistant.

Des types supplémentaires de CA apparaissent dans de nombreux pays et sont simplement omis lorsque il ne sont pas nécessaires ou connus :

Catype	NENA	PIDF	Description	Exemples
  0			langage	i-default [RFC2277]  |
16	PRD	PRD	direction principale de la rue	N
17	POD	POD	suffixe en queue de rue	SW
18	STS	STS	suffixe ou type de rue	Ave, Platz
19	HNO	HNO	numéro de maison	123
20	HNS	HNS	suffixe de numéro de maison	A, 1/2 
21	LMK	LMK	marque de territoire ou adresse de courtoisie	Columbia University
22	LOC	LOC	informations de localisation supplémentaires	Aile sud
23	NAM	NAM	nom (occupant de la résidence et bureau)	Coiffeur Chez Joe
24	ZIP	PC	code postal/zip	10027-1234
25			bâtiment (structure)	Librairie basse
26			unité (appartement, suite)	Apt 42
27		FLR	rez de chaussée	4
28			pièce	450F
29			type de lieu	bureau
30	PCN		nom de communauté postale	Leonia
31			boîte postale (P.O. Box)	12345
32			code supplémentaire	13203000003
33		SEAT	siège (bureau, compartiment, station de travail)	WS 181
34			nom principal de rue	Grand rue
35			section de route	14
36			nom d'embranchement de route	Lane 7	
37			nom de sous embranchement de route	Alley 8
38			pré modificateur de nom de rue 	Ancienne
39			post modificateur de nom de rue 	Service
128			script	Latn 
255			réservé 	|

Les types de CA marqués dans la seconde colonne correspondent aux éléments provenant des "Formats et protocole recommandés pour tous les échanges de données, réponses ALI et transpositions de GIS"de NENA [NENA], mais sont applicables à la plupart des pays. La colonne "NENA" se réfère au nom du dictionnaire de données dans le Exhibit 18 de [NENA].

La colonne marquée PIDF indique le nom d'élément de la [RFC4119]. (Certains éléments ont été ajoutés au présent document après l'achèvement de la définition de l'objet de localisation PIDF. Ces éléments n'ont actuellement pas d'équivalent PIDF-LO.)

Langage : l'élément "langage" (CAtype 0) identifie facultativement le langage utilisé pour présenter les informations d'adresse, d'après les étiquettes pour l'identification des langues dans la [RFC3066], comme exposé dans la [RFC4646]. Si il est omis, la valeur par défaut pour cette étiquette est "i-default" [RFC2277].

Script : l'élément "script" (CAtype 128) identifie facultativement l'écriture utilisée pour présenter les informations d'adresse, d'après les étiquettes pour l'identification des écritures décrites dans [ISO15924] et développées au paragraphe 2.2.3 de la [RFC4646]. Si il est omis, la valeur par défaut pour cette étiquette est "Latn".

POD, PRD : les abréviations N, E, S, W, et NE, NW, SE, SW DEVRAIT être utilisées pour le POD (suffixe en queue de rue) et PRD (direction générale de la rue) dans les pays de langue anglaise.

STS : STS désigne un suffixe ou type de rue. Aux États Unis (US) les abréviations recommandées par l'Appendice C de la publication 28 du service postal des États Unis [USPS], DEVRAIENT être utilisées.

HNS : HNS ("suffixe de numéro de maison") est un modificateur d'une adresse de rue ; il n'identifie pas des parties d'une adresse de rue.

bâtiment : bien qu'une marque de territoire (LMK, CAtype 21) puisse indiquer un complexe de bâtiments, "bâtiment" (CAtype 25) porte le nom d'un seul bâtiment si l'adresse de rue inclut plus d'un bâtiment ou si le nom du bâtiment aide à identifier la localisation.

LOC : LOC ("localisation", CAtype 22) est une chaîne non structurée qui spécifie des informations supplémentaires sur la localisation, comme la partie d'un bâtiment ou d'autres informations non structurées.

PCN: le nom de la communauté postale (CAtype 30) et la boîte postale (CAtype 31) permettent au receveur de construire une adresse postale. Le champ Boîte postale devrait contenir les mots "P.O. Box" ou une autre désignation postale appropriée localement.

NAM : l'objet NAM est utilisé pour aider à la localisation de l'usager ("Joe Miller", "Nettoyage à sec Alice"). Il n'identifie pas la personne qui utilise un appareil de communications, mais plutôt la personne ou organisation associée à l'adresse.

LMK : bien qu'une marque de territoire (LMK, CAtype 21) puisse indiquer un complexe de bâtiments, "bâtiment" (CAtype 25) porte le nom d'un seul bâtiment si l'adresse de rue inclut plus d'un bâtiment ou si le nom du bâtiment aide à identifier la localisation. (Par exemple, sur un campus universitaire, le numéro de maison n'est souvent pas affiché sur les bâtiments, tandis que le nom du bâtiment est inscrit en gros.)

Unité : l'objet "unité" (CAtype 26) contient le nom ou le numéro d'une partie d'une structure où il y a des unités administratives, propriétaires, ou locataires, séparées, comme des compagnies ou familles séparées qui occupent cette structure. Des exemples courants incluent des désignations de suites ou appartements.

Pièce : une "pièce" (CAtype 28) est la plut petite subdivision identifiable d'une structure.

Type de lieu : l'élément "type de lieu" (CAtype 29) décrit le type de lieu décrit par les coordonnées civiles. Par exemple, il décrit si c'est une maison, un bureau, une rue, ou un autre espace public. Les valeurs sont tirées des éléments dans le registre des types de localisation [RFC4589]. Cette information rend facile, par exemple, au client DHCP de remplir alors les informations de présence. Comme c'est un jeton enregistré par l'IANA, les désignations de langage et d'écriture ne s'appliquent pas à cet élément.

Code supplémentaire : l'élément "code supplémentaire" (CAtype 32) donne un code supplémentaire spécifique du pays pour identifier la localisation. Par exemple, pour le Japon, il contient le code d'adresse de la norme de l'industrie du Japon (JIS, Japan Industry Standard). Le code d'adresse JIS fournit une adresse unique au sein du Japon, jusqu'au niveau d'indication de l’étage dans le bâtiment.

Siège : l'élément "siège" (CAtype 33) désigne une place où une personne pourrait s’asseoir, comme un siège dans un stade ou un théâtre, ou un compartiment dans un bureau ouvert ou une cabine dans une exposition.

Nom de route principale : l'élément "route principale" (CAtype 34) est donné à la route ou nom de rue associé à l'adresse. Si les CAtypes de 35 à 37 ne sont pas spécifiés, le bâtiment ou localisation désigné se trouve sur cette rue. Si des CAtypes de 35 à 37 sont spécifiés, cela désigne la route principale, à partir de laquelle de plus petites rues s'embranchent et où la structure ou bâtiment est en fait situé.

Section de route : l'élément "section de route" (CAtype 35) désigne une section spécifique ou extension d'une route principale. C'est un nouvel élément de voie publique et est utile lorsque une rue principale est divisée en sections qui réutilisent les mêmes gammes de numéros de rues.

Nom d'embranchement de route : l'élément "nom d'embranchement de route" (CAtype 36) représente le nom ou identifiant d'une route ou rue qui coupe ou est associée à une route principale. Le nom d'embranchement de route n'est utilisé que dans les pays où les rues latérales n'ont pas de noms uniques au sein d'une municipalité ou autre unité administrative, mais doivent plutôt être qualifiées par le nom de la route principale dont elles sont un embranchement.

Nom de sous embranchement de route : l'élément "nom de sous embranchement de route" (CAtype 37) représente le nom d'une rue qui s'embranche sur un embranchement de route (CAtype 36). Le nom de sous embranchement de route n'est utilisé que dans les pays où de telles rues sont désignées par rapport au nom de la route principale et d'un embranchement auquel il la connecte.

Pré modificateur de nom de rue : le "pré modificateur de nom de rue" (CAtype 38) est un élément facultatif du nom de rue complet. C'est un mot ou phrase qui précède tous les autres éléments du nom de rue et le modifie, mais est séparé du nom de rue par un nom de rue pré directionnel. Un exemple est "Vieux" dans "Vieille première rue Nord".

Post modificateur de nom de rue : le "post modificateur de nom de rue" (CAtype 39) est un élément facultatif du nom de rue complet. C'est un mot ou phrase qui suit tous les autres éléments du nom de rue et le modifie, mais il est séparé du nom de rue par un nom de rue post directionnel et/ou suffixe de rue. Un exemple est "étendue" dans "Avenue extrémité Est étendue".

 	4.	Adresses postales

En général, un receveur peut construire une adresse postale en utilisant tous les éléments de langage appropriés, incluant le code postal (ZIP, CAtype 24). Cependant, certains éléments outrepassent les composants de l'adresse civile pour créer une adresse postale. Si les éléments incluent une boîte postale (CAtype 31), les composants d'adresse de rue (CAtype 34, PRD, POD, STS, HNO, HNS) sont remplacés par l'élément Boîte postale. Si un nom de communauté postale est spécifié, le nom de communauté civile (normalement, A3) est remplacé par le nom de communauté postale (PCN, CAtype 30). Une connaissance spécifique du pays est nécessaire pour créer une adresse postale valide. Le formatage de telles adresses sort du domaine d'application du présent document.

 	5.	Exemple

Plutôt que de montrer l'affichage précis des octets d'une option DHCP, on montre un exemple symbolique ci-dessous, représentant l'adresse civile de la mairie de Munich en Bavière, Allemagne. Le nom de la ville et de l'état sont aussi portés en anglais et en italien en plus de l'allemand ; les autres éléments sont supposés être communs dans toutes les langues. Toutes ces langues utilisent le script latin.

Catype	CAvalue
0	de
128	Latn
1	Bayern
2	Oberbayern
3	M=U+00FCnchen
6	Marienplatz
19	8
21	Rathaus
24	80331
29	Regierungsbauwerk
31	Postfach 1000
0	en
1	Bavaria
3	Munich
0	it
1	Baviera
3	Monaco

 	6.	Considérations sur la sécurité

Les considérations de sécurité discutées dans l'architecture GEOPRIV définie par la [RFC3693] s'appliquent.

Lorsque des décisions critiques pourraient être fondées sur la valeur de cette option GEOCONF_CIVIC, l'authentification DHCPv4 de la [RFC3118] DEVRAIT être utilisée pour protéger l'intégrité des options DHCP.

Comme il n'y a pas de protection de la confidentialité des messages DHCP, un espion qui peut surveiller la liaison entre le serveur DHCP et le client demandeur peut découvrir les informations contenues dans cette option. Donc, l'usage de cette option sur des réseaux sans restriction d'accès ou mécanismes de confidentialité de couche réseau ou de couche de liaison N'EST PAS RECOMMANDÉ.

Pour minimiser l'exposition involontaire des informations de localisation, l'option GEOCONF_CIVIC DEVRAIT n'être retournée par les serveurs DHCPv4 que quand le client DHCPv4 a inclus cette option dans sa "liste des param鑼res demand駸" (paragraphe 3.5 de la [RFC2131]). De même, l'option OPTION_GEOCONF_CIVIC DEVRAIT n'être retournée par les serveurs DHCPv6 que quand le client DHCPv6 a inclus cette option dans son OPTION_ORO.

Après l'introduction initiale des informations de localisation, elles DOIVENT être protégées conformément à ce qui est défini dans la [RFC3694]. Donc, les informations de localisation NE DEVRAIENT PAS être envoyées d'un client DHCP à un serveur DHCP. Si un client décide d'envoyer des informations de localisation au serveur, il accorde implicitement à ce serveur des permissions illimitées de rétention et distribution.

 	7.	Considérations relatives à l'IANA

L'IANA a enregistré de nouveaux codes d'option DHCPv4 et DHCPv6 pour l'adresse civile (respectivement GEOCONF_CIVIC et OPTION_GEOCONF_CIVIC).

Le présent document établit un nouveau registre IANA pour les types de CA désignant les composants d'adresse civile. En se référant à la [RFC2434], ce registre opère sous les règles de "revue d'expert" et de "spécification exigée". L'IESG appointera un expert réviseur qui donnera rapidement son avis à l'IANA sur chaque demande d'un nouveau CAtype ou de sa révision.

CAtype : identifiant numérique, alloué par l'IANA.

Brève description : description courte identifiant la signification de l'élément.

Référence à une spécification publiée : référence stable à une RFC ou autre référence permanente et directement disponible, en détails suffisants pour que l'interopérabilité entre des mises en œuvre indépendantes soit possible.

Considérations spécifiques du pays : si applicable, notent si l'élément est seulement applicable ou défini pour certains pays.

La liste initiale des enregistrements est contenue au paragraphe 3.4.

Les mises à jour des considérations spécifiques du pays pour les CAtypes définis précédemment ne sont pas définies par des enregistrements de l'IANA car ils sont purement descriptifs, et ne sont pas un enregistrement d'identifiants. Comme noté précédemment, les conventions spécifiques d'un pays peuvent facultativement être rédigées dans des documents intitulés "Adresses civiles pour [pays]".

 	8.	Références
 	8.1	Références normatives

[ISO15924]	Organisation Internationals de Normalisation, ISO 15924:2004. "Information et documentation - Codes pour la représentation des noms des écritures", janvier 2004.

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2131]	R. Droms, "Protocole de configuration dynamique d'hôte", mars 1997. (DS) (Mà J par RFC3396, RFC4361, RFC5494, et RFC6849)

[RFC2277]	H. Alvestrand, "Politique de l'IETF en matière de jeux de caractères et de langages", BCP 18, janvier 1998.

[RFC3066]	H. Alvestrand, "Étiquettes pour l'identification des langues", BCP 47, janvier 2001. (Obsolète, voir la RFC4646.)

[RFC3118]	R. Droms et W. Arbaugh, "Authentification des messages DHCP", juin 2001. (P.S.) 

[RFC3315]	R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422 et RFC6644, RFC7227 ; rendue obsolète par RFC8415)

[RFC3396]	T. Lemon et S. Cheshire, "Codage d'options longues dans le protocole de configuration dynamique d'hôte (DHCPv4)", novembre 2002.

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003.

[RFC3693]	J. Cuellar et autres, "Exigences pour Geopriv", février 2004. (Information)

[RFC3694]	M. Danley et autres, "Analyse des menaces pour le protocole Geopriv", février 2004. (Information)

[RFC4589]	H. Schulzrinne, H. Tschofenig, "Registre des types de localisation", juillet 2006. (P.S.)

 	8.2	Références pour information

[NENA]  National Emergency Number Assocation, "NENA Recommended Formats and Protocols For ALI Data Exchange, ALI Response and GIS Mapping", NENA NENA-02-010, janvier 2002.

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC3825]	J. Polk, J. Schnizlein, M. Linsner, "Option du protocole de configuration dynamique d'hôte pour les informations de configuration de localisation fondées sur des coordonnées", juillet 2004. (Obsolète, voir RFC6225) (P.S.)

[RFC4119]	J. Peterson, "Format d'objet de localisation GEOPRIV fondé sur la présence", décembre 2005. (MàJ par RFC5139) (P.S.)

[RFC4646]	A. Phillips, M. Davis, "Étiquettes d'identification des langues", BCP0047 septembre 2006. (Remplacée par RFC5646)

[USPS]	United States Postal Service, "Postal Addressing Standards", novembre 2000.

 	Remerciements
Harald Alvestrand, Stefan Berger, Peter Blatherwick, Joel M. Halpern, David Kessens, Cheng-Hong Li, Rohan Mahy, James Polk, Martin Thomson et Hannes Tschofenig ont fourni d'utiles commentaires. Les exemples et l'inspiration ont été tirés de la norme de données d'adresse des rues du Comité Fédéral des données géographiques.

 	Adresse de l'auteur
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY  10027
US

téléphone : +1 212 939 7004
mél : hgs+geopriv@cs.columbia.edu 
URI : http://www.cs.columbia.edu 

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2006). 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 droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes 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 droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction 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 ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.