Groupe de travail Réseau	J. Winterbottom, Andrew Corporation
Request for Comments: 5491	M. Thomson, Andrew Corporation
RFC mise à jour : 4119	H. Tschofenig, Nokia Siemens Networks
Catégorie : Sur la voie de la normalisation	mars 2009
Traduction Claude Brière de L'Isle	

Précisions, considérations et recommandations sur l'utilisation de l'objet de localisation de format de données d'informations de présence (PIDF-LO) GEOPRIV

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la 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 droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
La spécification d'objet de localisation de format de données d'informations de présence (PIDF-LO, Presence Information Data Format Location Object) donne un moyen souple et versatile de représenter les informations de localisation. Il y a cependant des circonstances qui surviennent quand des informations doivent être contraintes quant à la façon de les représenter. Dans ces circonstances, la gamme des options qui doivent être mises en œuvre est réduite. Il y a un intérêt croissant à être capable d'utiliser les informations de localisation contenues dans un PIDF-LO pour les applications d'acheminement. Pour permettre l'interopérabilité entre applications, les informations de localisation doivent être normatives et plus étroitement contraintes qu'il n'est actuellement spécifié dans la RFC 4119 (PIDF-LO). Le présent document fait des recommandations sur la façon de contraindre, représenter, et interpréter les localisations dans un PIDF-LO. Il recommande de plus un sous ensemble du langage de balisage géographique (GML, Geography Markup Language) 3.1.1 qui est de mise en œuvre obligatoire par les applications impliquées dans l'acheminement fondé sur la localisation.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Utilisation des informations de localisation	2
3.1 Informations de localisation civile seule	4
3.2 Informations de localisation civile et géospatiale	4
3.3 Configuration manuelle/automatique d'informations de localisation	5
3.4 Plusieurs objets de localisation dans un seul PIDF-LO	5
4. Représentation des coordonnées géodésiques	6
5. Représentation de forme géodésique	6
5.1 Restrictions sur le polygone	7
5.2 Exemples de formes	8
6. Considérations sur la sécurité	15
7. Remerciements	15
8. Références	16
8.1 Références normatives	16
8.2 Références pour information	16
Adresse des auteurs	16

 	1.	Introduction

L'objet de localisation de format de données d'informations de présence (PIDF-LO, Presence Information Data Format Location Object) [RFC4119] est la façon recommandée de coder les informations de localisation et les politiques de confidentialité associées. Les informations de localisation dans un PIDF-LO peuvent être décrites de manière géospatiale sur la base d'un sous ensemble du langage de balisage géographique (GML, Geography Markup Language) 3.1.1 [OGC-GML3.1.1] ou comme informations de localisation civiles [RFC5139]. Un profil GML pour exprimer les formes géodésiques dans un PIDF-LO est décrit dans [GeoShape]. Les utilisations pour le PIDF-LO sont envisagées dans le contexte de nombreuses applications fondées sur la localisation. Le présent document fait des recommandations pour les formats et les conventions pour rendre l'interopérabilité moins problématique.

Le PIDF-LO fournit un format général de présence pour représenter les informations de localisation, et permet la spécification des informations de localisation relatives à une gamme complète d'aspects d'une cible. Le modèle général des données de présence est décrit dans la [RFC4479] et pourvoit à un document de présence pour décrire les différents aspects de l'accessibilité à une présentité. En continuant cette approche, un document de présence peut contenir plusieurs objets GEOPRIV qui spécifient différentes localisations et aspects d'accessibilité relatifs à une présentité. Ce degré de flexibilité est important, et les recommandations de ce document ne tentent pas d'interdire l'usage d'un PIDF-LO de cette manière. Le présent document donne un ensemble spécifique de lignes directrices pour construire des documents de présence quand il est important de porter sans ambiguïté exactement une localisation.

 	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 le BCP 14, [RFC2119],.

La définition de "cible" est tirée de la [RFC3693].

Dans ce document, une "localisation discrète" est définie comme un endroit, point, zone, ou volume dans lequel une cible peut être trouvée.

Le terme "localisation composée" est utilisé pour décrire des informations de localisation représentées par un composé d'informations à la fois civiles et géodésiques. Un exemple de localisation composée pourrait être un polygone géodésique décrivant le périmètre d'un bâtiment et un élément civil représentant le rez de chaussée du bâtiment.

Le terme "méthode" dans le présent document se réfère au mécanisme utilisé pour déterminer la localisation d'une cible. Cela peut être quelque chose employé par un serveur d'informations de localisation (LIS, Location Information Server) ou par la cible elle-même. Il ne se réfère spécifiquement pas au protocole de configuration de localisation (LCP, Location Configuration Protocol) utilisé pour livrer les informations de localisation à la cible ou au receveur.

Le terme "source" est utilisé pour se référer au LIS, nœud, ou appareil d'où un receveur (cible ou tiers) obtient les informations de localisation.

 	3.	Utilisation des informations de localisation

