Spécification de la plateforme pour les préférences de confidentialité 1.0 (P3P1.0)

Recommandation du W3C du 16 avril 2002

Cette version :: http://www.w3.org/TR/2002/REC-P3P-20020416/
Dernière version :: http://www.w3.org/TR/P3P/
Version précédente :: http://www.w3.org/TR/2002/PR-P3P-20020128/
Éditeurs :: Massimo Marchiori, W3C / MIT / University of Venice, (massimo@w3.org)
Auteurs :: Lorrie Cranor, AT&T; Marc Langheinrich, ETH Zurich; Massimo Marchiori, W3C/MIT/ University of Venice; Martin Presler-Marshall, IBM; Joseph Reagle, W3C/MIT

Veuillez consulter la liste des errata →vf de ce document, laquelle peut contenir des corrections normatives.

Voir aussi d'éventuelles traductions.

Résumé

Ce document constitue la spécification de la plateforme pour les préférences de confidentialité (P3P). Avec ses références normatives, il contient toutes les indications nécessaires pour la mise en œuvre d'applications P3P interopérables.

Statut de ce document

Ce chapitre décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le supplanter. La dernière version de cet ensemble de documents est conservée au W3C.

C'est la recommandation du W3C de la spécification de la plateforme pour les préférences de confidentialité 1.0 (P3P1.0).

Ce document, qui a été revu par les membres du W3C et les tiers concernés, a été approuvé par le Directeur comme recommandation du W3C. C'est un document stable qui peut être utilisé comme matériel de référence ou cité comme norme de référence par un autre document. Le rôle du W3C, en produisant cette recommandation, est de mettre en lumière la spécification et d'en promouvoir le plus large déploiement. Cela participe à améliorer la fonctionnalité et l'interopérabilité du Web.

Ce document a été produit par le Groupe de Travail sur la spécification P3P du W3C, partie de l'activité sur la vie privée du Domaine Technologie & Société du W3C.

On peut consulter les divulgations de brevets concernant cette spécification sur la page de divulgation de brevets →vf de P3P1.0, conformément à la politique de brevetabilité du W3C.

Veuillez signaler les erreurs dans ce documents sur www-p3p-public-comments@w3.org (archives publiques).

La liste des erreurs connues dans cette spécification est disponible à http://www.w3.org/2002/04/P3Pv1-errata.

Seule la version en anglais de cette spécification est normative. Les renseignements concernant les traductions (éventuelles) de ce document sont disponibles à http://www.w3.org/2002/04/P3Pv1-translations.

On peut trouver une liste des rapports techniques courants publics du W3C à http://www.w3.org/TR.

Table des matières

Introduction
L'appel des politiques
La syntaxe et la sémantique des politiques
Les politiques compactes
Les schémas de données
Annexes
Annexe 1 : Références (normatif)
Annexe 2 : Références (non normatif)
Annexe 3 : La définition du schéma de données P3P de base (normatif)
Annexe 4 : La définition du schéma XML (normatif)
Annexe 5 : La définition du DTD XML (non normatif)
Annexe 6 : La notation ABNF (normatif)
Annexe 7 : Les principes directeurs de P3P (non normatif)
Annexe 8 : Les contributeurs du Groupe de Travail (non normatif)

1. Introduction

Le projet de plateforme pour les préférences de confidentialité (P3P) permet aux sites Web d'exprimer leurs politiques de confidentialité dans un format normalisé que les agents utilisateurs peuvent obtenir automatiquement et interpréter aisément. Les agents utilisateurs P3P permettront d'informer les utilisateurs des pratiques des sites (dans des formats lisibles à la fois par une machine et par un humain) et d'automatiser au besoin les prises de décisions en fonction de ces pratiques. Les utilisateurs n'auront donc pas besoin de lire les politiques de confidentialité de chaque site visité.

Bien que le protocole P3P fournisse le moyen technique permettant aux utilisateurs d'être informés des politiques de confidentialité avant de confier des renseignements personnels, il n'offre aucun mécanisme technique qui garantisse le comportement des sites conformément à leurs politiques. Les produits qui mettent en œuvre cette spécification PEUVENT fournir une aide dans ce sens, selon les mises en œuvre en question, mais cela n'est pas traité par cette spécification. Toutefois, le protocole P3P complète les lois et les programmes auto-règlementés définissant des mécanismes d'application. En outre, le protocole P3P ne comprend aucun mécanisme de transport des données ou de sécurisation des données personnelles en transit ou stockées. On peut intégrer P3P à des outils conçus pour faciliter le transport des données. Ces outils devraient inclure les sécurités appropriées.

1.1 La spécification P3P1.0

La spécification P3P1.0 définit la syntaxe et la sémantique des politiques de confidentialité P3P et les mécanismes permettant d'associer les politiques aux ressources Web. Les politiques P3P consistent en déclarations utilisant le vocabulaire P3P afin d'exprimer des pratiques touchant à la vie privée. Les politiques P3P appellent également des éléments du schéma de données de base de P3P, un jeu standard d'éléments de données que tout agent utilisateur P3P devrait reconnaître. La spécification P3P comprend un mécanisme permettant de définir de nouveaux éléments de données et ensembles de données et un mécanisme simple autorisant l'extension du vocabulaire de P3P.

1.1.1 Les buts et les possibilités de P3P1.0

Le protocole P3P version 1.0 est conçu pour informer les utilisateurs du Web des pratiques des sites Web concernant la collecte de données. Il permet à un site Web de transcrire ses pratiques de collecte et d'utilisation des données dans un format XML, lisible par une machine, que l'on appelle politique P3P. La spécification P3P définit :

Un schéma standard des données qu'un site Web est susceptible de collecter, appelé schéma de données P3P de base ;
Un jeu standard d'usages, de destinataires, de catégories de données et d'autres divulgations concernant la vie privée ;
Un format XML pour exprimer une politique de confidentialité ;
Un moyen permettant d'associer des politiques de confidentialité aux pages Web, ou aux sites Web, et aux cookies ;
Un mécanisme de transport des politiques P3P via le protocole HTTP.

Le but de P3P version 1.0 est double. Premièrement, permettre aux sites Web d'annoncer leurs pratiques de collecte de données de manière normalisée, lisible par une machine et facilement disponible. Deuxièmement, permettre aux utilisateurs du Web de savoir quelles données seront collectées par les sites visités, comment ces données seront utilisées, et quels usages de ces données ces utilisateurs accepteront (N.D.T. opt-in) ou bien refuseront (N.D.T. opt-out].

1.1.2 Exemple d'utilisation de P3P

En introduction à P3P, prenons un scénario d'utilisation courant où intervient le protocole P3P. Claudia décide de visiter un magasin en ligne appelé CatalogueExemple et situé à http://www.catalog.example.com/. Supposons que la société CatalogueExemple ait placé des politiques P3P sur toutes ses pages et que Claudia utilise un navigateur avec P3P incorporé.

Claudia entre l'adresse de CatalogueExemple dans son navigateur. Celui-ci peut automatiquement récupérer la politique P3P pour la page en question. La politique annonce que les seules données collectées sur la page d'accueil seront celles contenues dans les journaux d'accès HTTP standards. Le navigateur compare maintenant cette politique aux préférences définies par Claudia. Cette politique est-elle acceptable ou bien faut-il la prévenir ? Supposons que Claudia ait défini le comportement comme étant acceptable. Auquel cas, la page d'accueil s'affiche normalement, sans irruption d'un message. Son navigateur peut très bien lui signaler, au moyen d'une petite icone quelque part le long d'un bord de la fenêtre, que le site a transmis une politique de confidentialité qui correspondait à ses préférences.

Claudia clique ensuite sur un lien menant au catalogue en ligne du site. La partie catalogue fait appel à un programme plus complexe. Ce programme recourt à des cookies pour reproduire les fonctionnalités d'un panier d'achat. Comme d'autres renseignements sont collectés dans cette partie du site, le serveur Web fournit une politique P3P distincte pour celle-ci. En supposant encore que cette politique corresponde aux préférences de Claudia, elle ne reçoit donc aucun message. Claudia poursuit en sélectionnant les articles qu'elle souhaite acheter. Enfin, elle passe sur la page pour leur règlement.

La page de règlement de CatalogueExemple demande certains renseignements supplémentaires : le nom, l'adresse, le numéro de carte de crédit et le numéro de téléphone de Claudia. Il s'y trouve une autre politique P3P laquelle décrit les données qui seront collectées et déclare que ces données ne seront utilisées que pour la réalisation de la transaction courante, c'est-à-dire la commande.

Le navigateur de Claudia examine cette politique P3P. Imaginons que Claudia ait indiqué au navigateur qu'elle souhaite être avertie lorsqu'un site demande son numéro de téléphone. Auquel cas, le navigateur émettra un message disant que ce site Web demande son numéro de téléphone et en expliquant le contenu de la déclaration P3P. Claudia peut alors décider d'accepter ou non. Si c'est le cas, elle poursuit sa commande, sinon elle peut annuler la transaction.

Autrement, Claudia aurait pu indiquer qu'elle ne voulait être avertie que si un site demandait son numéro de téléphone pour le communiquer à un tiers et/ou l'utiliser pour autre chose que la réalisation de la transaction courante. Auquel cas, elle n'aurait pas du tout été interrogée par son navigateur et aurait poursuivi en concluant son achat.

Remarquer que ce scénario décrit une seule mise en œuvre possible de P3P. D'autres types d'interfaces utilisateurs sont également envisageables.

1.1.3 Les politiques P3P

Les politiques P3P utilisent un codage XML avec des espaces de nommage (cf. [XML] et [XML-Name]) du vocabulaire P3P afin de fournir les coordonnées de l'entité légale responsable des pratiques de confidentialité d'une politique, d'énumérer les types de données ou les éléments de données collectés et d'expliquer la destination des données en question. En outre, les politiques identifient les destinataires des données et divulguent d'autres informations, dont les renseignements pour la résolution des litiges et l'adresse de la politique de confidentialité d'un site écrite pour un humain. Les politiques P3P doivent couvrir tous les éléments de données et pratiques mobilisés. Toutefois, les questions concernant le respect des demandes de renseignement légales ne sont pas traitées par cette spécification. Tout en respectant sa politique de non-redistribution des données à des tiers, un site peut être contraint de le faire par force de loi. Les déclarations P3P sont positives : les sites annoncent ce qu'ils font plutôt que ce qu'ils ne font pas. Le vocabulaire P3P est conçu pour décrire les pratiques d'un site plutôt que d'être juste un indicateur de la conformité à une loi particulière ou un code de conduite particulier. Par contre, on peut développer les agents utilisateurs de façon à tester si les pratiques d'un site sont conformes, ou non, à une loi ou un code.

Les politiques P3P représentent les pratiques du site. Les intermédiaires, tels que les opérateurs de télécommunications, les fournisseurs d'accès Internet, les serveurs mandataires et autres, peuvent avoir connaissance de l'échange des données entre un site et un utilisateur, sans que leurs pratiques ne soient régies par les politiques du site en question. En outre, il faut remarquer que chaque politique P3P s'applique aux ressources Web spécifiques (pages Web, images, cookies, etc.) listées dans un fichier d'appel de politique. Quand une entreprise ou une organisation placent une ou plusieurs politiques P3P sur un site Web, elles ne déclarent pas les pratiques de confidentialité associées aux autres ressources Web non mentionnées dans leurs fichiers d'appel de politique ou aux autres activités en ligne ou hors ligne ne se servant pas des données collectées sur les sites Web couverts par leurs politiques P3P.

Lorsque le vocabulaire P3P n'est pas suffisamment précis pour décrire les pratiques d'un site Web, les sites devraient utiliser les termes du vocabulaire qui correspondent au plus près à leurs pratiques et fournir des explications complémentaires (comme indiqué dans la section 3.2). Par contre, les politiques NE DOIVENT PAS faire de déclarations fausses ou trompeuses.

1.1.4 Les agents utilisateurs P3P

Les agents utilisateurs P3P1.0 peuvent être intégrés aux navigateurs Web, aux modules d'extension des navigateurs ou aux serveurs mandataires. Ils peuvent aussi se présenter sous forme d'applets Java ou de scripts JavaScript, ou être intégrés à des portefeuilles électroniques, des remplisseurs de formulaire automatiques ou à d'autres outils de gestion des données de l'utilisateur. Les agents utilisateurs P3P recherchent les appels de politiques P3P dans l'emplacement notoire, dans les en-têtes P3P des réponses HTTP et dans les balises link incorporées à un contenu HTML. Ces appels indiquent l'emplacement des politiques P3P concernées. Les agents utilisateurs peuvent récupérer la politique à l'endroit indiqué, l'analyser puis afficher des symboles, émettre des sons ou générer des invites pour l'utilisateur afin de refléter les pratiques de confidentialité P3P d'un site. Ils peuvent aussi comparer les politiques P3P aux préférences de confidentialité choisies par l'utilisateur et prendre les mesures appropriées. Le protocole P3P peut faire office de portier pour les mécanismes de transfert de données, tels que les portefeuilles électroniques et les remplisseurs de formulaire automatiques. Un agent utilisateur intégré à l'un de ces mécanismes récupérerait les politiques P3P, les comparerait aux préférences de l'utilisateur et n'autoriserait la délivrance des données, premièrement, que si la politique est cohérente avec les préférences de l'utilisateur et, deuxièmement, si le transfert de données requis est cohérent avec la politique en question. Si l'une de ces conditions n'était pas remplie, l'utilisateur sera informé du désaccord et pourra accorder ou non la délivrance des données en connaissance de cause.

La spécification P3P1.0 impose peu de contraintes sur l'interface utilisateur des agents utilisateurs. Les développeurs peuvent ainsi choisir les messages et symboles à présenter à l'utilisateur pour les informer de la politique de confidentialité d'un site Web. Les développeurs ne sont pas tenus d'utiliser textuellement les définitions qui se trouvent dans cette spécification pour leurs interfaces utilisateurs. Toutefois, ils devraient s'assurer que les informations présentées à l'utilisateur, quelles qu'elles soient, représentent fidèlement les politiques P3P décrites, comme dans l'Annexe 7 Les principes directeurs de P3P.

1.1.5 La mise en œuvre de P3P1.0 sur les serveurs

Les sites Web peuvent mettre en œuvre P3P1.0 sur leurs serveurs en transcrivant leurs politiques de confidentialité, lisibles par un humain, vers une syntaxe P3P puis en publiant les fichiers résultants en même temps qu'un fichier d'appel de politique qui désigne les parties du site concernées par la politique. Des outils automatisés peuvent assister les opérateurs de site dans cette traduction. On peut mettre en œuvre P3P1.0 sur les serveurs Web existants, conformes à HTTP/1.1, sans autre programme ou mise à jour. Les serveurs peuvent publier leurs fichiers d'appel de politique dans l'emplacement notoire ou les appeler avec une balise link dans un contenu HTML/XHTML. Autrement, on peut configurer les serveurs compatibles pour qu'ils insèrent une en-tête d'extension P3P dans toutes leurs réponses HTTP, celle-ci indiquant l'emplacement du fichier d'appel de politique du site.

Les sites Web ont toutes latitudes sur la manière d'utiliser P3P : ils peuvent opter pour une seule politique P3P pour le site en entier ou pour des politiques distinctes pour les différentes parties du site. Une politique P3P DOIT couvrir toutes les données générées ou échangées au cours des interactions HTTP du site avec les visiteurs. En outre, certains sites peuvent souhaiter écrire des politiques couvrant toutes les données collectées par une entité, sans se préoccuper de la manière dont elles l'ont été.

1.1.6 Les futures versions de P3P

Des pans significatifs des premiers brouillons de la spécification P3P1.0 ont été supprimés pour faciliter la mise en œuvre et accélérer le déploiement d'une première étape P3P. Une future version de la spécification P3P pourra réintégrer ces fonctionnalités après le déploiement de P3P1.0. Cette spécification comportera vraisemblablement des améliorations en fonction des commentaires en retour d'expérience de mise en œuvre et de déploiement et aussi de quatre composants majeurs, appartenant à la vision P3P originale mais non compris dans P3P1.0 :

Un mécanisme permettant aux sites de proposer un choix de politiques P3P à leurs visiteurs ;
Un mécanisme permettant aux visiteurs, au travers de leur agent utilisateur, d'agréer explicitement une politique P3P ;
Des mécanismes assurant la non-répudiation des accords entre les visiteurs et les sites Web ;
Un mécanisme permettant aux agents utilisateurs de transférer les données d'utilisateur vers des services.

1.2 À propos de cette spécification

Ce document, ainsi que ses références normatives, comprend toutes les indications nécessaires pour la mise en œuvre d'applications P3P interopérables.

Les mots-clés suivants, employés tout au long du document, doivent se comprendre comme des conditions pour l'interopérabilité. Cette spécification emploient les termes définis dans RFC2119 [KEY] pour déterminer le caractère d'obligation de chaque condition particulière. Voici ces termes :

DOI(VEN)T ou NE DOI(VEN)T PAS: Ce terme ou le qualificatif obligatoire désignent une condition nécessaire à la spécification.
DEVRAI(EN)T ou NE DEVRAI(EN)T PAS: Ce terme ou le qualificatif recommandé signifient qu'il peut exister, en certaines circonstances, des raisons valables pour ignorer la condition en question mais on devrait envisager toutes les conséquences et soupeser soigneusement le cas avant d'opter différemment.
PEU(VEN)T: Ce terme ou le qualificatif optionnel indiquent une condition véritablement facultative. Un éditeur peut choisir d'en tenir compte parce qu'un marché particulier l'exige ou parce que celle-ci améliore le produit, par exemple, un concurrent ayant pu l'oublier.

La spécification P3P, sauf en ce qui concerne la section 2.2.2, la section 2.2.3 et la section 4, définit une syntaxe XML avec espaces de nommage (cf. [XML] et [XML-Name]). Par souci de brièveté, on emploiera librement XML par la suite, au lieu de l'expression plus exacte XML avec espaces de nommage.