Le format PIDF fournit un nombre illimité d'éléments <tuple>, <device>, et <person>. Chacun de ces éléments contient un seul élément <status> qui peut contenir plus d'un élément <geopriv> comme enfant. Chaque élement <geopriv> doit contenir au moins les deux éléments fils suivants : <location-info> et <usage-rules>. Un ou plusieurs éléments contenant des informations de localisation sont contenus dans un élément <location-info>.

Donc, un seul document PIDF peut contenir un nombre arbitraire d'objets de localisation, dont certains ou tous peuvent être contradictoires ou complémentaires. Graphiquement, la structure d'un document PIDF-LO peut être décrite comme le montre la Figure 1.

   <presence>
      <tuple> -- #1
         <status>
            <geopriv> -- #1
               <location-info>
                  élément de localisation n° 1
                  élément de localisation n° 2
                  ...
                  élément de localisation n° n
               <usage-rules>
            </geopriv>
            <geopriv> -- n° 2
            <geopriv> -- n° 3
            ...
            <geopriv> -- n° m
         </status>
      </tuple>
      <device>
         <geopriv> -- n° 1
            <location-info>
               éléments de localisation
            <usage-rules>
         </geopriv>
         <geopriv> -- n° 2
         ...
         <geopriv> -- n° m
      </device>
      <person>
         <geopriv> -- n° 1
            <location-info>
               éléments de localisation
            <usage-rules>
         </geopriv>
         <geopriv> -- n° 2
         ...
         <geopriv> -- n° m
      </person>
      <tuple> -- n° 2
      <device> -- n° 2
      <person> -- n° 2
      ...
      <tuple> -- n° o
   </presence>

Figure 1 : Structure d'un document PIDF-LO

Toutes ces sources potentielles et lieux de mémorisation pour la localisation conduisent à la confusion pour les générateurs, convoyeurs, et consommateurs des informations de localisation. L'expérience pratique au sein de l'association nationale des numéros d'urgence (NENA, National Emergency Number Association) des États-Unis à essayer de résoudre ces ambiguïtés a conduit à l'adoption d'un ensemble de conventions. Ces règles n'ont pas d'ordre particulier, mais devraient être suivies par les créateurs et consommateurs d'informations de localisation contenues dans un PIDF-LO pour assurer qu'une interprétation cohérente des données peut être réalisée.

Règle n° 1 : un élément <geopriv> DOIT décrire une localisation discrète.

Règle n° 2 : lorsque une localisation discrète peut être décrite de façon unique de plus d'une manière, chaque description de localisation DEVRAIT résider dans un élément <tuple>, <device>, ou <person> séparé ; seulement un élément geopriv par tuple.

Règle n° 3 : fournir plus d'un élément <geopriv> dans un seul document de présence (PIDF) DOIT seulement être fait si les localisations se réfèrent au même endroit ou si elles sont mises dans des types d'éléments différents. Par exemple, une localisation dans un élément <tuple>, une seconde localisation dans un élément <device>, et une troisième localisation dans un élément <person>. Cela peut arriver si la localisation d'une cible est déterminée en utilisant une série de techniques différentes ou si la cible souhaite représenter sa localisation ainsi que celle de son ordinateur portable. En général, on évitera de mettre plus d'une localisation dans un document sauf si il y a du sens à le faire.

Règle n° 4 : fournir plus d'un tronçon de localisation dans un seul élément <location-info> DEVRAIT être évité lorsque possible. Les règles n° 5 et n° 6 précisent ce point.

Règle n° 5 : quand on fournit plus d'un tronçon de localisation dans un seul élément <location-info>, les localisations DOIVENT être fournies par une source commune au même moment et par la même méthode de détermination  de localisation.

Règle n° 6 : fournir plus d'un tronçon de localisation dans un seul élément <location-info> DEVRAIT n'être utilisé que pour représenter une localisation composée se référant au même endroit. Par exemple, une localisation géodésique décrivant un point, et une localisation civile indiquant le rez de chaussée d'un bâtiment.

Règle n° 7 : lorsque la localisation composée est fournie dans un seul élément <location-info>, les informations de localisation grossières DOIVENT être fournies en premier. Par exemple, une localisation géodésique décrivant une zone et une localisation civile indiquant le rez de chaussée devrait être représentée avec la zone d'abord suivie de la localisation civile.

Règle n° 8 : lorsque un document PIDF contient plus d'un élément <geopriv>, la priorité de l'interprétation est donnée au premier élément <device> dans le document contenant une localisation. Si aucun élément <device> contenant une localisation n'est présent dans le document, alors la priorité est donnée au premier élément <tuple> contenant une localisation. Les localisations contenues dans des tuplets de <person> DEVRAIT n'être utilisées qu'en dernier ressort.

Règle n° 9 : lorsque plusieurs documents PIDF peuvent être envoyés ou reçus ensemble, disons dans un corps multi-parties MIME, et que les informations de localisation courantes sont demandées par le receveur, le choix de document DEVRAIT alors être fondé sur l'ordre des documents, le premier document considéré en premier.

Les exemples qui suivent illustrent l'application de ces règles.

 	3.1	Informations de localisation civile seule
Jane est dans un café au rez de chaussée d'un grand centre commercial. Elle allume sa tablette et se connecte au WiFi du café ; Jane obtient une adresse civile complète pour sa localisation actuelle, par exemple, en utilisant le mécanisme civil DHCP défini dans la [RFC4776]. Un objet de localisation est construit qui consiste en un seul document PIDF, avec un seul élément <tuple> ou <device>, un seul élément <status>, un seul élément <geopriv>, et un seul tronçon de localisation résidant dans l'élément <location-info>. Ce document est sans ambiguïté, et devrait être interprété de façon cohérente par les nœuds receveurs si il est envoyé sur le réseau.

 	3.2	Informations de localisation civile et géospatiale
Mike visite son bureau de Seattle et connecte son ordinateur portable à l'accès Ethernet dans une pièce d'accueil. Dans ce cas, les informations de localisation sont une localisation géodésique, avec l'altitude représentée comme le numéro de l'étage du bâtiment. La localisation principale de Mike est le point spécifié par les coordonnées géodésiques. De plus, Mike est au second étage du bâtiment situé à ces coordonnées. En appliquant les règles 6 et 7, les informations de localisation composées résultantes sont montrées à la Figure 2.

    <presence xmlns="urn:ietf:params:xml:ns:pidf"
              xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
              xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
              xmlns:gml="http://www.opengis.net/gml"
              xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
              entity="pres:mike@seattle.example.com">
      <dm:device id="mikepc">
        <gp:geopriv>
          <gp:location-info>
            <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>-43.5723 153.21760</gml:pos>
            </gml:Point>
            <cl:civicAddress>
              <cl:FLR>2</cl:FLR>
            </cl:civicAddress>
          </gp:location-info>
          <gp:usage-rules/>
          <gp:method>Wiremap</gp:method>
        </gp:geopriv>
        <dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
        <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
      </dm:device>
    </presence>

Figure 2 : PIDF-LO contenant une localisation composée

 	3.3	Configuration manuelle/automatique d'informations de localisation
Lorraine a une localisation civile prédéfinie mémorisée dans sa tablette, comme elle vit normalement à Sydney, l'adresse est celle de son appartement de Sydney. Lorraine décide de visiter San Francisco, et quand elle y arrive, elle connecte sa tablette et passe un appel. La tablette de Lorraine reçoit une nouvelle localisation de la part du réseau visité à San Francisco. Comme ce système ne peut pas être sûr que la localisation préexistante et la nouvelle décrivent toutes deux le même endroit, l'ordinateur de Lorraine génère un nouveau PIDF-LO et va l'utiliser pour représenter la localisation de Lorraine. Si la tablette de Lorraine devait ajouter la nouvelle localisation au document existant de localisation PIDF (violant la règle n° 3) alors les informations correctes pourraient quand même être interprétées par le receveur de localisation pourvu que le système de Lorraine applique la règle n° 9. Dans ce cas, l'ordre des informations de localisation résultant dans le document PIDF devrait être San Francisco d'abord, suivi par Sydney. Comme les informations sont fournies par des sources différentes, la règle n° 8 devrait aussi être appliquée et les informations placées dans des tuples différents, avec le tuple contenant la localisation de San Francisco en premier.

 	3.4	Plusieurs objets de localisation dans un seul PIDF-LO
Vanessa a son ordinateur portable avec elle au parc, mais du fait d'une mauvaise configuration, son PC rapporte sa localisation comme étant au bureau. Le PIDF-LO résultant va avoir un élément <device> montrant la localisation du PC de Vanessa au parc, et un élément <person> disant que Vanessa est à son bureau.

    <presence xmlns="urn:ietf:params:xml:ns:pidf"
              xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
              xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
              xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
              xmlns:gml="http://www.opengis.net/gml"
              xmlns:gs="http://www.opengis.net/pidflo/1.0"
              entity="pres:ness@example.com">
      <dm:device id="nesspc-1">
        <gp:geopriv>
          <gp:location-info>
            <ca:civicAddress xml:lang="en-AU">
              <ca:country>AU</ca:country>
              <ca:A1>NSW</ca:A1>
              <ca:A3>  Wollongong
              </ca:A3><ca:A4>North Wollongong
            </ca:A4>
            <ca:RD>Flinders</ca:RD><ca:STS>Street</ca:STS>
            <ca:RDBR>Campbell Street</ca:RDBR>
            <ca:LMK>
              Gilligan's Island
              </ca:LMK> <ca:LOC>Corner</ca:LOC>
              <ca:NAM> Video Rental Store </ca:NAM>
              <ca:PC>2500</ca:PC>
              <ca:ROOM> Westerns and Classics </ca:ROOM>
              <ca:PLC>store</ca:PLC>
              <ca:POBOX>Private Box 15</ca:POBOX>
            </ca:civicAddress>
          </gp:location-info>
          <gp:usage-rules/>
          <gp:method>GPS</gp:method>
        </gp:geopriv>
        <dm:deviceID>mac:1234567890ab</dm:deviceID>
        <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
      </dm:device>
      <dm:person id="ness">
        <gp:geopriv>
          <gp:location-info>
            <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>-34.410649 150.87651</gml:pos>
              <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                30
              </gs:radius>
            </gs:Circle>
          </gp:location-info>
          <gp:usage-rules/>
          <gp:method>Manual</gp:method>
        </gp:geopriv>
        <dm:timestamp>2007-06-24T12:28:04Z</dm:timestamp>
      </dm:person>
    </presence>