On utilise aussi une notation semblable à BNF pour toute la spécification : la notation [ABNF] employée ici est spécifiée dans RFC2234 et résumée dans l'Annexe 6. Cependant, dans le cas d'une syntaxe XML, remarquez que cette syntaxe ABNF n'est qu'une représentation grammaticale utilisée pour faciliter la lecture (elle manque, par exemple, de toutes les souplesses syntaxiques qui sont implicites dans XML, c'est-à-dire, les règles concernant les caractères blancs, la citation avec des guillemets simples ' ou des guillemets doubles ", le masquage des caractères →vf, les commentaires, la sensibilité à la casse, l'ordre des attributs, la gestion des espaces de nommage) et, en tant que telle, elle n'a pas de valeur normative. Toute la syntaxe XML définie dans cette spécification DOIT être conforme au schéma XML de P3P (cf. l'Annexe 4) qui, avec les autres contraintes exprimées en langage naturel dans la spécification, constitue la définition normative.

On PEUT utiliser la définition de type de document (DTD), non normative, fournie dans l'Annexe 5 pour vérifier la validité des fichiers P3P. Toutefois, il se peut que certains fichiers valides soient rejetés lors de l'évaluation contre le DTD parce que ceux-ci utilisent des espaces de nommage.

Donc, pour tout ce qui concerne la syntaxe non XML définie dans cette spécification (à savoir, la section 2.2.2 définissant l'en-tête HTTP de P3P, la section 2.2.3 définissant l'usage de P3P dans HTML et la section 4 définissant les politiques compactes), c'est la notation ABNF (avec les autres contraintes exprimées en langage naturel dans cette spécification) qui constitue la définition normative.

1.3 La terminologie

Adresse URI: Un identificateur de ressource uniforme (URI) servant à localiser une ressource Web. Pour des précisions sur la syntaxe et la sémantique d'une adresse URI, cf. [URI]. Les adresses URI qui apparaissent dans XML ou HTML doivent être traitées comme indiqué dans [CHARMODEL] à la section Le codage des caractères dans les adresses URI. Les adresses URI qui apparaissent dans les champs des en-têtes HTTP ne sont pas concernées ; celles-ci devraient toujours être entièrement masquées.
Agent utilisateur: Un programme destiné à la médiation des interactions avec les services, pour le compte et selon les préférences de l'utilisateur. Un utilisateur peut disposer de plusieurs agents utilisateurs, ceux-ci ne résidant pas forcément sur le bureau de l'utilisateur, mais tout agent utilisateur ne doit être contrôlé que par l'utilisateur et n'agir que pour le compte de celui-ci. La relation de confiance entre un utilisateur et son agent utilisateur peut dépendre de contraintes étrangères à P3P. Par exemple, cette confiance accordée à l'agent utilisateur peut exister parce qu'il fait partie du système d'exploitation de l'utilisateur ou du client Web, ou bien qu'il fait partie des conditions d'utilisation d'un fournisseur d'accès ou d'un serveur mandataire confidentiel.
Caractère: Les chaînes consistent en une séquence de zéro caractère ou plus, un caractère se définissant comme dans la recommandation XML [XML]. Un seul caractère dans P3P correspond ainsi à un seul caractère abstrait Unicode avec une seule valeur scalaire Unicode correspondante (cf. [UNICODE]).
Catégorie de données: Un attribut significatif d'un élément de données, ou d'un jeu de données, pouvant être utilisé par un dispositif de confiance pour déterminer le type d'élément dont il est question, telles que des coordonnées physiques. Le protocole P3P1.0 définit un jeu de catégories de données.
Déclaration: Une déclaration P3P est un jeu de divulgations à propos des pratiques de confidentialité associées à une collection d'éléments de données.
Données identifiées: Les données qui peuvent raisonnablement servir à un collecteur de données pour identifier un individu.
Élément de données: Une entité de données individuelle, tel qu'un nom ou un numéro de téléphone. Pour l'interopérabilité, le protocole P3P1.0 spécifie un jeu d'éléments de données de base.
Fournisseur de services (contrôleur de données, entité légale): La personne (ou l'entité légale) qui fournit des informations, des produits ou des services à partir d'un site Web, qui collecte des renseignements et qui est responsable des allégations effectuées dans une déclaration de pratique.
Intention: La ou les raisons présidant à la collecte et à l'utilisation des données.
Jeu de données: Un regroupement prédéfini d'éléments de données, tel que "user.home-info.postal". Le schéma de données de base de P3P1.0 définit un certain nombre de jeux de données.
Politique: Une collection composée d'une ou de plusieurs déclarations de confidentialité associées à des informations faisant valoir l'identité, l'adresse URI, les garanties et les procédures de résolution des litiges du service couvert par la politique en question.
Pratique: Le jeu des divulgations concernant l'utilisation des données, comprenant l'intention, les destinataires et d'autres divulgations.
Pratique uniforme: Une pratique qui est très semblable à une autre, l'intention et les destinataires étant identiques ou plus contraints que l'original, et les autres divulgations n'étant pas significativement différentes. Par exemple, deux sites qui ont des pratiques sinon similaires obéissant à des jeux de directives sectorielles différents pourtant semblables.
Préférence: Une règle, ou jeu de règles, qui détermine quelle(s) action(s) un agent utilisateur effectuera. Une préférence peut s'exprimer comme une déclaration analysable définie formellement (par exemple, le langage d'échange de préférences [APPEL]).
Référentiel: Un mécanisme de stockage des données personnelles sous le contrôle de l'agent utilisateur.
Ressource: Un objet ou un service de données en réseau identifiables par une adresse URI. Les ressources peuvent être disponibles sous diverses formes (par exemple, en plusieurs langues, formats de données, tailles et résolutions) ou varier de diverses manières.
Schéma de données: Une collection d'éléments et de jeux de données définis au moyen de l'élément P3P1.0 <DATASCHEMA>. Le protocole P3P1.0 définit un schéma de données standard appelé schéma de données P3P de base.
Service: Un programme qui délivre des politiques et (éventuellement) des requêtes de données. Selon cette définition, un service peut être un serveur (site), une application locale, un fragment de code actif local, comme un contrôle ActiveX ou une applet Java, ou même un autre agent utilisateur. Cependant, un service sera habituellement un site Web. Dans cette spécification, les termes service et site Web sont souvent interchangeables.
Structure de données: Une description hiérarchique d'un jeu d'éléments de données. On peut décrire un jeu de données en fonction de sa structure de données. Le protocole P3P1.0 définit un jeu de structures de données de base utilisé pour décrire les jeux de données dans le schéma de données P3P de base.
Utilisateur: Un individu (ou groupe d'individus agissant comme une seule entité) pour le compte duquel un service est sollicité et pour lequel des données personnelles existent. Les politiques P3P décrivent la collecte et l'utilisation des données personnelles concernant cet individu ou ce groupe.
Zone sûre: La partie d'un site Web où le fournisseur de services effectue seulement une collecte minimale de renseignements et où toutes les données collectées sont utilisées de telle sorte qu'il n'est pas possible d'identifier raisonnablement un individu.

2. L'appel des politiques

2.1 Vue d'ensemble et utilisation des appels de politique

La localisation d'une politique P3P est l'une des premières étapes dans le déroulement du protocole P3P. Les services recourent à des appels de politique pour déclarer quelle politique s'applique à telle adresse URI ou tel jeu d'adresses URI. Les agents utilisateurs recourent à des appels de politique pour localiser la politique de confidentialité appliquée à une ressource Web afin de traiter cette politique pour le bénéfice de l'utilisateur.

Les appels de politique contribuent beaucoup à l'optimisation des performances. Les politiques P3P contiennent généralement plusieurs kilo octets de données, tandis qu'une adresse URI appelant une politique de confidentialité pèse en général moins de 100 octets. En plus des économies de bande passante, les appels de politiques réduisent également les besoins en calcul : les politiques sont en correspondance unique avec les adresses URI et les agents utilisateurs n'ont ainsi besoin d'analyser et de traiter une politique qu'une seule fois au lieu de la traiter avec chacun des documents auxquels elle s'applique. En outre, la centralisation des informations sur les politiques concernées simplifie l'administration du site Web.

On utilise un fichier d'appel de politique pour associer les politiques P3P à certaines régions de l'espace d'adresses URI. Le fichier d'appel de politique est un fichier XML avec espaces de nommage (cf. [XML] et [XML-Name]) qui peut définir la politique d'un seul document Web, ou de tout ou parties d'un site Web. Le fichier d'appel de politique peut désigner une ou plusieurs politiques P3P ; un seul fichier d'appel peut donc couvrir un site entier, même si différentes politiques P3P s'appliquent à différentes parties du site. On utilise le fichier d'appel de politique pour faire une ou toutes les déclarations suivantes :

L'adresse URI où se trouve une politique P3P ;
Les adresses URI ou les régions de l'espace d'adresses URI couverts par cette politique ;
Les adresses URI ou les régions de l'espace d'adresses URI non couverts par cette politique ;
Les régions de l'espace d'adresses URI d'un contenu incorporé sur d'autres serveurs couverts par cette politique ;
Les cookies qui sont couverts, ou non, par cette politique ;
Les méthodes d'accès pour lesquelles cette politique est applicable ;
L'intervalle de temps pour lequel ces revendications sont considérées comme valides.

Toutes ces déclarations sont contenues dans le corps du fichier d'appel de politique.

2.2 La localisation des fichiers d'appel de politique

Cette section décrit le mécanisme servant à localiser un fichier d'appel de politique. On donne également la syntaxe détaillée des mécanismes mis en œuvre.

La localisation du fichier d'appel de politique peut être indiquée en recourant à l'un de quatre mécanismes. Le fichier d'appel de politique peut :

se trouver dans un emplacement notoire prédéfini, ou
être indiqué dans un document HTML par une balise link, ou
être indiqué dans un document XHTML par une balise link, ou
être indiqué par une en-tête HTTP.

Remarquez que, si l'agent utilisateur peut récupérer un contenu HTML (ou respectivement XHTML) via HTTP, il DOIT gérer de façon interchangeable les mécanismes 1, 2 et 3 (et 4 pour XHTML) listés ci-dessus. Voir également les conditions de non-ambiguïté.

Les politiques s'appliquent au niveau des ressources. Une page, du point de vue de l'utilisateur, peut se composer de multiples ressources HTTP ; chacune peut se voir associer une politique P3P propre. En pratique, cependant, le fait de placer beaucoup de politiques P3P différentes sur les diverses ressources d'une seule page peut compliquer la tâche des agents utilisateurs qui est de restituer cette page et de signaler les politiques mises en jeu à l'utilisateur. Par conséquent, on recommande aux services d'essayer de construire leurs fichiers d'appel de politique de telle sorte qu'un seul fichier d'appel couvre la page en question, afin d'accélérer la session de navigation de l'utilisateur.

Pour qu'un agent utilisateur puisse traiter la politique qui s'applique à une ressource donnée, il doit localiser le fichier d'appel de politique, l'analyser, récupérer toutes les politiques P3P requises puis analyser cette (ou ces) politique(s) P3P.

Ce document ne spécifie pas comment associer les politiques P3P aux ressources Web récupérées par un autre protocole que HTTP. Toutefois, il n'interdit pas le développement futur de mécanismes pour associer les politiques P3P aux ressources récupérées par d'autres protocoles. En outre, d'autres méthodes d'association des politiques P3P aux ressources HTTP sont susceptibles de développements ultérieurs.

2.2.1 L'emplacement notoire

Les sites Web utilisant P3P PEUVENT (et ils sont fortement encouragés à le faire) placer un fichier d'appel de politique dans un emplacement notoire. Pour cela, on devrait disposer sur le site un fichier d'appel de politique ayant pour chemin d'accès /w3c/p3p.xml.

Remarquez que les sites ne sont pas obligés de recourir à ce mécanisme ; toutefois, les sites qui le font sont assurés que leur politique P3P sera accessible aux agents utilisateurs avant toute autre ressource demandée au site. Les agents utilisateurs n'auront plus autant besoin d'accéder au site en recourant à des pratiques de zone sûre. En outre, si c'est la méthode choisie pour le site, le fichier d'appel de politique dans cet emplacement notoire n'est pas obligé de couvrir le site entier. Par exemple, les sites dont le contenu n'est pas tout entier contrôlé par une seule organisation PEUVENT ne pas opter pour ce mécanisme, ou PEUVENT opter pour placer un fichier d'appel de politique ne couvrant qu'une partie limitée du site.

Recourir à l'emplacement notoire pour le fichier d'appel de politique n'empêche pas de recourir à d'autres méthodes de spécification de ce fichier. Des parties du site PEUVENT employer n'importe lequel des autres mécanismes reconnus pour indiquer un fichier d'appel tant que les conditions de non-ambiguïté sont respectées.

Par exemple, imaginons un site de galerie marchande Web tenu par l'entreprise GalerieExemple. Sur leur site Web (galerie.example.com), les entreprises offrant des produits ou des services dans cette galerie disposent d'un sous-arbre propre du site, avec un chemin d'accès comme /entreprises/nom-entreprise. L'entreprise GalerieExemple peut choisir de placer un fichier d'appel de politique dans l'emplacement notoire couvrant le site en entier, sauf le sous-arbre /entreprises. Ainsi, lorsque l'entreprise ChaussuresExemple place un contenu à /entreprises/chaussuresexemple, elle peut utiliser l'un des autres mécanismes pour indiquer la localisation d'un fichier d'appel de politique couvrant sa partie du site galerie.example.com.

L'utilisation de l'emplacement notoire pour le fichier d'appel de politique se révèle particulièrement utile dans le cas d'un site dont le contenu est réparti sur plusieurs hôtes. Par exemple, supposons un site utilisant pour toutes ses applications Web un hôte logique différent de celui hébergeant son contenu HTML statique. Les autres mécanismes de localisation du fichier d'appel de politique obligent à récupérer une certaine adresse URI sur l'hôte concerné pour localiser ce fichier d'appel de politique. Au contraire, ce n'est pas nécessaire pour l'emplacement notoire. En supposant, par exemple, un formulaire HTML qui se trouve sur www.example.com et l'adresse URI de l'attribut "action" de ce formulaire qui conduit au serveur cgi.example.com. Le fichier d'appel de politique, qui couvre le formulaire, est incapable de produire une déclaration portant sur l'adresse URI (de l'attribut "action") traitant le formulaire. L'administrateur du site publie néanmoins un fichier d'appel de politique à http://cgi.example.com/w3c/p3p.xml qui couvre l'adresse URI (de l'attribut "action"), et permet ainsi à un agent utilisateur de localiser facilement la politique P3P qui s'y applique, avant de soumettre le contenu du formulaire.

2.2.2 Les en-têtes HTTP

Tout document récupéré par HTTP PEUT pointer vers un fichier d'appel de politique au travers d'une nouvelle en-tête de réponse : l'en-tête P3P ([P3P-HEADER]). Si un site utilise des en-têtes P3P, il DEVRAIT les inclure dans toutes les réponses des méthodes de requête appropriées, y compris les requêtes HEAD et OPTIONS.

L'en-tête P3P colporte une ou plusieurs directives, séparées par des virgules. En voici la syntaxe :

[1]    p3p-header        =  `P3P: ` p3p-header-field *(`,` p3p-header-field)

[2]    p3p-header-field  =   policy-ref-field | compact-policy-field | extension-field

[3]    policy-ref-field  =  `policyref="` URI-reference `"`

[4]    extension-field   =   token
                             [`=` (token | quoted-string) ]

Ici, la valeur URI-reference est définie selon RFC 2396 [URI] ; les valeurs token et quoted-string sont définies par [HTTP1.1].

Comme pour les autres en-têtes HTTP, la casse du nom de l'en-tête P3P est indifférente. Par contre, le contenu devrait s'écrire précisément avec la casse indiquée dans ce document.

La directive policyref fournit une adresse URI qui indique la localisation d'un fichier d'appel de politique, qui peut alors appeler la politique P3P couvrant le document pointant vers le fichier d'appel et d'autres éventuellement. Quand l'attribut policyref est une adresse URI relative, celle-ci est relative à l'adresse URI de la requête. Remarquez que la récupération de l'adresse URI fournie par la directive policyref PEUT donner lieu à un code de réponse de la classe HTTP 300 (redirection) ; les agents utilisateurs DOIVENT interpréter ces redirections selon la sémantique HTTP normale. Les fournisseurs de services vont sans doute remarquer que les redirections accroissent le temps nécessaire pour que les agents utilisateurs trouvent et interprètent leurs politiques. L'adresse URI de policyref NE DOIT PAS servir pour un autre usage que la localisation et l'appel des politiques P3P.

La directive compact-policy-field sert à indiquer des politiques compactes. Cf. la section 4.

Les agents utilisateurs rencontrant des directives non reconnues (dans les directives extension-field) DOIVENT les ignorer. Ceci afin de faciliter le déploiement des versions ultérieures de P3P.

Exemple 2.1 :

1. Le client effectue une requête GET :

GET /index.html HTTP/1.1
Host: catalogue.example.com
Accept: */*
Accept-Language: de, en
User-Agent: WonderBrowser/5.2 (RT-11)

2. Le serveur renvoie un contenu et l'en-tête P3P pointant vers la politique de la ressource :

HTTP/1.1 200 OK
P3P: policyref="http://catalogue.example.com/P3P/ReferencesPolitiques.xml"
Content-Type: text/html
Content-Length: 7413
Server: CC-Galaxy/1.3.18

2.2.3 La balise HTML `link`

Les serveurs PEUVENT renvoyer un contenu HTML incorporant des balises link (cf. [HTML]) qui indiquent la localisation du fichier d'appel de politique P3P concerné. Cette utilisation de P3P n'induit aucun changement dans le comportement du serveur.

La balise link code les informations d'appel de politique qui auraient pu être exprimées au moyen d'une en-tête P3P. La balise link prend la forme suivante (on a juste produit un format ABNF possible pour la balise link et supposé que les règles de syntaxe [HTML] pouvaient s'appliquer pour cette balise dans un fichier HTML) :

[5]    p3p-link-tag   =  `<link rel="P3Pv1" href="` URI `">`

Ici, la valeur URI est définie selon RFC 2396 [URI].

Quand l'attribut href est une adresse URI relative, celle-ci est relative à l'adresse URI de la requête.

Pour illustrer l'emploi de la balise link, on reprend l'appel de politique exprimée dans l'Exemple 2.1 avec des en-têtes HTTP. Cet exemple peut s'exprimer de manière équivalente en utilisant la balise link dans le fragment HTML suivant :

<link rel="P3Pv1"
    href="http://catalogue.example.com/P3P/ReferencesPolitiques.xml">

Enfin, puisqu'on incorpore p3p-link-tag à un document HTML, on remarquera que son codage de caractères sera le même que celui du document HTML. À la différence des documents de politique P3P et d'appel de politique (cf. la section 2.3 et la section 3 ci-dessous), il n'est pas nécessaire de transcrire p3p-link-tag dans le codage [UTF-8]. Remarquez également que la balise link n'est pas sensible à la casse.

2.2.4 La balise XHTML `link`

En parallèlle de la balise HTML link, le protocole P3P gère également XHTML (cf. [XHTML-MOD]). Les serveurs PEUVENT, au moyen du module link XHTML (cf. la section 5.19 de la spécification [XHTML-MOD]), renvoyer un contenu XHTML qui indique l'emplacement du fichier d'appel de politique P3P concerné avec une balise XHTML link incorporée. Comme pour HTML, on peut utiliser une balise XHTML link pour coder les informations d'appel de politique (qui auraient pu être exprimées par une en-tête P3P) :

en donnant à son attribut rel la valeur "P3Pv1" ;
en donnant à son attribut href l'adresse URI du fichier d'appel de politique P3P concerné.

2.2.5 Les ports HTTP et les autres protocoles

Les mécanismes décrits ici PEUVENT servir pour des transactions HTTP sur n'importe quel protocole sous-jacent. À savoir le protocole HTTP en texte brut sur des connexions TCP/IP ou HTTP crypté sur des connexions SSL, ou bien HTTP sur tout autre protocole de communication dont les concepteurs souhaitent la mise en œuvre.

Les adresse URI PEUVENT contenir des numéros de port de réseau, comme défini dans RFC 2396 [URI]. En ce qui concerne le protocole P3P, les ports différents sur un seul hôte DOIVENT être considérés comme étant des sites distincts. Ainsi, par exemple, le fichier d'appel de politique à l'emplacement notoire pour www.example.com sur le port 80 (http://www.example.com/w3c/p3p.xml) ne donnerait aucune information sur les politiques applicables à www.example.com lors d'un accès via SSL (étant donné que la communication SSL interviendra sur un port différent, 443 par défaut).

Ce document ne définit pas comment associer les politiques P3P à des ressources récupérées par d'autres moyens que HTTP. Toutefois, cela n'exclut pas le développement futur de mécanismes d'association de politiques P3P à des ressources récupérées via d'autres protocoles. En outre, d'autres méthodes associant des politiques P3P à des ressources récupérées via HTTP sont susceptibles d'être développées ultérieurement.

errata E1

2.3 La syntaxe et la sémantique du fichier d'appel de politique

Cette section détaille le contenu des fichiers d'appel de politique.

2.3.1 Exemple de fichier d'appel de politique

Considérons le cas d'un site Web souhaitant faire les déclarations suivantes :

La politique P3P /P3P/Politiques.xml#un s'applique au site entier, sauf aux ressources dont les chemins d'accès commence par /catalogue, /cgi-bin ou /servlet ;
La politique P3P /P3P/Politiques.xml#deux s'applique à toutes les ressources dont les chemins d'accès commencent par /cgi-bin ou /servlet, sauf /servlet/inconnu.
Aucune déclaration sur la politique P3P qui s'applique à /servlet/inconnu ;
Ces déclarations sont valides pour deux jours.

On peut représenter ces déclarations dans le fragment XML suivant :

Exemple 2.2 :

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY-REFERENCES>
  <EXPIRY max-age="172800"/>

    <POLICY-REF about="/P3P/Politiques.xml#un">
      <INCLUDE>/*</INCLUDE>
      <EXCLUDE>/catalogue/*</EXCLUDE>
      <EXCLUDE>/cgi-bin/*</EXCLUDE>
      <EXCLUDE>/servlet/*</EXCLUDE>
    </POLICY-REF>

    <POLICY-REF about="/P3P/Politiques.xml#deux">
      <INCLUDE>/catalogue/*</INCLUDE>
    </POLICY-REF>

    <POLICY-REF about="/P3P/Politiques.xml#trois">
      <INCLUDE>/cgi-bin/*</INCLUDE>
      <INCLUDE>/servlet/*</INCLUDE>
      <EXCLUDE>/servlet/inconnu</EXCLUDE>
    </POLICY-REF>

 </POLICY-REFERENCES>
</META>

Remarquez que cet exemple inclut également, via l'élément <EXPIRY>, une date d'échéance relative dans le document (cf. la section 2.3.2.3.2).

2.3.2 La définition du fichier d'appel de politique

Cette section définit la syntaxe et la sémantique des fichiers d'appel de politique P3P. Tous les fichiers d'appel de politique DOIVENT être codés en [UTF-8]. Les serveurs P3P DOIVENT coder leurs fichiers d'appel de politique en utilisant cette syntaxe.

2.3.2.1 Le traitement du fichier d'appel de politique

2.3.2.1.1 L'importance de l'ordre

Un fichier d'appel de politique a pour racine l'élément <META>. Il peut contenir plusieurs éléments <POLICY-REF>. S'il contient plus d'un élément, alors les agents utilisateurs DOIVENT les traiter dans l'ordre d'apparition dans le fichier. Quand un agent utilisateur essaye de déterminer quelle politique s'applique à une adresse URI donnée, il DOIT utiliser le premier élément <POLICY-REF> concernant cette adresse URI dans le fichier d'appel de politique.

Remarquez que chaque élément <POLICY-REF> peut contenir plusieurs éléments <INCLUDE>, <EXCLUDE>, <METHOD>, <COOKIE-INCLUDE> et <COOKIE-EXCLUDE > et que tous ces sous-éléments d'un élément <POLICY-REF> DOIVENT être évalués ensemble pour déterminer si cet élément <POLICY-REF> s'applique, ou non, à une adresse URI donnée. Ainsi, il ne suffit pas de trouver un élément <INCLUDE> qui corresponde à une adresse URI donnée, car des éléments <EXCLUDE> ou <METHOD> peuvent intervenir comme modificateurs et l'élément <POLICY-REF> ne correspondra donc plus.

2.3.2.1.2 Les caractères jokers dans les fichiers d'appel de politique

Les fichiers d'appel de politique déclarent quelle politique s'applique à une adresse URI donnée. Ils reconnaissent un caractère joker simple qui permet des déclarations limitées à certaines régions de l'espace d'adresses URI. Le caractère astérisque * sert à représenter une séquence de zéro ou plus caractères arbitraires. Aucun autre caractère spécial (comme ceux utilisés dans les expressions rationnelles) n'est reconnu.

Comme l'astérisque est aussi un caractère légal pour les adresses URI ([URI]), on doit adopter des conventions spéciales pour coder ces adresses URI étendues dans un fichier d'appel de politique :

Les adresses URI apparaissant dans les fichiers d'appel DOIVENT être correctement masquées, comme décrit dans [URI], sauf que :
- les caractères * littéraux des adresses URI dans les fichiers d'appel DOIVENT être masqués (c'est-à-dire qu'on doit les représenter par "%2A"). Tout caractère * présent dans une adresse URI dans un fichier d'appel sera interprété comme un caractère joker astérisque ;
- et, pour cette raison, les agents utilisateurs P3P DOIVENT correctement développer une adresse URI apparaissant dans un fichier de référence, selon [URI], avant d'essayer de la comparer à une adresse URI dans une représentation interne, toutefois seulement après qu'un éventuel caractère * littéral présent aura été reconnu comme un caractère joker astérisque.

Le masquage et le démasquage des adresses URI dépendent en grande partie de la combinaison réelle utilisée et peuvent même différer d'un composant individuel à l'autre dans une seule combinaison, on ne peut donc pas donner ici de règle simple permettant de déterminer quels caractères doivent être masqués. Reportez-vous directement à [URI] pour des précisions sur le processus de masquage standard. Remarquez que les agents utilisateurs P3P PEUVENT ignorer tout motif d'adresse URI non conforme à [URI].

On PEUT utiliser le caractère joker dans les éléments <INCLUDE> et <EXCLUDE>, dans les éléments <COOKIE-INCLUDE> et <COOKIE-EXCLUDE> et dans l'élément <HINT>.

2.3.2.2 Les éléments `META` et `POLICY-REFERENCES`

<META>: L'élément <META> contient un fichier d'appel de politique complet. Un élément <POLICIES> optionnel peut suivre. L'élément <META> peut également contenir un ou plusieurs éléments <EXTENSION> (cf. la section 3.5), ainsi qu'un attribut xml:lang (cf. la section 2.4.2) pour indiquer la langue dans laquelle son contenu est exprimé.
<POLICY-REFERENCES>: Cet élément PEUT contenir un ou plusieurs éléments <POLICY-REF> (appel de politique). Il PEUT aussi contenir un élément <EXPIRY> (qui donne la date d'expiration), un ou plusieurs éléments <HINT> et un ou plusieurs éléments <EXTENSION> (cf. la section 3.5).

[6]    prf         =  `<META xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `>`
                      *extension
                       policyrefs
                       [policies]
                      *extension
                      "</META>"

[7]    policyrefs  =  "<POLICY-REFERENCES>"
                       [expiry]
                      *policyref
                      *hint
                      *extension
                      "</POLICY-REFERENCES>"

Ici la valeur PCDATA est définie dans [XML].

2.3.2.3 La durée de vie d'un fichier d'appel de politique et l'élément `<EXPIRY>`

2.3.2.3.1 La motivation et le mécanisme

Il est souhaitable que les serveurs puissent informer les agents utilisateurs de la durée pendant laquelle ceux-ci peuvent utiliser les affirmations faites dans un fichier d'appel de politique. Permettre aux clients de mettre en cache le contenu d'un fichier d'appel réduit le temps requis pour traiter la politique de confidentialité associée à une ressource Web. La charge exercée sur le réseau s'en trouve également atténuée. En outre, les clients ne disposant pas d'un fichier d'appel de politique valide pour une adresse URI devront adopter des pratiques de zone sûre pour leurs requêtes. Si les clients disposent de fichiers d'appel de politique dont la validité est avérée, alors ils peuvent décider en connaissance de cause de la façon de procéder.

Pour en tirer des bénéfices, les fichiers d'appel de politique DEVRAIENT contenir un élément <EXPIRY>, qui indique la durée de vie de ces fichiers. Si le fichier d'appel ne contient pas d'élément <EXPIRY>, alors sa durée de vie implicite est de 24 heures.

La durée de vie d'un fichier d'appel de politique indique aux agents utilisateurs la période pendant laquelle ceux-ci peuvent compter sur les affirmations contenues dans le fichier d'appel. En donnant une durée de vie au fichier d'appel de politique, le site éditeur établit que les politiques mentionnées dans le fichier d'appel sont recevables pour la durée de vie de celui-ci. Par exemple, si un fichier d'appel a une durée de vie de trois jours, alors l'agent utilisateur n'aura pas besoin de recharger ce fichier au cours des trois jours suivants et pourra supposer que les références contenues dans ce fichier seront exactes dans cet intervalle. Tous les appels de politique contenus dans un seul fichier d'appel de politique auront la même durée de vie. La seule façon de définir d'autres durées de vie à des appels de politique différents sera de recourir à des fichiers d'appel de politique séparés.

Ce mécanisme pour indiquer la durée de vie d'un fichier d'appel de politique est le même qui sert à indiquer celle d'une politique P3P. Ainsi, on DEVRAIT associer un élément <EXPIRY> aux éléments <POLICIES>. Cette durée de vie s'applique à toutes les politiques P3P contenues dans l'élément <POLICIES>. Si aucun élément <EXPIRY> n'est associé à une politique P3P, alors sa durée de vie implicite est de 24 heures.

Au moment de choisir les durées de vie des politiques et des fichiers d'appel de politique, les sites doivent retenir celle qui représente le meilleur compromis entre deux positions antagonistes. D'une part, que la durée de vie soit suffisante pour que les agents utilisateurs puissent retirer un avantage significatif de la mise en cache. D'autre part, que le site puisse changer de politique pour une nouvelle collecte de données sans devoir attendre une échéance trop lointaine. Une durée de vie comprise dans une fourchette d'un à sept jours apparaît comme un compromis raisonnable entre ces deux objectifs concurrents. Les sites doivent également revoir les conditions de mise à jour des politiques lorsque ces mises à jour ont lieu.

Lorsqu'un fichier d'appel de politique est expiré, l'agent utilisateur NE DOIT PAS utiliser les informations qui y sont contenues tant qu'il n'a pas revalidé avec succès le fichier d'appel ou récupéré une nouvelle version de celui-ci.

Bien que les agents utilisateurs ne soient pas obligés de revalider les fichiers d'appel de politique, ou ceux des politiques non expirées, ils PEUVENT choisir de le faire avant leur expiration pour diminuer les probabilités de devoir recourir à des pratiques de zone sûre. Un agent utilisateur P3P valide n'est pas obligé de mettre en place un cache pour les politiques et les fichiers d'appel de politique, quoique ses performances puissent être meilleures s'il en avait un.

errata E2

2.3.2.3.2 L'élément `<EXPIRY>`

On peut utiliser l'élément <EXPIRY> dans un fichier d'appel de politique et/ou dans un élément <POLICIES> pour indiquer combien de temps le fichier d'appel (ou les politiques) restent valides. L'expiration est exprimée soit comme une échéance absolue, soit comme une échéance relative. Une échéance absolue est une date, exprimée en temps GMT, juqu'où le fichier d'appel de politique ou bien les politiques sont valides. Une échéance relative est le nombre de secondes pendant lesquelles le fichier d'appel ou bien les politiques sont valides. Cette dernière est relative au moment où le client a demandé le fichier d'appel ou bien les politiques. Le calcul DOIT tenir compte de l'instant de la requête originale, ou de la revalidation, et de l'instant courant, les deux temps ayant été générés par l'horloge du client. La revalidation est définie dans la section 13.3 de la spécification [HTTP1.1].

La quantité minimale de temps pour une échéance relative est de 24 heures, soit 86400 secondes. Toute échéance relative de moins de 86400 secondes DOIT être considérée comme valant 86400 secondes par la mise en œuvre du client. Si un client rencontre une échéance absolue dépassée, il DOIT agir comme si AUCUN fichier d'appel de politique (ou AUCUNE politique) n'était disponible. Cf. la section 2.4.7 L'absence d'un fichier d'appel de politique pour la procédure à suivre dans ces cas.

[8]    expiry   =  "<EXPIRY" (absdate|reldate) "/>"

[9]    absdate  =  `date="` HTTP-date `"`

[10]   reldate  =  `max-age="` delta-seconds `"`

Ici, la valeur HTTP-date est définie dans la section 3.3.1 et la valeur delta-seconds dans la section 3.3.2 de la spécification [HTTP1.1].

2.3.2.3.3 La requête des politiques et des fichiers d'appel de politique

Dans un réseau réel, il peut y avoir des caches stockant les contenus des politiques et des fichiers d'appel de politique. Cette mise en cache favorise les performances d'ensemble du réseau mais présente de sérieux inconvénients en ce qui concerne le fonctionnement de P3P quand elle est mal utilisée. Deux problèmes particuliers se posent :

Lorsqu'un agent utilisateur reçoit un fichier d'appel de politique (ou une politique) provenant d'un serveur mandataire (par exemple, cf. [CACHING]), il aura besoin de savoir depuis combien de temps le fichier d'appel (ou la politique) résidait sur le serveur. On DOIT soustraire cette quantité de la durée de vie des fichiers d'appel de politique ou des politiques dont l'échéance est relative ;
Lorsqu'un agent utilisateur doit revalider un fichier de d'appel de politique (ou une politique), il doit avoir la certitude que la revalidation produira une version courante du fichier d'appel (ou de la politique). Par exemple, supposons qu'un agent utilisateur possède un fichier d'appel de politique ayant une échéance relative d'un jour. Si l'agent utilisateur recharge un fichier résidant depuis trois jours sur un serveur mandataire, il ne sera alors d'aucune utilité.

Le protocole HTTP 1.1 [HTTP1.1] comporte des mécanismes puissants pour contrôler la mise en cache qui permettent aux clients de contraindre les caches d'un réseau ; ces mécanismes peuvent apporter des solutions aux problèmes mentionnés ci-dessus. On décrira une méthode particulière plus loin.

Par contre, le protocole HTTP 1.0 n'offre pas ces mécanismes de contrôle de cache sophistiqués. Un serveur mandataire HTTP 1.0 calculera certainement la durée de vie de cache du fichier d'appel de politique (ou des politiques) à partir de la dernière date de modification du fichier ; la durée de vie de cache pourra être beaucoup plus grande que celle indiquée par l'élément <EXPIRY>. Le serveur est donc susceptible de renvoyer aux clients un fichier d'appel de politique (ou des politiques) bien après l'échéance indiquée par l'élément <EXPIRY> et les agents utilisateurs recevront par conséquent un fichier d'appel (ou des politiques) inutilisable.

Le second problème des serveurs mandataires HTTP 1.0 tient au fait que l'agent utilisateur n'a aucun moyen de savoir depuis combien de temps le fichier d'appel est stocké dans le serveur mandataire. Si le fichier d'appel de politique (ou les politiques) est régi par une échéance relative, il sera alors impossible pour l'agent utilisateur de déterminer si la durée de vie du fichier est épuisée ou si elle va l'être.

Donc, si un agent utilisateur demande un fichier d'appel de politique, ou une politique, et qu'il n'est pas sûr qu'aucun cache HTTP 1.0 ne se trouve sur le trajet vers le serveur d'origine, alors la requête DOIT forcer une revalidation de bout en bout. On peut obtenir ce comportement en utilisant l'en-tête de requête HTTP Pragma: no-cache. Remarquez que ni le protocole HTTP ni le protocole P3P ne définissent de moyen pour déterminer si un serveur mandataire HTTP 1.0 existe sur une route dans un réseau, et c'est la raison pour laquelle l'agent utilisateur, à moins d'être informé par une source extérieure, DOIT forcer une revalidation de bout en bout.

Si l'agent utilisateur sait, d'une manière ou d'une autre, que tous les caches sur la route vers le serveur d'origine sont compatibles HTTP 1.1 (ou qu'il n'y a aucun cache sur cette route), plutôt que de forcer une revalidation de bout en bout, il PEUT alors :

Utiliser des en-têtes de requête Cache-Control pour s'assurer que le fichier reçu n'a pas dépassé sa durée de vie. On utilise pour cela le paramètre de gestion de cache max-age avec une valeur très antérieure à la durée du vie du fichier d'appel de politique (ou des politiques). Par exemple, un agent utilisateur pourrait envoyer Cache-Control: max-age=43200, assurant ainsi que la réponse ne sera pas âgée de plus de 12 heures ;
Soustraire l'âge de la réponse de la durée de vie du fichier d'appel de politique (ou des politiques), si ce fichier utilise une échéance relative. L'âge de la réponse est donnée par l'en-tête de réponse HTTP Age: .

Remarquez que le client est incapable de déterminer avec précision l'importance de la latence susceptible d'affecter une requête HTTP. Donc, si la durée de vie du fichier d'appel de politique concerné par une requête est sur le point d'expirer, l'agent utilisateur PEUT envisager d'avertir l'utilisateur et/ou de revalider le fichier de référence avant de poursuivre la requête.

2.3.2.3.4 La gestion d'erreurs pour les durées de vie des fichiers d'appel de politique et des politiques

Les situations suivantes font l'objet d'une sémantique bien définie :

Une échéance absolue située dans le passé rend le fichier d'appel de politique (ou les politiques) obsolète(s), tout comme une échéance invalide ou malformée, que celle-ci soit relative ou bien absolue. Auquel cas, les agents utilisateurs DOIVENT agir comme si AUCUN fichier d'appel de politique (ou AUCUNE politique) n'était disponible. Cf. la section 2.4.7 L'absence d'un fichier d'appel de politique pour la procédure à suivre dans de tels cas ;
Une échéance relative inférieure à 86400 secondes (un jour) est censée valoir 86400 secondes ;
Lorsqu'un fichier d'appel de politique contient plusieurs éléments <EXPIRY>, c'est le premier qui détermine la durée de vie du fichier d'appel.

2.3.2.4 L'élément `POLICY-REF`

Un fichier d'appel de politique peut appeler plusieurs politiques P3P, en fournissant des informations sur chacune d'elles. L'élément <POLICY-REF> décrit les attributs d'une seule politique P3P. Les sous-éléments de l'élément <POLICY-REF> indiquent l'emplacement de la politique et définissent les régions de l'espace d'adresse URI (et les cookies) que chaque politique couvre.

<POLICY-REF>: contient les informations concernant une seule politique P3P.
about (attribut obligatoire): l'appel d'une adresse URI ([URI]), dont la partie identificateur de fragment indique le nom de la politique (donné dans son attribut name) et dont la partie adresse URI indique l'adresse URI où la politique réside, c'est-à-dire, un fichier de politique ou un fichier d'appel de politique (cf. la section 3.2). S'il s'agit de l'appel d'une adresse URI relative, on l'interprète par rapport à l'adresse URI du fichier d'appel de politique qui le contient.

[11]    policy-ref  =  `<POLICY-REF about="` URI-reference `">`
                       *include
                       *exclude
                       *cookie-include
                       *cookie-exclude
                       *method-element
                       *extension
                       `</POLICY-REF>`

Ici, la valeur URI-reference est définie selon RFC 2396 [URI].

2.3.2.5 Les éléments `INCLUDE` et `EXCLUDE`

Chaque élément <INCLUDE> ou <EXCLUDE> indique une adresse URI locale ou un jeu d'adresses URI locales. Il s'agira d'un jeu d'adresses URI si le caractère joker * apparaît dans le motif d'adresse URI. Ces éléments servent à désigner la partie du site Web couverte par la politique appelée par l'élément <POLICY-REF> englobant.

Lorsque les éléments <INCLUDE> et, en option, <EXCLUDE> sont présents dans un élément <POLICY-REF>, alors la politique indiquée par l'attribut about de l'élément <POLICY-REF> s'applique à toutes les adresses URI, sur l'hôte appelé, correspondant à l'adresse URI locale (ou aux adresses URI locales) filtrée(s) par l'élément (ou les éléments) <INCLUDE>, sauf les adresses filtrées par des éléments <EXCLUDE>.

Une politique référencée dans un fichier d'appel de politique ne peut s'appliquer qu'aux adresses URI sur l'hôte DNS (Domain Name System) qui l'appelle. Donc, par exemple, un fichier d'appel de politique trouvé à l'emplacement notoire de l'hôte www.example.com ne peut appliquer de politiques qu'aux ressources hébergées sur www.example.com. Toutefois, si l'hôte foo.example.com insère dans ses réponses une en-tête HTTP P3P qui appelle un fichier d'appel de politique sur bar.example.com, alors ce fichier s'appliquera aux ressources de foo.example.com (et non à celles de bar.example.com ou de www.example.com). Le même fichier d'appel de politique peut être appelé au travers des en-têtes HTTP P3P envoyées par plusieurs hôtes, auquel cas il pourra s'appliquer à chacun des hôtes qui l'appellent. Les éléments <INCLUDE> et <EXCLUDE> DOIVENT définir les motifs d'adresse URI relativement à la racine de l'hôte DNS auquel ils s'appliquent. Cette condition ne s'applique PAS à l'emplacement du fichier de politique P3P (c'est-à-dire, l'attribut about de l'élément <POLICY-REF>).

Si un élément <METHOD> (section 2.3.2.8) indique une ou plusieurs méthodes pour appeler une politique englobante, il s'ensuit que toutes les méthodes non mentionnées ne seront donc pas couvertes par cette politique. S'il s'agit du seul appel de politique pour un préfixe d'adresse URI donné, alors les agents utilisateurs DOIVENT supposer qu'il n'y a PAS de politique en vigueur pour toutes les méthodes NON mentionnées dans le fichier d'appel de politique. Quoique ça ne serve à rien, on peut légalement avoir un élément <METHOD> sans élément <INCLUDE> ni élément <COOKIE-INCLUDE>.

Tout aussi légal mais inutile, il peut y avoir un élément <EXCLUDE> sans élément <INCLUDE> ; auquel cas, les agents utilisateurs DOIVENT ignorer cet élément <EXCLUDE>.

Remarquez que le jeu d'adresse URI défini par les éléments <INCLUDE> et <EXCLUDE> n'inclut pas les cookies qui peuvent être installés ou lus au cours d'une requête vers l'une de ces adresses URI : on devra recourir aux éléments <COOKIE-INCLUDE> et <COOKIE-EXCLUDE> pour associer des politiques aux cookies.

[12]    include  =  "<INCLUDE>" relativeURI "</INCLUDE>"

[13]    exclude  =  "<EXCLUDE>" relativeURI "</EXCLUDE>"

Ici, la valeur relativeURI est définie selon RFC 2396 [URI], en ajoutant le caractère * qu'il faut traiter comme un caractère joker selon les définitions de la section 2.3.2.1.2.

2.3.2.6 L'élément `HINT`

Les conseils d'appel de politique permettent une optimisation des performances et on peut y recourir dans certaines conditions. Un site peut déclarer un appel de politique vers lui-même en recourant à l'emplacement notoire, à une en-tête de réponse P3P ou à une balise HTML/XHTML link. Le site PEUT en outre fournir des conseils pour d'autres appels de politique, comme ceux déclarés par d'autres sites.

Par exemple, une page HTML peut conseiller des appels de politique pour ses hyperliens, son contenu incorporé et ses adresses URI d'action. Les agents utilisateurs PEUVENT utiliser le mécanisme de conseil pour découvrir les fichiers d'appel de politique avant de demander les adresses URI affectées quand les appels de politique ne sont pas disponibles depuis l'emplacement notoire.

Les agents utilisateurs utilisant des conseils pour récupérer des politiques NE DOIVENT PAS appliquer ces politiques à un autre site que celui contenant le fichier d'appel de politique conseillé.

Tout fichier d'appel de politique PEUT contenir zéro ou plus conseils d'appel de politique. Chaque conseil est contenu dans un élément <HINT> avec deux attributs : scope et path.

L'attribut scope sert à indiquer un système d'adresse URI et une autorité à laquelle l'appel de politique peut s'appliquer. Si la composante autorité (cf. [URI]) est un composant de serveur (par exemple, un nom d'hôte ou une adresse IP), la partie hôte de l'autorité PEUT commencer par un caractère joker, comme défini dans la section 2.3.2.1.2. L'attribut scope NE DOIT PAS contenir de caractère joker à une autre position, il DOIT être codé en suivant les conventions de la section 2.3.2.1.2 et il NE DOIT PAS contenir un chemin d'accès, une requête ou un fragment de composante d'adresse URI. De surcroît, si l'autorité est un serveur, celle-ci ne DEVRAIT PAS contenir de partie userinfo.

Par exemple, les valeurs légales pour scope comprennent :

http://www.example.com
http://www.example.com:81
http://*.example.com
ftp://ftp.example.org

Les valeurs suivantes sont illégales pour l'attribut scope :

http://www.*.com : le caractère joker se trouve uniquement en tête ;
http://www.example.com/ : la barre oblique finale n'est pas admise ;
www.example.com ; le système d'adresse URI doit être déclaré ;
*://www.example.com : le système d'adresse URI ne peut pas contenir de caractère joker ;
http://www.example.com:* : le port ne peut contenir de caractère joker.

L'attribut path sert à la localisation du fichier d'appel de politique sur le site conseillé. C'est une adresse URI relative dont la base se compose du système d'adresse URI et de l'autorité filtrés dans l'attribut scope. L'attribut path NE DOIT PAS être une adresse URI absolue, de sorte que le fichier d'appel de politique soit toujours récupéré sur le site auquel il s'applique.

Exemple 2.3 :

<HINT scope="http://www.example.org" path="/mapolitique/p3.xml" />
<HINT scope="http://www.example.net:81" path="/w3c/prf.xml" />
<HINT scope="http://*.shop.example.com" path="/w3c/prf.xml" />

[14]    hint  =  `<HINT scope="` scheme ( `://` | `:/` ) authority `" path="` relativeURI `/>`

Ici, les valeurs scheme, authority et relativeURI sont définies dans RFC 2965 [STATE].

2.3.2.7 Les éléments `COOKIE-INCLUDE` et `COOKIE-EXCLUDE`

Les éléments <COOKIE-INCLUDE> et <COOKIE-EXCLUDE> servent à associer des politiques aux cookies (cf. [COOKIES] et [STATE]).

Une politique de cookie DOIT couvrir toutes les données (dans le champ de P3P) qui sont stockées dans ce cookie ou exploitées par celui-ci. En outre, toutes les données/intentions reliées par ce cookie DOIVENT être mentionnées dans la politique de cookie. Si ces données reliées sont collectées par HTTP, alors la politique, qui couvre cette requête GET/POST/quelle que soit la méthode, doit aussi couvrir cette collecte de données. Par exemple, quand l'entreprise CatalogueExemple demande à ses clients de remplir un formulaire, avec leur nom, leur adresse de facturation et de livraison, la politique P3P qui couvre la soumission du formulaire annoncera alors que CatalogueExemple collecte ces données et en expliquera la destination. Si l'entreprise CatalogueExemple place un cookie, dans le but de reconnaître ses clients et d'observer leurs comportements sur son site Web, elle aura une politique distincte pour ce cookie. Par contre, si ce cookie est aussi relié au nom, à l'adresse de facturation et de livraison de l'utilisateur, par exemple, parce que CatalogueExemple souhaite générer des pages de catalogue personnalisées en fonction de l'endroit où le client habite, alors cette utilisation des données doit également faire l'objet d'une divulgation dans la politique de cookie.

Pour les besoins de cette spécification, les mécanismes de gestion d'état utilisent soit l'en-tête SET-COOKIE, soit l'en-tête SET-COOKIE2, et l'espace de nommage du cookie est défini selon la valeur des attributs NAME, VALUE, Domain et Path, définis dans [COOKIES] et [STATE].

Chacun élément <COOKIE-INCLUDE> ou <COOKIE-EXCLUDE> peut servir à filtrer (d'une manière similaire aux éléments <INCLUDE> et <EXCLUDE>) les composants NAME, VALUE, Domain et Path d'un cookie, en exprimant les cookies couverts par la politique indiquée par l'attribut about lorsque les cookies sont installés par des ressources du site Web où le fichier de référence de politique réside :

<COOKIE-INCLUDE> (resp. <COOKIE-EXCLUDE>): inclut (resp. exclut) les cookies qui correspondent aux attributs name, value, domain et path
name: correspond à la partie NAME du cookie
value: correspond à la partie VALUE du cookie
domain: correspond à la partie Domain du cookie
path: correspond à la partie Path du cookie

Si l'attribut domain a pour valeur le caractère point ., le domaine ne correspondra qu'aux cookies qui omettent l'attribut Domain (et ont donc un domaine équivalant à l'hôte visé par la requête selon RFC 2965 ([STATE])).

Les cookies qui omettent l'attribut Path ont pour chemin d'accès implicite celui de l'adresse URI de la requête qui a généré la réponse Set-Cookie, selon RFC 2965 [STATE]. L'attribut path de l'élément <COOKIE-INCLUDE> devrait être évalué par rapport à cette valeur implicite lorsque le cookie omet l'attribut Path.

Tous les quatre attributs sont optionnels. Si un attribut est absent, l'élément <COOKIE-INCLUDE> (resp. <COOKIE-EXCLUDE>) correspondra donc aux cookies qui auront cet attribut, quelle que soit sa valeur.

Quand les éléments <COOKIE-INCLUDE> et, en option, <COOKIE-EXCLUDE> sont présents dans un élément <POLICY-REF>, la politique indiquée par l'attribut about de cet élément <POLICY-REF> s'applique à tous les cookies filtrés par un élément <COOKIE-INCLUDE> et ceux qui ne le sont pas par un élément <COOKIE-EXCLUDE>.

Les agents utilisateurs DOIVENT interpréter les éléments <COOKIE-INCLUDE> et <COOKIE-EXCLUDE> d'un fichier d'appel de politique pour déterminer quelle politique s'applique aux cookies installés ou lus sur l'hôte auquel le fichier d'appel s'applique. Bien que l'attribut domain d'un élément <COOKIE-INCLUDE> puisse représenter une correspondance plus large (par exemple, si l'attribut domain est omis, il filtre implicitement n'importe quelle valeur de domaine), les agents utilisateurs DOIVENT limiter leur application de la politique aux domaines susceptibles d'être utilisés légalement dans un cookie installé sur l'hôte auquel le fichier d'appel de politique s'applique. Par exemple, si abc.xyz.example.com déclare un appel de politique par <COOKIE-INCLUDE domain="*.xyz.*ple.com"/>, cette déclaration pourra correspondre aux domaines .abc.xyz.example.com et .xyz.example.com, mais pas à .example.com ou .xyz.sample.com.

Une politique P3P peut être associée à un cookie par l'hôte qui a installé le cookie, tout comme par l'un ou tous les hôtes sur lesquels ce cookie peut être lu. Un agent utilisateur PEUT récupérer une politique de cookie au moment de l'installation du cookie et l'appliquer plus tard lorsque le cookie en question est lu, par exemple, par les autres hôtes dans le domaine. Un agent utilisateur PEUT demander un fichier d'appel de politique à un hôte avant de lire un cookie pour cet hôte et, si le fichier d'appel contient un élément <COOKIE-INCLUDE> adéquat, une politique s'appliquera à ce cookie, même s'il n'a pas été installé par cet hôte. Tout hôte dont le cookie peut être lu DOIT être capable d'honorer toutes les politiques associées au cookie, que cet hôte déclare une politique pour ce cookie ou non. Il est donc nécessaire de coordonner les sites qui installent des cookies susceptibles d'être lus par les divers hôtes d'un domaine, afin de s'assurer que tous puissent suivre la politique déclarée. En outre, les sites devraient se montrer prudents en utilisant les caractères jokers et s'assurer qu'ils n'appliquent pas, par inadvertence, une politique à des cookies qui ne seraient pas concernés (y compris les cookies toujours actifs installés précédemment et ceux installés par les autres hôtes du domaine).

La politique appliquée à un cookie s'exerce tant qu'elle n'a pas expiré, même si le fichier d'appel de politique associé expire avant la politique (mais après que le cookie a été installé). Si la politique associée à un cookie est expirée, alors l'agent utilisateur DEVRAIT révaluer la politique de cookie avant d'envoyer le cookie. En outre, les agents utilisateurs DOIVENT uniquement se servir de politiques et de fichiers d'appel de politique non expirés pour l'évaluation de nouveaux événements Set-Cookie.

L'exemple 2.4 déclare que la politique désignée par /P3P/Politiques.xml#un s'applique à tous les cookies.

Exemple 2.4 :

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Politiques.xml#un">
       <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

L'exemple 2.5 déclare que la politique désignée par /P3P/Politiques.xml#un s'applique à tous les cookies, sauf ceux dont l'attribut name a la valeur "cookie-repoussant", l'attribut domain a la valeur ".example.com" et l'attribut path la valeur "/", et déclare, au contraire, que la politique /P3P/Politiques.xml#deux s'applique à tous les cookies dont les attributs name, domain et path ont justement ces dernières valeurs.

Exemple 2.5 :

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Politiques.xml#un">
       <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/>
       <COOKIE-EXCLUDE name="cookie-repoussant" value="*" domain=".example.com" path="/"/>
    </POLICY-REF>
    <POLICY-REF about="/P3P/Politiques.xml#deux">
       <COOKIE-INCLUDE name="cookie-repoussant" value="*" domain=".example.com" path="/"/>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

[15]    cookie-include  = "<COOKIE-INCLUDE"
                          [` name="` token `"`]   ; correspond à l'attribut NAME du cookie
                          [` value="` token `"`]  ; correspond à l'attribut VALUE du cookie
                          [` domain="` token `"`] ; correspond à l'attribut Domain du cookie
                          [` path="` token `"`]   ; correspond à l'attribut Path du cookie
                          "/>"

[16]    cookie-exclude  = "<COOKIE-EXCLUDE"
                          [` name="` token `"`]   ; correspond à l'attribut NAME du cookie
                          [` value="` token `"`]  ; correspond à l'attribut VALUE du cookie
                          [` domain="` token `"`] ; correspond à l'attribut Domain du cookie
                          [` path="` token `"`]   ; correspond à l'attribut Path du cookie
                          "/>"

Ici, les valeurs token, NAME, VALUE, Domain et Path sont définies selon RFC 2965 [STATE], en ajoutant le caractère * qu'il faut traiter comme un caractère joker, comme défini dans la section 2.3.2.1.2.

Remarquez que [STATE] définit des valeurs implicites pour les attributs Domain et Path des cookies : on devrait utiliser ces valeurs de comparaison lorsque ces attributs sont absents d'un cookie donné. Également, conformément à [STATE], si la valeur explicite d'un attribut Domain ne commence pas par un caractère point (.), alors l'agent utilisateur DOIT le lui ajouter en préfixe ; remarquez que chaque valeur d'attribut Path commence par le caractère /.

2.3.2.8 L'élément `METHOD`

Par défaut, un appel de politique s'applique aux adresses URI déclarées, quelle que soit la méthode employée pour accéder à la ressource. Toutefois, un site Web peut vouloir définir différentes politiques P3P en fonction de la méthode à appliquer à une ressource. Par exemple, un site peut vouloir collecter plus de données des utilisateurs si ceux-ci utilisent les méthodes PUT ou DELETE au lieu de la méthode GET.

L'élément <METHOD> d'un fichier d'appel de politique sert à déclarer que l'appel de politique englobant ne s'applique que si on utilise les méthodes indiquées pour accéder aux ressources demandées. On peut répéter l'élément <METHOD> pour indiquer plusieurs méthodes applicables. Si l'élément <METHOD> est absent d'un élément <POLICY-REF>, alors cet élément <POLICY-REF> couvrira les ressources indiquées quelles que soient les méthodes utilisées pour y accéder.

Ainsi, pour déclarer que la politique désignée par /P3P/Politiques.xml#un s'appliquera à toutes les ressources dont le chemin d'accès commence par /docs/ pour les méthodes GET et HEAD, tandis que la politique désignée par /P3P/Politiques.xml#deux s'appliquera aux méthodes PUT et DELETE, on écrirait l'appel de politique de la manière suivante :

Exemple 2.6 :

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Politiques.xml#un">
      <INCLUDE>/docs/*</INCLUDE>
      <METHOD>GET</METHOD>
      <METHOD>HEAD</METHOD>
    </POLICY-REF>
    <POLICY-REF about="/P3P/Politiques.xml#deux">
      <INCLUDE>/docs/*</INCLUDE>
      <METHOD>PUT</METHOD>
      <METHOD>DELETE</METHOD>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

Remarquez que le protocole HTTP impose un même comportement pour les requêtes GET et HEAD et il est donc inutile de définir des politiques P3P différentes pour ces méthodes. La syntaxe de l'élément <METHOD> est la suivante :

[17]    method-element  = `<METHOD>` Method `</METHOD>`

Ici, la valeur Method est définie dans la section 5.1.1 de [HTTP1.1].

Enfin, remarquez que l'élément <METHOD> est conçu pour une utilisation conjointe avec les éléments <INCLUDE> ou <COOKIE-INCLUDE>. Un élément <METHOD> n'appliquera jamais de lui-même un élément <POLICY-REF> à une adresse URI.

2.3.3 L'application d'une politique à une adresse URI

Un fichier d'appel de politique indique la politique qui s'applique à une certaine adresse URI. En d'autres termes, la politique indiquée décrit tous les effets issus de la résolution d'une adresse URI donnée (et, dans certains cas, conformément aux spécifications de l'élément <METHOD>).

La règle générale décrivant comment une politique P3P est supposée couvrir une adresse URI est la suivante : la politique appelée DOIT couvrir les actions que le logiciel client de l'utilisateur est censé entreprendre en réponse de la requête de cette adresse URI. Évidemment, la politique doit décrire toute la collecte des données effectuée par le site en conséquence du traitement de la requête de l'adresse URI. Si donc une adresse URI donnée est couverte pour des requêtes de type GET, alors la politique indiquée par le fichier d'appel de politique DOIT décrire entièrement la collecte des données effectuée par le site quand cette adresse URI est sollicitée. De même, si une adresse URI est couverte pour des requêtes de type POST, toute collecte de données survenant en résultat de la soumission d'un formulaire ou d'un autre contenu DOIT être décrite par la politique.

La notion d'actions que le logiciel client est censé entreprendre comprend l'installation des cookies côté client ou d'autres mécanismes de gestion d'état invoqués par la réponse. Si la requête d'une adresse URI renvoie un code exécutable, alors la politique P3P qui couvre cette adresse URI DOIT aussi couvrir les actions susceptibles de se produire à l'exécution de ce code. Ces actions couvertes sont toutes celles qui surviendraient sans une invocation explicite par l'utilisateur. Si une action explicite de l'utilisateur provoque la collecte de données, la politique P3P couvrant l'adresse URI de cette action révèlerait alors cette collecte.

Quelques exemples caractéristiques :

La ressource désignée par une adresse URI consiste en une page HTML contenant un formulaire et le contenu de ce formulaire est transmis à une deuxième adresse URI quand l'utilisateur clique un bouton Envoyer. La politique P3P qui couvre la deuxième adresse URI DOIT divulguer toutes les données collectées par le formulaire. La politique P3P qui couvre la première adresse URI (celle par laquelle le formulaire a été chargé) PEUT divulguer, ou NON, les données qui seront collectées par le formulaire ;
Une page HTML comprend un code JavaScript enregistrant la durée d'affichage de la page et les déplacements du pointeur de la souris sur tel objet de cette page ; au moment de quitter la page, ce script envoie ces renseignements au serveur d'où la page HTML provient. L'activité du script DOIT être couverte par la politique P3P de la page HTML. Le raisonnement présidant à cette obligation est le suivant : cette activité se déroule indépendamment de l'utilisateur et sans son consentement puisqu'elle survient automatiquement au chargement de la page ;
Une ressource renvoie un code exécutable pour un logiciel de messagerie électronique. Pour que l'utilisateur puisse se servir du logiciel de messagerie, il doit lancer un programme d'installation puis le logiciel de messagerie pour enfin utiliser ses fonctionnalités. La politique P3P couvrant l'adresse URI d'où le logiciel de messagerie a été téléchargé n'est pas tenue de déclarer les données susceptibles d'une collecte au cours de l'utilisation de ce logiciel. L'installation et le lancement du logiciel de messagerie ne font clairement pas partie de la session de navigation Web et ne sont donc pas couverts par cette spécification. On pourrait concevoir un protocole distinct qui permette aux applications téléchargées de présenter une politique P3P, mais cela n'est pas l'objet de cette spécification ;
Une page HTML contenant un formulaire permet d'appeler un code exécutable qui fournit une commande personnalisée côté client. À la soumission du formulaire, les données de la commande sont transmises vers un site. Dans ce cas, la politique associée à l'adresse URI de la page HTML n'est pas obligée de déclarer les données concernant l'adresse URI de la commande personnalisée. Par contre, l'adresse URI qui reçoit le contenu posté par le formulaire DOIT couvrir les données provenant de la commande personnalisée, tout comme elle devrait couvrir toutes les autres données collectées au cours du traitement du formulaire. C'est un comportement similaire à celui observé par les formulaires HTML quand ceux-ci n'utilisent que des commandes HTML standards : la commande en elle-même ne collecte aucune donnée et les données sont collectées lors du postage du formulaire. Remarquez que cet exemple suppose que la transmission du formulaire n'a lieu que si l'utilisateur presse effectivement un bouton de type submit ou apparenté. Si le formulaire était posté automatiquement (par exemple, par un code JavaScript dans la page), on aurait alors un exemple identique à l'exemple n°2, c'est-à-dire que les données collectées par le formulaire DOIVENT alors être décrites par la politique P3P couvrant le formulaire HTML ;
Les requêtes vers une adresse URI sont redirigées vers un tiers. Si le premier interlocuteur incorpore des données personnelles collectées précédemment dans la chaîne de requête ou dans ailleurs dans l'adresse URI de redirection, la politique de confidentialité de l'adresse URI de ce premier interlocuteur DOIT décrire les types des données transmises et inclure le tiers comme destinataire.

2.3.4 Les formulaires et les mécanismes apparentés

Les formulaires méritent une attention particulière, dans la mesure où ils sont souvent reliés à des scripts CGI ou à d'autres applications côté serveur par leur adresse URI d'action (l'action d'une adresse URI est l'adresse URI indiquée par l'attribut action de l'élément HTML FORM, comme défini dans la section 17.3 de [HTML]). Ces adresses URI d'action sont très souvent couvertes par une politique différente de celle du formulaire lui-même.

Si un agent utilisateur ne trouve pas de règle <include> correspondant à une adresse URI donnée dans le fichier d'appel de politique, appelé depuis la page, il DEVRAIT en déduire qu'aucune politique n'est active. Dans ce cas, les agents utilisateurs DEVRAIENT examiner l'emplacement notoire sur l'hôte de l'adresse URI d'action pour essayer de trouver un fichier d'appel de politique couvrant cette adresse URI d'action. Si cette démarche ne révèle aucune politique P3P couvrant l'adresse URI d'action, alors l'agent utilisateur PEUT essayer de récupérer le fichier d'appel de politique en utilisant le mécanisme des éléments <HINT> sur l'adresse URI d'action et/ou en émettant une requête HEAD vers l'adresse URI d'action, avant la soumission effective des données, pour rechercher la politique active. Les services DEVRAIENT s'assurer que les applications côté serveur puissent répondre correctement à ces requêtes HEAD et renvoyer le lien d'appel de politique correspondant dans les en-têtes. Au cas où l'application sous-jacente ne reconnaîtrait pas la requête HEAD et qu'aucune politique ne serait prédéclarée pour l'adresse URI d'action en question, l'agent utilisateur DOIT en déduire qu'aucune politique n'est active et il DEVRAIT avertir l'utilisateur de la situation ou prendre les mesures appropriées conformément aux préférences de l'utilisateur.

Remarquez que les services peuvent utiliser l'élément <METHOD> pour déclarer des politiques sur les applications côté serveur qui ne couvrent qu'un sous-ensemble des méthodes reconnues, par exemple, POST ou GET. Dans ce cas, on peut accepter de l'application en question qu'elle ne reconnaisse que les méthodes indiquées dans le fichier d'appel de politique (par exemple, il n'est pas nécessaire de reconnaître les requêtes PUT). Les agents utilisateurs NE DEVRAIENT PAS essayer de faire une requête HEAD vers une adresse URI d'action si les méthodes concernées, indiquées par l'attribut method du formulaire, ont été correctement prédéclarées dans le fichier d'appel de politique de la page.

Dans certains cas, la même adresse URI d'action collectera des données différentes en fonction d'une sélection effectuée dans le formulaire. Par exemple, un service peut proposer à la fois une recherche sur des personnes (par leur nom et/ou leur adresse électronique) et sur des images (arbitraires). En jouant sur une combinaison de boutons radio sur le formulaire, une seule application côté serveur située à une seule et même adresse URI d'action gèrera les deux cas et collectera les renseignements nécessaires pour une recherche. Si un service souhaite prédéclarer les pratiques de collecte de données de l'application côté serveur, il PEUT toutes les déclarer dans un seul fichier d'appel de politique (en utilisant un élément <INCLUDE> correspondant à l'adresse URI d'action). Auquel cas, les agents utilisateurs DOIVENT en déduire que les éléments de données sont tous collectés à chaque fois. La commodité de cette solution tient à l'utilisation d'une politique unique mais elle reflètera peut-être mal le fait que seule une partie des éléments de données est collectée à un moment donné. Les services DEVRAIENT s'assurer par une requête HEAD simple vers l'adresse URI d'action (c'est-à-dire, sans argument et notamment sans la valeur du bouton radio sélectionné) qu'elle renverra une politique couvrant tous les cas.

Remarquez que si la gestion d'un formulaire a lieu au travers d'une utilisation de la méthode GET, alors l'adresse URI d'action reflète le choix des éléments de formulaire sélectionnés par l'utilisateur. Dans certains cas, il sera possible d'utiliser la syntaxe avec caractère joker, admise dans les fichiers d'appel de politique, pour indiquer différentes politiques pour des utilisations différentes de la même adresse URI de gestionnaire d'action du formulaire. C'est pourquoi les agents utilisateurs DOIVENT inclure la partie chaîne de requête des adresses URI lors des comparaisons avec les éléments <INCLUDE> et <EXCLUDE> des fichiers d'appel de politique.

2.4 Les autres conditions requises

2.4.1 La non-ambiguïté

Les agents utilisateurs doivent être capables de déterminer sans ambiguïté quelle politique s'applique à une adresse URI donnée. Les sites DEVRAIENT donc éviter de déclarer plus d'une politique non expirée par adresse URI donnée. Dans certains cas rares, les sites PEUVENT déclarer plusieurs politiques non expirées par adresse URI, par exemple, au cours d'une période de transition où le site change de politique. Dans ce cas, le site sera probablement incapable de déterminer avec certitude quelle politique un utilisateur donné aura vue, et il DOIT alors honorer toutes les politiques (il en est de même pour les politiques compactes, cf. la section 4.1 et la section 4.6). Les sites DOIVENT se montrer prudents dans leurs pratiques quand ils déclarent plusieurs politiques pour une adresse URI donnée et s'assurer de leur capacité effective à honorer simultanément toutes les politiques.

Si un fichier d'appel de politique à l'emplacement notoire déclare une politique non expirée pour une adresse URI donnée, alors c'est elle qui s'appliquera indépendamment d'éventuels fichiers d'appel contradictoires appelés au travers d'en-têtes HTTP ou de balises HTML/XHTML link.

Si une en-tête de réponse HTTP inclut des appels à plusieurs fichiers d'appel de politique, alors les agents utilisateurs P3P DOIVENT ignorer tous les appels suivant le premier.

Si un fichier HTML (ou XHTML) inclut des balises HTML (ou XHTML) link appelant plusieurs fichiers d'appel de politique, alors les agents utilisateurs DOIVENT ignorer tous les appels suivant le premier.

Si un agent utilisateur découvre plusieurs politiques P3P non expirées pour une adresse URI donnée (par exemple, parce qu'une page a en même temps une en-tête P3P et une balise link appelant des fichiers d'appel de politique différents, ou parce que les en-têtes P3P pour deux pages du site appellent des fichiers d'appel différents qui déclarent des politiques différentes pour une même adresse URI), alors l'agent utilisateur PEUT en déduire que n'importe quelle politique (ou toutes) s'applique car le site DOIT toutes les honorer.

2.4.2 Les diverses langues

Le serveur peut offrir des versions en plusieurs langues (traductions) de la même politique en recourant à l'en-tête HTTP Content-Language pour préciser la langue particulière utilisée par la politique. C'est une caractéristique utile qui permet de présenter les champs lisibles par un humain, tels que la personne et les implications, en différentes langues. Ce même mécanisme peut servir à fournir des versions en différentes langues des schémas de données. Les serveurs DEVRAIENT renvoyer une politique localisée en réponse à une requête HTTP ayant une en-tête Accept-Language lorsqu'une politique correspondant aux préférences de langue indiquées est disponible.

Dès lors qu'on utilise une en-tête Content-Language pour distinguer des politiques offertes en plusieurs langues à une même adresse URI, la teneur de ces politiques DOIT être la même dans chacune des langues. Deux politiques (ou deux schémas de données) sont considérées comme identiques si :

Tous les éléments de protocole formels (ceux qui ne sont pas en langage naturel) sont sémantiquement identiques (par exemple, l'ordre des attributs tout comme la présence, ou l'absence, d'une valeur par défaut ne sont pas important mais les valeurs des attributs le sont) ;
Tous les éléments de protocole en langage naturel correspondent un-à-un, et quelle que soit la correspondance, l'une est la traduction exacte des autres.

En raison de l'utilisation du mécanisme Accept-Language, les développeurs devraient noter que les agents utilisateurs sont susceptibles de voir des traductions différentes d'une politique ou d'un fichier d'appel de politique pour la même requête Accept-Language envoyée si une nouvelle traduction d'une politique ou d'un schéma de données est ajoutée.

Enfin, on peut aussi inclure directement les déclarations de langue dans les fichiers XML P3P : les éléments <POLICY>, <POLICIES>, <META> et <DATASCHEMA> PEUVENT avoir un attribut xml:lang pour indiquer la langue de tous les champs lisibles par un humain qui y sont contenus (la définition normative de xml:lang se trouve dans la section 2.12 de [XML]).

[18]    xml-lang  =  ` xml:lang="` language `"`

Ici, la valeur language est un identificateur de langue, comme défini dans [LANG].

2.4.3 La zone sûre

Le protocole P3P définit un ensemble particulier de pratiques de zone sûre (N.D.T. safe zone) que tous les agents utilisateurs et les services mettant en œuvre P3P DEVRAIENT observer pour les échanges intervenant dans la récupération d'une politique ou d'un fichier d'appel de politique P3P. Ces pratiques de zone sûre DEVRAIENT notamment couvrir les requêtes vers l'emplacement notoire pour les fichiers d'appel de politique. Les échanges couverts par ces pratiques DEVRAIENT se résumer à une collecte minimale de données ; aucune de ces données ne devrait être identifiable en cours d'utilisation.

Pour établir cette zone sûre, les agents utilisateurs P3P DEVRAIENT supprimer la transmission des données qui ne sont pas indispensables à la recherche de la politique d'un site tant que celle-ci n'aura pas été récupérée. Aussi les pratiques de zone sûre pour les agents utilisateurs comprennent les contraintes suivantes :

Les agents utilisateurs NE DEVRAIENT PAS envoyer une en-tête HTTP Referer dans la zone sûre ;
Les agents utilisateurs NE DEVRAIENT PAS accepter les cookies de requêtes issues de la zone sûre ;
Les agents utilisateurs PEUVENT également limiter l'envoi de renseignements les concernant ou de cookies déjà acceptés dans une session précédente lors de requêtes dans la zone sûre ;
Les développeurs d'agents utilisateurs doivent garder à l'esprit que l'utilisation de l'en-tête HTTP Accept-Language dans la zone sûre constitue un risque pour la confidentialité. Un bon usage de l'en-tête Accept-Language permettra, le cas échéant, de récupérer une politique P3P dans la langue choisie par l'utilisateur mais certaines informations sur son identité pourront être révélées. Les agent utilisateurs PEUVENT laisser aux utilisateurs le soin de décider du moment où ce type d'en-tête doit être envoyé.

Les pratiques de zone sûre pour les serveurs comprennent les contraintes suivantes :

Les serveurs NE DEVRAIENT PAS imposer en réception d'en-têtes HTTP Referer, de cookies, de renseignements concernant l'agent utilisateur ou d'autres informations non indispensables pour le service des requêtes dans la zone sûre ;
Si l'agent utilisateur supprime l'en-tête HTTP Accept-Language pour une opération dans la zone sûre, le serveur est alors libre de choisir l'une des traductions disponibles ;
Si les échanges ont lieu au travers d'une liaison sécurisée, tel que SSL, alors le serveur NE DEVRAIT PAS demander un certificat d'identité à l'agent utilisateur pour les requêtes dans la zone sûre ;
En outre, les serveurs NE DEVRAIENT PAS utiliser de manière identifiable les renseignements collectés pour le service d'une requête dans la zone sûre.

Remarquez que les contraintes de zone sûre n'interdisent pas aux sites de conserver les renseignements identifiables mais seulement qu'ils NE DEVRAIENT PAS utiliser de manière identifiable ces renseignements lors du service d'un fichier de politique ou d'appel de politique. Par exemple, la recherche de la source d'une attaque en déni de service peut être une raison légitime d'utiliser ces renseignements.

2.4.4 Le traitement des politiques et des fichiers d'appel de politique par les agents utilisateurs

Les agents utilisateurs P3P DOIVENT interpréter (ou agir sur) les politiques P3P et les fichiers d'appel de politique seulement si ce sont des fichiers XML bien formés.

Les agents utilisateurs P3P DEVRAIENT interpréter (ou agir sur) les politiques P3P et les fichiers d'appel de politique seulement s'ils sont conformes au schéma XML fourni dans l'Annexe 4 et ils NE DEVRAIENT PAS tenir compte d'une partie de politique ou de fichier d'appel non conforme à ce schéma XML.

Les agents utilisateurs NE DOIVENT PAS modifier localement une politique P3P ou un fichier d'appel de politique pour les rendre conformes au schéma XML.

2.4.5 La sûreté du transport des politiques

Les politiques P3P et les fichiers d'appel de politique NE DEVRAIENT PAS contenir de renseignements sensibles. Il n'existe aucune contrainte de sécurité supplémentaire, pour le transport d'un appel vers une politique P3P, hormi les contraintes du document auquel cet appel est associé ; donc, si un document HTML est servi normalement au cours d'une session non cryptée, le protocole P3P n'impose pas ni ne recommande qu'il le soit dans une session cryptée lorsqu'un appel de politique P3P se trouve dans le document.

2.4.6 Les mises à jour des politiques

Lorsqu'un site Web change de politique P3P, remarquez que la politique antérieure s'applique aux données collectées quand celle-ci était active. Le site a la responsabilité de conserver un historique des politiques P3P et des fichiers d'appel de politique, avec les dates où ils étaient en vigueur, et d'appliquer ces politiques de manière adéquate.

Si un site souhaite appliquer une nouvelle politique P3P sur des données collectées précédemment, il DOIT en faire part aux utilisateurs et leur laisser la possibilité d'accepter la nouvelle politique, conformément aux lois en vigueur, aux directives de l'industrie ou à d'autres accords concernant la vie privée passés par le site.

2.4.7 L'absence d'un fichier d'appel de politique

Si aucun fichier d'appel de politique n'est disponible pour un site donné, les agents utilisateurs DOIVENT supposer qu'il en existe un (vide) à l'emplacement notoire, ayant une durée de vie de 24 heures ; si l'utilisateur retourne sur le site après ce délai, l'agent utilisateur DOIT donc essayer de récupérer à nouveau un fichier d'appel à l'emplacement notoire. Les agents utilisateurs PEUVENT vérifier l'emplacement notoire plus souvent ou à l'occasion de certains événements, par exemple, quand l'utilisateur effectue un rafraîchissement du cache du navigateur. Les sites PEUVENT placer, à l'emplacement notoire, un fichier d'appel de politique faisant état d'aucune politique mais indiquant une date d'expiration, de sorte que les agents utilisateurs sachent qu'il n'est pas nécessaire de vérifier le site toutes les 24 heures.

2.4.8 L'évaluation asynchrone

Les agents utilisateurs PEUVENT récupérer et évaluer des politiques P3P de manière asynchrone. C'est-à-dire que les politiques P3P ne seront pas forcément récupérées et évaluées préalablement à d'autres transactions HTTP. Ce comportement peut dépendre des préférences de l'utilisateur et du type de la requête effectuée. Tant qu'une politique n'est pas évaluée, l'agent utilisateur DEVRAIT agir comme si le site n'avait pas de politique de confidentialité. Une fois celle-ci évaluée, l'agent utilisateur DEVRAIT appliquer les préférences de l'utilisateur. Pour favoriser un comportement déterministe, l'agent utilisateur DEVRAIT retarder l'application de la politique juqu'à un certain point. Par exemple, un navigateur Web peut appliquer les préférences de l'utilisateur juste après avoir terminé une navigation ou bien au moment de confirmer la soumission d'un formulaire.

2.5 Exemples de scénarios

Pour aider au déploiement du protocole P3P sur les sites, on décrit plusieurs scénarios d'utilisation de P3P sur des sites.

Scénario n°1 : Le site Web basique.example.com utilise diverses images, toutes hébergées sur le site. Il contient également quelques formulaires qui renvoient tous au site. Il peut déclarer une seule politique P3P pour le site entier (ou, si des politiques distinctes s'appliquent à des parties différentes du site, déclarer plusieurs politiques P3P). Puisque toutes les images et les adresses URI d'action des formulaires se trouvent dans des répertoires couverts par la politique P3P du site, les agents utilisateurs reconnaîtront automatiquement la couverture des images et des formulaires par la politique du site.

Scénario n°2 : Le site Web bourdonnant.example.com utilise, pour héberger ses images, un réseau de diffusion de contenu appelé rdc.example.com afin de répartir la charge entre ses serveurs. Ainsi, toutes les images du site ont des adresse URI dans rdc.example.com. Dans cette configuration, l'hôte Rdc qui se comporte comme un agent pour l'hôte Bourdonnant ne collecte pas d'autres données que des données d'accès. Ces données d'accès ne sont utilisées que pour le site Web et l'administration du système dans le cadre de la fourniture de services contractée par Bourdonnant. La politique de confidentialité de Bourdonnant s'applique aux images hébergées par Rdc, c'est pourquoi Bourdonnant utilise un élément <HINT> dans son fichier d'appel de politique pour désigner un fichier d'appel de politique adéquat sur Rdc, indiquant que les images sont couvertes par une politique P3P de example.com.

Scénario n°3 : Le site Web bourdonnant.example.com a également passé un contrat avec une entreprise de publicité, nommée cliquepub.example.com, pour la fourniture de bandeaux de publicité sur son site. Le contrat autorise Cliquepub à placer des cookies afin de contrôler la présentation, pas plus de trois fois, d'un bandeau de publicité au visiteur. Cliquepub collecte des statistiques sur le nombre de visiteurs voyant chaque publicité et établit un rapport destiné aux sociétés dont les produits font l'objet des publicités. Toutefois, ces rapports ne révèlent aucun renseignement personnel sur le visiteur. Comme pour le scénario n°2, la politique de confidentialité de Bourdonnant s'applique à ces publicités hébergées par Cliquepub, et Bourdonnant utilise ainsi un élément <HINT>, dans son fichier d'appel de politique, pour désigner un fichier d'appel de politique adéquat sur Cliquepub, indiqnant que la politique P3P de Bourdonnant s'applique aux contenus servis par cliquepub.example.com. Les sociétés dont les produits font l'objet des publicités n'ont pas besoin d'être mentionnées dans la politique de confidentialité de Bourdonnant parce qu'elles reçoivent seulement des données agrégées.

Scénario n°4 : En outre, le site Web bourdonnant.example.com a passé un contrat avec discussion.example.com afin d'héberger un espace de discussion pour ses utilisateurs. Quand les utilisateurs entrent dans l'espace de discussion, ils quittent en réalité le site Bourdonnant. Toutefois, l'espace de discussion affiche le logo de Bourdonnant et l'espace est couvert par la politique de confidentialité de Bourdonnant. Dans ce cas, Discussion se comporte comme un agent pour Bourdonnant mais, à la différence des exemples précédents, son contenu n'est pas incorporé dans le site de Bourdonnant. Bourdonnant peut utiliser un élément <HINT>, dans son fichier de référence de politique, pour désigner un fichier d'appel de politique adéquat sur Discussion, lequel indique que l'espace de discussion de Discussion est couvert par la politique de confidentialité de Bourdonnant, facilitant de ce fait une transition en douceur vers l'espace de discussion.

Scénario n°5 : Le site Web metarecherche.example.com contient un formulaire qui permet aux utilisateurs de taper une requête de recherche, celle-ci ayant lieu sur le moteur de recherche de leur choix situé sur un autre site. Quand un utilisateur clique le bouton d'envoi, la requête de recherche est en réalité directement soumise à ces moteurs de recherche, l'adresse URI d'action n'étant pas situé sur recherche.example.com mais plutôt sur le moteur de recherche sélectionné par l'utilisateur. Metarecherche peut déclarer les politiques de confidentialité de ces moteurs de recherche en utilisant un élément <HINT> pour désigner le fichier d'appel de politique qui leur correspond. Lorsque l'utilisateur clique sur le bouton d'envoi, son agent utilisateur peut donc vérifier sa politique de confidentialité avant de poster des données. Pour que ce mécanisme de choix fonctionne, Metarecherche peut en réalité offrir un formulaire dont l'adresse URI d'action mène sur son propre site, en effectuant une redirection vers le moteur de recherche concerné. Dans ce cas, l'agent utilisateur devrait vérifier la politique de confidentialité du moteur de recherche à la réception de la réponse de redirection.

Scénario n°6 : Le site Web metarecherche.example.com contient aussi un formulaire qui permet aux utilisateurs de taper une requête de recherche qui sera soumise à dix moteurs de recherche en même temps. Metarecherche soumet les requêtes, reçoit en retour les résultats obtenus par chaque moteur de recherche, supprime les doublons et présente un résultat final à l'utilisateur. Dans ce cas, l'utilisateur n'interagit qu'avec Metarecherche. La seule politique P3P impliquée est donc celle qui couvre le site Web de Metarecherche. Toutefois, le site Metarecherche doit annoncer qu'il partage les requêtes de recherche de l'utilisateur avec des tiers (les sites des moteurs de recherche), à moins que Metarecherche ait contracté avec ces moteurs de recherche, auquel cas ils agissent comme des agents pour Metarecherche.

Scénario n°7 : Le site Web metarecherche.example.com comporte également des bandeaux de publicité fournis par une société nommée reseaupub.example.com. Reseaupub utilise des cookies pour établir des profils d'utilisateur partagés entre de nombreux sites différents, afin de leur proposer des bandeaux de publicité mieux adaptés à leurs centres d'intérêt. Puisque les données concernant les sites visités par les utilisateurs ne se limitent pas seulement à servir des publicités sur le site Web de Metarecherche, on ne peut pas considérer Reseaupub comme un agent dans ce contexte. Reseaupub doit créer sa propre politique P3P et utiliser son propre fichier de référence de politique pour indiquer à quel contenu elle s'applique. En outre, Metarecherche peut, en option, utiliser un élément <HINT>, dans son fichier d'appel de politique, pour indiquer que le fichier d'appel de politique P3P de Reseaupub s'applique aux publicités. Metarecherche ne devrait le faire que si Reseaupub a indiqué quelle politique P3P s'applique aux publicités et a accepté de notifier Metarecherche lorsque l'appel de politique nécessitera un changement.

Scénario n°8: Le site Web bourdonnant.example.com utilise des cookies partout dans le site. Il annonce une politique de cookie, distincte de sa politique P3P générale, qui couvre ces cookies. Il utilise un élément <COOKIE-INCLUDE>, dans son fichier d'appel de politique, pour déclarer la politique appropriée à ceux-ci. Afin d'optimiser les performances, il fournit également une politique compacte, au moyen d'une en-tête P3P qui inclut celle-ci, à chaque fois où un cookie est installé.

Scénario n°9: Le site Web config.example.com propose des services d'optimisation pour tous types de contenu Web en fonction du matériel et de la configuration Internet de chaque utilisateur. Les utilisateurs se rendent sur le site Web de Config et répondent à diverses questions concernant leur système, leur écran et leur connexion Internet. Config code et range ces réponses dans un cookie. Par la suite, lorsque l'utilisateur visite le site de Bourdonnant, qui a passé des accords avec Config, et dès lors que son navigateur aura demandé un contenu optimisable (certaines images ou fichiers audio, etc.), Bourdonnant redirigera l'utilisateur vers Config, qui lira le cookie de l'utilisateur et délivrera le contenu adéquat. Dans ce cas, le site Config devrait déclarer une politique de confidentialité décrivant les types des données collectées et stockées dans ses cookies et comment celles-ci sont exploitées. Il devrait utiliser un élément <COOKIE-INCLUDE>, dans son fichier d'appel de politique, pour déclarer la politique de cookies. Il appellera éventuellement la politique P3P de Bourdonnant pour les fichiers d'images ou audio effectivement délivrés, en cours d'opération un peu comme Rdc le fait dans le scénario n°2. Le site Bourdonnant utilisera aussi probablement des éléments <HINT>, dans son fichier d'appel de politique, pour appeler la politique pour le contenu délivré par Config.

3. La syntaxe et la sémantique des politiques

Les politiques P3P sont codées en XML avec des espaces de nommage (cf. [XML] et [XML-Name]). Un codage possible utilisant le modèle de données RDF ([RDF]) est fourni dans [P3P-RDF].

La section 3.1 commence par un exemple de politique de confidentialité en langue naturelle et la politique P3P correspondante. Les politiques P3P contiennent des assertions générales, qui s'appliquent à la politique entière, ainsi que des assertions particulières, appelées déclarations, qui s'appliquent seulement à la manipulation de types de données particuliers, appelées appels de données. La section 3.2 décrit l'élément <POLICY> et les assertions au niveau de la politique. La section 3.3 décrit les déclarations et les appels de données.

3.1 Exemples de politiques

3.1.1 Les politiques en langage naturel

Voici deux exemples de politique de confidentialité en langage naturel avant leur transcription dans une politique P3P. Les deux politiques concernent la société fictive CatalogueExemple qui a différentes politiques, selon que le visiteur navigue seulement dans le site ou que le visiteur achète effectivement des produits. L'exemple 3.1 se présente à la fois en français et dans une description plus formelle utilisant les noms d'éléments et d'attributs P3P.

Exemple 3.1 : Politique de confidentialité de CatalogueExemple pour les navigateurs

Chez CatalogueExemple, nous sommes attachés au respect de votre vie privée. Lorsque vous venez chez nous pour chercher un article, les renseignements recueillis à cette occasion servent uniquement à améliorer le site et ils ne sont pas stockés avec des informations permettant de vous identifier.
La société CatalogueExemple participe au programme SceauConfidentielExemple. Le programme SceauConfidentielExemple garantit le respect de votre vie privée en soumettant les sites Web affiliés à des règles de confidentialité strictes et en certifiant par des audits indépendants que les pratiques vis-à-vis des renseignements recueillis sont respectées.
Veuillez adresser les questions concernant cette déclaration à :

CatalogueExemple

4000 Lincoln Ave.

Birmingham, MI 48009 USA

email : catalogue@example.com

Telephone 248-EXAMPLE (248-392-6753)

Si nous n'avons pas répondu à vos demandes ou alors d'une manière non satisfaisante, vous pouvez contacter SceauConfidentielExemple à http://www.sceauconfidentiel.example.org. La société CatalogueExemple corrigera toutes les erreurs ou les actions erronnées qui auraient pu survenir conformément à la politique de confidentialité.
Les renseignements que nous collectons et pourquoi nous les collectons :
Au cours de votre navigation sur notre site, nous collectons :

des renseignements de base à propos de votre configuration et votre connexion afin de nous assurer que vous recevez les informations voulues et pour des raisons de sécurité ;
des informations globales sur les pages demandées ou visitées par nos clients afin d'améliorer le fonctionnement de notre site.

Rétention des données :
Les informations de navigation que nous collectons sont purgées toutes les deux semaines.

Voici maintenant l'exemple 3.1 dans une description plus formelle utilisant les noms d'éléments et d'attributs P3P [la section de la spécification utilisée est citée entre crochets pour en faciliter la référence] :

Adresse URI de divulgation : http://www.catalogue.example.com/confidentialite_navigation.html
[3.2.2 Policy]
Entité : CatalogueExemple
4000 Lincoln Ave.
Birmingham, MI 48009
USA
catalogue@example.com
+1 (248) 392-6753
[3.2.4 L'élément ENTITY]
Accès aux informations identifiables : aucun
[3.2.5 L'élément ACCESS]
Litiges :
resolution-type: independent
service: http://www.sceauconfidentiel.example.org
description: SceauConfidentielExemple
[3.2.6 L'élément DISPUTES]
Résolutions : nous corrigerons tous les torts de notre fait.
[3.2.7 L'élément REMEDIES]
Nous collectons :
dynamic.clickstream
dynamic.http
[4.5 Le schéma de données de base]
Utilisation : site Web et administration du système, recherche et développement
[3.3.4 L'élément PURPOSE]
Destinataires : seulement nous-mêmes et nos agents
[3.3.5 L'élément RECIPIENT]
Rétention : aussi longtemps que nécessaire pour les utilisations déclarées
[3.3.6 L'élément RETENTION]
(Remarquez également que la politique de confidentialité du site lisible par un humain DOIT mentionner la purge des données toutes les deux semaines ou bien donner un lien vers cette information).

Exemple 3.2 : Politique de confidentialité de CatalogueExemple pour les acheteurs

Chez CatalogueExemple, nous sommes attachés au respect de votre vie privée. Nous ne partagerons en aucun cas votre numéro de carte de crédit ou tout autre renseignement financier avec un tiers. Avec votre accord uniquement, nous pourrons vous proposer de partager ces renseignements avec des partenaires commerciaux soigneusement sélectionnés susceptibles de correspondre aux préférences que vous avez exprimées ou bien à vos achats passés. Plus nous saurons ce que vous aimez et n'aimez pas, mieux nous pourrons adapter nos offres à vos besoins.

La société CatalogueExemple participe au programme SceauConfidentielExemple. Le programme SceauConfidentielExemple garantit le respect de votre vie privée en soumettant les sites Web affiliés à des règles de confidentialité strictes et en certifiant par des audits indépendants que les pratiques vis-à-vis des renseignements recueillis sont respectées.

Veuillez adresser les questions concernant cette déclaration à :

CatalogueExemple

4000 Lincoln Ave.

Birmingham, MI 48009 USA

email: catalogue@example.com

Telephone +1 248-EXAMPLE (+1 248-392-6753)

Si nous n'avons pas répondu à vos demandes ou alors d'une manière non satisfaisante, vous pouvez contacter SceauConfidentielExemple à http://www.sceauconfidentiel.example.org. La société CatalogueExemple corrigera toutes les erreurs ou les actions erronnées qui auraient pu survenir conformément à la politique de confidentialité.
Au cours de votre navigation sur notre site, nous collectons :

des renseignements de base à propos de votre configuration et votre connexion, afin de nous assurer que vous recevez les informations voulues et pour des raisons de sécurité ;
des informations globales sur les pages demandées ou visitées par nos clients afin d'améliorer le fonctionnement de notre site.

Si vous achetez un article, nous vous demanderons des renseignements supplémentaires dont :

vos nom et adresse, afin que nous puissions vous livrer votre achat ou vous contacter ultérieurement ;
votre adresse électronique et votre numéro de téléphone, afin que nous puissions vous contacter ;
un identifiant et un mot de passe, qui seront utilisés ensuite à tout moment pour mettre à jour les informations vous concernant ;
des renseignements financiers, afin de terminer votre achat (vous pouvez choisir de les stocker pour un usage futur) ;
vous pouvez, en option, entrer d'autres renseignements démographiques, qui serviront à personnaliser nos services à l'avenir.

Sur cette page, vous pourrez également opter pour recevoir des messages électroniques, des appels téléphoniques ou des annonces commerciales de CatalogueExemple, ou bien de partenaires commerciaux soigneusement sélectionnés ayant des pratiques de confidentialité similaires. Si vous optez pour recevoir ces offres, veuillez juste cocher la case appropriée. Vous pouvez vous désinscrire à tout moment en modifiant simplement vos préférences.
Modification et mise à jour des informations personnelles
Les clients peuvent modifier toutes les informations sur leur compte personnel en se rendant dans la section préférences de CatalogueExemple à http://catalogue.example.com/preferences.html. Vous pouvez modifier votre adresse, votre numéro de téléphone, votre adresse électronique, votre mot de passe ainsi que vos préférences de confidentialité.
Cookies
CatalogueExemple emploie des cookies uniquement pour déterminer si vous êtes déjà client chez nous et, le cas échéant, pour personnaliser nos services en fonction de vos habitudes de navigation et d'achat. Nous ne stockons aucun renseignement personnel dans les cookies ni ne partageons ni vendons quelques informations que ce soient à des tiers ou affiliés.
Rétention des données
Nous conservons les renseignements vous concernant et ceux concernant vos achats aussi longtemps que vous restez notre client. Si vous ne passez aucune commande dans une période d'un an, nous supprimerons ces informations de nos bases de données.

3.1.2 Le codage XML des politiques

Les fragments [XML] suivants effectuent une capture des données exprimées dans les deux exemples ci-dessus. Les politiques P3P sont des déclarations exprimées correctement comme XML bien formé. La syntaxe des politiques sera abordée plus en détails dans la section qui suit.

Le codage XML de l'exemple 3.1 :

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY name="pourNavigateur" 
     discuri="http://www.catalogue.example.com/confidentialite_navigation.html"
     xml:lang="en">
  <ENTITY>
   <DATA-GROUP>
    <DATA ref="#business.name">CatalogueExemple</DATA>
    <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
    <DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
    <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
    <DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
    <DATA ref="#business.contact-info.postal.country">USA</DATA>
    <DATA ref="#business.contact-info.online.email">catalogue@example.com</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
   </DATA-GROUP>
  </ENTITY>
  <ACCESS><nonident/></ACCESS>
  <DISPUTES-GROUP>
   <DISPUTES resolution-type="independent"
     service="http://www.sceauconfidentiel.example.org"
     short-description="sceauconfidentiel.example.org">
    <IMG src="http://www.sceauconfidentiel.example.org/Logo.gif" alt="Le logo de SceauConfidentiel"/>
    <REMEDIES><correct/></REMEDIES>
   </DISPUTES>
  </DISPUTES-GROUP>
  <STATEMENT>
   <PURPOSE><admin/><develop/></PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION>
   			<!-- Remarquez également que la politique
   			de confidentialité du site lisible
			par un humain DOIT mentionner la purge
			des données toutes les deux semaines,
			ou fournir un lien vers cette information. -->
   <DATA-GROUP>
    <DATA ref="#dynamic.clickstream"/>
    <DATA ref="#dynamic.http"/>
   </DATA-GROUP>
  </STATEMENT>
 </POLICY>
</POLICIES>

Codage XML de l'exemple 3.2 :

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY name="pourAcheteurs" 
     discuri="http://www.catalogue.example.com/Privacy/confidentialite_achat.html"
     opturi="http://catalogue.example.com/preferences.html"
     xml:lang="en">
  <ENTITY>
   <DATA-GROUP>
    <DATA ref="#business.name">CatalogueExemple</DATA>
    <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
    <DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
    <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
    <DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
    <DATA ref="#business.contact-info.postal.country">USA</DATA>
    <DATA ref="#business.contact-info.online.email">catalogue@example.com</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
   </DATA-GROUP>
  </ENTITY>
  <ACCESS><contact-and-other/></ACCESS>
  <DISPUTES-GROUP>
   <DISPUTES resolution-type="independent"
     service="http://www.sceauconfidentiel.example.org"
     short-description="sceauconfidentiel.example.org">
    <IMG src="http://www.sceauconfidentiel.example.org/Logo.gif" alt="Logo de SceauConfidentiel"/>
    <REMEDIES><correct/></REMEDIES>
   </DISPUTES>
  </DISPUTES-GROUP>
  <STATEMENT>
   <CONSEQUENCE>
     Nous enregistrons certaines informations pour servir votre commande
     et pour la sécurité et l'amélioration de notre site Web.
   </CONSEQUENCE>
   <PURPOSE><admin/><develop/></PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION>
   <DATA-GROUP>
    <DATA ref="#dynamic.clickstream"/>
    <DATA ref="#dynamic.http.useragent"/>
   </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
   <CONSEQUENCE>
     Nous utilisons ce renseignement quand vous effectuez un achat.
   </CONSEQUENCE>
   <PURPOSE><current/></PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION>
   <DATA-GROUP>
    <DATA ref="#user.name"/>
    <DATA ref="#user.home-info.postal"/>
    <DATA ref="#user.home-info.telecom.telephone"/>
    <DATA ref="#user.business-info.postal"/>
    <DATA ref="#user.business-info.telecom.telephone"/>
    <DATA ref="#user.home-info.online.email"/>
    <DATA ref="#user.login.id"/>
    <DATA ref="#user.login.password"/>
    <DATA ref="#dynamic.miscdata">
     <CATEGORIES><purchase/></CATEGORIES>
    </DATA>
   </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
   <CONSEQUENCE>
     À votre demande, nous vous enverrons des offres commerciales soigneusement
     sélectionnées qui sont susceptibles de vous intéresser.
   </CONSEQUENCE>
   <PURPOSE>
    <contact required="opt-in"/>
    <individual-decision required="opt-in"/>
    <tailoring required="opt-in"/>
   </PURPOSE>
   <RECIPIENT><ours/><same required="opt-in"/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION>
   <DATA-GROUP>
    <DATA ref="#user.name" optional="yes"/>
    <DATA ref="#user.home-info.postal" optional="yes"/>
    <DATA ref="#user.home-info.telecom.telephone" optional="yes"/>
    <DATA ref="#user.business-info.postal" optional="yes"/>
    <DATA ref="#user.business-info.telecom.telephone" optional="yes"/>
    <DATA ref="#user.home-info.online.email" optional="yes"/>
   </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
   <CONSEQUENCE>
     Vous pouvez disposer d'un mot de passe permettant
     d'accéder à vos informations personnelles.
   </CONSEQUENCE>
   <PURPOSE><individual-decision required="opt-in"/></PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION>
   <DATA-GROUP>
    <DATA ref="#user.login.id"/>
    <DATA ref="#user.login.password"/>
     <CATEGORIES><uniqueid/></CATEGORIES>
    </DATA>
   </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
   <CONSEQUENCE>
     À votre demande, nous pouvons personnaliser notre site et mettre en exergue
     les produits qui correspondent à vos intérêts.
   </CONSEQUENCE>
   <PURPOSE>
     <pseudo-decision required="opt-in"/>
     <tailoring required="opt-in"/>
   </PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION>
   <DATA-GROUP>
    <DATA ref="#user.bdate.ymd.year" optional="yes"/>
    <DATA ref="#user.gender" optional="yes"/>
   </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
   <CONSEQUENCE>
     Nous personnalisons notre site en fonction de vos visites antérieures.
   </CONSEQUENCE>
   <PURPOSE><tailoring/><develop/></PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION>
   <DATA-GROUP>
    <DATA ref="#dynamic.cookies">
     <CATEGORIES><state/></CATEGORIES>
    </DATA>
    <DATA ref="#dynamic.miscdata">
     <CATEGORIES><preference/></CATEGORIES>
    </DATA>
   </DATA-GROUP>
  </STATEMENT>
 </POLICY>
</POLICIES>

3.2 Les politiques

Cette section définit la syntaxe et la sémantique des politiques P3P. Toutes les politique DOIVENT être codées en utilisant [UTF-8].

Au cas où le vocabulaire P3P n'est pas assez précis pour décrire les pratiques d'un site Web, les sites devraient employer les termes de vocabulaire qui se rapprochent le plus de leurs pratiques et fournir des explications plus complètes dans le champ <CONSEQUENCE> et/ou leur politique lisible par un humain. Néanmoins, les politiques NE DOIVENT PAS faire de déclarations fausses ou trompeuses.

Les politiques doivent être placées dans un élément <POLICIES>.

3.2.1 L'élément `POLICIES`

L'élément <POLICIES> rassemble une ou plusieurs politiques P3P dans un seul fichier. Cette caractéristique permet d'optimiser les performances : plusieurs politiques sont réunies pour composer une seule requête, ce qui améliore le trafic sur les réseaux et la mise en cache.

L'élément <POLICIES> est l'élément racine des fichiers de politique. En outre, on peut placer des éléments <POLICIES> dans le fichier d'appel de politique, à l'intérieur d'un élément <META> ; auquel cas, l'agent utilisateur n'a besoin de récupérer qu'un seul fichier contenant à la fois le fichier d'appel de politique et les politiques.

L'élément <POLICIES> peut contenir, en option, un attribut xml:lang (cf. la section 2.4.2), un élément <EXPIRY>, indiquant la date d'expiration des politiques incluses, et un schéma de données incorporé en utilisant l'élément <DATASCHEMA> (cf. la section 5).

Puisque les politiques sont incluses dans un élément <POLICIES>, chacune DOIT avoir un attribut name unique dans le fichier. C'est ce qui permet leur mobilisation par les appels de politique (dans les éléments <POLICY-REF>).

Exemple 3.3 :

Le fichier situé à http://www.example.com/magasin/politiques.xml pourrait avoir le contenu suivant :

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
   <POLICY name="politique1" discuri="http://www.example.com/disc1"> .... </POLICY>
   <POLICY name="politique2" discuri="http://www.example.com/disc2"> .... </POLICY>
   <POLICY name="politique3" discuri="http://www.example.com/disc3"> .... </POLICY>
</POLICIES>

Les fichiers situés à http://www.example.com/magasin/CDs/* pourraient alors être associés à la deuxième politique ("politique2") en utilisant le fichier d'appel de politique suivant, à http://www.example.com/w3c/p3p.xml :

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
<POLICY-REFERENCES>
    <POLICY-REF about="/magasin/politiques#politique2">
      <INCLUDE>/magasin/CDs/*</INCLUDE>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

[19]    policies  =  `<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `>`
                     [expiry]
                     [dataschema]
                     *policy
                     "</POLICIES>"

3.2.2 L'élément `POLICY`

L'élément <POLICY> contient une politique P3P complète. Chaque politique DOIT contenir exactement un seul élément <POLICY>. L'élément <POLICY> DOIT contenir un élément <ENTITY> identifiant l'entité légale exposant les pratiques de confidentialité contenues dans la politique. En outre, l'élément <POLICY> DOIT contenir un élément <ACCESS>, un ou plusieurs éléments <STATEMENT>, un élément <DISPUTES-GROUP>, un schéma de données P3P et une ou plusieurs extensions.

<POLICY>: comprend une ou plusieurs déclarations. Chaque déclaration inclut un ensemble de divulgations telles qu'elles s'appliquent à un ensemble d'éléments de données.
name (attribut obligatoire): le nom de la politique, utilisé comme identificateur de fragment pour appeler la politique.
discuri (attribut obligatoire): l'adresse URI de la déclaration de confidentialité en langage naturel.
opturi: l'adresse URI des instructions permettant aux utilisateurs d'accepter ou de refuser l'utilisation des données les concernant dans un but particulier (inscription ou désinscription). Cet attribut est obligatoire pour les politiques contenant un élément <PURPOSE> dont la valeur de l'attribut required est "opt-in" ou "opt-out". Remarquez que les procédures d'inscription ou de désinscription sont déterminées par chaque site et ne comprennent pas forcément un mécanisme centralisé pour le site entier ou un mécanisme automatisé en ligne.
xml:lang: la langue dans laquelle la politique est exprimée (cf. la section 2.4.2).

[20]    policy      =  `<POLICY name=` quotedstring
                       ` discuri=` quoted-URI
                       [` opturi=` quoted-URI]
                       [xml-lang] `>`
                       *extension
                       [test]
                       entity
                       access
                       [disputes-group]
                       1*statement-block
                       *extension
                       `</POLICY>`

[21]    quoted-URI  =  `"` URI `"`

Ici, la valeur URI est définie selon RFC 2396 [URI].

3.2.3 L'élément `TEST`

L'élément <TEST> sert à effectuer des simulations : la présence de cet élément dans une politique indique que celle-ci est simplement un exemple et, de ce fait, elle DOIT être ignorée et considérée comme une politique P3P invalide.

[22]    test  =  "<TEST/>"

3.2.4 L'élément `ENTITY`

L'élément <ENTITY> donnent une description précise de l'entité légale qui expose ses pratiques de confidentialité.

<ENTITY>: identifie l'entité légale qui expose ses pratiques de confidentialité dans la politique.

L'élément <ENTITY> contient une description de l'entité légale qui consiste en éléments <DATA> appelant tout ou partie des champs du jeu de données d'entreprise : il DOIT contenir au moins le nom de l'entité légale et un (ou plusieurs) champ(s) de coordonnées choisi(s) parmi les champs adresse postale, numéro de téléphone, adresse électronique, adresse URI. Remarquez que certains règlements légaux et codes de conduite imposent aux entités d'inclure une adresse postale ou d'autres renseignements spécifiques comme coordonnées.

[23]    entity             =  "<ENTITY>"
                              *extension
                              entitydescription
                              *extension
                              "</ENTITY>"

[24]    entitydescription  =  "<DATA-GROUP>"
                              `<DATA ref="#business.name"/>` PCDATA "</DATA>"
                              *(`<DATA ref="#business.` string `"/>` PCDATA "</DATA>")
                              "</DATA-GROUP>"

Ici, la valeur string est définie comme une séquence de caractères (les caractères " et & étant masqués) composant une des valeurs admises du jeu de données d'entreprise. La valeur PCDATA est définie comme dans [XML].

3.2.5 L'élément `ACCESS`

L'élément <ACCESS> indique si le site offre, ou non, un accès à divers types de renseignements.

<ACCESS>: la possibilité offerte à un individu de consulter des données identifiées et d'adresser ses questions ou ses inquiétudes au fournisseur de services. Les fournisseurs de services DOIVENT fixer une valeur de divulgation pour l'attribut access. La méthode d'accès n'est pas spécifiée. Une annonce (autre que <all/>) n'implique pas qu'on puisse accéder à toutes les données mais seulement à certaines, et les utilisateurs devraient entrer en relation avec le fournisseur de services pour déterminer quelles sont les possibilités dont ils disposent.
Remarquez que les fournisseurs de services peuvent aussi autoriser un accès aux informations collectées via d'autres moyens que par le Web à l'adresse URI indiquée par l'attribut discuri. La portée des déclarations P3P est limitée aux données collectées au travers du protocole HTTP ou d'autres protocoles de transport Web. En outre, lorsque cet accès a lieu par le Web, on recommande l'utilisation de mécanismes d'authentification et de sécurité forts pour ces échanges ; les questions de sécurité ne sont toutefois pas abordées par ce document.

L'élément <ACCESS> doit contenir l'un des éléments suivants :

<nonident/>: le site Web ne collecte pas de données identifiées.
<all/>: Toutes les données identifiées : l'accès est permis pour toutes les données identifiées.
<contact-and-other/>: Coordonnées et autres données identifiées : l'accès est permis pour toutes les coordonnées en ligne et physiques ainsi que pour d'autres données identifiées.
<ident-contact/>: Coordonnées identifiables : l'accès est permis pour les coordonnées en ligne et physiques identifiées (par exemple, les utilisateurs peuvent accéder à une adresse postale).
<other-ident/>: Autres données identifiées : l'accès est permis pour d'autres données identifiées (par exemple, les utilisateurs peuvent accéder à leurs comptes en ligne).
<none/>: Aucun : aucun accès à des données identifiées n'est permis.

[25]    access             =  "<ACCESS>"
                              *extension
                              access_disclosure
                              *extension
                              "</ACCESS>"

[26]    access_disclosure  =  "<nonident/>"          | ; Les données identifiées ne sont pas utilisées

                              "<all/>"               | ; Toutes les informations identifiables
                              "<contact-and-other/>" | ; Les coordonnées et autres données identifiées
                              "<ident-contact/>"     | ; Les coordonnées identifiables
                              "<other-ident/>"       | ; Autres données identifiées
                              "<none/>"                ; Aucun

3.2.6 L'élément `DISPUTES`

Une politique DEVRAIT contenir un élément <DISPUTES-GROUP> contenant à son tour un ou plusieurs éléments <DISPUTES>. Ces éléments décrivent les procédures de résolution des litiges à observer en cas de contestation des pratiques de confidentialité des services. Chaque élément <DISPUTES> peut contenir, en option, un élément <LONG-DESCRIPTION>, un élément <IMG> et un élément <REMEDIES>. Les fournisseurs de services qui disposent de plusieurs procédures de résolution des litiges devraient se servir d'un élément <DISPUTES> différent pour chacune d'elles. Puisque les différentes procédures de contentieux appellent des processus de réparation séparés, chacun des éléments <DISPUTES> aura besoin d'éléments <LONG-DESCRIPTION>, <IMG> et <REMEDIES> distincts, si on se sert de ces éléments.

<DISPUTES>

Décrit les procédures de résolution des litiges à observer en cas de contestation des pratiques de confidentialité d'un service ou en cas de violation du protocole.

resolution-type (attribut obligatoire)

Prend l'une des quatres valeurs suivantes :

service: Service clientèle : Un individu peut se plaindre auprès du représentant du service clientèle du site Web chargé de la résolution des litiges concernant l'utilisation des données collectées. La description DOIT inclure des renseignements sur les moyens de contacter le service clientèle.
independent: Organisation indépendante : Un individu peut se plaindre auprès d'une organisation indépendante pour la résolution des litiges concernant l'utilisation des données collectées. La description DOIT inclure des renseignements sur les moyens de contacter ce tiers.
court: Tribunal : Un individu peut porter plainte à l'encontre du site Web.
law: Lois applicables : Les litiges en rapport avec la déclaration de confidentialité seront résolus selon les lois citées dans la description.

service (attribut obligatoire)

L'adresse URI de la page Web du service clientèle, ou de l'organisation indépendante, ou l'adresse URI renseignant sur la juridiction ou les lois applicables concernées.

verification

L'adresse URI ou le certificat à utiliser dans un but de vérification. Il est prévu de mettre en place un mécanisme permettant aux organismes de labellisation de vérifier le label auquel un site prétend.

short-description

Une description brève, lisible par un humain, indiquant le nom de la juridiction concernée, les règlements applicables ou une organisation tierce, ou bien les coordonnées du service clientèle si celles-ci ne sont pas déjà mentionnées à l'adresse URI du service en question. La description ne doit pas faire plus de 255 caractères.

L'élément <DISPUTES> peut contenir un élément <LONG-DESCRIPTION> dans lequel se trouve une description lisible par un humain : cette description devrait comprendre le nom de la juridiction concernée, les règlements applicables ou une organisation tierce, ou bien les coordonnées du service clientèle si celles-ci ne sont pas déjà mentionnées à l'adresse URI du service en question.

<LONG-DESCRIPTION>: Cet élément contient une description lisible par un humain (qui peut être très détaillée).

<IMG>: L'image d'un logo (par exemple, celui de l'organisation indépendante ou celui de la juridiction concernée).
src (attribut obligatoire): L'adresse URI de l'image du logo
width: La largeur en pixels de l'image du logo.
height: La hauteur en pixels de l'image du logo.
alt (attribut obligatoire): Un remplacement textuel très court pour l'image du logo.

[27]    disputes-group   =  "<DISPUTES-GROUP>"
                            *extension
                            1*dispute
                            *extension
                            "</DISPUTES-GROUP>"

[28]    dispute          =  "<DISPUTES"
                            " resolution-type=" '"'("service"|"independent"|"court"|"law")'"'
                            " service=" quoted-URI
                            [" verification=" quotedstring]
                            [" short-description=" quotedstring]
                            ">"
                            *extension
                            [longdescription]
                            [image]
                            [remedies]
                            *extension
                            "</DISPUTES>"

[29]    longdescription  =  <LONG-DESCRIPTION> PCDATA </LONG-DESCRIPTION>

[30]    image            =  "<IMG src=" quoted-URI
                            [" width=" `"` number `"`]
                            [" height=" `"` number `"`]
                            " alt=" quotedstring
                            "/>"

[31]    quotedstring     =  `"` string `"`

Ici, la valeur string est définie comme une séquence de caractères (les caractères " et & doivent être masqués) et la valeur PCDATA est définie comme dans [XML].

Remarquez qu'il peut y avoir plusieurs services de certification, indiqués par autant d'éléments <DISPUTES> dans l'élément <DISPUTES-GROUP>. Ces champs sont censés être utilisés de plusieurs façons, y compris l'indication que les pratiques de confidentialité en question sont auto-certifiées, contrôlées par un tiers ou soumises à la juridiction d'un organisme de régulation.

3.2.7 L'élément `REMEDIES`

Chaque élément <DISPUTES> DEVRAIT contenir un élément <REMEDIES> qui définit les réparations possibles en cas de violation de la politique.

<REMEDIES>: Les réparations en cas de violation de la politique.

L'élément <REMEDIES> doit contenir l'un ou plusieurs des éléments suivants :

<correct/>: Les erreurs ou les actions injustifiées survenant en rapport avec la politique de confidentialité seront corrigées par le service.
<money/>: Si le fournisseur de services ne respecte pas sa politique de confidentialité, il versera à la personne lésée une compensation financière précisée dans la politique de confidentialité lisible par un humain ou bien une compensation à hauteur des dommages subis.
<law/>: Les réparations pour non-respect de la déclaration de politique seront déterminées par les lois citées dans la description lisible par un humain.

[32]    remedies  =  "<REMEDIES>"
                     *extension
                     1*remedy
                     *extension
                     "</REMEDIES>"

[33]    remedy    =  "<correct/>" |
                     "<money/>"   |
                     "<law/>"

3.3 Les déclarations

Les déclarations décrivent le traitement appliqué aux types de données spécifiques.

3.3.1 L'élément `STATEMENT`

L'élément <STATEMENT> est un conteneur regroupant un élément <PURPOSE>, un élément <RECIPIENT>, un élément <RETENTION>, un élément <DATA-GROUP> et, en option, un élément <CONSEQUENCE> ainsi qu'une ou plusieurs extensions. Toutes les données référencées par l'élément <DATA-GROUP> sont manipulées conformément aux divulgations présentes dans les autres éléments contenus par la déclaration. Les sites peuvent ainsi regrouper les éléments qui se manipulent de la même façon et créer une déclaration pour chaque regroupement. Les sites préférant divulguer séparément des intentions et d'autres informations pour chaque type de données collectées peuvent le faire en créant une déclaration séparée par élément de données.

<STATEMENT>: Les pratiques concernant les données telles qu'appliquées aux éléments de données.

[34]    statement-block  =  "<STATEMENT>"
                            *extension
                            [consequence]
                            ((purpose recipient retention 1*data-group) |
                            (non-identifiable [purpose] [recipient] [retention] *data-group))
                            *extension
                            "</STATEMENT>"

Pour simplifier la déclaration des pratiques, les fournisseurs de services peuvent assembler n'importe quelle divulgation (c'est-à-dire, les intentions (<INTENTION>), les destinataires (<RECIPIENT>) et la rétention (<RETENTION>)) en une déclaration globale couvrant les éléments de données. Les fournisseurs de services DOIVENT réaliser ces assemblages de manière additive. Par exemple, un site distribuant votre âge selon une destination <ours> (nous-mêmes et nos agents) et, par contre, votre code postal selon une destination <unrelated> (tiers non apparenté) PEUT annoncer qu'il distribue votre nom et votre code postal selon les destinations <ours> et <unrelated>. Une telle déclaration semblera distribuer plus de données qu'en réalité. Il est de la responsabilité du fournisseur de services de déterminer la concision et la précision de ses divulgations. Remarquez que, dans un assemblage de divulgations issues de déclarations parmi lesquelles apparaît un élément <NON-IDENTIFIABLE>, cet élément ne pourra être inclus dans la déclaration assemblée (globale) que s'il apparaît dans chacune des déclarations prises séparément.

De même, on doit toujours divulguer toutes les options qui s'appliquent. Supposons un site dont le seul but est de collecter des informations avec une intention <contact/> (Contact des visiteurs pour la commercialisation de services ou produits). Bien que cette opération puisse avoir lieu dans le contexte d'une intention <current/> (Achèvement et support d'un processus avec les données fournies), le site doit déclarer les deux intentions <contact/> et <current/>. Supposons qu'un site distribue des informations à un destinataire <ours> pour leur redistribution à un destinataire <public> : le site doit alors déclarer les deux destinataires <ours> et <public>.

Les fournisseurs de services assemblent souvent les données qu'ils collectent. Parfois, ces données globales seront utilisées pour d'autres buts, partagées plus largement ou conservées plus longtemps que les données originales. Par exemple, beaucoup de sites publient ou divulguent des statistiques pour leurs annonceurs, tels que le nombre des visiteurs sur leur site Web, le pourcentage des visiteurs rangés par groupes démographiques, etc. Lorsqu'on utilise ou partage des statistiques globales à partir desquelles il est impossible de déduire des renseignements personnels concernant un individu ou un foyer, il n'est pas nécessaire de les divulguer dans une politique P3P. Par contre, les services DOIVENT divulguer la collecte des données originales et déclarer toute utilisation de celles-ci avant leur assemblage.

3.3.2 L'élément `CONSEQUENCE`

Les éléments <STATEMENT> peuvent, en option, contenir un élément <CONSEQUENCE> dont la présentation permettra à un utilisateur humain d'obtenir plus informations concernant les pratiques d'un site.

<CONSEQUENCE>: Les conséquences qui peuvent être présentées à l'utilisateur afin d'expliquer l'intérêt de la pratique suggérée dans un contexte donné, même si, normalement, l'utilisateur ne l'aurait pas autorisée.

[35]    consequence  =  "<CONSEQUENCE>"
                        PCDATA
                        "</CONSEQUENCE>"

3.3.3 L'élément `NON-IDENTIFIABLE`

Un élément <STATEMENT> peut contenir, en option, un élément <NON-IDENTIFIABLE>, dont la présence signifie soit qu'aucune donnée n'est collectée dans le cadre de cet élément <STATEMENT>, soit que les données appelées par cet élément <STATEMENT> seront rendues anonymes lors de leur collecte.

<NON-IDENTIFIABLE/>: Cet élément annonce soit qu'aucune donnée n'est collectée (y compris les journaux d'accès Web), ou bien que l'organisation collectrice des données rendra anonyme les données référencées dans l'élément <STATEMENT> englobant. Les données seront considérées anonymes si l'entité ou un tiers sont dans l'incapacité de les rattacher à l'identité d'une personne en utilisant des moyens raisonnables. Par essence, certains types de données sont anonymes comme c'est le cas, par exemple, pour les identifiants de session générés aléatoirement. Les données qui, dans certaines circonstances, sont susceptibles de permettre l'identification des personnes, tels que les adresses IP, les noms ou les adresses, doivent subir une transformation non réversible pour être considérées anonymes.
Comme exemple de transformation irrémédiable : supprimer les sept derniers bits d'une adresse IP et les remplacer par des zéros. Cette transformation doit s'appliquer à tous les exemplaires de ces données, y compris ceux stockés sur un support de sauvegarde. Un algorithme selon lequel les données identifiées sont remplacées par une valeur unique correspondante dans une table n'est pas considéré comme étant irrémédiable. En outre, une fonction de hachage cryptographique unidirectionnelle ne sera pas considérée comme irrémédiable si le jeu des valeurs possibles est trop petit puisque toutes les valeurs hachées possibles pourront être générées puis comparées avec le hachage de la valeur qu'on essaye de dévoiler.

Si l'élément <NON-IDENTIFIABLE> est présent dans un élément <STATEMENT> de politique, alors on DOIT inclure une explication, lisible par un humain, des moyens par lesquels les données ont été rendues anonymes ou bien indiquer l'adresse de cette explication avec un attribut discuri.

De même, si l'élément <NON-IDENTIFIABLE> est présent dans un élément <STATEMENT>, alors les autres éléments contenus dans ce <STATEMENT> deviennent optionnels.

[36]    non-identifiable  =  "<NON-IDENTIFIABLE/>"

3.3.4 L'élément `PURPOSE`

Tout élément <STATEMENT> sans sous-élément <NON-IDENTIFIABLE> DOIT contenir un élément <PURPOSE> qui exprime une ou plusieurs intentions concernant la collecte ou l'utilisation des données. Les sites DOIVENT classer leurs pratiques vis-à-vis des données dans l'une ou plusieurs des catégories d'intention énoncées ci-dessous.

<PURPOSE>: Les intentions pour le traitement des données en rapport avec le Web.

L'élément <PURPOSE> DOIT contenir l'une ou plusieurs des intentions suivantes :

<current/>: Achèvement et support d'un processus avec les données fournies : Les renseignements peuvent servir au fournisseur de service afin d'achever le processus pour lequel ceux-ci ont été fournis, qu'il s'agisse d'une activité ponctuelle, comme retourner le résultat d'une recherche sur le Web, faire suivre une adresse électronique ou placer une commande, ou qu'il s'agisse d'une activité récurrente, comme offrir un service d'abonnement ou autoriser l'accès à un carnet d'adresses en ligne ou à un porte-monnaie électronique.
<admin/>: Administration du site Web et du système : Les renseignements peuvent servir au support technique du site Web et de son système informatique. C'est le cas du traitement des informations concernant les comptes hébergés et des informations utilisées pour la sécurisation et la maintenance du site et pour la vérification de l'activité du site Web par le site ou par ses agents.
<develop/>: Recherche et développement : Les renseignements peuvent servir à l'amélioration, l'évaluation ou encore à la mise à jour du site, d'un service, d'un produit ou d'un marché. Cela ne concerne pas les informations personnelles utilisées pour la personnalisation ou la modification du contenu en fonction de cet individu particulier ni celles utilisées pour évaluer, cibler, profiler ou contacter la personne.
<tailoring/>: Ajustement ponctuel : Les renseignements peuvent servir à l'ajustement ou à la modification du contenu ou de l'aspect du site ; on ne peut les utiliser que pour une seule visite du site et pas pour une quelconque personnalisation ultérieure. Par exemple, un magasin en ligne peut suggérer d'autres articles susceptibles d'intéresser un visiteur en fonction des articles déjà contenus dans son panier d'achat.
<pseudo-analysis/>: Analyse pseudonyme : Les renseignements peuvent servir à la création ou à l'élaboration d'un enregistrement concernant un individu (ou un ordinateur) particulier, lié à un identifiant pseudonyme sans associer de données identifiées (comme le nom, l'adresse, le numéro de téléphone ou l'adresse électronique) à l'enregistrement. Ce profil servira à déterminer les habitudes, les centres d'intérêts ou les autres caractéristiques d'un individu, dans un but de recherche, d'analyse et d'étude, mais pas pour essayer d'identifier des personnes particulières. Par exemple, un mercaticien peut vouloir étudier l'intérêt des visiteurs pour les diverses parties d'un site Web.
<pseudo-decision/>: Décision pseudonyme : Les renseignements peuvent servir à la création ou à l'élaboration d'un enregistrement concernant un individu (ou un ordinateur) particulier, lié à un identifiant pseudonyme sans associer de données identifiées (comme le nom, l'adresse, le numéro de téléphone ou l'adresse électronique) à l'enregistrement. Ce profil servira à déterminer les habitudes, les centres d'intérêts ou les autres caractéristiques des individus afin de prendre une décision affectant directement un individu, mais pas pour essayer d'identifier des personnes particulières. Par exemple, un mercaticien peut vouloir ajuster ou modifier le contenu affiché par le navigateur en fonction des pages visitées antérieurement.
<individual-analysis/>: Analyse individuelle : Les renseignements peuvent servir à déterminer les habitudes, les centres d'intérêts ou les autres caractéristiques des individus en être combinées avec des données identifiées dans un but de recherce, d'analyse ou d'étude. Par exemple, le site Web en ligne d'un magasin physique peut vouloir analyser le comportement des acheteurs en ligne dans un magasin physique.
<individual-decision/>: Décision individuelle : Les renseignements peuvent servir à déterminer les habitudes, les centres d'intérêts ou les autres caractéristiques des individus et être combinées avec des données identifiées afin de prendre une décision affectant directement un individu. Par exemple, un magasin en ligne suggère au visiteur des articles qu'il serait susceptible d'acheter en fonction des articles achetés au cours des visites antérieures.
<contact/>: Contact des visiteurs pour la commercialisation de services ou produits : Les renseignements peuvent servir à contacter l'individu, par un autre canal de communication que le téléphone, afin de promouvoir un produit ou un service. Sont concernées les notifications adressées aux visiteurs à propos des mises à jour du site Web mais pas les réponses directes, constituant une seule transaction, à une question, ou à un commentaire, ou à un service clientèle (on utilisera plutôt la valeur d'intention <current/>). En outre, n'est pas concernée la commercialisation, via un contenu Web ou des bandeaux publicitaires personnalisés, incorporée aux sites visités par l'utilisateur (ces cas seraient couverts par les valeurs d'intention <tailoring/>, <pseudo-analysis/> et <pseudo-decision/>, ou <individual-analysis/> et <individual-decision/>).
<historical/>: Conservation historique : Les renseignements peuvent être archivée ou stockée à des fins de conservation des antécédents sociaux comme exigé par une loi (ou une politique) existante. Cette loi (ou cette politique) DOIT être citée dans l'élément <DISPUTES> et DOIT inclure une définition précise du type de chercheur qualifié pouvant accéder à ces informations, de l'endroit où ces informations seront stockées et, particulièrement, en quoi cette collecte participe à la conservation historique.
<telemarketing/>: Contact des visiteurs pour la commercialisation de services ou produits par téléphone : Les renseignements peuvent servir à contacter l'individu par téléphone afin de promouvoir un service ou un produit. Ne sont pas concernées les réponses directes, constituant une seule transaction, à une question, ou à un commentaire, ou à un service clientèle (on utilisera plutôt la valeur d'intention <current/>).
<other-purpose> chaîne </other-purpose>: Autres usages : Les renseignements peuvent servir pour d'autres buts qui ne rentrent pas dans les définitions précédentes. (Dans ce cas, on DOIT fournir une explication lisible par un humain).

Chaque type d'intention (sauf <current/>) admet les attributs optionnels suivants :

required

La caractéristique d'obligation de la pratique pour le site. L'attribut prend les valeurs suivantes :

always : L'intention est toujours obligatoire et les utilisateurs ne peuvent ni accepter ni refuser cet usage de leurs données. C'est la valeur implicite en l'absence de l'attribut required ;
opt-in : Les données peuvent être utilisées dans l'intention en question si l'utilisateur affirme cet usage, par exemple, à l'occasion d'une inscription sur une liste de diffusion. Une requête affirmative oblige l'utilisateur à exercer une action spécifique pour manifester sa volonté. Par exemple, lorsque l'utilisateur remplit un formulaire de sondage, le fait de cocher une case supplémentaire pour s'inscrire à une liste de diffusion constitue une requête affirmative. Par contre, ce ne serait pas le cas si le formulaire de sondage était présenté avec une demande d'inscription précochée. En outre, quelle que soit l'intention pour laquelle l'utilisateur se manifeste affirmativement, il doit pouvoir se désengager s'il change d'avis (on DOIT le préciser à l'adresse URI indiquée par l'attribut opturi ;
opt-out : Les données peuvent être utilisées dans l'intention en question, à moins que l'utilisateur demande qu'on ne les utilise pas de cette manière. Pour cette valeur, le service DOIT fournir à l'utilisateur des instructions claires, à l'adresse URI indiquée par l'attribut opturi, afin qu'il puisse se soustraire de cette intention. Les services DEVRAIENT également afficher ces instructions, ou un pointeur vers celles-ci, au point de collecte des données.

[37]    purpose       =  "<PURPOSE>"
                         *extension
                         1*purposevalue
                         *extension
                         "</PURPOSE>"

[38]    purposevalue  =  "<current/>"                           | ; Achèvement et support d'un processus
                                                                  ; avec les données fournies
                         "<admin" [required]   "/>"             | ; Administration du site et du système
                         "<develop" [required] "/>"             | ; Recherche et développement
                         "<tailoring" [required] "/>"           | ; Ajustement ponctuel
                         "<pseudo-analysis" [required] "/>"     | ; Analyse pseudonyme
                         "<pseudo-decision" [required] "/>"     | ; Décision pseudonyme
                         "<individual-analysis" [required] "/>" | ; Analyse individuelle
                         "<individual-decision" [required] "/>" | ; Décision individuelle
                         "<contact" [required] "/>"             | ; Contact des visiteurs pour la
                                                                  ; commercialisation de services ou produits
                         "<historical" [required] "/>"          | ; Conservation historique
                         "<telemarketing" [required] "/>"       | ; Commercialisation par téléphone
                         "<other-purpose" [required] ">" PCDATA "</other-purpose>" ; Autres usages

[39]    required      =  " required=" `"` ("always"|"opt-in"|"opt-out") `"`

Les fournisseurs de services DOIVENT utiliser les éléments ci-dessus pour expliquer l'intention motivant la collecte des données. Ils DOIVENT divulguer toutes les intentions qui s'appliquent. Si un fournisseur de services n'annonce pas d'utilisation d'un élément de données pour une intention donnée, cela implique que ces données ne seront pas utilisées dans l'intention en question. Les fournisseurs de services qui annoncent l'utilisation de données pour une intention Autres usages (<other-purpose>) DOIVENT fournir des explications lisibles par un humain de cette intention.

3.3.5 L'élément `RECIPIENT`

Tout élément <STATEMENT> sans sous-élément <NON-IDENTIFIABLE> DOIT contenir un élément <RECIPIENT> lequel indique le (ou les) destinataire(s) des données collectées. Les sites DOIVENT doivent classer les destinataires parmi l'un ou plusieurs des suivants :

<RECIPIENT>: L'entité légale ou le domaine, hormi le fournisseur de services et ses agents, où les données peuvent être distribuées.

L'élément <RECIPIENT> DOIT contenir l'un ou plusieurs des destinataires suivants :

<ours>: Nous-même et/ou des entités agissant en tant qu'agents ou les entités pour le compte desquelles nous agissons comme tel : Dans ce contexte, on définit un agent comme un tiers traitant les données pour le compte du fournisseur de services afin de réaliser les intentions déclarées. Par exemple, le fournisseur de services et son service de publication qui imprime les étiquettes d'adresses sans faire autre chose avec ces informations.
<delivery>: Services de livraison suivant peut-être d'autres pratiques : Les personnes morales opérant un service de livraison qui utilisent les données pour d'autres intentions que la réalisation de l'intention déclarée. Les services de livraison dont les pratiques vis-à-vis des données sont inconnues devraient aussi entrer dans ce cas.
<same>: Personnes morales suivant nos pratiques : Les personnes morales qui utilisent les données pour leur propre compte en suivant des pratiques équivalentes. Par exemple, supposons un fournisseur de services permettant à l'utilisateur d'accéder aux informations personnelles collectées et à un partenaire, lequel les utilise une seule fois puis les jette. Bien que le partenaire ait par ailleurs des pratiques identiques, puisqu'il ne peut pas garantir à l'utilisateur un accès aux informations détruites, on ne le considèrera pas comme ayant les mêmes pratiques.
<other-recipient>: Personnes morales suivant des pratiques différentes : Les personnes morales qui sont sous contrat et qui sont responsables auprès du fournisseur de services original, mais qui sont susceptibles d'utiliser les données d'une manière non définie dans les pratiques du fournisseur de services. Par exemple, le fournisseur de services collecte des données et les partage avec un partenaire qui les utilise pour d'autres intentions. Mais le fournisseur de services devrait veiller sur ces données car leur utilisation abusive pourrait nuire aux intérêts de l'utilisateur comme aux siens.
<unrelated>: Tiers non apparentés : Les personnes morales dont les pratiques vis-à-vis de l'utilisation des données sont inconnues du fournisseur de services original.
<public>: Tribunes publiques : Les tribunes publiques, tels que les babillards, les annuaires publics ou les annuaires de CD-ROM commerciaux.

Chacune des balises précédentes peuvent inclure en option :

une ou plusieurs balises <recipient-description> contenant une description du destinataire ;
et, sauf pour la balise <ours>, un attribut required. Cet attribut, qui est défini exactement comme l'attribut analogue de l'élément <PURPOSE>, indique s'il est possible, ou non, d'accepter N.D.T. opt-in ou de refuser (N.D.T. opt-out) le partage des données (la valeur par défaut est always).

[40]    recipient       =  "<RECIPIENT>"
                           *extension
                           1*recipientvalue
                           *extension
                           "</RECIPIENT>"

[41]    recipientvalue  =  "<ours>" *recdescr
                           "</ours>                         | ; Seulement nous-même et nos agents

                           "<same" [required] ">" *recdescr
                           "</same>"                        | ; Les personnes morales suivant
                                                              ; nos pratiques

                           "<other-recipient" [required] ">" *recdescr
                           "</other-recipient>"             | ; Les personnes morales suivant
                                                              ; des pratiques différentes

                           "<delivery" [required] ">" *recdescr
                           "</delivery>"                    | ; Les services de livraison suivant
                                                              ; des pratiques différentes

                           "<public" [required] ">" *recdescr
                           "</public>"                      | ; Les tribunes publiques

                           "<unrelated" [required] ">" *recdescr
                           "</unrelated>"                     ; Les tiers non apparentés

[42]    recdescr        =  "<recipient-description>"
                           PCDATA                             ; Description du destinataire
                           "</recipient-description>"

Les fournisseurs de services DOIVENT divulguer tous les destinataires qui s'appliquent. Le protocole P3P ne fait aucune distinction sur la manière dont les données sont délivrées au destinataire ; en cas de partage des données, il impose simplement la divulgation de ce partage dans la politique P3P. Comme exemples de divulgations de données qui DOIVENT être couvertes par une politique P3P :

La transmission des données d'un client pour la réalisation d'une commande ou le traitement d'une facture ;
La cession ou la vente de fichiers d'adresses ;
Le placement de renseignements personnels dans les adresses URI des requêtes redirigeant vers un tiers ;
Le placement de renseignements personnels dans les adresses URI pointant vers un tiers.

Remarquez que le jeu de destinataires ci-dessus peut, dans certains cas, ne pas décrire entièrement tous les destinataires des données. Par exemple, la question des facilitateurs de transaction, tels que les services d'expédition ou de paiement, nécessaires pour l'achèvement et le support du processus mais susceptibles de suivre des pratiques différentes, posait problème. Pour l'instant, seuls les services de livraison peuvent être explicitement représentés dans une politique. Les autres facilitateurs de transaction devraient l'être dans les catégories qui réflètent le mieux leurs politiques par rapport au fournisseur de services original.

Un élément spécifique est prévu pour les services de livraison mais pas un seul pour les facilitateurs de paiement (tels que les banques ou les organismes de crédit), pour la raison suivante : les institutions financières auront généralement passé des accords séparés avec leurs clients, concernant leurs données bancaires, tandis que les destinataires d'une livraison n'auront pas eu l'opportunité d'examiner la politique de confidentialité du service de livraison en question.

Remarquez qu'on NE DEVRAIT PAS utiliser la balise <delivery> pour les services de distribution qui reconnaissent seulement utiliser les données au nom du fournisseur de services afin de terminer la livraison.

3.3.6 L'élément `RETENTION`

Tout élément <STATEMENT> sans sous-élément <NON-IDENTIFIABLE> DOIT contenir un élément <RETENTION> indiquant le type de politique de rétention appliqué aux données référencées dans la déclaration.

<RETENTION>: Le type de politique de rétention en vigueur.

L'élément <RETENTION> DOIT contenir l'une des éléments suivants :

<no-retention/>: Les renseignements sont conservés pour la brève durée nécessaire à leur utilisation au cours d'une seule opération en ligne. Les renseignements DOIVENT être détruits immédiatement après cette opération et NE DOIVENT PAS apparaître dans un journal, ni être archivés ou stockés d'une manière quelconque. Ce type de politique de rétention concerne, par exemple, les services qui ne tiennent aucun journal des accès Web, qui placent un cookie uniquement pour la durée d'une seule session ou collectent des informations pour une recherche sans tenir un journal des recherches effectuées.
<stated-purpose/>: Pour l'intention déclarée : les renseignements sont conservés pour satisfaire à l'intention déclarée. Les renseignements devront être détruits le plus tôt possible. Les sites DOIVENT avoir une politique de rétention établissant un calendrier de destruction. La politique de rétention DOIT être incluse ou reliée à la politique de confidentialité lisible par un humain.
<legal-requirement/>: Comme exigé par la loi ou en responsabilité selon les lois en vigueur : les renseignements sont conservés pour satisfaire à une intention déclarée mais la période de rétention est plus importante du fait d'une obligation légale ou d'une responsabilité légale. Par exemple, une loi peut permettre aux consommateurs de contester les transactions pendant un certain délai ; une entreprise peut donc décider, pour une question de responsabilité, de conserver un enregistrement des transactions, ou une loi peut imposer affirmativement à une certaine entreprise de conserver des enregistrements pour un audit ou d'autres raisons de validité. Les sites DOIVENT avoir une politique de rétention établissant un calendrier de destruction. La politique de rétention DOIT être incluse ou reliée à la politique de confidentialité lisible par un humain.
<business-practices/>: Selon les pratiques commerciales du fournisseur de service : les renseignements sont conservés sous couvert des pratiques commerciales déclarées par le fournisseur de services. Les sites DOIVENT avoir une politique de rétention établissant un calendrier de destruction. La politique de rétention DOIT être incluse ou reliée à la politique de confidentialité lisible par un humain.
<indefinitely/>: Indéfiniment : les renseignements sont conservés pour une durée indéterminée. Cette option reflète l'absence d'une politique de rétention. C'est la politique de rétention appropriée lorsque le destinataire est une tribune publique.

[43]    retention       =  "<RETENTION>"
                           *extension
                           retentionvalue
                           *extension
                           "</RETENTION>"

[44]    retentionvalue  =  "<no-retention/>"       | ; non conservé
                           "<stated-purpose/>"     | ; selon l'intention déclarée
                           "<legal-requirement/>"  | ; selon une intention déclarée et la loi
                           "<business-practices/>" | ; selon des pratiques commerciales
                           "<indefinitely/>"         ; durée indéterminée

3.3.7 Les éléments `DATA-GROUP` et `DATA`

Tout élément <STATEMENT> sans sous-élément <NON-IDENTIFIABLE> DOIT contenir au moins un élément <DATA-GROUP> lequel contient à son tour un ou plusieurs éléments <DATA>. Les éléments <DATA> servent à décrire les type de données collectés par un site.

<DATA-GROUP>: Décrit les données à transférer ou inférer.
base: L'URI de base ([URI]) pour les références d'URI présent dans les attributs ref. Quand cet attribut est omis, la valeur par défaut pour l'URI correspond à l'URI du schéma de données P3P de base (http://www.w3.org/TR/P3P/base). Quand l'attribut se présente sous la forme d'une chaîne vide (""), la base correspond au document local.

<DATA>: Décrit les donnés à transférer ou à inférer.
ref (attribut obligatoire): L'adresse URI ([URI]), dans laquelle la partie identificateur de fragment indique le nom d'un élément de données/jeu de données et la partie URI indique le schéma de données correspondant. Lorsque la partie URI est absente, et si l'élément <DATA> est contenu dans un élément <DATA-GROUP>, alors l'adresse URI de base par défaut est censée être celle indiquée par l'attribut base. Pour les autres cas, comme toujours, l'adresse URI de base par défaut se réfère au même document ([URI]).
Ne pas oublier que les noms des éléments et des jeux de données sont sensibles à la casse (ainsi, par exemple, user.gender se distingue de USER.GENDER ou User.Gender).
optional: Indique si le site impose, ou non, aux visiteurs de soumettre cet élément de données pour accéder à une ressource ou achever une transaction ; la valeur "no" signifie que l'élément de données n'est pas optionnel (donc obligatoire) et la valeur "yes", au contraire, qu'il est optionnel. La valeur implicite est "no". L'attribut optional n'apparaît que dans les politiques (pas dans les définitions des schémas de données).

Remarquez que les agents utilisateurs devraient prendre des précautions lorsqu'ils utilisent l'attribut optional dans le contexte d'une prise de décision automatisée. Si l'attribut optional est associé directement à un élément de données contrôlé par l'agent utilisateur (tels qu'une en-tête HTTP Referer ou un cookie), alors l'agent utilisateur devrait faire attention à ne pas transmettre ces données à des sites Web sur lesquels un élément de données est optionnel et où la politique du site ne correspondrait pas aux préférences de l'utilisateur si l'élément de données était obligatoire. De même, pour les éléments de données que les utilisateurs saisissent habituellement dans les formulaires, les agents utilisateurs devraient avertir les utilisateurs lorsque les pratiques d'un site vis-à-vis de données optionnelles ne correspondent pas à leurs préférences.

Les éléments <DATA> peuvent contenir les données réelles (comme défini pour l'élément <ENTITY>) et des informations sur la catégorie apparentée.

[45]    data-group  =  "<DATA-GROUP"
                       [" base=" quoted-URI]
                       ">"
                       *extension
                       1*dataref
                       *extension
                       "</DATA-GROUP>"

[46]    dataref     =  `<DATA" ref="` URI-reference `"`
                       [" optional=" `"` ("yes"|"no") `"`] ">"
                       [categories]    ; les catégories de l'élément de données.
                       [PCDATA]        ; la valeur éventuelle de l'élément de données
                       "</DATA>"

Ici, la valeur URI-reference est définie comme dans [URI].

Par exemple, le service qui voudrait référencer la ville de l'adresse du domicile de l'utilisateur, tous les éléments du jeu de données user.business-info et (en option) tous les éléments du jeu de données user.home-info.telecom indiquera dans sa politique P3P les références suivantes :

<DATA-GROUP>
<DATA ref="#user.home-info.city"/>
<DATA ref="#user.home-info.telecom" optional="yes"/>
<DATA ref="#user.business-info"/>
</DATA-GROUP>

Lorsque la valeur réelle d'une donnée est connue, elle peut apparaître dans l'élément <DATA>. Par exemple, cf. les exemples de politiques :

 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogueExemple</DATA>
   <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
...

3.4 Les catégories et l'élément `CATEGORIES`

Les catégories sont des éléments dans les éléments de données offrant aux utilisateurs et aux agents utilisateurs des indications concernant les usage prévus des données. Les catégories sont essentielles et facilitent la mise en œuvre et l'utilisation des agents utilisateurs P3P. Remarquez que les catégories ne sont pas des éléments de données : elles permettent simplement aux utilisateurs d'exprimer des préférences et des règles plus générales pour échanger leurs données. On NE DEVRAIENT PAS utiliser recourir aux catégories dans les sous-éléments <DATA> des éléments <ENTITY>.

On utilise les éléments suivants pour indiquer les catégories des données :

[47]    categories  =  "<CATEGORIES>" 1*category "</CATEGORIES>"

[48]    category    =  "<physical/>"    | ; coordonnées physiques
                       "<online/>"      | ; coordonnées en ligne
                       "<uniqueid/>"    | ; identificateurs uniques
                       "<purchase/>"    | ; informations d'achat
                       "<financial/>"   | ; informations financières
                       "<computer/>"    | ; informations sur le système
                       "<navigation/>"  | ; données de navigation et de parcours
                       "<interactive/>" | ; données interactives
                       "<demographic/>" | ; données démographiques et socio-économiques
                       "<content/>"     | ; contenu
                       "<state/>"       | ; mécanismes de gestion d'état
                       "<political/>"   | ; informations politiques
                       "<health/>"      | ; informations de santé
                       "<preference/>"  | ; données préférentielles
                       "<location/>"    | ; données géographiques
                       "<government/>   | ; identificateurs d'origine gouvernementale
                       "<other-category>" PCDATA "</other-category>" ; Autres

<physical/>: Coordonnées physiques : Les renseignements qui permettent de contacter ou de localiser une personne dans le monde physique, tels qu'un numéro de téléphone ou une adresse.
<online/>: Coordonnées en ligne : Les renseignements qui permettent de contacter ou de localiser une personne sur l'Internet, telle qu'une adresse électronique. Ces informations sont souvent indépendantes de l'ordinateur particulier utilisé pour accéder au réseau. (Cf. la catégorie Informations sur le système).
<uniqueid/>: Identificateurs uniques : Les identificateurs non financiers, à l'exclusion des identificateurs d'origine gouvernementale, émis dans le but d'identifier ou de reconnaître un individu de manière fiable. Sont concernés les identificateurs délivrés par un site Web ou un service.
<purchase/>: Informations d'achat : Les renseignements générés activement par l'achat d'un produit ou d'un service, y compris les informations concernant la méthode de paiement.
<financial/>: Informations financières : Les renseignements concernant les finances d'un individu dont les informations sur l'état du compte et son activité tels que la position du compte, l'historique des paiements ou des découverts, et les informations sur les achats effectués par individu ou l'utilisation d'instruments financiers, y compris celles concernant sa carte de crédit ou de retrait d'argent. Les informations concernant un achat discret par un individu, comme décrit dans la catégorie Informations d'achat, n'entrent pas seules dans le cadre de la catégorie Informations financières.
<computer/>: Informations sur le système : Les renseignements concernant le système informatique utilisé par l'individu pour accéder au réseau tels que le numéro IP, le nom de domaine, le type du navigateur ou le système d'exploitation.
<navigation/>: Données de navigation et de parcours : Les données générées passivement en navigant sur le site Web tels que les pages visitées et le temps passé à chaque page.
<interactive/>: Données interactives : Les données générées activement à la suite ou reflétant les interactions explicites avec un fournisseur de service au travers de son site tels que les requêtes vers un moteur de recherche ou le journal de l'activité d'un compte.
<demographic/>: Données démographiques et socio-économiques : Les données concernant des caractéristiques individuelles tels que le genre, l'âge et le revenu.
<content/>: Contenu : Les mots et les expressions contenus dans le corps d'un échange tels que le texte d'un courrier électronique, les articles postés dans une tribune publique ou les discussions en ligne.
<state/>: Mécanismes de gestion d'état : Les mécanismes permettant de conserver l'état d'une session avec un utilisateur ou de reconnaître automatiquement les utilisateurs ayant visité un certain site ou accédé à un certain contenu précédemment tels que les cookies HTTP.
<political/>: Informations politiques : L'appartenance ou l'affiliation à un groupe tels qu'une organisation religieuse, un syndicat, une association professionnelle, un parti politique, etc.
<health/>: Informations de santé : Les informations concernant la santé physique ou mentale d'un individu, son orientation sexuelle, l'utilisation ou la sollicitation de services ou de produits de santé et l'achat de services ou de produits de santé.
<preference/>: Données préférentielles : Les données concernant les goûts individuels tels que la couleur favorite ou les goûts musicaux.
<location/>: Données géographiques : Les informations pouvant servir à identifier la situation géographique courante d'un individu et de suivre ses déplacements telles que les données de positionnement GPS.
<<government/>>: Identificateurs d'origine gouvernementale : Les identificateurs délivrés par un gouvernement dans le but d'identifier un individu de manière fiable.
<other-category> chaîne </other-category>: Autres : Les autres types de données n'entrant pas dans les cadres définis précédemment. (Dans ce cas, une explication lisible par un humain devrait être fournie entre les balises <other-category> et </other-category>).

Les catégories computer, navigation, interactive et content peuvent se distinguer comme suit. La catégorie computer comprend les informations sur l'ordinateur de l'utilisateur y compris l'adresse IP et la configuration logicielle. Les données de type navigation décrivent le comportement effectif de l'utilisateur lors d'une navigation. Lorsqu'une adresse IP est stockée dans un fichier journal avec des informations relatives à l'activité de navigation, on devrait utiliser les deux catégories computer et navigation. La catégorie interactive correspond aux données sollicitées activement, hormi celles de navigation, afin d'obtenir un certain service utile d'un site. La catégorie content correspond aux informations échangées sur un site au motif de la communication.

On ne devrait se servir de la catégorie other que si les données requises n'entrent dans aucune autre catégorie.

Le protocole P3P utilise des catégories pour fournir des indications supplémentaires aux utilisateurs et aux agents utilisateurs sur le type d'information requis par un service. Bien que la plupart des données dans le schéma de données de base se rangent dans des catégories connues (ou un jeu de catégories connu), certains éléments de données peuvent se trouver dans plusieurs catégories, en fonction du contexte. Celles des catégories connues sont appellées éléments de données de catégorie fixe (ou, en abrégé, éléments de données fixes) et les autres éléments de données de catégorie variable (ou éléments de données variables). Les deux types d'élément sont décrits dans la section 5.7.

3.5 Le mécanisme d'extension : l'élément `EXTENSION`

Le protocole P3P offre un mécanisme souple et puissant permettant d'étendre sa syntaxe et sa sémantique grâce à l'élément <EXTENSION>. Cet élément sert à indiquer les parties de la politique, du fichier d'appel de politique ou du schéma de données qui appartiennent à une extension. La signification des données dans l'élément <EXTENSION> est définie par l'extension elle-même.

<EXTENSION>: Décrit une extension de la syntaxe.
optional: Cet attribut détermine si l'extension est obligatoire ou optionnelle. On indique qu'une extension est obligatoire en donnant la valeur "no" à l'attribut optional. Une extension obligatoire de la syntaxe P3P signifie que les applications qui ne comprennent pas cette extension ne pourront pas non plus comprendre la politique en entier (ou le fichier d'appel de politique, ou le schéma de données) qui la contient. Une extension optionnelle, l'attribut optional ayant la valeur "yes", signifie que les applications qui ne comprennent pas cette extension peuvent ignorer en toute sécurité le contenu de l'élément <EXTENSION> et poursuivre le traitement de la politique entière (ou du fichier d'appel de politique, ou du schéma de données) comme si de rien n'était. L'attribut optional n'est pas obligatoire : sa valeur implicite est "yes".

[49]    extension  =  "<EXTENSION" [" optional=" `"` ("yes"|"no") `"`] ">" PCDATA "</EXTENSION>"

Par exemple, si le site www.catalogue.example.com souhaite ajouter une fonctionnalité à P3P telle que seuls les utilisateurs vivant aux États-Unis, au Canada et au Mexique sont concernés par la collecte d'un certain jeu de données, il pourrait définir l'extension obligatoire suivante :

<DATA-GROUP>
...
<EXTENSION optional="no">
<COLLECTION-GEOGRAPHY type="include" xmlns="http://www.catalogue.example.com/P3P/region">
<USA/><Canada/><Mexique/>
</COLLECTION-GEOGRAPHY>
</EXTENSION>
</DATA-GROUP>

À l'inverse, si www.catalogue.example.com souhaite ajouter une extension qui annonce la localisation géographique du serveur, l'extension optionnelle suivante serait plus appropriée :

<POLICY>
<EXTENSION optional="yes">
<ORIGIN xmlns="http://www.catalogue.example.com/P3P/origine" country="USA"/>
</EXTENSION>
...
</POLICY>

L'attribut xmlns est significatif car il définit l'espace de nommage pour l'interprétation des noms des éléments et attributs utilisés dans l'extension. Remarquez que, comme spécifié dans [XML-Name], l'adresse URI de l'espace de nommage sert juste d'identificateur unique aux entités XML utilisées par l'extension. Toutefois, les fournisseurs de services PEUVENT fournir une page décrivant l'extension à l'adresse URI correspondante.

L'élément <EXTENSION> peut apparaître à diverses positions dans la syntaxe P3P : le schéma XML présent dans l'annexe 4 spécifie ces positions de manière normative (elles sont définies de manière informelle par la syntaxe ABNF et le DTD présent dans l'annexe 5).

3.6 Les préférences de l'utilisateur

Les agents utilisateurs DOIVENT documenter une méthode permettant d'importer et de traiter des préférences et DEVRAIENT en documenter une permettant de les exporter.

Les agents utilisateurs P3P DOIVENT agir en fonction des réglages de préférence sélectionnés par l'utilisateur. Pour cela, ils doivent être capables de traiter une politique, ou un fichier d'appel de politique, de manière à pouvoir évaluer chaque politique en fonction des préférences de l'utilisateur ou d'autres critères de réglage. Selon ces paramètres, l'agent utilisateur pourra, par exemple, vérifier la présence des parties obligatoires dans la politique P3P ou bien la validité de la syntaxe de la politique en entier.

4. Les politique compactes

Les politiques compactes sont des politiques P3P résumées fournissant aux agents utilisateurs des indications leur permettant de prendre des décisions rapides et synchrones pour l'application de la politique. Les politiques compactes représentent une optimisation des performances OPTIONNELLE pour les agents utilisateurs ainsi que pour les serveurs. Les agents utilisateurs qui n'obtiennent pas suffisamment d'informations dans une politique compacte pour prendre une décision en fonction des préférences de l'utilisateur DEVRAIENT récupérer la politique complète.

Dans P3P, les politiques compactes contiennent des informations de politique relatives à des cookies (cf. [COOKIES] et [STATE]). Le serveur Web est responsable de la construction d'une politique P3P compacte pour représenter les cookies référencés dans une politique complète. La politique spécifiée dans une politique P3P compacte s'applique aux données stockées dans tous les cookies placés au cours de la même réponse HTTP que la politique compacte, à tous les cookies placés par des scripts associés à cette réponse HTTP et aussi aux données reliées aux cookies.

4.1 L'appel des politiques compactes

Toute ressource HTTP PEUT inclure une politique P3P compacte au moyen de l'en-tête de réponse P3P (cf. section 2.2.2). Lorsqu'un site se sert d'en-têtes P3P, il DEVRAIT les inclure aux réponses de toutes les méthodes de requête appropriées, y compris les requêtes HEAD et OPTION.

L'en-tête de politique compacte P3P comporte une chaîne entre guillemets susceptible de contenir un ou plusieurs atomes séparés (d'où politique compacte). Les atomes peuvent apparaître dans n'importe quel ordre et le caractère espace est le seul délimiteur valide. La syntaxe de cette en-tête est la suivante :

[50]    compact-policy-field  =  `CP="` compact-policy `"`

[51]    compact-policy        =  compact-token *(" " compact-token)

[52]    compact-token         =  compact-access           |
                                 compact-disputes         |
                                 compact-remedies         |
                                 compact-non-identifiable |
                                 compact-purpose          |
                                 compact-recipient        |
                                 compact-retention        |
                                 compact-categories       |
                                 compact-test

Comme pour toutes les en-têtes HTTP, le nom du champs d'en-tête P3P est insensible à la casse. Par contre, la valeur du champs (c'est-à-dire, le contenu de l'en-tête) est sensible à la casse.

Si une réponse HTTP inclut plusieurs politiques compacte, les agents utilisateurs DOIVENT ignorer toutes celles après la première.

4.2 Le vocabulaire des politiques compactes

Les politiques compactes P3P recourent à des atomes qui représentent les éléments suivants du vocabulaire P3P : <ACCESS>, <CATEGORIES>, <DISPUTES>, <NON-INDENTIFIABLE>, <PURPOSE>, <RECIPIENT>, <REMEDIES>, <RETENTION> et <TEST>.

Si un atome apparaît plusieurs fois dans une seule politique compacte, sa sémantique est la même que si l'atome n'était apparu qu'une seule fois. Si un atome inconnu apparaîtt dans une politique compacte, sa sémantique est la même qui si cet atome était absent.

Le vocabulaire des politiques compactes P3P s'exprime à l'aide d'un code lisible par un développeur afin de réduire le nombre d'octets transférés via un réseau dans l'en-tête de réponse HTTP. La syntaxe des atomes est la suivante :

4.2.1 L'élément `ACCESS` compact

Les politiques compactes représentent les informations contenues dans l'élément <ACCESS> par des atomes formés d'un code en trois lettres :

[53]    compact-access  =  "NOI" | ; pour <nonident/>
                           "ALL" | ; pour <all/>
                           "CAO" | ; pour <contact-and-other/>
                           "IDC" | ; pour <ident-contact/>
                           "OTI" | ; pour <other-ident/>
                           "NON"   ; pour <none/>

4.2.2 L'élément `DISPUTES` compact

Si une politique P3P complète a un sous-élément <DISPUTES-GROUP> contenant un ou plusieurs éléments <DISPUTES>, alors le serveur devrait avertir l'agent utilisateur en lui fournissant un seul atome "DSP" dans le champ de politique compacte P3P :

[54]    compact-disputes  =  "DSP" ; il y a un ou plusieurs éléments DISPUTES

4.2.3 L'élément `REMEDIES` compact

Les informations contenues dans l'élément <REMEDIES> ont la représentation compacte suivante :

[55]    compact-remedies  =  "COR" | ; pour <correct/>
                             "MON" | ; pour <money/>
                             "LAW"   ; pour <law/>

4.2.4 L'élément `NON-IDENTIFIABLE` compact

La présence de l'élément <NON-IDENTIFIABLE> dans toutes les déclarations de la politique est signalée par un atome "NID" (remarquez qu'on NE DOIT PAS utiliser l'atome "NID" tant que l'élément <NON-IDENTIFIABLE> n'est pas présent dans chaque déclaration dans la politique) :

[56]    compact-non-identifiable  =  "NID" ; pour <NON-IDENTIFIABLE/>

4.2.5 L'élément `PURPOSE` compact

Dans une politique P3P compacte, les intentions sont représentées par des atomes composés d'un code en trois lettres plus un attribut optionnel représenté par une lettre. Ces attributs optionnels codent la valeur de l'attribut required trouvé dans une politique P3P complète : sa valeur peut être "a", "i" ou "o", ce qui équivaut respectivement aux valeurs "always", "opt-in" ou "opt-out" de l'attribut required dans la politique P3P correspondante.

Si une politique P3P compacte doit représenter une ou plusieurs intentions <other-purpose> de la politique P3P complète, on n'utilisera qu'un seul drapeau "OTP" pour signaler à l'agent utilisateur l'existence d'une ou de plusieurs intentions <other-purpose> dans la politique P3P complète.

Les correspondances entre les intentions de la politiques P3P complète et les codes de la politique compacte sont les suivantes :

[57]    compact-purpose  =  "CUR"        | ; pour <current/>
                            "ADM" [creq] | ; pour <admin/>
                            "DEV" [creq] | ; pour <develop/>
                            "TAI" [creq] | ; pour <tailoring/>
                            "PSA" [creq] | ; pour <pseudo-analysis/>
                            "PSD" [creq] | ; pour <pseudo-decision/>
                            "IVA" [creq] | ; pour <individual-analysis/>
                            "IVD" [creq] | ; pour <individual-decision/>
                            "CON" [creq] | ; pour <contact/>
                            "HIS" [creq] | ; pour <historical/>
                            "TEL" [creq] | ; pour <telemarketing/>
                            "OTP" [creq]   ; pour <other-purpose/>

[58]    creq             =  "a" | ; pour "always"
                            "i" | ; pour "opt-in"
                            "o"   ; pour "opt-out"

4.2.6 L'élément `RECIPIENT` compact

Dans une politique P3P compacte, les destinataires sont représentés par des atomes composés d'un code en trois lettres plus un attribut optionnel représenté par une lettre. Ces attributs optionnels codent la valeur de l'attribut required trouvé dans une politique P3P complète : sa valeur peut être "a", "i" ou "o", ce qui équivaut respectivement aux valeurs "always", "opt-in" ou "opt-out" de l'attribut required dans la politique P3P correspondante.

Les correspondances entre les destinataires de la politique P3P complète et les codes de la politique compacte sont les suivantes :

[59]    compact-recipient  =  "OUR"        | ; pour <ours/>
                              "DEL" [creq] | ; pour <delivery/>
                              "SAM" [creq] | ; pour <same/>
                              "UNR" [creq] | ; pour <unrelated/>
                              "PUB" [creq] | ; pour <public/>
                              "OTR" [creq]   ; pour <other-recipient/>

4.2.7 L'élément `RETENTION` compact

Les informations contenues dans un élément <RETENTION> ont la représentation compacte suivante :

[60]    compact-retention  =  "NOR" | ; pour <no-retention/>
                              "STP" | ; pour <stated-purpose/>
                              "LEG" | ; pour <legal-requirement/>
                              "BUS" | ; pour <business-practices/>
                              "IND"   ; pour <indefinitely/>

4.2.8 L'élément `CATEGORIES` compact

Les catégories sont représentées dans les politiques compactes comme suit :

[61]    compact-categories  =  "PHY" | ; pour <physical/>
                               "ONL" | ; pour <online/>
                               "UNI" | ; pour <uniqueid/>
                               "PUR" | ; pour <purchase/>
                               "FIN" | ; pour <financial/>
                               "COM" | ; pour <computer/>
                               "NAV" | ; pour <navigation/>
                               "INT" | ; pour <interactive/>
                               "DEM" | ; pour <demographic/>
                               "CNT" | ; pour <content/>
                               "STA" | ; pour <state/>
                               "POL" | ; pour <political/>
                               "HEA" | ; pour <health/>
                               "PRE" | ; pour <preference/>
                               "LOC" | ; pour <location/>
                               "GOV" | ; pour <government/>
                               "OTC"   ; pour <other-category/>

Remarquez que, si une politique P3P complète indique une ou plusieurs catégories <other-category/>, on n'utilisera qu'un seul atome "OTC" dans la politique compacte pour signaler à l'agent utilisateur l'existence d'une ou de plusieurs catégories <other-category/> dans la politique P3P complète.

4.2.9 L'élément `TEST` compact

La présence de l'élément <TEST> est signalée par l'atome "TST" :

[62]    compact-test  =  "TST" ; pour <TEST/>

4.3 La portée d'une politique compacte

Lorsqu'une politique P3P compacte est incluse dans une en-tête de réponse HTTP, elle s'applique aux cookies installés par la réponse courante. C'est-à-dire, les cookies placés au moyen d'une en-tête HTTP Set-Cookie ou ceux placés par un script.

4.4 La durée de vie d'une politique compacte

Pour utiliser des politiques compactes, il faut que la validité de la politique P3P compacte couvre la durée de vie du cookie. Aucune méthode ne permet d'indiquer que la validité de la politique dépasse la durée de vie du cookie parce que les valeurs mises en cache par l'agent utilisateur sont marginales, dans la mesure où les sites ne sauraient pas s'ils doivent optimiser en n'envoyant pas de politique compacte. Lorsqu'un serveur envoie une politique compacte, il fait valoir que la politique compacte et la politique P3P complète correspondante seront en vigueur pour au moins la durée de vie du cookie sur lequel la politique compacte s'applique.

4.5 La transformation d'une politique P3P en une politique compacte

Lorsqu'un site Web utilise des politiques P3P compactes, il est tenu de construire une politique compacte en résumant les politiques appelées par les éléments <COOKIE-INCLUDE> d'un fichier d'appel de politique P3P. Si le fichier d'appel de politique d'un site utilise des éléments <COOKIE-EXCLUDE>, alors le site devra gérer l'envoi des politiques P3P compactes à l'agent utilisateur, en fonction des cookies installés au cours d'une réponse particulière.

La transformation d'une politique P3P en une politique P3P compacte peut se traduire par une perte descriptive des informations de politique, la politique compacte risquant de ne pas contenir toutes les informations de politique trouvées dans la politique P3P complète. Ces informations de la politique complète qui auront disparu pour la construction de la politique compacte comprennent l'élément <EXPIRY>, les éléments <DATA-GROUP>/<DATA>, <ENTITY> et <CONSEQUENCE>, et les éléments <DISPUTES> seront réduits.

Les politiques complètes incluant des extensions obligatoires NE DOIVENT PAS être représentées par des politiques compactes.

On DOIT assembler toutes les intentions, tous les destinataires et toutes les catégories qui apparaissent dans les diverses déclarations d'une politique complète pour une politique compacte, comme décrit dans la section 3.3.1. Au cours de l'assemblage, le site Web DOIT divulguer tous les atomes concernés (cf. l'exemple 4.1 dans lequel plusieurs politiques de rétention sont spécifiées).

En outre, pour chaque élément de données de catégorie fixe apparaissant dans une déclaration, la catégorie associée telle que définie dans le schéma correspondant DOIT être incluse dans la politique compacte.

Exemple 4.1 :

Supposons la politique P3P suivante :

 <POLICY name="echantillon" 
   discuri="http://www.example.com/politique_cookie.html"
   opturi="http://www.example.com/opt.html">
   <ENTITY>
     <DATA-GROUP>
       <DATA ref="#business.name">Exemple, Corp.</DATA>
       <DATA ref="#business.contact-info.online.email">vieprivee@example.com</DATA>
     </DATA-GROUP>
   </ENTITY>
   <ACCESS><none/></ACCESS>
   <DISPUTES-GROUP>
     <DISPUTES resolution-type="service"
      service="http://www.example.com/confidentialite.html"
      short-description="Pour les questions de confidentialité, merci de
                         contacter notre service clientèle en envoyant
                         un courrier électronique à vieprivee@example.com"/>
   </DISPUTES-GROUP>
   <STATEMENT>
     <PURPOSE><admin/><develop/><pseudo-decision/></PURPOSE>
     <RECIPIENT><ours/></RECIPIENT>
     <RETENTION><indefinitely/></RETENTION>
     <DATA-GROUP>
       <DATA ref="#dynamic.cookies">
         <CATEGORIES><preference/><navigation/></CATEGORIES>
       </DATA>
     </DATA-GROUP>
   </STATEMENT>
   <STATEMENT>
     <PURPOSE><individual-decision required="opt-out"/></PURPOSE>
     <RECIPIENT><ours/></RECIPIENT>
     <RETENTION><stated-purpose/></RETENTION>
     <DATA-GROUP>
       <DATA ref="#user.name.given"/>
       <DATA ref="#dynamic.cookies">
         <CATEGORIES><preference/><uniqueid/></CATEGORIES>
       </DATA>
     </DATA-GROUP>
   </STATEMENT>
 </POLICY>

La politique compacte correspondante sera la suivante :

"NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"

4.6 La transformation d'une politique compacte en une politique P3P

Certains agents utilisateurs pourront essayer de générer une politique P3P complète à partir d'une politique compacte dans le but d'évaluer les préférences de l'utilisateur. Ils ne pourront pas fournir de valeurs pour les éléments <ENTITY> et <DISPUTES> tout comme pour un certain nombre d'attributs. Néanmoins :

Au cas où il n'y a pas plusieurs valeurs de rétention compacte différentes,: ils devraient pouvoir générer une politique avec un élément <ACCESS> adéquat et un seul élément <STATEMENT> contenant les éléments <RECIPIENT>, <RETENTION> et <PURPOSE> adéquats, ainsi qu'un élément dynamic.miscdata avec l'élément <CATEGORIES> adéquat.
Au cas où il y a plusieurs valeurs de rétention compacte différentes,: ils devraient pouvoir générer une politique avec un élément <ACCESS> adéquat et plusieurs éléments <STATEMENT> (autant qu'il y a de valeurs différentes de rétention compactes) contenant une valeur correspondante différente pour l'élément <RETENTION>, l'élément <RECIPIENT> adéquat et des éléments <PURPOSE>, ainsi qu'un élément dynamic.miscdata avec l'élément <CATEGORIES> adéquat.

Remarquez que, conformément aux conditions de non-ambiguïté déclarées dans la section 2.4.1, un site DOIT honorer, dans tous les cas, une politique compacte pour une adresse URI donnée (même si la politique complète référencée dans le fichier d'appel de politique pour cette adresse URI ne correspond pas, selon la section 4.5, à la politique compacte elle-même).

5. Les schémas de données

Un schéma de données représente une description d'un jeu de données. Le protocole P3P permet de décrire des schémas de données afin que les services puissent communiquer avec les agents utilisateurs au sujet des données qu'ils collectent. Un schéma de données se construit à partir d'un certain nombre d'éléments de données, qui sont des items de données spécifiques susceptibles d'être collectés par les services.

Les éléments de données d'un schéma de données peuvent avoir les propriétés suivantes :

Nom de l'élément de données. Le nom de l'élément de données est utilisé lorsqu'une politique P3P inclut cet élément dans un élément <DATA>. Il est obligatoire pour tous les éléments de données ;
Nom descriptif ou nom abrégé. Le nom abrégé d'un élément de données fournit un nom bref et compréhensible par un humain pour l'élément de données. Le nom abrégé n'est pas obligatoire mais fortement recommandé ;
Description longue. La description longue d'un élément de donnée fournit une définition plus détaillée et compréhensible par un humain de l'élément de données. Comme pour le nom abrégé, il n'est pas obligatoire mais fortement recommandé ;
Catégorie ou catégories. La plupart du temps, les éléments de données ont des catégories assignées lorsqu'ils sont définis dans un schéma de données. Cf. la section sur les catégories pour plus d'informations.

Les éléments de données sont organisés selon une hiérarchie. Un élément de données inclut automatiquement tous ceux situés plus bas dans la hiérarchie. Par exemple, l'élément de données représentant le nom de l'utilisateur inclut ceux représentant le prénom de l'utilisateur, le nom de famille de l'utilisateur, et ainsi de suite. La hiérarchie est fondée sur le nom de l'élément de données. Ainsi les éléments de données user.name.given, user.name.family et user.name.nickname sont tous des sous-éléments de l'élément de données user.name lequel est, à son tour, un sous-élément de l'élément de données user.

Le protocole P3P définit un schéma de données, appelé schéma de données P3P de base, qui comprend un grand nombre d'éléments de données d'utilisation courante pour les services.

Les services peuvent déclarer des nouveaux éléments de données en créant leurs propres schémas de données à l'aide d'un élément <DATASCHEMA>. Les schémas de données peuvent se présenter sous deux formes : publiés dans des fichiers XML autonomes (dont l'élément racine est alors <DATASCHEMA>) ou incorporés dans un fichier de politique (le cas échéant, dans le même fichier dont les politiques appellent alors le schéma de données en question).

L'élément <DATASCHEMA> est défini comme suit :

[63]    dataschema  =  "<DATASCHEMA" [` xmlns="http://www.w3.org/2002/01/P3Pv1"`] [xml-lang] ">"
                       *(datadef|datastruct|extension)
                       "</DATASCHEMA>"

L'élément racine du fichier XML constituant un schéma de données autonome est élément <DATASCHEMA>. L'attribut xmlns définit l'espace de nommage approprié qui permet de l'identifier comme schéma de données P3P :

<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1">
<DATA-STRUCT ... />
...
<DATA-DEF ... />
</DATASCHEMA>

En option, l'élément <DATASCHEMA> peut contenir un attribut xml:lang (cf. la section 2.4.2).

Lorsqu'on déclare un schéma de données dans un fichier de politique, alors l'élément <DATASCHEMA> reste toujours utilisé (comme décrit dans la section 3.2.1 L'élément <POLICIES>).

5.1 La gestion des langues des schémas de données

Les schémas de données contiennent un certain nombre de champs en langage naturel. Le service qui publie un schéma de données PEUT vouloir traduire ces champs dans diverses langues. Les noms longs et abrégés des éléments de données PEUVENT être traduits mais on NE DOIT PAS traduire le nom de l'élément de données (ce champ doit rester constant d'une traduction du schéma de données à l'autre).

Si un service veut fournir un schéma de données en plusieurs langues, alors il DEVRAIT examiner l'en-tête de requête HTTP Accept-Language, lors des requêtes vers ce schéma de données, afin de retenir la meilleure option disponible.

5.2 Les structures de données

Les schémas de données réutiliseront souvent un groupe d'éléments de données commun. Une structure de données est une définition abstraite nommée d'un groupe d'éléments de données. Lors de la définition d'un élément de données, on peut le définir comme étant d'un type non structuré, auquel cas il n'a aucun sous-élément. On peut aussi définir l'élément de données comme étant d'un type structuré spécifique, auquel cas il sera automatiquement développé pour inclure, comme sous-éléments, tous les éléments définis dans la structure de données. Par exemple, on utilise la structure suivante pour représenter une date et une heure :

<!-- Structure de données "date" -->
<DATA-STRUCT name="date.ymd.year"
    short-description="Année"/>

<DATA-STRUCT name="date.ymd.month"
    short-description="Mois"/>

<DATA-STRUCT name="date.ymd.day"
    short-description="Jour"/>

<DATA-STRUCT name="date.hms.hour"
    short-description="Heure"/>

<DATA-STRUCT name="date.hms.minute"
    short-description="Minute"/>

<DATA-STRUCT name="date.hms.second"
    short-description="Seconde"/>

Maintenant, nous allons définir un élément de données "rendezvous", avec une heure et un lieu de rendez-vous :

<DATA-DEF name="rendezvous.heure"
    short-description="Heure du rendez-vous"
    structref="#date"/>
<DATA-DEF name="rendezvous.lieu"
    short-description="Lieu du rendez-vous"/>

Comme rendezvous.lieu n'appelle aucune structure, il s'agit donc d'un type non structuré qui n'a aucun sous-élément. L'élément rendezvous.heure utilise la structure date. Par cette déclaration, on crée les sous-éléments suivants :

rendezvous.heure.ymd.year
rendezvous.heure.ymd.month
rendezvous.heure.ymd.day
rendezvous.heure.hms.hour
rendezvous.heure.hms.minute
rendezvous.heure.hms.second

La politique P3P peut maintenant déclarer qu'elle collecte l'élément de données rendezvous, ce qui implique la collecte de tous les sous-éléments de rendezvous, ou elle peut aussi utiliser les éléments de données situés plus bas dans la hiérarchie (par exemple, rendezvous.heure ou rendezvous.heure.ymd.day).

5.3 Les éléments `DATA-DEF` et `DATA-STRUCT`

<DATA-DEF> et <DATA-STRUCT>: Définissent respectivement un élément de données et une structure de données. Les structures de données sont des définitions de types structurés réutilisables qui peuvent servir à construire des éléments de données. Les éléments de données sont déclarés dans un élément <STATEMENT> d'une politique P3P afin de décrire les données couvertes par cette déclaration.

Les attributs suivants sont communs aux deux éléments :

name (attribut obligatoire): Indique le nom de l'élément de données ou de la structure de données. Ne pas oublier que les noms des éléments de données et des structures de données sont sensibles à la casse, donc, par exemple, l'élément user.gender diffère de USER.GENDER ou de User.Gender. De plus, aucun caractère numérique ne peut apparaître immédiatement après un point dans les noms des éléments et des structures de données.
structref: Une adresse URI ([URI]), où la partie identificateur de fragment indique la structure et la partie URI indique le schéma de données correspondant où la structure est définie. L'adresse URI de base par défaut réfère au même document ([URI]). Les éléments de données et les structures de données sans attribut structref (et, de ce fait, sans structure associée), sont dits non structurés.
short-description: Une chaîne indiquant le nom d'affichage abrégé de l'élément ou de la structure de données ; elle ne contient pas plus de 255 caractères.

Les éléments <DATA-DEF> et <DATA-STRUCT> peuvent aussi contenir une description longue de l'élément ou de la structure de données, en utilisant l'élément <LONG-DESCRIPTION>.

[64]    datadef     =  "<DATA-DEF name=" quotedstring 
                       [` structref="` URI-reference `"`]
                       [" short-description=" quotedstring]
                       ">"
                       [categories] ; les catégories de l'élément de données. 
                       [longdescription] ; la description longue de l'élément de données.
                       "</DATA-DEF>"

[65]    datastruct  =  "<DATA-STRUCT name=" quotedstring 
                       [` structref="` URI-reference `"`]
                       [" short-description=" quotedstring]
                       ">"
                       [categories] ; les catégories de la strucutre de données. 
                       [longdescription] ; La description longue de la structure de données.
                       "</DATA-STRUCT>"

Ici, la valeur URI-reference est définie comme dans [URI].

Les éléments de données peuvent être structurés tout comme dans les langages de programmation courants. Les structures sont des descriptions hiérarchiques (arborescentes) d'éléments de données ; cette description hiérarchique, reflétée dans l'attribut name, se sert du caractère point . comme séparateur.

Le protocole P3P fournit un schéma de données P3P de base qui comporte les définitions d'un certain nombre de structures et d'éléments de données largement répandus. Toutes les mises en œuvre P3P sont tenues de reconnaître le schéma de données P3P de base, de sorte que les structures et les éléments qui y sont définis restent toujours disponibles pour les développeurs P3P.

Un schéma de données peut inclure plusieurs éléments <DATA-STRUCT> décrivant ensemble une structure. Par exemple, il n'y a pas d'élément <DATA-STRUCT> tout seul pour la structure de données uri (cf. section 5.5.7.1) dans le schéma de données P3P de base. Néanmoins, l'interprétation simultanée des éléments uri.authority, uri.stem et uri.querystring permet de définir cette structure.

5.3.1 Les catégories dans les schémas de données P3P

On peut assigner des catégories aux structures de données et aux éléments de données. Les règles suivantes définissent comment ces définitions de catégorie doivent être utilisées :

Les éléments <DATA-STRUCT> PEUVENT inclure des définitions de catégorie. Si une définition de structure comprend des catégories, alors toutes les utilisations de ces structures dans les définitions des données et des structures de données reprennent ces catégories. Si une structure ne contient aucune catégorie, alors on PEUT définir des catégories pour cette structure lorsque celle-ci est utilisées dans une autre structure ou un autre élément de données. Sinon, un élément de données utilisant cette structure est un élément de catégorie variable. Toute utilisation d'un élément de données de catégorie variable dans une politique exige que ses catégories soient listées dans cette politique ;
Un élément <DATA-DEF> de type non structuré est un élément de catégorie variable si aucune catégorie n'y est définie ou, si des catégories y sont incluses, il liste alors exactement ces catégories ;
Un élément <DATA-DEF> (ou <DATA-STRUCT>), de type structuré mais sans catégorie définie sur cette structure, produit un élément de données (ou une structure de données) de catégorie variable si aucune catégorie n'est définie dans l'élément <DATA-DEF> (ou dans l'élément <DATA-STRUCT>). Si l'élément <DATA-DEF> (ou <DATA-STRUCT>) liste des catégories, alors celles-ci s'appliquent à cet élément de données (ou à cette structure de données) et tous ses sous-éléments. En d'autres termes, les catégories sont héritées par les sous-éléments lorsqu'on définit un élément de données comme étant d'un type structuré et que ce type structuré ne définit aucune catégorie ;
Un élément <DATA-DEF> qui utilise un type structuré sur lequel des catégories sont définies reprend toutes les catégories listées sur la structure. En outre, l'élément <DATA-DEF> peut lister d'autres catégories qui s'ajoutent alors à celles définies dans la structure. Ces catégories ne sont définies qu'au niveau de cet élément de données et ne se répercutent pas aux sous-éléments ;
Un élément <DATA-STRUCT> sur lequel aucune catégorie n'est assignée, utilisant un sous-type structuré où des catégories sont définies, retient toutes les catégories listées sur ce sous-type ;
Un élément <DATA-STRUCT> sur lequel des catégories sont assignées, utilisant un sous-type structuré, remplace toutes les catégories qui y seraient listées ;
Il y a une règle de remontée des catégories lors de l'appel des éléments de données selon laquelle les éléments de données doivent au moins inclure toutes les catégories définies par leurs sous-éléments. Cette règle s'applique récursivement, de sorte que, par exemple, toutes les catégories définies par les éléments foo.a.w, foo.a.y et foo.b.z DEVRONT s'appliquer aux éléments de données foo ;
On ne peut pas définir un élément <DATA-STRUCT> avec certains sous-éléments étant de catégorie variable et d'autres étant de catégorie fixe. Tous les sous-éléments d'une structure doivent soit être de catégorie variable, soit avoir une ou plusieurs catégories assignées ;
On NE DOIT PAS appeler un élément <DATA-DEF> dont certains sous-éléments sont de catégorie variable et d'autres sont de catégorie fixe. On ne peut donc pas appeler la structure dynamic (cf. section 5.6.4 Les données dynamiques), appartenant au schéma de données de base, dans une politique (par contre, chacun de ses sous-éléments dynamic.clickstream, dynamic.http, etc. pourra l'être individuellement).

5.3.2 Exemple de schéma de données P3P

Étudions le cas d'une société GrandeVitesseExemple qui souhaite décrire les caractéristiques d'un véhicule en se servant d'une structure appelée vehicule. Cette structure comprend :

Le modèle du véhicule (vehicule.modele),
La couleur du véhicule (vehicule.couleur),
La date de construction du vehicule (vehicule.construction.annee) et
Le prix du véhicule (vehicule.prix).

Si la société GrandeVitesseExemple veut aussi inclure le lieu de construction dans la définition d'un véhicule, elle pourra ajouter d'autres champs à la structure avec toutes les données nécessaires comme le pays, l'adresse, le code postal, et ainsi de suite. Mais chaque partie de structure peut aussi recourir à d'autres structures : on peut composer les structures. Dans le cas présent, le schéma de données P3P de base fournit déjà la structure postal pour décrire toutes les informations postales concernant un lieu. La définition finale de la structure vehicule est donc :

vehicule.modele (non structuré)
vehicule.couleur (non structuré)
vehicule.prix (non structuré)
vehicule.construction.annee (non structuré)
vehicule.construction.lieu (avec la structure postal du schéma de données de base).

La structure postal comprend les champs postal.street, postal.city, etc. Puisque nous avons appliqué la structure postal à l'élément de données vehicule.construction.lieu, nous pouvons donc accéder à la rue et à la ville de construction d'un véhicule en utilisant respectivement les descriptions vehicule.construction.lieu.street et vehicule.construction.lieu.city. Par l'application d'une structure (la structure postal dans le cas présent), on peut ainsi construire des descriptions très complexes de façon modulaire.

La société GrandeVitesseExemple veut que toutes les informations concernant le véhicule soient de la catégorie <preference/>. Les champs vehicule.modele, vehicule.couleur, vehicule.prix et vehicule.construction.annee étant tous de type non structuré, on peut donc le faire en assignant à chacun la catégorie <preference/>. Puisque vehicule est une définition de structure, en assignant la catégorie <preference/> à vehicule.construction.lieu, on va remplacer les catégories définies sur les sous-éléments de vehicule.construction.lieu par la catégorie <preference/>, même si la structure postal était définie à l'origine comme étant dans d'autres catégories.

Comme dit précédemment, les structures ne contiennent pas d'élément de données : ce sont juste des types de données abstraits. On peut les utiliser pour construire rapidement des collections d'éléments de données structurées. En poursuivant avec cet exemple, la société GrandeVitesseExemple a besoin d'une description abstraite des caractéristiques d'un véhicule parce qu'elle veut en réalité échanger des données pour des voitures et des motos. Elle pourra donc définir deux éléments de données, appelés auto et moto, les deux s'appuyant sur la structure vehicule précédente.

Cette description des éléments de données et des structures de données se traduit en XML en recourant à un schéma de données. Dans le cas de la société GrandeVitesseExemple, ce schéma de données pourra avoir la forme suivante :

<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1">
<DATA-STRUCT name="vehicule.modele" 
    short-description="Modèle">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicule.couleur"
    short-description="Couleur">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicule.construction.annee" 
    short-description="Année de construction">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicule.construction.lieu" 
    structref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Lieu de construction">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-DEF name="auto" structref="#vehicule"/>
<DATA-DEF name="moto" structref="#vehicule"/>
</DATASCHEMA>

En poursuivant avec l'exemple, la société GrandeVitesseExemple ou n'importe quel autre service pourra référencer un modèle d'auto et l'année de sa construction en envoyant dans une politique P3P les appels suivants :

<DATA-GROUP>
  <!-- Premièrement, l'élément de données "auto.modele",
  dont la définition se trouve dans le schéma de données à
  http://www.GrandeVitesse.example.com/modeles-schema
    -->
<DATA ref="http://www.GrandeVitesse.example.com/modeles-schema#auto.modele"/>

  <!-- Deuxièmement, l'élément de données "auto.construction.annee",
  dont la définition se trouve dans le schéma de données à
  http://www.GrandeVitess.example.com/modeles-schema
    -->
<DATA ref="http://www.GrandeVitesse.example.com/modeles-schema#auto.construction.annee"/>
</DATA-GROUP>

En utilisant l'attribut base, on peut écrire les appels précédents d'une manière encore plus compacte :

<DATA-GROUP base="http://www.GrandeVitesse.example.com/modeles-schema">
    <DATA ref="#auto.modele"/>
    <DATA ref="#auto.construction.annee"/>
</DATA-GROUP>

Sinon on peut incorporer le schéma de données directement dans un fichier de politique, qui pourra être le suivant :

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<!-- Schéma de données incorporé -->
<DATASCHEMA>
<DATA-STRUCT name="vehicule.modele" 
    short-description="Modèle">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicule.couleur" 
    short-description="Couleur">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicule.construction.annee" 
    short-description="Année de construction"">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicule.construction.lieu" 
    structref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Lieu de construction">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-DEF name="auto" structref="#vehicule"/>
<DATA-DEF name="moto" structref="#vehicule"/>
</DATASCHEMA>
<!-- Fin du schéma de données incorporé -->
<POLICY name="politique1" discuri="http://www.example.com/disc1">
...
<DATA-GROUP base="">
<DATA ref="#auto.modele"/>
<DATA ref="#auto.construction.annee"/>
</DATA-GROUP>
...
</POLICY>
<POLICY name="politique2" discuri="http://www.example.com/disc2"> .... </POLICY>
<POLICY name="politique3" discuri="http://www.example.com/disc3"> .... </POLICY>
</POLICIES>

Dans tous les cas, il NE DOIT PAS y avoir plus d'un schéma de données par fichier.

5.3.3 L'utilisation des noms des éléments de données

Remarquez que les noms des éléments de données, indiqués dans le schéma de données de base ou dans les schémas de données des extensions, peuvent être utilisés ailleurs que dans les politiques P3P. Par exemple, les sites Web peuvent s'en servir pour nommer les champs des formulaires HTML. En référençant de la même façon les données des politiques P3P et des formulaires, on pourra intégrer plus facilement des routines pour remplir automatiquement les formulaires aux agents utilisateurs P3P.

5.4 La persistance des schémas de données

Une condition essentielle pour les schémas de données est la persistance : les schémas de données récupérables à une certaine adresse URI ne peuvent être changés qu'en les étendant de manière rétrocompatible (c'est-à-dire que le changement du schéma de données ne modifie pas le sens d'une politique qui l'utilise). Ainsi, l'adresse URI d'une politique agit d'une certaine façon comme un identificateur unique pour les éléments de données et les structures de données qui y sont contenus : tout schéma de données non rétrocompatible doit donc utiliser une adresse URI différente.

Remarquez que de la persistance du schéma de données peut se révéler utile, par exemple, dans le cas d'un site multilingue : le serveur peut offrir plusieurs versions (traductions) du même schéma de données en se servant du champs d'en-tête HTTP Content-Language afin d'indiquer exactement la langue particulière utilisée pour le schéma de données.

5.5 Les structures de données de base

Les structures de données de base sont celles utilisées par le schéma de données P3P de base (et, en raison de leur nature élémentaire, les autres schémas de données devraient autant que possible les réutiliser). Toutes les mises en œuvre d'agent utilisateur conformes à P3P DOIVENT reconnaître les structures de données de base. Chacun des tableaux suivants définit les éléments d'une structure de données de base, les catégories associées, leurs structures et les noms abrégés affichés aux utilisateurs. On peut associer plusieurs catégorie à un élément de données fixe. Toutefois, une catégorie seulement est associée à chaque élément de données de base tant que c'est possible. On recommande aux concepteurs de schémas de données de faire la même chose.

5.5.1 Les dates

La structure date définit une date. Dans la mesure où les informations de date peuvent s'employer de plusieurs façons, en fonction du contexte, toutes les informations de type date sont étiquetées comme étant de catégorie variable (cf. la section 5.7.2). Les définitions de schéma peuvent fixer explicitement la catégorie correspondante dans l'élément qui appelle cette structure, ainsi, par exemple, la demande de la date d'anniversaire d'un utilisateur pourra concerner la catégorie Données démographiques et socio-économiques tandis que la date d'expiration d'une carte de crédit relèvera de la catégorie Informations d'achat.

`date`	Catégorie	Structure	Nom abrégé
ymd.year	(catégorie variable)	non structuré	Année
ymd.month	(catégorie variable)	non structuré	Mois
ymd.day	(catégorie variable)	non structuré	Jour
hms.hour	(catégorie variable)	non structuré	Heure
hms.minute	(catégorie variable)	non structuré	Minute
hms.second	(catégorie variable)	non structuré	Seconde
fractionsecond	(catégorie variable)	non structuré	Fraction de seconde
timezone	(catégorie variable)	non structuré	Fuseau horaire

Par exemple, l'information du fuseau horaire est décrite dans le temps normalisé [ISO8601]. Remarquez qu'on peut utiliser respectivement date.ymd et date.hms pour appeler rapidement les blocs année/mois/jour et heure/minute/seconde.

5.5.2 Les noms

La structure personname définit les informations nominales d'une personne.

`personname`	Catégorie	Structure	Nom abrégé
prefix	Données démographiques et socio-économiques	non structuré	Titre
given	Coordonnées physiques	non structuré	Prénom
family	Coordonnées physiques	non structuré	Nom de famille
middle	Coordonnées physiques	non structuré	Deuxième prénom
suffix	Données démographiques et socio-économiques	non structuré	Suffixe de nom
nickname	Données démographiques et socio-économiques	non structuré	Surnom

5.5.3 Les connexions

La structure login définit les informations (identificateur et mot de passe) nécessaires aux systèmes informatiques et aux sites Web pour une authentification. Remarquez qu'on ne devrait pas se servir de cet élément de données pour les systèmes ou les sites Web utilisant des certificats d'authentification numériques : pour ces cas, on se servira de la structure certificate.

`login`	Catégorie	Structure	Nom abrégé
id	Identificateurs uniques	non structuré	Identifiant de connexion
password	Identificateurs uniques	non structuré	Mot de passe de connexion

Le champ id représente la partie ID de l'information de connexion pour un système informatique. Les ID des utilisateurs sont souvent rendus publics, tandis que les mots de passe sont tenus secrets. Les ID n'incluent aucun type de mécanisme d'authentification biométrique.

Le champ password représente la partie mot de passe de l'information de connexion pour un système informatique. C'est une donnée secrète, généralement une chaîne de caractères, utilisée pour l'authentification d'un utilisateur. Les mots de passe sont typiquement tenus secrets et constituent généralement une information sensible.

5.5.4 Les certificats

La structure certificate sert à définir des certificats d'identité (par exemple, les certificats X.509).

`certificate`	Catégorie	Structure	Nom abrégé
key	Identificateurs uniques	non structuré	Clé de certificat
format	Identificateurs uniques	non structuré	Format de certificat

Le champ format sert à représenter les informations de format d'une clé publique ou d'un certificat d'authentification enregistrés auprès de l'IANA, alors que le champ key sert à représenter la clé de certificat correspondante.

5.5.5 Les numéros de téléphone

La structure telephonenum définit les caractéristiques d'un numéro de téléphone.

`telephonenum`	Catégorie	Structure	Nom abrégé
intcode	Coordonnées physiques	non structuré	Indicatif téléphonique international
loccode	Coordonnées physiques	non structuré	Indicatif téléphonique régional
number	Coordonnées physiques	non structuré	Numéro de téléphone
ext	Coordonnées physiques	non structuré	Poste téléphonique supplémentaire
comment	Coordonnées physiques	non structuré	Commentaires téléphoniques optionnels

5.5.6 Les coordonnées

La structure contact sert à définir des coordonnées. Les services peuvent définir précisément le jeu de données dont ils ont besoin, à savoir les coordonnées postales, de télécommunication ou en ligne.

`contact`	Catégorie	Structure	Nom abrégé
postal	Coordonnées physiques, Données démographiques et socio-économiques	postal	Adresse postale
telecom	Coordonnées physiques	telecom	Télécommunications
online	Coordonnées en ligne	online	Adresse en ligne

5.5.6.1 Les coordonnées postales

La structure postal définit une adresse de courrier postal.

`postal`	Catégorie	Structure	Nom abrégé
name	Coordonnées physiques, Données démographiques et socio-économiques	personname	Nom
street	Coordonnées physiques	non structuré	Rue
city	Données démographiques et socio-économiques	non structuré	Ville
stateprov	Données démographiques et socio-économiques	non structuré	État ou province
postalcode	Données démographiques et socio-économiques	non structuré	Code postal
country	Données démographiques et socio-économiques	non structuré	Pays
organization	Données démographiques et socio-économiques	non structuré	Organisation

Le champ country représente le nom d'un pays (par exemple, un de ceux listés dans [ISO3166]).

5.5.6.2 Les coordonnées de télécommunication

La structure telecom définit les coordonnées de télécommunication concernant une personne.

`telecom`	Catégorie	Structure	Nom abrégé
telephone	Coordonnées physiques	telephonenum	Numéro de téléphone
fax	Coordonnées physiques	telephonenum	Numéro de télécopie
mobile	Coordonnées physiques	telephonenum	Numéro de mobile
pager	Coordonnées physiques	telephonenum	Numéro de téléavertisseur

5.5.6.3 Les coordonnées en ligne

La structure online définit les coordonnées en ligne concernant une personne physique ou morale.

`online`	Catégorie	Structure	Nom abrégé
email	Coordonnées en ligne	non structuré	Adresse électronique
uri	Coordonnées en ligne	non structuré	Adresse de page d'accueil

5.5.7 Les journaux d'accès et les adresses Internet

Deux structures servant à représenter les formes d'adresses Internet sont fournies : la structure uri qui couvre les identificateurs de ressource universels (URI, définis dans [URI] et la structure ipaddr qui représente les adresses IP et les noms d'hôte du système de nom de domaine (DNS).

5.5.7.1 Les adresses URI

`uri`	Catégorie	Structure	Nom abrégé
authority	(catégorie variable)	non structuré	Autorité de l'adresse URI
stem	(catégorie variable)	non structuré	Radical de l'adresse URI
querystring	(catégorie variable)	non structuré	Partie chaîne de requête de l'adresse URI

L'autorité d'une adresse URI correspond à la définition du composant authority dans [URI]. Le radical d'une adresse URI correspond aux informations contenues dans la partie de l'adresse URI située après l'autorité et jusqu'au premier caractère point d'interrogation ? compris, la chaîne de requête correspond aux informations contenues dans la portion de l'adresse URI située après le premier caractère point d'interrogation ?. Pour les adresses URI sans caractère point d'interrogation ?, le radical correspond à l'adresse URI entière et la chaîne de requête correspond à l'élément vide.

Puisque les informations contenues dans l'adresse URI peuvent s'utiliser de différentes manières, en fonction du contexte, tous les champs de la structure uri sont étiquetés comme étant de catégorie variable. Les définitions de schéma DOIVENT explicitement assigner la catégorie correspondante dans l'élément appelant cette structure de données.

5.5.7.2 Les adresses IP

La structure ipaddr représente le nom d'hôte et l'adresse IP d'un système.

`ipaddr`	Catégorie	Structure	Nom abrégé
hostname	Informations sur le système	non structuré	Nom d'hôte et de domaine complet
partialhostname	Informations démographiques et socio-économiques	non structuré	Nom d'hôte partiel
fullip	Informations sur le système	non structuré	Adresse IP complète
partialip	Informations démographiques et socio-économiques	non structuré	Adresse IP partielle

Le champ hostname sert à représenter une collection composée soit du simple nom d'hôte d'un système, soit du nom d'hôte complet, y compris le nom de domaine. Le champ partialhostname se compose d'un nom d'hôte entièrement qualifié, dont on a retiré au moins la partie hôte du nom d'hôte. En d'autres termes, on DOIT retirer tout ce qui va jusqu'au premier caractère point ., dans le nom d'hôte entièrement qualifié, pour qu'on puisse considérer l'adresse comme un nom d'hôte partiel.

Le champ fullip correspond à une adresse IP version 4 (ou IP version 6) complète. Le champ partialip représente une adresse IP version 4 (uniquement, et pas une adresse de version 6), dont au moins les sept derniers bits d'information ont été supprimés. On DOIT effectuer la suppression en remplaçant ces bits par un motif fixe pour tous les visiteurs (par exemple, seulement des 0 ou seulement des 1).

Certains sites Web sont connus pour ne pas utiliser l'adresse IP ou le nom d'hôte complets du visiteur, mais seulement une forme réduite. Par conséquent, la collecte d'un sous-ensemble des informations composant une adresse permet au visiteur du site de bénéficier d'une certaine forme d'anonymat. Cette spécification ne prétend absolument pas qu'il soit impossible d'associer ces adresses IP ou ces noms d'hôte tronqués à un utilisateur individuel, mais plutôt que cette association est rendue beaucoup plus difficile. Les sites qui opèrent cette réduction des données PEUVENT le déclarer afin de mieux refléter leurs pratiques.

5.5.7.3 Les informations du journal d'accès

La structure loginfo sert à représenter les informations stockées habituellement dans le journal des accès du serveur Web.

`loginfo`	Catégorie	Structure	Nom abrégé
uri	Données de navigation et de parcours	uri	Adresse URI de la ressource demandée
timestamp	Données de navigation et de parcours	date	Datation de la requête
clientip	Informations du système, Données démographiques et socio-économiques	ipaddr	Adresse IP ou nom d'hôte du client
other.httpmethod	Données de navigation et de parcours	non structuré	Méthode de requête HTTP
other.bytes	Données de navigation et de parcours	non structuré	Nombre d'octets de données dans la réponse
other.statuscode	Données de navigation et de parcours	non structuré	Code de statut de la réponse

La ressource objet de la requête HTTP est capturée par le champ uri. L'heure à laquelle le serveur traite la requête est représentée par le champ timestamp. Les mises en œuvre de serveur sont libres de définir ce champs comme le moment de la réception de la requête, le moment où le serveur a lancé l'envoi de la réponse, le moment où l'envoi de la réponse s'est terminé ou toute représentation commode du moment où la requête a été traitée. L'adresse IP du système client à l'origine de la requête est donnée par le champ clientip.

Les divers champs de données other représentent les autres informations stockées habituellement dans les journaux d'accès des serveurs Web. Le champ other.httpmethod représente la méthode HTTP (telle que GET, POST, etc.) utilisée dans la requête du client, le champ other.bytes le nombre d'octets dans le corps de la réponse envoyée par le serveur, le champ other.statuscode le code de statut HTTP de la requête, tel que 200, 302 ou 404 (cf. la section 6.1.1 de [HTTP1.1] pour des précisions).

5.5.7.4 Les autres informations du protocole HTTP

La structure httpinfo représente les informations véhiculées par le protocole HTTP non couvertes par la structure loginfo.

`httpinfo`	Catégorie	Structure	Nom abrégé
referer	Données de navigation et de parcours	uri	Dernière adresse URI demandée par l'utilisateur
useragent	Informations de système	non structuré	Agent utilisateur

Le champ useragent représente les informations contenues dans l'en-tête HTTP User-Agent qui renseigne sur les type et version du navigateur Web de l'utilisateur et/ou les en-têtes HTTP Accept*.

Le champ referer représente les informations contenues dans l'en-tête HTTP Referer qui renseigne sur la page précédente visitée par l'utilisateur. Remarquez que l'intitulé de ce champ contient une erreur orthographique tout comme l'en-tête HTTP correspondante (NdT. l'orthographe anglaise correcte est referrer).

5.6 Le schéma de données de base

Toutes les mises en œuvre d'agent utilisateur P3P conformes DOIVENT reconnaître les éléments de données du schéma de données P3P de base. Le schéma de données P3P de base comprend les définitions des structures de données de base et quatre jeux d'éléments de données : user, thirdparty, business et dynamic. Les jeux user, thirdparty et business comprennent des éléments auxquels les utilisateurs et/ou les entreprises peuvent donner des valeurs, alors que le jeu dynamic comprend des éléments automatiquement générés au cours de la session de navigation d'un utilisateur. Les agents utilisateurs peuvent gérer des mécanismes divers, y compris des mécanismes multi-utilisateurs, permettant aux utilisateurs de fixer les valeurs des éléments du jeu user et de stocker ces valeurs dans un référentiel de données. Les utilisateurs peuvent aussi ne pas fixer de valeur pour ces éléments de données.

La définition XML formelle du schéma de données P3P de base est fournie dans l'annexe 3. Dans les sections suivantes, les éléments de données et les jeux de données de base sont expliqués individuellement. Une demande pour la création d'autres jeux et éléments de données est très probable Les applications évidentes à prévoir comprennent les schémas de catalogue, de paiement et d'attributs d'agent/système (un jeu étendu d'éléments système est fourni en exemple dans http://www.w3.org/TR/NOTE-agent-attributes).

Chaque tableau suivant définit un jeu, les éléments de ce jeu, la catégorie associée à l'élément, la structure de l'élément et le nom abrégé affiché pour l'utilisateur. On peut associer plusieurs catégories à un élément de données fixe. Néanmoins, si c'est possible, chaque élément de données de base n'est associé qu'à une seule catégorie. On recommande aux concepteurs de schémas de données de faire de même.

5.6.1 Les données de l'utilisateur

Le jeu de données user inclut des informations générales au sujet de l'utilisateur.

`user`	Catégorie	Structure	Nom abrégé
name	Coordonnées physiques, Données démographiques et socio-économiques	personname	Nom de l'utilisateur
bdate	Données démographiques et socio-économiques	date	Date de naissance de l'utilisateur
login	Identificateurs uniques	login	Identifiant de connexion de l'utilisateur
cert	Identificateurs uniques	certificate	Certificat d'identité de l'utilisateur
gender	Données démographiques et socio-économiques	non structuré	Genre (masculin ou féminin)
employer	Données démographiques et socio-économiques	non structuré	Employeur de l'utilisateur
department	Données démographiques et socio-économiques	non structuré	Service ou division de l'organisation employant l'utilisateur
jobtitle	Données démographiques et socio-économiques	non structuré	Profession de l'utilisateur
home-info	Coordonnées physiques, Coordonnées en ligne, Données démographiques et socio-économiques	contact	Coordonnées de l'utilisateur au domicile
business-info	Coordonnées physique, Coordonnées en ligne, Données démographiques et socio-économiques	contact	Coordonnées de l'utilisateur au bureau

Remarquer que ce jeu de données comprend des éléments qui sont en réalité eux-mêmes des jeux de données. Ces jeux sont définis dans la sous-section Les structures de données de ce document. On définit le nom abrégé d'un élément individuel contenu dans un jeu de données comme étant la concaténation des noms abrégés d'affichage qui ont été définis pour le jeu et l'élément, délimités par des caractères appropriés selon la langue ou l'écriture en question, c'est-à-dire, des caractères virgule en français. Par exemple, le nom abrégé pour user.home-info.postal.postalcode pourrait être Coordonnées de l'utilisateur au domicile, Adresse postale, Code postal. Les mises en œuvre d'agent utilisateur peuvent choisir de développer leurs propres noms abrégés d'affichage au lieu d'utiliser des noms concaténés pour une présentation d'informations à l'utilisateur.

5.6.2 Les données d'un tiers

Le jeu de données thirdparty permet aux utilisateurs et aux entreprises de fournir des valeurs pour un tiers concerné. Ceci peut se révéler utile à chaque fois qu'on aura besoin d'échanger les informations d'un tiers, par exemple, lorsqu'on commande un cadeau en ligne devant être envoyé à une autre personne, ou lorsqu'on fournit des renseignements concernant un(e) époux(se) ou un(e) associé(e). Ces renseignements pourraient être stockés dans un référentiel d'utilisateur en accompagnement du jeu de données user. Les agents utilisateurs peuvent proposer de stocker plusieurs jeux de données thirdparty de ce type et permettre aux utilisateurs de sélectionner à la demande les valeurs appropriées dans une liste.

Le jeu de données thirdparty est identique au jeu de données user. Cf. la section 5.6.1 Les données de l'utilisateur pour des précisions.

5.6.3 Les données de l'entreprise

Le jeu de données business représente un sous-ensemble du jeu de données user convenant à la description des personnes morales. Dans le protocole P3P1.0, ce jeu de données sert principalement à déclarer l'entité responsable de la politique, bien que le jeu puisse aussi s'appliquer aux échanges interentreprises.

`business`	Catégorie	Structure	Nom abrégé
name	Données démographiques et socio-économiques	non structuré	Nom de l'organisation
department	Données démographiques et socio-économiques	non structuré	Service ou division de l'organisation
cert	Identificateurs uniques	certificate	Certificat d'identité de l'organisation
contact-info	Coordonnées physique, Coordonnées en ligne, Données démographiques et socio-économiques	contact	Coordonnées de l'organisation

5.6.4 Les données dynamiques

Dans certains cas, il est nécessaire de définir des éléments de données sans valeur fixe qu'un utilisateur peut saisir ou stocker dans un référentiel. Dans le schéma de données P3P de base, tous les éléments de ce type sont regroupés dans le jeu de données dynamic. Les sites peuvent se référer aux types des données qu'ils collectent en utilisant seulement le jeu de données dynamic, au lieu d'énumérer tous les éléments de données spécifiques.

`dynamic`	Catégorie	Structure	Nom abrégé
clickstream	Données de navigation et de parcours, Informations de système	loginfo	Informations de parcours
http	Données de navigation et de parcours, Informations de système	httpinfo	Informations de protocole HTTP
clientevents	Données de navigation et de parcours	non structuré	Interaction de l'utilisateur avec une ressource
cookies	(catégorie variable)	non structuré	Utilisation de cookies HTTP
miscdata	(catégorie variable)	non structuré	Informations diverses hors du schéma de données de base
searchtext	Données interactives	non structuré	Termes de recherche
interactionrecord	Données interactives	non structuré	Historique de l'échange stocké par le serveur

Ces éléments sont souvent implicites dans la navigation ou les interactions Web. On devrait les utiliser avec des catégories pour décrire le type d'information collecté par ces méthodes. Une brève description suit :

clickstream: L'élément clickstream s'appliquera quasiment à tous les sites Web. Il représente une combinaison d'informations trouvées typiquement dans les journaux d'accès des serveurs Web : l'adresse IP ou le nom d'hôte du système de l'utilisateur, l'adresse URI de la ressource demandée, le moment où la requête a eu lieu, la méthode HTTP employée pour la requête, la taille de la réponse et son code de statut. Les sites Web collectant les journaux d'accès standards des serveurs, ainsi que ceux analysant les chemins d'accès des adresses URI, peuvent recourir à cet élément de données afin de décrire comment sont utilisées les données. Les sites Web ne collectant qu'une partie des éléments de données listés pour l'élément clickstream PEUVENT opter pour lister ces éléments spécifiques au lieu de l'élément dynamic.clickstream en entier. Cela permet aux sites dont les pratiques de collecte des données sont plus limitées de présenter exactement ces pratiques à leurs visiteurs.
http: L'élément http contient des informations supplémentaires issues du protocole HTTP. Cf. la définition de la structure httpinfo pour la description des éléments spécifiques. Les sites PEUVENT utiliser le champ dynamic.http comme raccourci pour couvrir tous les éléments de la structure httpinfo, ou bien ils PEUVENT appeler individuellement les éléments de la structure httpinfo.
clientevents: L'élément clientevents représente des données liées au comportement de l'utilisateur vis-à-vis de son navigateur Web au cours d'une interaction avec une ressource. Par exemple, une application souhaite collecter les informations répondant aux questions suivantes : l'utilisateur a-t-il amené le pointeur sur telle image de telle page, ou a-t-il recouru à la fenêtre d'aide d'un applet Java. Ce type d'information est représenté par l'élément de données dynamic.clientevents. La majeure partie de l'enregistrement de ces interactions est représentée par les événements et les données définis dans la spécification du modèle objet de document (DOM) niveau 2 m‐ Événements [DOM2-Events]. L'élément clientevents couvre également toutes les autres données en rapport avec les interactions de l'utilisateur avec son navigateur au cours de l'affichage d'une ressource, à l'exception des événements couverts par d'autres éléments du schéma de données de base. Par exemple, le fait de requérir une page en cliquant sur un lien au cours de la consultation d'une page constitue une interaction de l'utilisateur avec son navigateur, tandis que le simple fait de collecter l'adresse URL correspondant au lien cliqué par l'utilisateur ne nécessite pas de déclarer cet élément de données : cet événement est couvert par clickstream. Par contre, l'événement DOM DOMFocusIn (représentant le déplacement du pointeur sur un objet d'une page par l'utilisateur) n'est couvert par aucun élément existant, et si un site enregistre l'occurrence de cet événement, il doit donc déclarer collecter l'élément dynamic.clientevents. Les items couverts par cet élément de données sont typiquement collectés côté client par des langages de script tel que JavaScript ou par des applets tels que des applets ActiveX ou Java. Bien que la discussion précédente tienne du point de vue d'un utilisateur voyant une ressource, remarquez que cet élément de données s'applique également aux applications Web non visuelles, par exemple, les navigateurs Web sonores.
cookies: On devrait utiliser l'élément cookies à chaque fois que des cookies HTTP sont installés ou récupérés par un site. Remarquez que cookies est un élément de données variable qui nécessite une déclaration explicite des catégories d'utilisation dans la politique.
miscdata: L'élément miscdata référence des informations collectées par un service ne recourant pas à un élément de données spécifique. On doit se servir de catégories afin de décrire mieux ces données : les sites DOIVENT référencer dans leurs politiques des éléments miscdata séparés pour chaque catégorie de données diverses collectées.
searchtext: L'élément searchtext référence un type de sollicitation particulier utilisé pour une recherche dans les sites et pour leur indexation. Par exemple, si les seuls champs de la page d'un moteur de recherche sont des champs de recherche, alors le site aura seulement besoin de divulguer cet élément de données.
interactionrecord: On devrait utiliser l'élément interactionrecord si le serveur garde la trace des interactions avec un utilisateurs (c'est-à-dire, d'autres informations que des données de parcours, par exemple, les transactions sur un compte, etc.).

5.7 Les catégories et les éléments/structures de données

5.7.1 Les éléments/structures de données de catégorie fixe

La plupart des éléments du schéma de données de base sont dits fixes : ils appartiennent à une ou deux (au plus) classes de catégorie. En assignant invariablement une catégorie aux éléments/structures du schéma de donnés de base, les services et les utilisateurs peuvent se référer à des groupes d'éléments entiers en appelant simplement la catégorie correspondante. Par exemple, en utilisant le langage d'échange de préférences de confidentialité [APPEL], les utilisateurs peuvent écrire des règles afin d'être avertis lorsqu'ils visiteront un site collectant des éléments de données d'une certaine catégorie.

Lors de la création de schémas de données pour des éléments de données fixes, les concepteurs doivent explicitement énumérer les catégories auxquelles ces éléments appartiennent. Par exemple :

<DATA-STRUCT name="postal.street"     structref="#text" 
          short-description="Nom de la rue">
<CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

Si un élément, ou une structure, appartient à plusieurs catégories, on peut utiliser plusieurs éléments référençant les catégories appropriées. Par exemple, le fragment XML suivant peut servir à déclarer que les éléments de données dans user.name ont les deux catégories physical et demographic :

<DATA-STRUCT name="user.name"     structref="#personname" 
          short-description="Nom de l'utilisateur">
<CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-STRUCT>

Remarquez qu'on ne peut pas supprimer les classes de catégorie des éléments/structures de données fixes, par exemple, en écrivant des règles ou des politiques assignant une catégorie différente à un élément de données de base fixe connu. Les agents utilisateurs DOIVENT ignorer ces catégories et continuer d'utiliser la catégorie d'origine (ou le jeu de catégories d'origine) listée dans la définition du schéma. Préférablement, les agents utilisateurs PEUVENT avertir l'utilisateur de l'emploi d'un élément de données fixe ayant une classe de catégorie non standard.

5.7.2 Les éléments/structures de données de catégorie variable

Les éléments/structures de données dans le schéma de données de base n'appartiennent pas tous à une classe de catégorie prédéfinie. Parmi eux, il y en a qui contiendront des informations provenant de diverses catégories, en fonction d'une situation donnée. Ces éléments ou structures de données sont appelés éléments/structures de données de catégorie variable (ou, en abrégé, éléments/structures de données variables. Bien que la plupart des éléments de données variables du schéma de données P3P de base soit combinée dans le jeu d'éléments dynamic, ils peuvent apparaître dans n'importe quel jeu de données, et même mélangés avec des éléments de données de catégorie fixe.

Lors de la création d'une définition de schéma pour ces éléments et/ou structures, les auteurs NE DOIVENT PAS lister d'attribut de catégorie explicite car autrement l'élément/structure devient fixe. Par exemple, lorsqu'on définit la structure de données year, qui est susceptible d'entrer dans plusieurs catégories selon le contexte (par exemple, une date d'expiration de carte de crédit par opposition à une date d'anniversaire), on peut utiliser la définition de schéma suivante :

<DATA-STRUCT name="date.ymd.year"
          short-description="Année"/>  <!-- Structure de données variable -->

Cela permet aux nouvelles extensions de schéma qui appellent ces structures de données de catégorie variable d'assigner une catégorie spécifique aux éléments dérivés, en fonction de leur emploi dans cette extension. Par exemple, une extension de schéma pour le commerce en ligne peut ainsi définir la date d'expiration d'une carte de crédit de la manière suivante :

<DATA-STRUCT name="Carte.DateExp"         structref="#date.ymd" 
          short-description="Date d'expiration de la carte">
<CATEGORIES><purchase/></CATEGORIES>
</DATA-STRUCT>

Dans ces conditions, on assigne la catégorie fixe Informations d'achat à la structure de données variable date lorsqu'elle sert à définir la date d'expiration d'une carte de crédit.

Bien que les préférences de l'utilisateur puissent lister ces éléments de données variables sans autre indication de catégorie (en exprimant en fait des préférences pour n'importe quelle utilisation de cet élément), remarquez que les services DOIVENT toujours définir explicitement les catégories qui s'appliquent à l'utilisation d'un élément de données variable dans leur politique particulière. Cette information doit prendre la forme d'un élément <CATEGORIES> dans l'élément <DATA> listé dans la politique, par exemple, comme dans l'exemple suivant :

<POLICY ... >
   ...
   <DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/></CATEGORIES></DATA>
   ...
</POLICY>

Dans cet exemple, un service déclare utiliser des cookies afin de reconnaître un utilisateur sur le site (c'est-à-dire, avec la catégorie Identificateurs uniques).

Si un service souhaite déclarer un élément de données qui apparaît dans plusieurs catégories, il déclare simplement les catégories correspondantes (comme illustré dans la section précédente) :

<POLICY ... >
   ...
   <DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/><preference/></CATEGORIES></DATA>
   ...
</POLICY>

Selon la déclaration ci-dessus, un service annonce utiliser des cookies afin de reconnaître l'utilisateur sur le site et afin de stocker des données concernant les préférences de l'utilisateur. Remarquez que, pour le protocole P3P, un stockage de ces renseignements sur deux cookies distincts ou sur un seul cookie ne fait aucune différence.

Enfin, remarquez que les catégories peuvent aussi s'hériter : les catégories se répercutent sur les sous-éléments si les champs sont structurés mais uniquement quand ceux-ci n'ont aucune catégorie prédéfinie. On suggère donc aux auteurs de schémas de faire au mieux afin de s'assurer que toutes les catégories concernées puissent s'appliquer aux nouveaux éléments de données qu'ils auront créés.

5.6 L'utilisation des éléments de données

Le protocole P3P offre aux sites Web une grande souplesse dans la manière de décrire les types de données qu'ils collectent :

Les sites peuvent décrire les données généralement en recourant à l'élément dynamic.miscdata et les catégories appropriées ;
Les sites peuvent décrire les données spécifiquement en recourant aux éléments de données définis dans le schéma de données de base ;
Les sites peuvent décrire les données spécifiquement en recourant aux éléments de données définis dans de nouveaux schémas de données.

On peut combiner n'importe lesquelles de ces trois méthodes dans une seule politique.

En utilisant l'élément dynamic.miscdata, les sites peuvent indiquer les types de données qu'ils collectent, sans devoir énumérer individuellement chaque élément de données. Cela peut se révéler commode pour les sites collectant beaucoup de données ou appartenant à de grandes organisations qui veulent offrir une seule politique P3P couvrant l'organisation entière. Toutefois, cette approche présente l'inconvénient selon lequel les agents utilisateurs supposeront que le site est susceptible de collecter n'importe quel élément de données appartenant aux catégories référencées par le site. Ainsi, par exemple, si la politique d'un site déclare collecter les éléments de données dynamic.miscdata de la catégorie Coordonnées physiques, alors qu'il ne collecte en réalité comme seules coordonnées physiques que les adresses au bureau, les agents utilisateurs supposeront néanmoins que le site peut aussi collecter les numéros de téléphone. Si le site souhaite préciser ne pas collecter les numéros de téléphone ni aucune autre coordonnée physique hormi les adresses au bureau, alors il devrait divulguer une collecte des éléments de données user.business-info.contact.postal. De plus, comme les agents utilisateurs tendent à offrir des fonctionnalités de remplissage automatique des formulaires, les sites qui énumèrent les données collectées exploiteront vraisemblablement mieux ces outils.

En définissant de nouveaux schémas de données, les sites peuvent indiquer précisément quelles données sont collectées, au-delà du jeu de données de base. Toutefois, si les agents utilisateurs ne reconnaissent pas les éléments définis dans ces schémas, ils ne pourront offrir à l'utilisateur qu'un minimum d'information sur ces nouveaux éléments. Les informations fournies seront fondées sur la catégorie et sur les noms abrégés indiqués pour chaque élément.

Indépendamment du souhait de divulguer des données générales ou bien particulières, un site peut trouver d'autres avantages à divulguer des éléments spécifiques en partant du jeu de données dynamic. Par exemple, en divulguant les éléments de données dynamic.cookies, un site peut indiquer recourir à des cookies et exposer les raisons de leur utilisation. On encourage les mises en œuvre d'agent utilisateur qui offrent des interfaces de contrôle des cookies en fonction de ces informations. De la même façon, les agents utilisateurs qui n'envoient pas, par défaut, d'en-tête HTTP Referer pourront rechercher l'élément de données dynamic.http.referer dans les politiques P3P et envoyer alors cette en-tête, à condition que l'intention déclarée soit acceptable pour l'utilisateur.

6. Annexes

Annexe 1 : Références (normatif)

[ABNF]: D. Crocker, P. Overel. Augmented BNF for Syntax Specifications: ABNF, RFC2234, IETF, novembre 1997.
Disponible à http://www.ietf.org/rfc/rfc2234.txt.
[CHARMODEL]: M. Dürst, et al. (rédacteurs.), Un modèle de caractère pour le World Wide Web, World Wide Web Consortium Brouillon, 20 février 2002.
Dernière version disponible à http://www.w3.org/TR/charmod/.
[DOM2-Events]: T. Pixley (Ed.), Spécification du modèle objet de document (DOM) niveau 2 — Événements →vf, World Wide Web Consortium, Recommandation. 13 novembre 2000.
Disponible à http://www.w3.org/TR/DOM-Level-2-Events/.
[HTTP1.0]: T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer Protocol — HTTP/1.0, RFC1945, IETF, mai 1996.
Disponible à http://www.ietf.org/rfc/rfc1945.txt.
[HTTP1.1]: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer Protocol — HTTP/1.1, RFC2616, IETF, juin 1999. [Met à jour RFC2068]
Disponible à http://www.ietf.org/rfc/rfc2616.txt.
[HTML]: D. Raggett, A. Le Hors et I. Jacobs (rédacteurs). La spécification HTML 4.01 →vf, World Wide Web Consortium, Recommandation. 24 décembre 1999.
Disponible à http://www.w3.org/TR/html401/.
[KEY]: S. Bradner. Key words for use in RFCs to Indicate Requirement Levels, RFC2119, IETF, mars 1997.
Disponible à http://www.ietf.org/rfc/rfc2119.txt.
[LANG]: H. Alvestrand, Tags for the Identification of Languages, RFC1766, IETF, 1995.
Disponible à http://www.ietf.org/rfc/rfc1766.txt.
[STATE]: D. Kristol, L. Montulli, HTTP State Management Mechanism, RFC2695, IETF, octobre 2000 [Remplace RFC2109]
Disponible à http://www.ietf.org/rfc/rfc2965.txt.
[URI]: T. Berners-Lee, R. Fielding et L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax and Semantics, RFC2396, IETF, août 1998. [Met à jour RFC1738]
Disponible à http://www.ietf.org/rfc/rfc2396.txt.
[UTF-8]: F. Yergeau. UTF-8, a transformation format of ISO 10646, RFC2279, IETF, janvier 1998.
Disponible à http://www.ietf.org/rfc/rfc2279.txt.
[XHTML-MOD]: M. Altheim, et al. (rédacteurs). Modularization of XHTML, World Wide Web Consortium, Recommandation. 10 avril 2000.
Disponible à http://www.w3.org/TR/xhtml-modularization/.
[XML]: T. Bray, J. Paoli, C. M. Sperberg-McQueen, E.Maler (rédacteurs). Spécification du langage de balisage extensible (XML) 1.0 (deuxième édition), World Wide Web Consortium, Recommandation. 6 octobre 2000.
Disponible à http://www.w3.org/TR/REC-xml.
[XML-Name]: T. Bray, D. Hollander, A. Layman (rédacteurs). Les espaces de nommage dans XML →vf, World Wide Web Consortium, Recommandation. 14 janvier 1999.
Disponible à http://www.w3.org/TR/REC-xml-names/.
[XML-Schema1]: H. Thompson, D. Beech, M. Maloney et N. Mendelsohn (rédacteurs). XML Schema Part 1: Structures World Wide Web Consortium Recommandation. 2 mai 2001.
Disponible à http://www.w3.org/TR/xmlschema-1/.
[XML-Schema2]: P. Biron, A. Malhotra (Eds.). XML Schema - Tome 2 : Types de données World Wide Web Consortium Recommandation. 2 mai 2001.
Disponible à http://www.w3.org/TR/xmlschema-2/.

Annexe 2 : Références (non normatif)

[APPEL]: M. Langheinrich (rédacteur). A P3P Preference Exchange Language (APPEL), World Wide Web Consortium Working Draft. 26 février 2001.
Disponible à http://www.w3.org/TR/P3P-preferences.
[CACHING]: I. Cooper, I. Melve, G. Tomlinson. Internet Web Replication and Caching Taxonomy, RFC3040, IETF, janvier 2001.
Disponible à http://www.ietf.org/rfc/rfc3040.txt.
[COOKIES]: Persistent Client State — HTTP Cookies, Preliminary Specification, Netscape, 1999.
Disponible à http://www.netscape.com/newsref/std/cookie_spec.html.
[ISO3166]: "ISO3166: Codes for The Representation of Names of Countries." International Organization for Standardization.
[ISO8601]: "ISO8601: Data elements and interchange formats -- Information interchange -- Representation of dates and times." International Organization for Standardization.
[P3P-HEADER]: M. Marchiori, R. Lotenberg (rédacteurs), "The HTTP header for the Platform for Privacy Preferences 1.0 (P3P1.0)." IETF Internet Draft, 2002.
Dernière version disponible en texte à http://www.w3.org/2002/04/P3Pv1-header.txt.
Dernière version disponible en HTML à http://www.w3.org/2002/04/P3Pv1-header.html.
Dernière version disponible en XML à http://www.w3.org/2002/04/P3Pv1-header.xml.
[P3P-RDF]: B. McBride, R.Wenning, L.Cranor. An RDF Schema for P3P, World Wide Web Consortium, Note. 25 janvier 2002.
Dernière version disponible à http://www.w3.org/TR/p3p-rdfschema/.
[RDF]: O. Lassila and R. Swick (rédacteurs). Spécification du modèle et de la syntaxe du cadre de description des ressources (RDF) →vf, World Wide Web Consortium, Recommandation. 22 février 1999.
Disponible à http://www.w3.org/TR/REC-rdf-syntax/.
[UNICODE]: Unicode Consortium. The Unicode Standard,
Disponible à http://www.unicode.org/unicode/standard/standard.html.

Annexe 3 : La définition du schéma de données P3P de base (normatif)

On présente à la suite le schéma de données correspondant au schéma de données P3P de base pour en faciliter la consultation. Le schéma est également disponible dans un fichier séparé à l'adresse URI http://www.w3.org/TR/P3P/base.

<DATASCHEMA xmlns="http://www.w3.org/2002/01/P3Pv1">
<!-- ********** Structures de données de base ********** -->

<!-- Structure de données "date" -->
<DATA-STRUCT name="date.ymd.year"
    short-description="Année"/>

<DATA-STRUCT name="date.ymd.month"
    short-description="Mois"/>

<DATA-STRUCT name="date.ymd.day"
    short-description="Jour"/>

<DATA-STRUCT name="date.hms.hour"
    short-description="Heure"/>

<DATA-STRUCT name="date.hms.minute"
    short-description="Minute"/>

<DATA-STRUCT name="date.hms.second"
    short-description="Seconde"/>

<DATA-STRUCT name="date.fractionsecond"
    short-description="Fraction de seconde"/>

<DATA-STRUCT name="date.timezone"
    short-description="Fuseau horaire"/>

<!-- Structure de données "login" -->
<DATA-STRUCT name="login.id"
    short-description="Identifiant de connexion">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="login.password"
    short-description="Mot de passe de connexion">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "personname" -->
<DATA-STRUCT name="personname.prefix"
    short-description="Titre">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.given"
    short-description="Prénom">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.middle"
    short-description="Deuxième prénom">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.family"
    short-description="Nom de famille">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.suffix"
    short-description="Suffixe de nom">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.nickname"
    short-description="Surnom">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "certificate" -->
<DATA-STRUCT name="certificate.key"
    short-description="Clé de certificat">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="certificate.format"
    short-description="Format de certificat">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "telephonenum" -->
<DATA-STRUCT name="telephonenum.intcode"
    short-description="Indicatif téléphonique international">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.loccode"
    short-description="Indicatif téléphonique régional">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.number"
    short-description="Numéro de téléphone">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.ext"
    short-description="Poste téléphonique supplémentaire">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.comment"
    short-description="Commentaire téléphonique optionnel">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "postal" -->
<DATA-STRUCT name="postal.name" structref="#personname">
</DATA-STRUCT>

<DATA-STRUCT name="postal.street"
    short-description="Rue">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.city"
    short-description="Ville">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.stateprov"
    short-description="État ou province">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.postalcode"
    short-description="Code postal">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.organization"
    short-description="Nom de l'organisation">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.country"
    short-description="Pays">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "telecom" -->
<DATA-STRUCT name="telecom.telephone"
    short-description="Numéro de téléphone"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telecom.fax"
    short-description="Numéro de télécopie"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telecom.mobile"
    short-description="Numéro de mobile"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telecom.pager"
    short-description="Numéro de téléavertisseur"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "online" -->
<DATA-STRUCT name="online.email"
    short-description="Adresse électronique">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="online.uri"
    short-description="Adresse de page d'accueil">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "contact" -->
<DATA-STRUCT name="contact.postal"
    short-description="Adresse postale"
    structref="#postal">
</DATA-STRUCT>

<DATA-STRUCT name="contact.telecom"
    short-description="Coordonnées de télécommunication"
    structref="#telecom">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="contact.online"
    short-description="Coordonnées en ligne"
    structref="#online">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "uri" -->
<DATA-STRUCT name="uri.authority"
    short-description="Autorité d'adresse URI"/>

<DATA-STRUCT name="uri.stem"
    short-description="Radical d'adresse URI"/>

<DATA-STRUCT name="uri.querystring"
    short-description="Partie chaîne de requête d'adresse URI"/>

<!-- Structure de données "ipaddr" -->
<DATA-STRUCT name="ipaddr.hostname"
    short-description="Nom d'hôte et de domaine complet">
    <CATEGORIES><computer/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="ipaddr.partialhostname"
    short-description="Nom d'hôte partiel">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="ipaddr.fullip"
    short-description="Adresse IP complète">
    <CATEGORIES><computer/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="ipaddr.partialip"
    short-description="Adresse IP partielle">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "loginfo" -->
<DATA-STRUCT name="loginfo.uri"
    short-description="Adresse URI de la ressource demandée"
    structref="#uri">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.timestamp"
    short-description="Datation de la requête"
    structref="#date">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.clientip"
    short-description="Adresse IP ou nom d'hôte du client"
    structref="#ipaddr">
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.other.httpmethod"
    short-description="Méthode de requête HTTP">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.other.bytes"
    short-description="Nombre d'octets de données dans la réponse">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.other.statuscode"
    short-description="Code de statut de la réponse">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<!-- Structure de données "httpinfo" -->
<DATA-STRUCT name="httpinfo.referer"
    short-description="Dernière adresse URI demandée par l'utilisateur"
    structref="#uri">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="httpinfo.useragent"
    short-description="Informations sur l'agent utilisateur">
    <CATEGORIES><computer/></CATEGORIES>
</DATA-STRUCT>

<!-- ********** Schémas de données de base ********** -->

<!-- Schéma de données "dynamic" -->
<DATA-DEF name="dynamic.clickstream"
    short-description="Information de parcours"
    structref="#loginfo">
    <CATEGORIES><navigation/><computer/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.http"
    short-description="Informations de protocole HTTP"
    structref="#httpinfo">
    <CATEGORIES><navigation/><computer/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.clientevents"
    short-description="Interaction de l'utilisateur avec une ressource">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.cookies"
    short-description="Utilisation de cookies HTTP"/>

<DATA-DEF name="dynamic.searchtext"
    short-description="Termes de recherche">
    <CATEGORIES><interactive/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.interactionrecord"
    short-description="Historique de l'échange stocké par le serveur">
    <CATEGORIES><interactive/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.miscdata"
    short-description="Informations diverses hors schéma de données de base"/>

<!-- Schéma de données "user" -->
<DATA-DEF name="user.name"
    short-description="Nom de l'utilisateur"
    structref="#personname">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.bdate"
    short-description="Date de naissance de l'utilisateur"
    structref="#date">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.login"
    short-description="Identifiant de connexion de l'utilisateur"
    structref="#login">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.cert"
    short-description="Certificat d'identité de l'utilisateur"
    structref="#certificate">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.gender"
    short-description="Genre de l'utilisateur">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.jobtitle"
    short-description="Profession de l'utilisateur">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.home-info"
    short-description="Coordonnées de l'utilisateur au domicile"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.business-info"
    short-description="Coordonnées de l'utilisateur au bureau"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.employer"
    short-description="Nom de l'employeur de l'utilisateur">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.department"
    short-description="Service ou division de l'organisation employant l'utilisateur">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<!-- Schéma de données "thirdparty" -->
<DATA-DEF name="thirdparty.name"
    short-description="Nom du tiers"
    structref="#personname">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.bdate"
    short-description="Date d'anniversaire du tiers"
    structref="#date">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.login"
    short-description="Identification de connexion du tiers"
    structref="#login">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.cert"
    short-description="Certificat d'identité du tiers"
    structref="#certificate">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.gender"
    short-description="Genre du tiers">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.jobtitle"
    short-description="Profession du tiers">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.home-info"
    short-description="Coordonnées du tiers au domicile"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.business-info"
    short-description="Coordonnées du tiers au bureau"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.employer"
    short-description="Nom de l'employeur du tiers">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.department"
    short-description="Service ou division de l'organisation employant le tiers">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<!-- Schéma de données "business" -->
<DATA-DEF name="business.name"
    short-description="Nom de l'organisation">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="business.department"
    short-description="Service ou division de l'organisation">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="business.cert"
    short-description="Certificat d'identité de l'organisation"
    structref="#certificate">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="business.contact-info"
    short-description="Coordonnées de l'organisation"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

</DATASCHEMA>

Annexe 4 : La définition du schéma XML (normatif)

Cette annexe contient le schéma XML pour les fichiers d'appel de politique P3P, pour les documents de politique P3P et pour les documents de schéma de données P3P. Les fichiers d'appel de politique P3P, les documents de politique P3P et les documents de schéma de données P3P sont des documents XML qui DOIVENT se conformer à ce schéma. Remarquer que ce schéma se base sur la spécification XML Schéma [XML-Schema1][XML-Schema2]. Le schéma est également disponible en fichier séparé à l'URI http://www.w3.org/2002/01/P3Pv1.xsd.

<?xml version='1.0' encoding='UTF-8'?>
<schema
  xmlns='http://www.w3.org/2001/XMLSchema'
  xmlns:p3p='http://www.w3.org/2002/01/P3Pv1'
  targetNamespace='http://www.w3.org/2002/01/P3Pv1'
  elementFormDefault='qualified'>

<!-- activation de l'attribut xml:lang -->
 <import namespace='http://www.w3.org/XML/1998/namespace' 
    schemaLocation='http://www.w3.org/2001/xml.xsd' />

<!-- Type de données P3P de base -->
 <simpleType name='yes_no'>
  <restriction base='string'>
   <enumeration value='yes'/>
   <enumeration value='no'/>
  </restriction>
 </simpleType>


<!-- *********** Appel de politique *********** -->
<!-- ************** META ************** -->
 <element name='META'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:POLICY-REFERENCES'/>
    <element ref='p3p:POLICIES' minOccurs='0'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute ref='xml:lang' use='optional'/>
  </complexType>
 </element>

<!-- ******* POLICY-REFERENCES ******** -->
 <element name='POLICY-REFERENCES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:POLICY-REF' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:HINT' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  </complexType>
 </element>

 <element name='POLICY-REF'>
  <complexType>
   <sequence>
    <element name='INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='anyURI'/>
    <element name='EXCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='anyURI'/>
    <element name='COOKIE-INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='p3p:cookie-element'/>
    <element name='COOKIE-EXCLUDE'
             minOccurs='0' maxOccurs='unbounded' type='p3p:cookie-element'/>
    <element name='METHOD' 
             minOccurs='0' maxOccurs='unbounded' type='anyURI'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='about' type='anyURI' use='required'/>
  </complexType>
 </element>

 <complexType name='cookie-element'>
  <attribute name='name' type='string' use='optional'/>
  <attribute name='value' type='string' use='optional'/>
  <attribute name='domain' type='string' use='optional'/>
  <attribute name='path' type='string' use='optional'/>
 </complexType>

<!-- ************* HINT ************* -->
 <element name='HINT'>
  <complexType>
   <attribute name='scope' type='string' use='required'/>
   <attribute name='path' type='string' use='required'/>
  </complexType>
 </element>

<!-- ************ POLICIES ************ -->
 <element name='POLICIES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:DATASCHEMA' minOccurs='0'/>
    <element ref='p3p:POLICY' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute ref='xml:lang' use='optional'/>
  </complexType>
 </element>


<!-- ************* EXPIRY ************* -->
 <element name='EXPIRY'>
  <complexType>
   <attribute name='max-age' type='nonNegativeInteger' use='optional'/>
   <attribute name='date' type='string' use='optional'/>
  </complexType>
 </element>

<!-- **************** Politique **************** -->
<!-- ************* POLICY ************* -->
 <element name='POLICY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:TEST' minOccurs='0'/>
    <element ref='p3p:ENTITY'/>
    <element ref='p3p:ACCESS'/>
    <element ref='p3p:DISPUTES-GROUP' minOccurs='0'/>
    <element ref='p3p:STATEMENT' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='discuri' type='anyURI' use='required'/>
   <attribute name='opturi' type='anyURI' use='optional'/>
   <attribute name='name' type='ID' use='required'/>
   <attribute ref='xml:lang' use='optional'/>
  </complexType>
 </element>

<!-- ************* TEST ************* -->
 <element name='TEST'>
  <complexType/>
 </element>

<!-- ************* ENTITY ************* -->
 <element name='ENTITY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element name='DATA-GROUP'>
     <complexType>
      <sequence>
       <element name='DATA' type='p3p:data-in-entity' maxOccurs='unbounded'/>
      </sequence>
     </complexType>
    </element>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='data-in-entity' mixed='true'>
  <attribute name='ref' type='anyURI' use='required'/>
 </complexType>

<!-- ************* ACCESS ************* -->
 <element name='ACCESS'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice>
     <element name='nonident' type='p3p:access-value'/>
     <element name='ident-contact' type='p3p:access-value'/>
     <element name='other-ident' type='p3p:access-value'/>
     <element name='contact-and-other' type='p3p:access-value'/>
     <element name='all' type='p3p:access-value'/>
     <element name='none' type='p3p:access-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='access-value'/>

<!-- ************ DISPUTES ************ -->
 <element name='DISPUTES-GROUP'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:DISPUTES' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <element name='DISPUTES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice minOccurs='0'>
     <sequence>
      <element ref='p3p:LONG-DESCRIPTION'/>
      <element ref='p3p:IMG' minOccurs='0'/>
      <element ref='p3p:REMEDIES' minOccurs='0'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
     <sequence>
      <element ref='p3p:IMG'/>
      <element ref='p3p:REMEDIES' minOccurs='0'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
     <sequence>
      <element ref='p3p:REMEDIES'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
    </choice>
   </sequence>
   <attribute name='resolution-type' use='required'>
    <simpleType>
     <restriction base='string'>
      <enumeration value='service'/>
      <enumeration value='independent'/>
      <enumeration value='court'/>
      <enumeration value='law'/>
     </restriction>
    </simpleType>
   </attribute>
   <attribute name='service' type='anyURI' use='required'/>
   <attribute name='verification' type='string' use='optional'/>
   <attribute name='short-description' type='string' use='optional'/>
  </complexType>
 </element>

<!-- ******** LONG-DESCRIPTION ******** -->
 <element name='LONG-DESCRIPTION'>
  <simpleType>
   <restriction base='string'/>
  </simpleType>
 </element>

<!-- ************** IMG *************** -->
 <element name='IMG'>
  <complexType>
   <attribute name='src' type='anyURI' use='required'/>
   <attribute name='width' type='nonNegativeInteger' use='optional'/>
   <attribute name='height' type='nonNegativeInteger' use='optional'/>
   <attribute name='alt' type='string' use='required'/>
  </complexType>
 </element>

<!-- ************ REMEDIES ************ -->
 <element name='REMEDIES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice maxOccurs='unbounded'>
     <element name='correct' type='p3p:remedies-value'/>
     <element name='money' type='p3p:remedies-value'/>
     <element name='law' type='p3p:remedies-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='remedies-value'/>

<!-- *********** STATEMENT ************ -->
 <element name='STATEMENT'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element name='CONSEQUENCE' minOccurs='0' type='string'/>
    <choice>
     <sequence>
      <element ref='p3p:PURPOSE'/>
      <element ref='p3p:RECIPIENT'/>
      <element ref='p3p:RETENTION'/>
      <element name='DATA-GROUP' type='p3p:data-group-type' maxOccurs='unbounded'/>
     </sequence>
     <sequence>
      <element name='NON-IDENTIFIABLE'/>
      <element ref='p3p:PURPOSE' minOccurs='0'/>
      <element ref='p3p:RECIPIENT' minOccurs='0'/>
      <element ref='p3p:RETENTION' minOccurs='0'/>
      <element name='DATA-GROUP' type='p3p:data-group-type' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

<!-- ************ PURPOSE ************* -->
 <element name='PURPOSE'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice maxOccurs='unbounded'>
     <element name='current' type='p3p:purpose-value'/>
     <element name='admin' type='p3p:purpose-value'/>
     <element name='develop' type='p3p:purpose-value'/>
     <element name='tailoring' type='p3p:purpose-value'/>
     <element name='pseudo-analysis' type='p3p:purpose-value'/>
     <element name='pseudo-decision' type='p3p:purpose-value'/>
     <element name='individual-analysis' type='p3p:purpose-value'/>
     <element name='individual-decision' type='p3p:purpose-value'/>
     <element name='contact' type='p3p:purpose-value'/>
     <element name='historical' type='p3p:purpose-value'/>
     <element name='telemarketing' type='p3p:purpose-value'/>
     <element name='other-purpose'>
      <complexType mixed='true'>
       <attribute name='required' use='optional' type='p3p:required-value'/>
      </complexType>
     </element>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <simpleType name='required-value'>
  <restriction base='string'>
   <enumeration value='always'/>
   <enumeration value='opt-in'/>
   <enumeration value='opt-out'/>
  </restriction>
 </simpleType>

 <complexType name='purpose-value'>
  <attribute name='required' use='optional' type='p3p:required-value' default='always' />
 </complexType>

<!-- *********** RECIPIENT ************ -->
 <element name='RECIPIENT'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice maxOccurs='unbounded'>
     <element name='ours'>
      <complexType>
       <sequence>
        <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
       </sequence>
      </complexType>
     </element>
     <element name='same' type='p3p:recipient-value'/>
     <element name='other-recipient' type='p3p:recipient-value'/>
     <element name='delivery' type='p3p:recipient-value'/>
     <element name='public' type='p3p:recipient-value'/>
     <element name='unrelated' type='p3p:recipient-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='recipient-value'>
  <sequence>
   <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  <attribute name='required' use='optional' type='p3p:required-value'/>
 </complexType>

 <element name='recipient-description'>
  <complexType mixed='true'/>
 </element>

<!-- *********** RETENTION ************ -->
 <element name='RETENTION'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice>
     <element name='no-retention' type='p3p:retention-value'/>
     <element name='stated-purpose' type='p3p:retention-value'/>
     <element name='legal-requirement' type='p3p:retention-value'/>
     <element name='indefinitely' type='p3p:retention-value'/>
     <element name='business-practices' type='p3p:retention-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='retention-value'/>

<!-- ************** DATA ************** -->
 <complexType name='data-group-type'>
  <sequence>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   <element name='DATA' type='p3p:data-in-statement' maxOccurs='unbounded'/>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  <attribute name='base' type='anyURI' 
             use='optional' default='http://www.w3.org/TR/P3P/base'/>
 </complexType>

 <complexType name='data-in-statement' mixed='true'>
  <sequence minOccurs='0' maxOccurs='unbounded'>
   <element ref='p3p:CATEGORIES'/>
  </sequence>
  <attribute name='ref' type='anyURI' use='required'/>
  <attribute name='optional' use='optional' default='no' type='p3p:yes_no'/>
 </complexType>

<!-- ************** Schéma de données ************* -->
<!-- *********** DATASCHEMA *********** -->
 <element name='DATASCHEMA'>
  <complexType>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:DATA-DEF'/>
    <element ref='p3p:DATA-STRUCT'/>
    <element ref='p3p:EXTENSION'/>
   </choice>
   <attribute ref='xml:lang' use='optional'/>
  </complexType>
 </element>

 <element name='DATA-DEF' type='p3p:data-def'/>
 <element name='DATA-STRUCT' type='p3p:data-def'/>

 <complexType name='data-def'>
  <sequence>
   <element ref='p3p:CATEGORIES' minOccurs='0'/>
   <element ref='p3p:LONG-DESCRIPTION' minOccurs='0'/>
  </sequence>
  <attribute name='name' type='ID' use='required'/>
  <attribute name='structref' type='anyURI' use='optional'/>
  <attribute name='short-description' type='string' use='optional'/>
 </complexType>

<!-- *********** CATEGORIES *********** -->
 <element name='CATEGORIES'>
  <complexType>
   <choice maxOccurs='unbounded'>
    <element name='physical' type='p3p:categories-value'/>
    <element name='online' type='p3p:categories-value'/>
    <element name='uniqueid' type='p3p:categories-value'/>
    <element name='purchase' type='p3p:categories-value'/>
    <element name='financial' type='p3p:categories-value'/>
    <element name='computer' type='p3p:categories-value'/>
    <element name='navigation' type='p3p:categories-value'/>
    <element name='interactive' type='p3p:categories-value'/>
    <element name='demographic' type='p3p:categories-value'/>
    <element name='content' type='p3p:categories-value'/>
    <element name='state' type='p3p:categories-value'/>
    <element name='political' type='p3p:categories-value'/>
    <element name='health' type='p3p:categories-value'/>
    <element name='preference' type='p3p:categories-value'/>
    <element name='location' type='p3p:categories-value'/>
    <element name='government' type='p3p:categories-value'/>
    <element name='other-category' type='string'/>
   </choice>
  </complexType>
 </element>

 <complexType name='categories-value'/>

<!-- *********** EXTENSION ************ -->
 <element name='EXTENSION'>
  <complexType mixed='true'>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <any minOccurs='0' maxOccurs='unbounded' processContents='skip'/>
   </choice>
   <attribute name='optional' use='optional' default='yes' type='p3p:yes_no'/>
  </complexType>
 </element>

</schema>

Annexe 5 : La définition du DTD XML (non normatif)

Cet annexe contient le DTD pour les fichiers d'appel de politique P3P, pour les documents de politiques P3P et pour les documents de schéma de données P3P. Ce DTD PEUT servir à vérifier la validité des fichiers P3P (bien que certains fichiers valides puissent être rejetés dans la vérification contre le DTD). Le DTD est également disponible dans un fichier séparé à l'adresse URI http://www.w3.org/2002/01/P3Pv1.dtd.

<!-- *************** Entités *************** -->
<!ENTITY % URI "CDATA">
<!ENTITY % NUMBER "CDATA">

<!-- *********** Référence de politique *********** -->

<!-- ************** META ************** -->
<!ELEMENT META (EXTENSION*, POLICY-REFERENCES, POLICIES?, EXTENSION*)>
<!ATTLIST META xml:lang NMTOKEN #IMPLIED>
<!ATTLIST META xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1">

<!-- ******* POLICY-REFERENCES ******** -->
<!ELEMENT POLICY-REFERENCES (EXPIRY?, POLICY-REF*, HINT*, EXTENSION*)>

<!-- *********** POLICY-REF *********** -->
<!ELEMENT POLICY-REF (INCLUDE*,
    EXCLUDE*,
    COOKIE-INCLUDE*,
    COOKIE-EXCLUDE*,
    METHOD*,
    EXTENSION*)>
<!ATTLIST POLICY-REF
    about %URI; #REQUIRED >

<!-- ************** HINT ************** -->
<!ELEMENT HINT EMPTY>
<!ATTLIST HINT
    scope  CDATA  #IMPLIED
    path   CDATA  #IMPLIED >

<!-- ************* EXPIRY ************* -->
<!ELEMENT EXPIRY EMPTY>
<!ATTLIST EXPIRY
    max-age %NUMBER; #IMPLIED
    date    CDATA    #IMPLIED >

<!-- ************ POLICIES ************ -->
<!ELEMENT POLICIES (EXPIRY?, DATASCHEMA?,
    POLICY*)>
<!ATTLIST POLICIES xml:lang NMTOKEN #IMPLIED>
<!ATTLIST POLICIES xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1">

<!-- ***** INCLUDE/EXCLUDE/METHOD ***** -->
<!ELEMENT INCLUDE          (#PCDATA)>
<!ELEMENT EXCLUDE          (#PCDATA)>
<!ELEMENT COOKIE-INCLUDE   EMPTY>
<!ATTLIST COOKIE-INCLUDE
    name   CDATA  #IMPLIED
    value  CDATA  #IMPLIED
    domain CDATA  #IMPLIED
    path   CDATA  #IMPLIED>
<!ELEMENT COOKIE-EXCLUDE   EMPTY>
<!ATTLIST COOKIE-EXCLUDE
    name   CDATA  #IMPLIED
    value  CDATA  #IMPLIED
    domain CDATA  #IMPLIED
    path   CDATA  #IMPLIED>
<!ELEMENT METHOD           (#PCDATA)>

<!-- **************** Politique **************** -->

<!-- ************* POLICY ************* -->
<!ELEMENT POLICY (EXTENSION*,
    TEST?,
    ENTITY,
    ACCESS,
    DISPUTES-GROUP?,
    STATEMENT+,
    EXTENSION*)>
<!ATTLIST POLICY
    name     ID      #REQUIRED
    discuri  %URI;   #REQUIRED
    opturi   %URI;   #IMPLIED
    xml:lang NMTOKEN #IMPLIED>

<!-- ******** TEST ******** -->
<!ELEMENT TEST EMPTY>

<!-- ************* ENTITY ************* -->
<!ELEMENT ENTITY (EXTENSION*, DATA-GROUP, EXTENSION*)>

<!-- ************* ACCESS ************* -->
<!ELEMENT ACCESS (EXTENSION*,
   (nonident
    | all
    | contact-and-other
    | ident-contact
    | other-ident
    | none),
    EXTENSION*)>
<!ELEMENT nonident          EMPTY>
<!ELEMENT all               EMPTY>
<!ELEMENT contact-and-other EMPTY>
<!ELEMENT ident-contact     EMPTY>
<!ELEMENT other-ident       EMPTY>
<!ELEMENT none              EMPTY>

<!-- ************ DISPUTES ************ -->
<!ELEMENT DISPUTES-GROUP (EXTENSION*, DISPUTES+, EXTENSION*)>
<!ELEMENT DISPUTES (EXTENSION*,
    ( (LONG-DESCRIPTION, IMG?, REMEDIES?, EXTENSION*)
      | (IMG, REMEDIES?, EXTENSION*)
      | (REMEDIES, EXTENSION*) )?)>
<!ATTLIST DISPUTES
    resolution-type   (service | independent | court | law) #REQUIRED
    service           %URI;                                 #REQUIRED
    verification      CDATA                                 #IMPLIED
    short-description CDATA                                 #IMPLIED >

<!-- ******** LONG-DESCRIPTION ******** -->
<!ELEMENT LONG-DESCRIPTION (#PCDATA)>

<!-- ************** IMG *************** -->
<!ELEMENT IMG EMPTY>
<!ATTLIST IMG
    src    %URI;    #REQUIRED
    width  %NUMBER; #IMPLIED
    height %NUMBER; #IMPLIED
    alt    CDATA    #REQUIRED >

<!-- ************ REMEDIES ************ -->
<!ELEMENT REMEDIES (EXTENSION*, (correct | money | law)+, EXTENSION*)>
<!ELEMENT correct EMPTY>
<!ELEMENT money   EMPTY>
<!ELEMENT law     EMPTY>

<!-- *********** STATEMENT ************ -->
<!ELEMENT STATEMENT (EXTENSION*,
    CONSEQUENCE?,
    ((PURPOSE,RECIPIENT,RETENTION,DATA-GROUP+)|
     (NON-IDENTIFIABLE,PURPOSE?,RECIPIENT?,RETENTION?,DATA-GROUP*)),
    EXTENSION*)>

<!-- ********** CONSEQUENCE *********** -->
<!ELEMENT CONSEQUENCE (#PCDATA)>

<!-- ******** NON-IDENTIFIABLE ******** -->
<!ELEMENT NON-IDENTIFIABLE EMPTY>

<!-- ************ PURPOSE ************* -->
<!ELEMENT PURPOSE (EXTENSION*,
   (current
    | admin
    | develop
    | customization errata E3
    | tailoring
    | pseudo-analysis
    | pseudo-decision
    | individual-analysis
    | individual-decision
    | contact
    | historical
    | telemarketing
    | other-purpose)+,
    EXTENSION*)>

<!ENTITY % pur_att
         "required (always | opt-in | opt-out) #IMPLIED">
<!ELEMENT current             EMPTY>
<!ATTLIST current             %pur_att;>
<!ELEMENT admin               EMPTY>
<!ATTLIST admin               %pur_att;>
<!ELEMENT develop             EMPTY>
<!ATTLIST develop             %pur_att;>
<!ELEMENT customization       EMPTY>
<!ATTLIST customization       %pur_att;>
<!ELEMENT tailoring           EMPTY>
<!ATTLIST tailoring           %pur_att;>
<!ELEMENT pseudo-analysis     EMPTY>
<!ATTLIST pseudo-analysis     %pur_att;>
<!ELEMENT pseudo-decision     EMPTY>
<!ATTLIST pseudo-decision     %pur_att;>
<!ELEMENT individual-analysis EMPTY>
<!ATTLIST individual-analysis %pur_att;>
<!ELEMENT individual-decision EMPTY>
<!ATTLIST individual-decision %pur_att;>
<!ELEMENT contact             EMPTY>
<!ATTLIST contact             %pur_att;>
<!ELEMENT profiling           EMPTY>
<!ATTLIST profiling           %pur_att;>
<!ELEMENT historical          EMPTY>
<!ATTLIST historical          %pur_att;>
<!ELEMENT telemarketing       EMPTY>
<!ATTLIST telemarketing       %pur_att;>
<!ELEMENT other-purpose       (#PCDATA)>
<!ATTLIST other-purpose       %pur_att;>

<!-- *********** RECIPIENT ************ -->
<!ELEMENT RECIPIENT (EXTENSION*,
    (ours
    | same
    | other-recipient
    | delivery
    | public
    | unrelated)+,
    EXTENSION*)>
<!ELEMENT ours                  (recipient-description*)>
<!ELEMENT same                  (recipient-description*)>
<!ATTLIST same                  %pur_att;>
<!ELEMENT other-recipient       (recipient-description*)>
<!ATTLIST other-recipient       %pur_att;>
<!ELEMENT delivery              (recipient-description*)>
<!ATTLIST delivery              %pur_att;>
<!ELEMENT public                (recipient-description*)>
<!ATTLIST public                %pur_att;>
<!ELEMENT unrelated             (recipient-description*)>
<!ATTLIST unrelated             %pur_att;>
<!ELEMENT recipient-description (#PCDATA)>

<!-- *********** RETENTION ************ -->
<!ELEMENT RETENTION (EXTENSION*,
    (no-retention
    | stated-purpose
    | legal-requirement
    | indefinitely
    | business-practices),
    EXTENSION*)>
<!ELEMENT no-retention       EMPTY>
<!ELEMENT stated-purpose     EMPTY>
<!ELEMENT legal-requirement  EMPTY>
<!ELEMENT indefinitely       EMPTY>
<!ELEMENT business-practices EMPTY>

<!-- ************** DATA ************** -->
<!ELEMENT DATA-GROUP (EXTENSION*, DATA+, EXTENSION*)>
<!ATTLIST DATA-GROUP
    base     %URI;      "http://www.w3.org/TR/P3P/base" >
<!ELEMENT DATA (#PCDATA | CATEGORIES)*>
<!ATTLIST DATA
    ref      %URI;      #REQUIRED
    optional (yes | no) "no" >


<!-- *********** DATA SCHEMA *********** -->
<!ELEMENT DATASCHEMA (DATA-DEF | DATA-STRUCT | EXTENSION)*>
<!ATTLIST DATASCHEMA xml:lang NMTOKEN #IMPLIED>
<!ATTLIST DATASCHEMA xmlns CDATA #FIXED "http://www.w3.org/2002/01/P3Pv1">

<!ELEMENT DATA-DEF    (CATEGORIES?, LONG-DESCRIPTION?)>
<!ATTLIST DATA-DEF
    name              ID    #REQUIRED
    structref         %URI; #IMPLIED
    short-description CDATA #IMPLIED  >

<!ELEMENT DATA-STRUCT (CATEGORIES?, LONG-DESCRIPTION?)>
<!ATTLIST DATA-STRUCT
    name              ID    #REQUIRED
    structref         %URI; #IMPLIED
    short-description CDATA #IMPLIED  >

<!-- *********** CATEGORIES *********** -->
<!ELEMENT CATEGORIES (physical
  | online
  | uniqueid
  | purchase
  | financial
  | computer
  | navigation
  | interactive
  | demographic
  | content
  | state
  | political
  | health
  | preference
  | location
  | government
  | other-category)+>
<!ELEMENT physical    EMPTY>
<!ELEMENT online      EMPTY>
<!ELEMENT uniqueid    EMPTY>
<!ELEMENT purchase    EMPTY>
<!ELEMENT financial   EMPTY>
<!ELEMENT computer    EMPTY>
<!ELEMENT navigation  EMPTY>
<!ELEMENT interactive EMPTY>
<!ELEMENT demographic EMPTY>
<!ELEMENT content     EMPTY>
<!ELEMENT state       EMPTY>
<!ELEMENT political   EMPTY>
<!ELEMENT health      EMPTY>
<!ELEMENT preference  EMPTY>
<!ELEMENT location    EMPTY>
<!ELEMENT government  EMPTY>
<!ELEMENT other-category EMPTY>

<!-- *********** EXTENSION ************ -->
<!ELEMENT EXTENSION ANY>
<!ATTLIST EXTENSION
    optional (yes | no) "yes" >

Annexe 6 : La notation ABNF (normatif)

La grammaire formelle de P3P est donnée dans cette spécification en recourant à une version légèrement modifiée de [ABNF]. Voici une description simplifiée de la notation ABNF :

name = (éléments): où <name> est le nom de la règle et <éléments> représente un ou plusieurs noms de règle, ou terminaux, combinés selon les opérandes suivants. Les noms de règle sont insensibles à la casse.
(élément1 élément2): les éléments compris entre des parenthèses sont traités comme un seul élément dont le contenu est strictement ordonnés.
<a>*<b>élément: au moins <a> et au plus <b> apparitions de l'élément.; (1*4<élément> signifie de un à quatre éléments).
<a>élément: exactement <a> apparitions de l'élément.; (4<élément> signifie exactement quatre éléments).
<a>*élément: <a> éléments ou plus.; (4*<élément> signifie quatre éléments ou plus).
*<b>élément: 0 à <b> éléments.; (*5<élément> signifie de 0 à cinq éléments).
*élément: 0 ou plus éléments.; (*<élément> 0 jusqu'à l'infini éléments).
[élément]: élément optionnel, équivalent à *1(élément).; ([élément] signifie 0 ou 1 élément).
"string" ou 'string': correspond à la chaîne littérale donnnée entre guillemets doubles.

Les autres notations utilisées dans les productions :

; ou /* ... */: commentaire.

Annexe 7 : Les principes directeurs de P3P (non normatif)

Cette annexe décrit les objectifs qui ont présidé au développement du protocole P3P et elle recommande des directives pour une utilisation responsable de cette technologie. Une version précédente a été publiée dans la note du W3C Les principes directeurs de P3P (http://www.w3.org/TR/NOTE-P3P10-principles).

Le projet de plateforme pour les préférences de confidentialité (P3P) a été conçu pour être flexible et pour gérer un ensemble divers de préférences d'utilisateurs, de politiques publiques, de politiques de fournisseur de services et d'applications. Cette flexibilité permettra d'utiliser P3P dans beaucoup de situations inédites que même les concepteurs n'avaient pas entrevues. Les principes directeurs de P3P ont été créés pour exprimer les intentions des membres du groupe de travail P3P au moment de la conception de cette technologie et pour suggérer l'utilisation la plus efficace de P3P en protégeant la vie privée de l'utilisateur et en développant sa confiance dans le Web. Afin de maintenir cette flexibilité, ce document n'exerce aucune contrainte envers l'une ou l'autre partie. Il donne plutôt des conseils concernant, premièrement, ce qu'on devrait faire pour rester dans la logique des concepteurs du protocole P3P et, deuxièmement, la manière de renforcer la confiance de l'utilisateur vis-à-vis des mises en œuvre P3P et des services Web. Le protocole P3P a pour but de protéger la vie privée sur le Web. Nous invitons les organisations, les individus, les concepteurs de politique et les sociétés utilisant P3P à suivre ces principes directeurs afin de réaliser cet objectif.

La confidentialité des informations

Le protocole P3P a été conçu pour encourager la confidentialité et la confiance sur le Web en permettant aux fournisseurs de services de divulguer leurs pratiques en matière de données et en permettant aux individus de prendre des décisions raisonnées pour la collecte et l'utilisation des informations personnelles les concernant. Les agents utilisateurs P3P agissent pour le compte des individus en vue de trouver un accord avec les fournisseurs de services sur la collecte et l'utilisation de ces informations personnelles. La confiance se construit sur une compréhension mutuelle et sur le respect de l'accord établi par chaque partie.

Les fournisseurs de services devraient entretenir la confiance et protéger la vie privée en appliquant, à leurs pratiques, les lois correspondantes et les principes de protection et de confidentialité des données. Voici une liste des principes et des directives de confidentialité qui ont documenté le développement de P3P et qui peut être utile aux personnes utilisant P3P :

En outre, les fournisseurs de services et les développeurs P3P devraient repérer les problèmes particuliers touchant à la vie privée des enfants et y apporter des réponses.

La notification et la transmission

Les fournisseurs de services devraient fournir des notifications efficaces, en temps et en heure, de leurs pratiques en matière de données et les agents utilisateurs devraient fournir des outils efficaces qui permettent aux utilisateurs d'accéder à ces notifications et de prendre des décisions en fonction de celles-ci.

Les fournisseurs de services devraient :

indiquer explicitement la collecte et l'utilisation de données, en expliquant pourquoi des informations personnelles sont collectées et avec qui elles peuvent être partagées ;
utiliser des politiques de confidentialité P3P pour indiquer toutes les informations susceptibles d'être collectées au cours d'une interacton sur le Web ;
mettre bien en évidence les politiques de confidentialité lisibles par un humain, et que celles-ci soient claires.

Les agents utilisateurs devraient :

fournir aux utilisateurs les mécanismes permettant d'afficher les pratiques en matière de données d'un service ;
fournir aux utilisateurs une option leur permettant d'examiner facilement, pour accord ou rejet, chaque transfert d'informations personnelles qu'ils effectuent ;
ne pas être configurés par défaut pour transmettre, sans le consentement de l'utilisateur, des informations personnelles à un fournisseur de services ;
informer les utilisateurs des options de confidentialité qu'ils offrent.

Le choix et le contrôle

Les utilisateurs devraient pouvoir faire des choix raisonnables pour la collecte, l'utilisation et la divulgation d'informations personnelles. Les utilisateurs devraient garder le contrôle de leurs informations personnelles et pouvoir décider des conditions de leur divulgation.

Les fournisseurs de services devraient :

limiter leurs demandes aux informations nécessaires pour réaliser le niveau de service souhaité par l'utilisateur. Cela réduira les frustrations de l'utilisateur, renforcera la confiance et permettra des relations entre plusieurs utilisateurs, y compris ceux qui souhaitent des relations anonymes, pseudonymes ou personnalisées avec le service ;
obtenir un consentement en connaissance de cause préalablement à la collecte et à l'utilisation des données ;
fournir des renseignements sur les possibilités d'examiner et, le cas échéant, corriger des informations personnelles.

Les agents utilisateurs devraient :

inclure des outils de configuration qui permettent aux utilisateurs de personnaliser leurs préférences ;
permettre aux utilisateurs d'importer et de personnaliser les préférences P3P provenant d'un tiers ;
présenter aux utilisateurs les options de configuration d'une manière neutre voire orientée vers la confidentialité ;
être utilisables sans que l'utilisateur soit obligé de stocker des informations personnelles lors des procédures d'installation ou de configuration.

La loyauté et l'intégrité

Les fournisseurs de services devraient traiter les utilisateurs et leurs informations personnelles avec loyauté et intégrité. Ce point est capital pour la protection de la vie privée et le renforcement de la confiance.

Les fournisseurs de services devraient :

présenter exactement leurs pratiques en matière de données, clairement et sans ambiguïté (jamais dans le but de tromper les utilisateurs) ;
utiliser les informations fournies seulement dans l'intention déclaré et les garder seulement le temps nécessaire ;
s'assurer que les informations soient exactes, complètes et à jour ;
annoncer les responsabilités et les possibilités de recours ;
tant que les informations sont retenues, continuer de les traiter en fonction de la politique en vigueur au moment de leur collecte, à moins que les utilisateurs ne donnent leur assentiment à une nouvelle politique.

Les agents utilisateurs devraient :

agir seulement pour le compte de l'utilisateur, en fonction des préférences qu'il a défini ;
présenter exactement les pratiques du fournisseur de services.

La sécurité

Bien que le protocole P3P ne comporte aucun mécanisme de sécurité, il est prévu pour être employé avec des outils de sécurité. Les informations personnelles de l'utilisateur devraient toujours être protégées par des barrières de sécurité raisonnables en fonction de la sensibilité des données.

Les fournisseurs de services devraient :

fournir des mécanismes pour la protection de toutes les informations personnelles collectées ;
utiliser les protocoles certifiés appropriés pour la transmission sécurisée des données.

Les agents utilisateurs devraient :

fournir des mécanismes pour la protection des informations personnelles stockées par les utilisateurs dans les référentiels de données qu'ils maintiennent ;
utiliser les protocoles certifiés appropriés pour la transmission sécurisée des donnée ;
avertir les utilisateurs lorsqu'un mécanisme de transport non sécurisé est employé.

Annexe 8 : Les contributeurs du Groupe de Travail (non normatif)

Cette spécification a été produite par le Groupe de Travail pour la spécification P3P. Ont participé à ce groupe de travail, présidé par Lorrie Cranor (AT&T), les personnes suivantes : Mark Ackerman (University of California, Irvine), Margareta Björksten (Nokia), Eric Brunner (Engage), Joe Coco (Microsoft), Brooks Dobbs (DoubleClick), Rajeev Dujari (Microsoft), Matthias Enzmann (GMD), Patrick Feng (RPI), Aaron Goldfeder (Microsoft), Dan Jaye (Engage), Marit Koehntopp (Privacy Commission of Land Schleswig-Holstein, Germany), Yuichi Koike (NEC/W3C), Yusuke Koizumi (ENC), Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Zurich), Daniel Lim (PrivacyBank), Ran Lotenberg (IDcide), Massimo Marchiori (W3C/MIT/UNIVE), Christine McKenna (Phone.com, Inc.), Mark Nottingham (Akamai), Paul Perry (Microsoft), Jules Polonetsky (DoubleClick), Martin Presler-Marshall (IBM), Joel Reidenberg (Fordham Law School), Dave Remy (Geotrust), Ari Schwartz (CDT), Noboru Shimizu (ENC), Rob Smibert (Jotter Technologies Inc.), Tri Tran (AvenueA), Mark Uhrmacher (DoubleClick), Danny Weitzner (W3C), Michael Wallent (Microsoft), Rigo Wenning (W3C), Betty Whitaker (NCR), Allen Wyke (Engage), Kevin Yen (Netscape), Sam Yen (Citigroup), Alan Zausner (American Express).

Le Groupe de Travail pour la spécification P3P a été le dépositaire des travaux précédents des différents groupes de travail pour la spécification P3P. Le groupe de travail voudrait remercier les membres de ces groupes précurseurs pour leurs contributions (les affiliations indiquées sont celles des membres au moment de leur participation à chaque groupe de travail).

Le Groupe de Travail pour la mise en œuvre et le déploiement de P3P, présidé par Rolf Nelson (W3C) et Marc Langheinrich (NEC/ETH Zurich) : Mark Ackerman (University of California, Irvine), Rob Barrett (IBM), Joe Coco (Microsoft), Lorrie Cranor (AT&T), Massimo Marchiori (W3C/MIT), Gabe Montero (IBM), Stephen Morse (Netscape), Paul Perry (Microsoft), Ari Schwartz (CDT), Gabriel Speyer (Citibank), Betty Whitaker (NCR).

Le Groupe de Travail pour la syntaxe de P3P, présidé par Steve Lucas (Matchlogic) : Lorrie Cranor (AT&T), Melissa Dunn (Microsoft), Daniel Jaye (Engage Technologies), Massimo Marchiori (W3C/MIT), Maclen Marvit (Narrowline), Max Metral (Firefly), Paul Perry (Firefly), Martin Presler-Marshall (IBM), Drummond Reed (Intermind), Joseph Reagle (W3C).

Le Groupe de Travail pour l'harmonisation du vocabulaire de P3P, présidé par Joseph Reagle (W3C) : Liz Blumenfeld (America Online), Ann Cavoukian (Information and Privacy Commission/Ontario), Scott Chalfant (Matchlogic), Lorrie Cranor (AT&T), Jim Crowe (Direct Marketing Association), Josef Dietl (W3C), David Duncan (Information and Privacy Commission/Ontario), Melissa Dunn (Microsoft), Patricica Faley (Direct Marketing Association), Marit Köhntopp (Privacy Commissioner of Schleswig-Holstein, Germany), Tony Lam (Hong Kong Privacy Commissioner's Office), Tara Lemmey (Narrowline), Jill Lesser (America Online), Steve Lucas (Matchlogic), Deirdre Mulligan (Center for Democracy and Technology), Nick Platten (Data Protection Consultant, anciennement chez DG XV, European Commission), Ari Schwartz (Center for Democracy and Technology), Jonathan Stark (TRUSTe).