Figure 3 : PIDF-LO contenant plusieurs objets de localisation

 	4.	Représentation des coordonnées géodésiques

Les exemples géodésiques fournis dans la [RFC4119] sont illustrés en utilisant l'élément <gml:location>, qui utilise l'élément <gml:coordinates> à l'intérieur de l'élément <gml:Point>, et cette représentation a plusieurs inconvénients. D'abord, elle a été déconseillée dans les versions ultérieures de GML (3.1 et après) la rendant d'utilisation non recommandable pour les nouvelles applications. Ensuite, le format du type de coordonnées est opaque et peut donc être difficile à analyser et interpréter pour assurer des résultats cohérents, car la même localisation géodésique peut être exprimée de diverses façons. La spécification des formes géodésiques PIDF-LO [GeoShape] donne un profil GML spécifique pour exprimer les formes couramment utilisées en utilisant des représentations GML simples. Les formes définies dans [GeoShape] sont les formes recommandées pour assurer l'interopérabilité.

 	5.	Représentation de forme géodésique

Le monde du mobile cellulaire d'aujourd'hui fait un usage extensif des informations de localisation fondées sur les coordonnées géodésiques pour les applications d'urgence et autres fondées sur la localisation. Généralement, ces localisations sont exprimées comme un point (en deux ou trois dimensions) et une zone ou volume d'incertitude autour du point. En théorie, la zone ou volume représente  une couverture dans laquelle l'utilisateur a une probabilité relativement élevée de se trouver, et le point est un moyen pratique de définir le centroïde pour la zone ou volume. En pratique, la plupart des systèmes utilisent le point comme une valeur absolue et ignorent l'incertitude. Il est difficile de déterminer si les systèmes ont été mis en œuvre de cette manière pour sa simplicité, et il est encore plus difficile de prédire si l'incertitude va jouer un rôle plus important  à l'avenir. Une décision importante est si la zone d'incertitude devrait être spécifiée.

La spécification des formes géodésiques PIDF-LO [GeoShape] définit huit types de formes, dont la plupart sont facilement traduites en définitions de formes utilisées dans d'autres applications et protocoles, comme le protocole de localisation mobile (MLP, Mobile Location Protocol) de l'alliance mobile ouverte (OMA, Open Mobile Alliance). Pour être complet, les formes définies dans [GeoShape] sont données ci-après :
o  Point (2d et 3d)
o  Polygone (2d)
o  Cercle (2d)
o  Ellipse (2d)
o  Secteur d'arc (2d)
o  Sphère (3d)
o  Ellipsoïde (3d)
o  Prisme (3d)

Les formes mentionnées ci-dessus DOIVENT être mises en œuvre.

La spécification GeoShape [GeoShape] décrit aussi un ensemble standard de systèmes de référence de coordonnées (CRD, Coordinate Reference System) d'unités de mesure (UoM) et de conventions relatives aux lignes et aux distances. L'utilisation du système de référence de coordonnées du système géodésique mondial 1984 (WGS84, World Geodetic System 1984) [WGS84] et l'usage du code 4326 du groupe européen d'études du pétrole (EPSG, European Petroleum Survey Group) (tel qu'identifié par l'URN urn:ogc:def:crs:EPSG::4326, [CRS-URN]) pour les repésentations de formes bi-dimensionnelles (2d) et EPSG 4979 (identifié par l'URN urn:ogc:def:crs:EPSG::4979) pour les représentations de volume tri-dimensionnelles (3d) sont obligatoires. La distance et les hauteurs sont exprimées en mètres en utilisant EPSG 9001 (identifié par l'URN urn:ogc:def:uom:EPSG::9001). Les mesures angulaires DOIVENT utiliser les degrés ou radians. Les mesures en degrés DOIVENT être identifiées par l'URN urn:ogc:def:uom:EPSG::9102, les mesures en radians DOIVENT être identifiées par l'URN urn:ogc:def:uom:EPSG::9101. Les angles représentant des azimuts sont mesurés dans le sens des aiguilles d'une montre à partir du Nord géographique, comme défini par le CRS WGS84, pas le nord magnétique.

Les mises en œuvre DOIVENT spécifier le CRS en utilisant l'attribut srsName sur l'élément géométrque le plus externe. Le CRS NE DOIT PAS être re-spécifié ou changé dans ses sous-éléments. L'attribut srsDimension DEVRAIT être omis, car le nombre de dimensions dans ces CRS est connu. Un CRS DOIT être spécifié en utilisant seulement la notation d'URN ci-dessus ; les mises en œuvre n'ont pas besoin de prendre en charge les CRS définis par l'utilisateur.

Les valeurs numériques des coordonnées et mesures sont exprimées en utilisant la représentation lexicale pour "double" définie dans [REC-2-20041028]. Les zéros en tête et en queue après la virgule n'ont aucune signification ; par exemple "03.07500" est équivalent à "3.075".

Il est RECOMMANDÉ que l'incertitude soit exprimée avec un niveau de confiance de 95 % ou plus. Spécifier un niveau de confiance permet une meilleure utilisation des valeurs d'incertitude.

 	5.1	Restrictions sur le polygone
Le type de forme de polygone défini dans [GeoShape] ne met délibérément aucune contrainte sur le nombre de sommets qui peuvent être inclus pour définir les limites d'un polygone. Cela permet que soient définies des formes d'une complexité arbitraire et de les porter dans un PIDF-LO. Cependant, lorsque des informations de localisation sont à utiliser dans des applications de traitement en temps réel, comme d'acheminement dépendant de la localisation, avoir des formes d'une complexité arbitraire consistant en dizaines ou même centaines de points pourrait résulter en des impacts significatifs sur les performances. Pour atténuer ce risque, les formes de polygones DEVRAIENT être restreintes à un maximum de 15 points (16 en incluant le point répété) quand les informations de localisation sont destinées à une utilisation dans des applications en temps réel. Cette limite de 15 points est choisie pour permettre des définitions modérément complexes de formes tout en permettant en même temps l'interopération aves les autres protocoles transportant de la localisation comme ceux définis dans le projet en partenariat de troisième génération (3GPP, 3rd Generation Partnership Project) (voir [3GPP.23.032]) et l'OMA où la limite de 15 points est déjà imposée.

Les bords d'un polygone sont définis par le plus court chemin entre deux points dans l'espace (pas une courbe géodésique).  Des points bi-dimensionnels PEUVENT être interprétés comme ayant une valeur de zéro pour leur composant d'altitude. Pour éviter des erreurs significatives résultant d'une potentielle interpolation géodésique, la longueur entre des sommets adjacents DEVRAIT être restreinte à un maximum de 130 km. Plus d'informations sur cette restriction sont fournies dans [GeoShape].

Une ligne de connexion NE DEVRA PAS croiser une autre ligne de connexion du même polygone.

Les polygones DOIVENT être définis avec la normale ascendante pointant vers le haut. Cela se fait en définissant les sommets dans le sens contraire des aiguilles d'une montre.

Les points spécifiés dans un polygone en utilisant des coordonnées tri-dimensionnelles DOIVENT tous avoir la même altitude.

 	5.2	Exemples de formes
Ce paragraphe donne des exemples d'utilisation de formes plus complexes, comment elles sont déterminées, et comment elles sont représentées dans un PIDF-LO. Les détails complets de tous les types GeoShape sont fournis dans [GeoShape].

 	5.2.1	Point
Le type de forme "point" est la plus simple forme d'informations de localisation (LI, location information) géodésiques, qui est naturellement prise en charge par GML. L'élément gml:Point est utilisé quand il n'y a pas d'incertitude connue. Un point fait aussi partie d'un certain nombre d'autres géométries. Un point peut être spécifié en utilisant WGS 84 (latitude, longitude) ou WGS 84 (latitude, longitude, altitude). La Figure 4 pntre un point en 2d :

    <presence xmlns="urn:ietf:params:xml:ns:pidf"
              xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
              xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
              xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
              xmlns:gml="http://www.opengis.net/gml"
              entity="pres:point2d@example.com">
      <dm:device id="point2d">
        <gp:geopriv>
          <gp:location-info>
            <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>-34.407 150.883</gml:pos>
            </gml:Point>
          </gp:location-info>
          <gp:usage-rules/>
          <gp:method>Wiremap</gp:method>
        </gp:geopriv>
        <dm:deviceID>mac:1234567890ab</dm:deviceID>
        <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
      </dm:device>
    </presence>

Figure 4 : PIDF-LO contenant un point bi-dimensionnel

La Figure 5 montre un point en 3d :

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               entity="pres:point3d@example.com">
       <dm:device id="point3d">
         <gp:geopriv>
           <gp:location-info>
             <gml:Point srsName="urn:ogc:def:crs:EPSG::4979"
                        xmlns:gml="http://www.opengis.net/gml">
               <gml:pos>-34.407 150.883 24.8</gml:pos>
             </gml:Point>
           </gp:location-info>
           <gp:usage-rules/>
           <gp:method>Wiremap</gp:method>
         </gp:geopriv>
         <dm:deviceID>mac:1234567890ab</dm:deviceID>
         <dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>
       </dm:device>
     </presence>