Le Groupe de Travail pour les protocoles et le transport des données de P3P, présidé par Yves Leroux (Digital) : Lorrie Cranor (AT&T), Philip DesAutels (Matchlogic), Melissa Dunn (Microsoft), Peter Heymann (Intermind), Tatsuo Itabashi (Sony), Dan Jaye (Engage), Steve Lucas (Matchlogic), Jim Miller (W3C), Michael Myers (VeriSign), Paul Perry (FireFly), Martin Presler-Marshall (IBM), Joseph Reagle (W3C), Drummond Reed (Intermind), Craig Vodnik (Pencom Web Worlds).

Le Groupe de Travail pour le vocabulaire de P3P, présidé par Lorrie Cranor (AT&T) : Mark Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C), Upendra Shardanand (Firefly).

Le Groupe de Travail pour l'architecture de P3P, présidé par Martin Presler-Marshall (IBM) : Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C).

Enfin, l'annexe 7 s'inspire de la note du W3C Les principes directeurs de P3P, dont les signataires sont : Azer Bestavros (Bowne Internet Solutions), Ann Cavoukian (Information and Privacy Commission Ontario Canada), Lorrie Faith Cranor (AT&T Labs-Research), Josef Dietl (W3C), Daniel Jaye (Engage Technologies), Marit Köhntopp (Land Schleswig-Holstein), Tara Lemmey (Narrowline; TrustE), Steven Lucas (MatchLogic), Massimo Marchiori (W3C/MIT), Dave Marvit (Fujitsu Labs), Maclen Marvit (Narrowline Inc.), Yossi Matias (Tel Aviv University), James S. Miller (MIT), Deirdre Mulligan (Center for Democracy and Technology), Joseph Reagle (W3C), Drummond Reed (Intermind), Lawrence C. Stewart (Open Market, Inc.).