Figure 5 : PIDF-LO contenant un point tri-dimensionnel

 	5.2.2	Polygone
Le type de forme polygone peut être utilisé pour représenter un plan de construction ou une zone de couverture. Le premier et le dernier point du polygone doivent être le même. Par exemple, quand on regarde l'hexagone de la Figure 6 avec les sommets, A, B, C, D, E, et F. Le polygone résultant va être défini avec 7 points,le premier et le dernier portant tous deux les coordonnées du point A.

       F--------------E
      /                \
     /                  \
    /                    \
   A                      D
    \                    /
     \                  /
      \                /
       B--------------C

Figure 6 : Exemple de polygone

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               entity="pres:hexagon@example.com">
       <tuple id="polygon-pos">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:exterior>
                   <gml:LinearRing>
                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                     <gml:pos>43.111 -73.322</gml:pos> <!--F-->
                     <gml:pos>43.111 -73.222</gml:pos> <!--E-->
                     <gml:pos>43.311 -73.122</gml:pos> <!--D-->
                     <gml:pos>43.411 -73.222</gml:pos> <!--C-->
                     <gml:pos>43.411 -73.322</gml:pos> <!--B-->
                     <gml:pos>43.311 -73.422</gml:pos> <!--A-->
                   </gml:LinearRing>
                 </gml:exterior>
               </gml:Polygon>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>Wiremap</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

Figure 7 : PIDF-LO contenant un polygone

En plus de la forme montrée à la Figure 7, GML prend en charge une posList qui donne une représentation plus compacte des coordonnées des sommets du polygone que les éléments pos discrets. La forme la plus compacte est montrée à la Figure  8. Les deux formes sont permises.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               entity="pres:hexagon@example.com">
       <tuple id="polygon-poslist">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:exterior>
                   <gml:LinearRing>
                     <gml:posList>
                       43.311 -73.422 43.111 -73.322
                       43.111 -73.222 43.311 -73.122
                       43.411 -73.222 43.411 -73.322
                       43.311 -73.422
                     </gml:posList>
                   </gml:LinearRing>
                 </gml:exterior>
               </gml:Polygon>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>Wiremap</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

Figure 8 : Forme compacte d'un polygone exprimé dans un PIDF-LO

 	5.2.3	Cercle
La zone circulaire est utilisée pour les coordonnées dans les CRS bi-dimensionnels pour décrire l'incertitude sur un point. La définition est fondée sur la géométrie uni-dimensionnelle dans GML, gml:CircleByCenterPoint. Le point central d'une zone circulaire est spécifié en utilisant un CRS bi-dimensionnel ; en trois dimensions, l'orientation du cercle ne peut pas être spécifiée correctement en utilisant cette représentation. Un point avec incertitude qui est spécifié en trois dimensions devrait utiliser le type de forme de sphère.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:circle@example.com">
       <tuple id="circle">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>42.5463 -73.2512</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   850.24
                 </gs:radius>
               </gs:Circle>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>OTDOA</gp:method>
           </gp:geopriv>
         </status>
       </tuple>
     </presence>

Figure 9 : PIDF-LO contenant un cercle

 	5.2.4	Ellipse
Une zone elliptique décrit une ellipse dans un espace à deux dimensions. L'ellipse est décrite par un point central, la longueur de ses axes semi-majeur et semi-mineur, et l'orientation de l'axe semi-majeur. Comme la zone circulaire (cercle) l'ellipse DOIT être spécifiée en utilisant le CRS bi-dimensionnel.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:Ellipse@somecell.example.com">
       <tuple id="ellipse">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>42.5463 -73.2512</gml:pos>
                 <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   1275
                 </gs:semiMajorAxis>
                 <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   670
                 </gs:semiMinorAxis>
                 <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
                   43.2
                 </gs:orientation>
               </gs:Ellipse>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>Device-Assisted_A-GPS</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

Figure 10 : PIDF-LO contenant une ellipse

L'élément gml:pos indique la position du centre, ou origine, de l'ellipse. Les éléments gs:semiMajorAxis et gs:semiMinorAxis sont la longueur des axes, respectivement, semi-majeur et semi-mineur. L'élément gs:orientation est l'angle de rotation de l'axe semi-majeur par rapport au premier axe du CRS vers le second axe. Pour WGS 84, l'orientation indique la rotation du Nord vers l'Est, qui, si elle est spécifiée en degrés, est en gros équivalente à un azimut de boussole (si le Nord magnétique était le même que le pôle Nord WGS). Note : une ellipse avec des longueurs égales d'axes majeur et mineur est un cercle.

 	5.2.5	Secteur d'arc
Le type de forme de secteur d'arc est couramment généré dans les systèmes sans fil où des séquences d'avance de temps ou de décalage de code sont utilisées pour compenser les distances entre les combinés et le point d'accès. La bande d'arc est représentée comme deux rayons émanant d'un point central, et deux angles qui représentent l'angle de début et l'angle d'ouverture de l'arc. Dans un environnement cellulaire, le point central est nominalement la localisation de l'émetteur de la cellule, les deux rayons sont déterminés par la quantité d'avance de temps, et les deux angles sont généralement des informations provisionnées.