Spécification de la plateforme pour les préférences de confidentialité 1.0 (P3P1.0)

Recommandation du W3C du 16 avril 2002

Résumé

Table des matières

1. Introduction

1.1 La spécification P3P1.0

1.1.3 Les politiques P3P

1.1.4 Les agents utilisateurs P3P

1.1.5 La mise en œuvre de P3P1.0 sur les serveurs

1.1.6 Les futures versions de P3P

1.2 À propos de cette spécification

1.3 La terminologie

2.3.4 Les formulaires et les mécanismes apparentés

3.1.2 Le codage XML des politiques

3.2.1 L'élément POLICIES

3.3.1 L'élément STATEMENT

3.3.2 L'élément CONSEQUENCE

3.3.4 L'élément PURPOSE

3.3.5 L'élément RECIPIENT

3.3.6 L'élément RETENTION

4.2.5 L'élément PURPOSE compact

5.5 Les structures de données de base

5.5.1 Les dates

5.5.2 Les noms

5.5.3 Les connexions

5.5.4 Les certificats

5.5.5 Les numéros de téléphone

5.5.6 Les coordonnées

5.5.6.1 Les coordonnées postales

5.5.6.2 Les coordonnées de télécommunication

5.5.6.3 Les coordonnées en ligne

5.5.7 Les journaux d'accès et les adresses Internet

5.5.7.1 Les adresses URI

5.5.7.2 Les adresses IP

5.5.7.4 Les autres informations du protocole HTTP

5.6 Le schéma de données de base

5.6.1 Les données de l'utilisateur

5.6.2 Les données d'un tiers

5.6.3 Les données de l'entreprise

5.6.4 Les données dynamiques

5.7.1 Les éléments/structures de données de catégorie fixe

5.7.2 Les éléments/structures de données de catégorie variable

5.6 L'utilisation des éléments de données

6. Annexes

Annexe 1 : Références (normatif)

Annexe 2 : Références (non normatif)

Annexe 6 : La notation ABNF (normatif)

Annexe 7 : Les principes directeurs de P3P (non normatif)

La confidentialité des informations

La notification et la transmission

Le choix et le contrôle

La loyauté et l'intégrité

La sécurité

Annexe 8 : Les contributeurs du Groupe de Travail (non normatif)

3.2.1 L'élément `POLICIES`

3.3.1 L'élément `STATEMENT`

3.3.2 L'élément `CONSEQUENCE`

3.3.4 L'élément `PURPOSE`

3.3.5 L'élément `RECIPIENT`

3.3.6 L'élément `RETENTION`

4.2.5 L'élément `PURPOSE` compact