Par exemple, Paul utilise un appareil cellulaire sans fil et est en avance de 7 symboles de temps par rapport à l'émetteur de la cellule. Pour un réseau fondé sur le GSM, cela placerait Paul en gros entre 3 594 mètres et 4 148 mètres de l'émetteur de la cellule, fournissant les valeurs des rayons interne et externe. Si l'angle de début est de 20 degrés nord, et si l'angle d'ouverture est de 120  degrés, une bande d'arc représentant la localisation de Paul ressemblerait à la Figure 11.

         N ^        ,.__
           | a(s)  /     `-.
           | 20   /         `-.
           |--.  /             `.
           |   `/                \
           |   /__                \
           |  .   `-.              \
           | .       `.             \
           |. \        \             .
        ---c-- a(o) -- |             | -->
           |.  / 120   '             |   E
           |  .       /              '
           |    .    /              ;
                  .,'              /
               r(i)`.             /
            (3594m)  `.          /
                       `.      ,'
                         `.  ,'
                       r(o)`'
                     (4148m)

Figure 11 : Exemple d'un secteur d'arc

le PIDF-LO résultant est montré à la Figure 12.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:paul@somecell.example.com">
       <tuple id="arcband">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326">
                 <gml:pos>-43.5723 153.21760</gml:pos>
                 <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   3594
                 </gs:innerRadius>
                 <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">
                   4148
                 </gs:outerRadius>
                 <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">
                   20
                 </gs:startAngle>
                 <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">
                   20
                 </gs:openingAngle>
               </gs:ArcBand>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>TA-NMR</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

Figure 12 : PIDF-LO contenant un secteur d'arc

Une importante note à faire sur le secteur d'arc est que le point central utilisé dans la définition de la forme n'est pas inclus dans la zone enclose résultante, et que la cible peut être n'importe où dans la zone définie du secteur d'arc.

 	5.2.6	Sphère
La sphère est un volume qui donne les mêmes informations qu'un cercle en trois dimensions. La sphère doit être spécifiée en utilisant un CRS tri-dimensionnel. La Figure 13 montre le type de forme de sphère, qui est identique à l'exemple du cercle, sauf pour l'ajout d'une altitude dans les coordonnées fournies.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:sphere@example.com">
       <tuple id="sphere">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979">
                 <gml:pos>42.5463 -73.2512 26.3</gml:pos>
                 <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
                   850.24
                 </gs:radius>
               </gs:Sphere>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>Device-Based_A-GPS</gp:method>
           </gp:geopriv>
         </status>
       </tuple>
     </presence>

Figure 13 : PIDF-LO contenant une sphère

 	5.2.7	Ellipsoïde
L'ellipsoïde est le volume le plus couramment produit par les systèmes GPS. Il est utilisé extensivement dans les systèmes de navigation et les réseaux de localisation sans fil. L'ellipsoïde est construit autour d'un point central spécifié en trois dimensions, et trois axes perpendiculaires les uns aux autres sont étendus autour de ce point. Ces axes sont définis comme l'axe semi-majeur (M), l'axe semi-mineur (m), et l'axe vertical (v), respectivement. Un angle est utilisé pour exprimer l'orientation de l'ellipsoïde. L'angle d'orientation est mesuré en degrés à partir du Nord, et représente la direction de l'axe semi-majeur à partir du point central.

                  \
                _.-\""""^"""""-._
              .'    \   |        `.
             /       v  m          \
            |         \ |           |
            |          -c ----M---->|
            |                       |
             \                     /
              `._               _.'
                 `-...........-'

Figure 14 : Exemple d'ellipsoïde

Un PIDF-LO contenant un ellipsoïde est montré à la Figure 15.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:somone@gpsreceiver.example.com">
       <tuple id="ellipsoid">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Ellipsoid srsName="urn:ogc:def:crs:EPSG::4979">
                 <gml:pos>42.5463 -73.2512 26.3</gml:pos>
                 <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   7.7156
                 </gs:semiMajorAxis>
                 <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001">
                   3.31
                 </gs:semiMinorAxis>
                 <gs:verticalAxis uom="urn:ogc:def:uom:EPSG::9001">
                   28.7
                 </gs:verticalAxis>
                 <gs:orientation uom="urn:ogc:def:uom:EPSG::9102">
                   90
                 </gs:orientation>
               </gs:Ellipsoid>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>Hybrid_A-GPS</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

Figure 15 : PIDF-LO contenant un ellipsoïde

 	5.2.8	Prisme
Un prisme peut être utilisé pour représenter une partie d'un bâtiment ou une gamme d'étages d'un bâtiment. Le prisme étend un polygone en fournissant un élément de hauteur. Il consiste en une base constituée de points coplanaires définis en trois dimensions tous à la même altitude. Le prisme est alors une extrusion de cette base à la valeur spécifiée dans l'élément hauteur. La hauteur du prisme DOIT être une valeur positive. Le premier et le dernier point du polygone doivent être le même.

Par exemple, quand on regarde le cube de la Figure 16, si le prisme est extrudé de bas en haut, alors le polygone formant la base du prisme est définie par les points A, B, C, D, A. La hauteur du prisme est la distance entre le point A et le point E en mètres.

              G-----F
             /|    /|
            / |   / |
           H--+--E  |
           |  C--|--B
           | /   | /
           |/    |/
           D-----A

Figure 16 : Exemple de prisme

Le PIDF-LO résultant est montré à la Figure 17.

     <presence xmlns="urn:ietf:params:xml:ns:pidf"
               xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
               xmlns:gml="http://www.opengis.net/gml"
               xmlns:gs="http://www.opengis.net/pidflo/1.0"
               entity="pres:mike@someprism.example.com">
       <tuple id="prism">
         <status>
           <gp:geopriv>
             <gp:location-info>
               <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
                 <gs:base>
                   <gml:Polygon>
                     <gml:exterior>
                       <gml:LinearRing>
                         <gml:posList>
                           42.556844 -73.248157 36.6 <!--A-->
                           42.656844 -73.248157 36.6 <!--B-->
                           42.656844 -73.348157 36.6 <!--C-->
                           42.556844 -73.348157 36.6 <!--D-->
                           42.556844 -73.248157 36.6 <!--A-->
                         </gml:posList>
                       </gml:LinearRing>
                     </gml:exterior>
                   </gml:Polygon>
                 </gs:base>
                 <gs:height uom="urn:ogc:def:uom:EPSG::9001">
                   2.4
                 </gs:height>
               </gs:Prism>
             </gp:location-info>
             <gp:usage-rules/>
             <gp:method>Wiremap</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2007-06-22T20:57:29Z</timestamp>
       </tuple>
     </presence>

Figure 17 : PIDF-LO contenant un prisme

 	6.	Considérations sur la sécurité

Les principales considérations de sécurité se rapportent à la façon dont les informations de localisation sont convoyées et utilisées, ce qui sort du domaine d'application de ce document. Le présent document est destiné seulement à servir d'ensemble de lignes directrices sur quels éléments DOIVENT ou DEVRAIENT être mis en œuvre par les systèmes qui souhaitent effectuer un acheminement dépendant de la localisation. Les ramifications de ces recommandations font qu'elles s'étendent aux appareils et clients qui souhaitent utiliser de tels services.

 	7.	Remerciements

Les auteurs tiennent à remercier le groupe de travail GEOPRIV pour les discussions dans le contexte de PIDF-LO, en particulier Carl Reed, Ron Lake, James Polk, Henning Schulzrinne, Jerome Grenier, Roger Marshall et Robert Sparks. De plus, ils tiennent à remercier Jon Peterson, auteur de PIDF-LO et Nadine Abbott pour ses commentaires constructifs pour préciser certains aspects du document.

Merci à Karen Navas pour avoir relevé des omissions dans les exemples.

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

[GeoShape]	Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification 06-142r1, Version: 1.0, avril 2007.

[OGC-GML3.1.1]	Portele, C., Cox, S., Daisy, P., Lake, R., and A. Whiteside, "Geography Markup Language (GML) 3.1.1", OGC 03-105r1, juillet 2003.

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

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

[RFC4479]	J. Rosenberg, "Modèle de données pour Presence", juillet 2006. (P.S.)

[RFC5139]	M. Thomson, J. Winterbottom, "Format révisé de localisation civique d'un objet de localisation de données d'information de présence (PIDF-LO)", février 2008. (MàJ RFC4119) (P.S.)

[REC-2-20041028]	Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, octobre 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

 	8.2	Références pour information

[3GPP.23.032]	3rd Generation Partnership Project, "Universal Geographical Area Description (GAD)", 3GPP TS 23.032          V6.0.0, janvier 2005, <http://www.3gpp.org/ftp/Specs/html-info/23032.htm>.

[CRS-URN]	Whiteside, A., "GML 3.1.1 Common CRSs Profile", OGC 03-105r1, novembre 2005.

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

[RFC4776]	H. Schulzrinne, "Option du protocole de configuration dynamique d'hôte (DHCPv4 et DHCPv6) pour les informations de configuration d'adresses civiles", novembre 2006. (Remplace RFC4676) (P.S.)

[WGS84]	US National Imagery and Mapping Agency, "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, janvier 2000.

 	Adresse des auteurs
James Winterbottom	Martin Thomson	
Andrew Corporation	Andrew Corporation	
Wollongong	Wollongong	
NSW Australia	NSW Australia	
mél : james.winterbottom@andrew.com	mél : martin.thomson@andrew.com	

Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo  02600
Finland
téléphone : +358 (50) 4871445
mél : Hannes.Tschofenig@gmx.net
URI : http://www.tschofenig.priv.at