Recommandation P3P1 du W3C en version française

Statut du document traduit

Ceci est une traduction de la Recommandation du W3C portant sur la première version de la plateforme pour les préférences de confidentialité (P3P1).

Cependant ce n'est pas la version officielle en français de la Recommandation. Seul le document original en anglais a valeur de norme. On peut l'obtenir à : http://www.w3.org/TR/2002/REC-P3P-20020416/.

Avertissement

Des erreurs ont pu survenir malgré le soin apporté à ce travail.

Notes sur la traduction

Certains concepts sont difficiles à rendre en français ou peuvent nécessiter une explication, aussi les expressions originales en anglais viennent parfois en renfort dans le texte sous cette forme :
ex. traduction [N.d.T. translation]

D'autre part, certains liens renvoient sur des définitions contenues dans les recommandations originales du W3C. Ces liens sont doublés vers leur version française et sont signalés ainsi : vf.

Conventions : Les noms des éléments, sauf pour les titres, apparaissent comme ceci, <META> ou <current/>, et les noms des en-têtes HTTP comme ceci, GET ou Content-Langage.

Cette version française intègre toutes les corrections survenues depuis la parution de la recommandation en avril 2002. On peut trouver la liste des dernières modifications à l'adresse http://www.w3.org/2002/04/P3Pv1-errata.
Les liens vers l'errata traduit, à jour en date du 13 février 2003, apparaissent dans le document sous cette forme : « errata-E1 ».

Archives compressées et autres formats

Cette traduction est disponible sous forme d'archive compressée et, le cas échéant, dans d'autres formats à l'adresse http://www.yoyodesign.org/doc/w3c/w3c.html.

Autres documents traduits

On peut consulter les traductions en français d'autres documents du W3C à
http://www.w3.org/Consortium/Translation/French

Notice légale

Copyright © 1994-2002 World Wide Web Consortium,
(Massachusetts Institute of Technology,
Institut National de Recherche en Informatique et en Automatique,
Keio University).
Tous droits réservés. Consulter la notice de copyright pour les productions du W3C.


W3C

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

Se reporter à l'errata pour ce document, qui peut apporter des corrections normatives.

Voir également les traductions.


Résumé

Ceci est la spécification de la plateforme pour les préférences de confidentialité (P3P). Ce document, accompagné de ses références normatives, comprend toutes les spécifications nécessaires pour l'implémentation 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. Ceci pour 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 Technonogie & Société du W3C.

On peut trouver les divulgations de licence concernant cette spécification sur la page de divulgation de patente vf. de P3P1.0, conformément à la politique du W3C.

Merci de 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 anglaise 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

  1. Introduction
    1. La spécification P3P1.0
      1. Les buts et les possibilités de P3P1.0
      2. Exemple d'utilisation de P3P
      3. Les politiques de P3P
      4. Les agents utilisateurs P3P
      5. L'implémentation de P3P1.0 sur les serveurs
      6. Les versions ultérieures de P3P
    2. À propos de cette spécification
    3. La terminologie
  2. Le référencement des politiques
    1. Aperçu et but des références de politique
    2. La localisation des fichiers de référence de politique
      1. L'endroit bien déterminé
      2. Les en-têtes HTTP
      3. La balise HTML link
      4. La balise XHTML link
      5. Les ports HTTP et les autres protocoles
    3. La syntaxe et la sémantique du fichier de référence de politique
      1. Exemple de fichier de référence de politique
      2. La définition du fichier de référence de politique
        1. La traitement du fichier de référence de politique
          1. L'importance de l'ordre
          2. Les caractères joker dans les fichiers de référence de politique
        2. Les éléments META et POLICY-REFERENCES
        3. La durée de vie d'un fichier de référence de politique et l'élément EXPIRY
          1. La motivation et le mécanisme
          2. L'élément EXPIRY
          3. L'utilisation des en-têtes HTTP
          4. La gestion des erreurs pour les durées de vie des fichiers de référence de politique et des politiques
        4. L'élément POLICY-REF
        5. Les éléments INCLUDE et EXCLUDE
        6. L'élément HINT
        7. Les éléments COOKIE-INCLUDE et COOKIE-EXCLUDE
        8. L'élément METHOD
      3. L'application d'une politique à un URI
      4. Les formulaires et les mécanismes associés
    4. Les obligations supplémentaires
      1. La non-ambiguïté
      2. Les diverses langues
      3. La « zone sûre »
      4. Le traitement fait par les agents utilisateurs des politiques et des fichiers de référence de politique
      5. La sûreté du transport des politiques
      6. Les mises à jour des politiques
      7. L'absence d'un fichier de référence de politique
      8. L'évaluation asynchrone
    5. Scénarios exemples
  3. La syntaxe et la sémantique des politiques
    1. Exemples de politiques
      1. Les politiques en langage naturel
      2. Le codage XML des politiques
    2. Les politiques
      1. L'élément POLICIES
      2. L'élément POLICY
      3. L'élément TEST
      4. L'élément ENTITY
      5. L'élément ACCESS
      6. L'élément DISPUTES
      7. L'élément REMEDIES
    3. Les déclarations
      1. L'élément STATEMENT
      2. L'élément CONSEQUENCE
      3. L'élément NON-IDENTIFIABLE
      4. L'élément PURPOSE
      5. L'élément RECIPIENT
      6. L'élément RETENTION
      7. Les éléments DATA-GROUP et DATA
    4. Les catégories et l'élément CATEGORIES
    5. Le mécanisme d'extension : l'élément EXTENSION
    6. Les préférences de l'utilisateur
  4. Les politiques compactes
    1. Le référencement des politiques compactes
    2. Le vocabulaire des politiques compactes
      1. L'élément ACCESS compact
      2. L'élément DISPUTES compact
      3. L'élément REMEDIES compact
      4. L'élément NON-IDENTIFIABLE compact
      5. L'élément PURPOSE compact
      6. L'élément RECIPIENT compact
      7. L'élément RETENTION compact
      8. L'élément CATEGORIES compact
      9. L'élément TEST compact
    3. La portée d'une politique compacte
    4. La durée de vie d'une politique compacte
    5. La transformation d'une politique P3P en une politique compacte
    6. La transformation d'une politique compacte en une politique P3P
  5. Les schémas de données
    1. La gestion en langage naturel des schémas de données
    2. Les structures de données
    3. Les éléments DATA-DEF et DATA-STRUCT
      1. Les catégories dans les schémas de données P3P
      2. Exemple de schéma de données P3P
      3. L'utilisation des noms des éléments de données
    4. La persistance des schémas de données
    5. Les structures de données de base
      1. Les dates
      2. Les noms
      3. Les connexions
      4. Les certificats
      5. Les numéros de téléphone
      6. Les informations de contact
        1. Informations postale
        2. Télécommunications
        3. Informations en ligne
      7. Les journaux des accès et les adresses Internet
        1. URI
        2. ipaddr
        3. Les informations du journal d'accès
        4. Les autres informations du protocole HTTP
    6. Le schéma de données de base
      1. Les données de l'utilisateur
      2. Les données d'une tierce partie
      3. Les données de l'entreprise
      4. Les données dynamiques
    7. Les catégories et les éléments ou structures de données
      1. Les éléments ou structures de données de catégorie fixe
      2. Les éléments ou structures de données de catégorie variable
    8. L'utilisation des éléments de données
  6. Appendices
    Appendice 1 : Références (normatif)
    Appendice 2 : Références (non normatif)
    Appendice 3 : La définition du schéma de données P3P de base (normatif)
    Appendice 4 : La définition du schéma XML (normatif)
    Appendice 5 : La définition du DTD XML (non normatif)
    Appendice 6 : La notation ABNF (normatif)
    Appendice 7 : Les principes directeurs de P3P (non normatif)
    Appendice 8 : Les contributeurs au 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 leur politique de confidentialité dans un format standard qui peut être automatiquement obtenu et facilement interprété par les agents utilisateurs. Les agents utilisateurs P3P permettront aux utilisateurs d'être informés sur les pratiques du sites (dans des formats lisibles à la fois aux machines et aux humains) et d'automatiser si nécessaire la prise de décisions en fonction de ces pratiques. De cette façon, les utilisateurs n'ont pas besoin de lire les politiques de confidentialité de chaque site qu'ils visitent.

Bien que P3P fournisse les moyens techniques pour assurer les utilisateurs d'être informés des politiques de confidentialité avant de délivrer des renseignements personnels, celui-ci n'offre pas un mécanisme technique qui garantisse un comportement des sites en accord avec leur politique. Les produits qui implémentent cette spécification PEUVENT fournir une aide dans ce sens, mais cela dépend spécifiquement des implémentations et cela n'est pas couvert par cette spécification. Cependant, P3P vient en complément des lois et des programmes auto-régulatoires qui peuvent définir des mécanismes d'application. De plus, P3P ne comprend pas de mécanismes pour le transport des données ou pour sécuriser des données personnelles en transit ou stockées. P3P peut être intégré dans des outils conçus pour faciliter le transport des données. Ces outils devraient contenir des barrières de sécurité 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 par lesquels associer les politiques aux ressources Web. Les politiques P3P consistent en déclarations faites dans le vocabulaire P3P pour exprimer des pratiques ayant trait à la vie privée. Les politiques P3P référencent également des éléments du schéma de données de base de P3P -- un jeu standard des éléments de données que tout agent utilisateur P3P devrait reconnaître. La spécification P3P comprend un mécanisme qui autorise des extensions au vocabulaire de P3P.

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

P3P version 1.0 est un protocole conçu pour informer les utilisateurs du Web des pratiques de collecte des données des sites Web. Il offre à un site Web un moyen 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 :

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 façon standardisée, lisiblement pour une machine et facile à trouver. Deuxièmement, permettre aux utilisateurs Web de connaître quelles données seront collectées par les sites qu'ils visitent, comment ces données seront utilisées et quelles données ceux-ci peuvent « autoriser » ou « interdire ».

1.1.2 Exemple d'utilisation de P3P

En introduction à P3P, considérons un scénario d'utilisation courant faisant appel à P3P. Claudia décide de visiter un magasin en ligne appelé CatalogueExemple, situé à http://www.catalog.exemple.com/. Supposons que la société CatalogueExemple ait placé des politiques P3P sur toutes leurs pages et que Claudia utilise un navigateur incorporant P3P.

Claudia tape l'adresse de CatalogueExemple dans son navigateur. Celui-ci peut automatiquement ramener la politique P3P pour la page en question. La politique annonce que les seules données collectées sur la page d'accueil sont celles contenues dans les journaux d'accès HTTP standards. Maintenant, le navigateur de Claudia compare cette politique avec les préférences qu'elle lui a indiquées. Est-ce que cette politique est acceptable ou doit-on l'avertir ? Supposons que Claudia lui ait dit que c'était acceptable. Auquel cas, la page d'accueil s'affiche normalement, sans irruption de 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.

Ensuite, Claudia clique sur un lien amenant sur le catalogue en ligne du site. La partie catalogue fait appel à un programme plus complexe. Ce programme emploie des cookies pour implémenter la fonctionnalité 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 concernant celle-ci. De nouveau, supposons que cette politique corresponde aux préférences de Claudia, ainsi elle ne reçoit aucun message. Claudia poursuit et sélectionne quelques articles qu'elle souhaite acheter. Puis elle passe sur la page pour le règlement.

La page pour le 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 qui décrit les données qui sont collectées et déclare que ses données ne seront utilisées que pour réaliser la transaction courante, sa commande.

Le navigateur de Claudia examine cette politique P3P. Imaginons que Claudia ait indiqué au navigateur qu'elle souhaite être avertie quand un site demande son numéro de téléphone. Auquel cas, le navigateur fera apparaître un message lui disant que ce site Web lui demande son numéro de téléphone et lui expliquant le contenu de la déclaration P3P. Claudia peut alors déterminer si cela est acceptable. Si c'est le cas, elle peut poursuivre dans sa commande ; sinon, elle peut annuler la transaction.

D'une autre façon, Claudia aurait pu indiquer à son navigateur qu'elle ne voulait être avertie que si un site demandait son numéro de téléphone pour le donner à une tierce partie et/ou l'utiliser pour autre chose que l'achèvement de la transaction courante. Dans ce cas, elle n'aurait pas du tout reçu d'interrogation de la part de son navigateur et elle aurait poursuivi et terminé sa commande.

Remarquer que ce scénario décrit une implémentation hypothétique de P3P. D'autres types d'interfaces utilisateurs sont également envisageables.

1.1.3 Les politiques P3P

Les politiques P3P utilisent un codage XML du vocabulaire P3P avec des espaces de nommage (cf. [XML] et [XML-Name]) pour offrir une information de contact au sujet de l'entité légale qui effectue la représentation des pratiques ayant trait à la vie privée dans une politique, pour énumérer les types de données ou les éléments de données collectées et pour expliquer comment les données seront employées. De plus, les politiques identifient les destinataires des données et produisent diverses autres divulgations, dont l'information sur la résolution des contestations et l'adresse de la politique de condidentialité d'un site lisible par un humain. Les politiques P3P doivent couvrir tous les éléments de données et les pratiques concernés. Cependant, les questions légales, traitant des obligations de respect des lois sur l'information, ne sont pas abordées par cette spécification. Il est possible qu'un site, bien que respectant sa politique de non redistribution des données à des tiers, puisse être contraint à le faire par force de loi. Les déclarations P3P sont positives, signifiant par-là que les sites annoncent ce qu'ils font, plutôt que ce qu'ils ne font pas. Le vocabulaire P3P est conçu pour être descriptif des pratiques d'un site plutôt que d'être simplement un indicateur de conformité à une loi donnée ou un code de conduite. Cependant, les agents utilisateurs peuvent être développés pour tester si les pratiques d'un site sont conformes, ou non, avec une loi ou un code.

Les politiques P3P représentent les pratiques du sites. 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, mais leurs pratiques peuvent ne pas être régies par les politiques du site. De plus, remarquer que chaque politique P3P s'applique aux ressources Web spécifiques (des pages Web, des images, des cookies, etc.) listées dans un fichier de référence de politique. En plaçant une ou plusieurs politiques P3P sur un site Web, une entreprise ou une organisation ne font aucune déclaration sur les pratiques de confidentialité associées aux autres ressources Web non mentionnées dans leur fichier de référence de politique, aux autres activités en ligne n'impliquant pas les données collectées sur les sites Web couverts par leur politique P3P ou aux activités hors ligne n'impliquant pas les données collectées sur les sites Web couverts par leur politique P3P.

Pour les cas où le vocabulaire P3P n'était pas assez 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). Cependant, les politiques NE DOIVENT PAS faire des 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 être implémentés en applets Java ou en JavaScript ou intégrés dans des portefeuilles électroniques, des remplisseurs de formulaire automatiques ou d'autres outils de gestion des données de l'utilisateur. Les agents utilisateurs P3P cherchent les références aux politiques P3P dans des endroits bien déterminés, dans les en-têtes P3P des réponses HTTP et dans les balises link incorporées dans un contenu HTML. Ces références indiquent l'emplacement d'une politique P3P concernée. Les agents utilisateurs peuvent ramener la politique à partir de l'endroit indiqué, l'analyser, puis afficher des symboles, jouer des sons ou générer pour l'utilisateur des interrogations qui réflètent les pratiques de confidentialité P3P d'un site. Ils peuvent aussi comparer les politiques P3P avec les préférences de confidentialité choisies par l'utilisateur et prendre les mesures appropriées. P3P peut jouer le rôle 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 ramènerait les politiques P3P, les comparerait avec les préférences de l'utilisateur et autoriserait la délivrance de données seulement si a) la politique est cohérente avec les préférences de l'utilisateur et si b) le transfert de données requis est cohérent avec la politique. Si l'une de ces conditions n'était pas remplie, l'utilisateur serait informé du désaccord et aurait l'opportunité d'accorder la délivrance des données lui-même.

La spécification P3P1.0 place peu d'exigences sur l'interface utilisateur des agents utilisateurs. De ce fait, les implémenteurs peuvent chacun faire leurs propres choix quant aux messages et symboles informant l'utilisateur de la politique de confidentialité d'un site Web. Les implémenteurs ne sont pas tenus d'employer textuellement les définitions qui se trouvent dans cette spécification pour leurs interfaces utilisateurs. Néanmoins, ils devraient s'assurer que, quelle que soit l'information présentée à l'utilisateur, celle-ci représente fidèlement les politiques P3P décrites, tel que dans l'Appendice 7 : Les principes directeurs de P3P.

1.1.5 L'implémentation de P3P1.0 sur les serveurs

Les sites Web peuvent implémenter P3P1.0 sur leurs serveurs en transcrivant leurs politiques de confidentialité, lisibles aux humains, en une syntaxe P3P, puis en publiant les fichiers résultants en même temps qu'un fichier de référence 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 implémenter P3P1.0 sur les serveurs Web existants, conformes à HTTP/1.1, sans autre programme ou mise à jour. Les serveurs peuvent publier leurs fichiers de référence de politique dans un endroit bien déterminé ou les référencer dans un contenu HTML/XHTML à l'aide d'une balise link. D'une autre façon, on peut configurer les serveurs compatibles pour qu'ils insèrent une extension d'en-tête P3P dans toutes leurs réponses HTTP, celle-ci indiquant l'emplacement du fichier de référence de politique d'un site.

Les sites Web ont toute latitude sur la manière d'utiliser P3P : ils peuvent opter pour une seule politique P3P pour le site en entier ou ils peuvent désigner 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. De plus, certains sites peuvent vouloir écrire des politiques qui couvrent toutes les données qu'une entité collecte, indépendamment de la façon dont les données sont collectées.

1.1.6 Les versions ultérieures de P3P

Des pans importants ont été retirés des premiers brouillons de la spécification P3P1.0 pour faciliter l'implémentation et le déploiement rapide d'une première étape P3P. Une version ultérieure de la spécification P3P pourrait incorporer ces fonctionnalités après le déploiement de P3P1.0. Une telle spécification serait susceptible de comporter des améliorations en fonction des commentaires en retour des expériences d'implémentation et de déploiement, en fonction aussi de quatre composants majeurs, qui faisaient partie de la vision originale P3P mais non compris dans P3P1.0 :

1.2 À propos de cette spécification

Ce document, accompagné de ses références normatives, comprend toutes les spécifications nécessaires à l'implémentation d'applications P3P interopérables.

Les mots-clés suivants, qui sont employés tout au long du document, doivent être compris comme nécessaires pour l'interopérabilité. Cette spécification emploient les termes définis dans RFC2119 [KEY] pour déterminer l'échelle de chacune des obligations particulières. Voici ces expressions :

DOI(VEN)T ou NE DOI(VEN)T PAS
Cette expression ou le qualificatif « requis » indiquent une exigence absolue de l'item pour la spécification.
DEVRAI(EN)T ou NE DEVRAI(EN)T PAS
Cette expression ou le qualificatif « recommandé » signifient qu'il peut exister des raisons valables dans certaines circonstances pour ignorer cet item, mais toutes les conséquences devraient être envisagées et le cas soigneusement soupesé avant d'opter pour une voie différente.
PEU(VEN)T
Cette expression ou le qualificatif « optionnel » indiquent un item véritablement facultatif. Un éditeur peut choisir d'inclure l'item parce qu'un marché particulier l'exige ou parce que celui-ci renforce le produit, par exemple un concurrent ayant pu l'oublier.

La spécification P3P, sauf pour ce qui concerne la section 2.2.2, la section 2.2.3 et la section 4, défint une syntaxe XML avec espaces de nommage (cf. [XML] et [XML-Name]). Dans la suite, pour faire bref, on dira librement « XML » pour signifier l'expression plus juste « 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'Appendice 6. Cependant, remarquer que, dans le cas d'une syntaxe XML, une telle syntaxe ABNF n'est qu'une représentation grammaticale, utilisée pour faciliter la lecture (par exemple, celle-ci manque de toutes les souplesses syntaxiques qui sont implicites dans XML - les règles pour les 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 de l'espace de nommage), et, comme telle, n'a pas de valeur normative. Toute la syntaxe XML définie dans cette spécification DOIT être conforme avec XML Schema pour P3P (voir l'Appendice 4), qui, en même temps que les autres contraintes exprimées dans la spécification en langage naturel, constitue la définition normative.

Le DTD (non normatif) fourni dans l'Appendice 5 PEUT être utilisé pour vérifier que les fichiers P3P sont valides. Cependant, il se peut que certains fichiers valides soient rejetés quand évalués contre le DTD en raison de leur utilisation des espaces de nommage.

Aussi loin que la syntaxe non XML définie dans cette spécification est concernée (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 (en même temps que les autres contraintes exprimées en langage naturel dans cette spécification) qui constitue, plutôt, la définition normative.

1.3 La terminologie

Agent utilisateur [N.d.T. User Agent]
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, un agent utilisateur peut être considéré comme partie du système d'exploitation de l'utilisateur ou du client Web, ou comme partie des termes et conditions d'un fournisseur d'accès ou d'un serveur mandataire pour la confidentialité.
Caractère [N.d.T. Character]
Les chaînes consistent en une séquence de zéro ou plus caractères, un caractère étant défini comme dans la recommandation XML [XML]. Un seul caractère dans P3P correspond ainsi à seul caractère abstrait Unicode avec une seule valeur scalaire Unicode correspondante (voir [UNICODE]).
Catégorie de données [N.d.T. Data Category]
Un attribut significatif d'un élément de données, ou d'un jeu de données, qui peut être utilisé par un moteur de certification pour déterminer le type d'élément dont il est question, tel qu'une information de contact physique. P3P1.0 spécifie un jeu de catégories de données.
Déclaration [N.d.T. Statement]
Une déclaration P3P est un jeu de divulgations sur des pratiques de confidentialité concernant une collection d'éléments de données.
Dépôt [N.d.T. Repository]
Un mécanisme de stockage des données personnelles sous le contrôle de l'agent utilisateur.
Données identifiées [N.d.T. Identified Data]
Les données qui peuvent être raisonnablement utilisées par un collecteur de données pour identifier un individu.
Élément de données [N.d.T. Data Element]
Une entité de données individuelle, telle que le nom ou le numéro de téléphone. Pour l'interopérabilité, P3P1.0 spécifie un jeu de base des éléments de données.
Fournisseur de services (contrôleur de données, entité légale) [N.d.T. Service Provider (Data Controller, Legal Entity)]
La personne, ou l'entité légale, qui offre une information, des produits ou des services à partir d'un site Web, qui collecte des informations et qui est responsable des représentations faites dans une déclaration de pratique.
Intention [N.d.T. Purpose]
La ou les raisons de la collecte et de l'emploi des données.
Jeu de données [N.d.T. Data Set]
Un regroupement déterminé d'éléments de données, tel que "user.home-info.postal". Le schéma de données de base de P3P1.0 spécifie un certain nombre de jeux de données.
Politique [N.d.T. Policy]
Une collection d'une ou plusieurs déclarations de confidentialité réunies avec des informations affirmant l'identité, l'URI, les garanties et les procédures de résolution des contestations du service couvert par la politique.
Pratique [N.d.T. Practice]
Le jeu des divulgations concernant l'emploi des données, y compris leur destination, les destinataires et les autres divulgations.
Pratique uniforme [N.d.T. Equable Practice]
Une pratique qui est très semblable à une autre, le but et les destinataires étant les mêmes ou plus contraints que l'original et les autres divulgations n'étant pas significativement différentes. Par exemple, deux sites, ayant autrement d'autres pratiques similaires, qui suivent des jeux de directives sectorielles différents cependant similaires.
Préférence [N.d.T. Preference]
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 définie formellement analysable (par exemple, le langage d'échange de préférences [APPEL]).
Ressource [N.d.T. Resource]
Un objet ou un service de données en réseau identifiable par un URI. Les ressources peuvent être disponibles sous diverses formes (par exemple, de multiples langues, formats de données, tailles et résolutions) ou varier de diverses manières.
Schéma de données [N.d.T. Data Schema]
Une collection d'éléments et de jeux de données définis à l'aide de l'élément P3P1.0 <DATASCHEMA>. 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, en général, un service est habituellement un site Web. Dans cette spécification, les termes « service » et « site Web » sont souvent interchangeables.
Structure de données [N.d.T. Data Structure]
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. P3P1.0 définit un jeu de structures de données de base qui est utilisé pour décrire les jeux de données dans le schéma de données P3P de base.
URI
Un identifiant de ressource uniforme (URI) utilisé pour localiser des ressources Web. Pour des informations précises sur la syntaxe et la sémantique d'un URI, voir [URI]. Les URI qui surviennent dans XML ou HTML doivent être traités comme spécifié dans [CHARMODEL], dans la section sur Le codage des caractères dans les références d'URI. Ceci ne concerne pas les URI qui surviennent dans les champs des en-têtes HTTP ; ceux-ci devraient toujours être entièrement masqués.
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'usage des données personnelles concernant cet individu ou ce groupe.
Zone sûre [N.d.T. Safe Zone]
Une partie d'un site Web où le fournisseur de services n'effectue qu'une collecte d'information minimale et où toutes les données collectées ne sont utilisées que selon des façons qui ne permettraient pas d'identifier raisonnablement un individu.

2. Le référencement des politiques

2.1 Aperçu et but des références de politique

La localisation d'une politique P3P est l'une des premières étapes dans l'opération du protocole P3P. Les services utilisent les références de politique pour déclarer quelle politique s'applique à un URI ou jeu d'URI particuliers. Les agents utilisateurs utilisent les références de politique pour localiser la politique de confidentialité qui s'applique à une ressource Web, de manière à pouvoir traiter celle-ci pour le bénéfice de l'utilisateur.

Les références de politique s'utilisent de manière étendue comme optimisation des performances. Les politiques P3P comportent généralement plusieurs kilo octets de données, alors qu'un URI qui appelle une politique de confidentialité pèsent généralement moins de 100 octets. En plus des économies de bande passante, les références de politiques réduisent également les besoins en calcul : les politiques peuvent avoir une correspondance unique avec les URI, les agents utilisateurs n'ont ainsi besoin que d'analyser et traiter qu'une seule fois une politique plutôt que de la traiter avec chacun des documents auxquels celle-ci s'applique. Et plus, en centralisant l'information sur les politiques concernées dans un seul endroit, l'administration d'un site Web en est simplifiée.

Un fichier de référence de politique s'utilise pour associer les politiques P3P à certaines régions de l'espace d'URI. Le fichier de référence de politique est un fichier XML avec espaces de nommage (voir [XML] et [XML-Name]) qui peut spécifier la politique d'un seul document Web, de parties d'un site Web ou d'un site entier. Le fichier de référence de politique peut se référer à une ou plusieurs politiques P3P ; ceci permet à un seul fichier de référence de couvrir un site entier, même si différentes politiques P3P s'appliquent à différentes parties du site. Le fichier de référence de politique est utilisé pour l'une ou toutes les déclarations suivantes :

Toutes ces déclarations sont faites dans le corps du fichier de référence de politique.

2.2 La localisation des fichiers de référence de politique

Cette section décrit le mécanisme employé pour indiquer la localisation d'un fichier de référence de politique. On donne aussi la syntaxe détaillée pour les mécanismes reconnus.

On peut indiquer la localisation du fichier de référence de politique au moyen de l'un de quatre mécanismes. Le fichier de référence de politique :

  1. peut se situer dans un « endroit bien déterminé » prédéfini,
  2. un document peut indiquer un fichier de référence de politique au moyen d'une balise HTML link,
  3. un document peut indiquer un fichier de référence de politique au moyen d'une balise XHTML link
  4. ou au moyen d'une en-tête HTTP.

Remarquer que si l'agent utilisateur gère le chargement d'un contenu HTML (ou respectivement XHTML) via HTTP, il DOIT gérer de façon interchangeable les mécanismes 1, 2 et 3 (ainsi que 4 pour ce qui concerne XHTML) listés ci-dessus. Voir également les exigences 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 sa propre politique P3P. En pratique, cependant, le fait de placer de nombreuses politiques P3P différentes sur les différentes ressources d'une seule page peut compliquer le rendu de celle-ci et la signalisation des politiques concernées à l'utilisateur. En conséquence, on recommande aux services d'essayer de construire leurs fichiers de référence de politique de manière à ce qu'un seul fichier de référence couvre la « page » en question ; ceci accélérera la session de navigation de l'utilisateur.

Pour qu'un agent utilisateur traite la politique qui s'applique à une ressource donnée, il doit localiser le fichier de référence de politique, l'analyser, ramener toutes les politiques P3P requises, enfin analyser cette ou ces politiques P3P.

Ce document ne spécifie pas comment les politiques P3P peuvent être associées aux ressources Web ramenées autrement que par HTTP. Cependant, elle n'empêche pas le développement ultérieur de mécanismes pour associer des politiques P3P à des ressources ramenées à l'aide d'autres protocoles. En plus, des méthodes supplémentaires, associant des politiques P3P aux ressources HTTP, sont susceptibles d'un développement ultérieur.

2.2.1 L'endroit bien déterminé

Les sites Web qui utilisent P3P PEUVENT (et sont fortement encouragés à) placer un fichier de référence de politique dans un « endroit bien déterminé ». Pour ce faire, on devrait disposer un fichier de référence de politique sur le site avec le chemin d'accès /w3c/p3p.xml.

Remarquer que les sites ne sont pas tenus d'employer ce mécanisme ; néanmoins, en l'utilisant, les sites peuvent assurer que leur police P3P sera accessible aux agents utilisateurs avant que toute autre ressource ne soient demandée sur celui-ci. Ceci réduira le besoin des agents utilisateurs d'accéder au site en utilisant des méthodes de zone sûre. De plus, si un site choisit ce moyen, le fichier de référence de politique situé dans l'endroit bien déterminé en n'est pas tenu de couvrir le site entier. Par exemple, les sites dont le contenu n'est pas entièrement contrôlé par une seule organisation PEUVENT choisir de ne pas employer ce mécanisme ou PEUVENT choisir de mettre un fichier de référence de politique qui ne couvre qu'une partie limitée du site.

L'utilisation de l'endroit bien déterminé pour un fichier de référence de politique n'empêche pas celle d'autres mécanismes de spécification de ce fichier. Des parties de site PEUVENT employer n'importe lequel des autres mécanismes reconnus pour spécifier un fichier de référence pourvu que les exigences de non ambiguïté soient tenues.

Par exemple, imaginons un site galerie marchande Web tenu par l'entreprise GalerieExemple. Sur leur site Web (galerie.exemple.com), les entreprises, offrant des produits ou des services dans cette galerie, disposeraient d'un sous-arbre propre du site, peut-être avec un chemin d'accès comme /entreprises/nom-entreprise. L'entreprise GalerieExemple peut choisir de placer un fichier de référence de politique dans l'endroit bien déterminé qui couvre leur site en entier, sauf le sous-arbre /entreprises. De cette façon, si l'entreprise ChaussuresExemple avait un contenu dans /entreprises/chaussuresexemple, elle pourrait employer l'un des autres mécanismes pour indiquer la localisation d'un fichier de référence de politique couvrant son emplacement du site galerie.exemple.com.

Il est un cas où l'utilisation de l'endroit bien déterminé pour un fichier de référence de politique se révèle particulièrement utile, c'est quand un site dispose d'un contenu réparti entre plusieurs hôtes. Par exemple, considérons un site qui utilise pour toutes ses applications basées sur le Web un hôte logique différent de celui pour son contenu HTML statique. Les autres mécanismes autorisés pour la spécification de l'emplacement d'un fichier de référence de politique exigent qu'un certain URI, sur l'hôte en cours d'accès, doive être ramené pour localiser le fichier de référence. Néanmoins, le mécanisme de localisation de l'endroit bien déterminé n'a pas une telle exigence. Considérons l'exemple d'un formulaire HTML situé à www.exemple.com. Imaginons que l'URI de l'attribut "action" sur ce formulaire mène au serveur cgi.exemple.com. Le fichier de référence de politique qui couvre le formulaire est incapable de produire une déclaration portant sur l'URI de l'attribut "action" qui traite le formulaire. Cependant, l'administrateur du site publie un fichier de référence de politique à http://cgi.exemple.com/w3c/p3p.xml qui couvre l'URI de l'attribut "action", permettant ainsi à un agent utilisateur de localiser facilement la politique P3P qui s'y applique, avant la soumission du contenu du formulaire.

2.2.2 Les en-têtes HTTP

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

L'en-tête P3P donne 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, URI-reference est défini selon RFC 2396 [URI], token et quoted-string sont définis par [HTTP1.1].

En conservant les règles pour les autres en-têtes HTTP, le nom de l'en-tête P3P peut s'écrire en toute casse. Le contenu devrait être écrit précisément selon la casse spécifiée dans ce document.

La directive policyref donne un URI qui spécifie la localisation d'un fichier de référence de politique, celui-ci peut appeler à son tour la politique P3P couvrant le document qui pointait vers le fichier de référence et, éventuellement, aussi bien d'autres. Quand l'attribut policyref est un URI relatif, cet URI est interprété relativement à l'URI de requête. Remarquer que le rapport de l'URI donné dans la directive policyref PEUT conduire à un code en retour de la classe HTTP 300 (redirection) ; les agents utilisateurs DOIVENT interpréter ces redirections selon une sémantique HTTP normale. Les fournisseurs de services devraient remarquer, bien sûr, que l'emploi de redirections va accroître le temps nécessaire aux agents utilisateurs pour trouver et interpréter leurs politiques. L'URI de policyref NE DOIT PAS être utilisé dans un autre but que la localisation et l'appel des politiques P3P.

La directive compact-policy-field est utilisée pour spécifier des « politiques compactes ». Ceci est décrit dans la Section 4.

Les agents utilisateurs qui trouvent des directives non reconnues (dans les directives extension-field) DOIVENT ignorer celles-ci. Ceci pour autoriser un déploiement plus aisé 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.exemple.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 qui pointe vers la politique de la ressource.

HTTP/1.1 200 OK
P3P: policyref="http://catalogue.exemple.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 avec des balises link incorporées (cf. [HTML]) qui indiquent la localisation du fichier de référence de politique P3P concerné. Cet emploi de P3P ne requiert aucun changement dans le comportement du serveur.

La balise link encode l'information de référence de politique qui aurait pu être exprimée avec une en-tête P3P. La balise link prend la forme suivante (ici, on a juste produit un format ABNF possible pour la balise link et supposé que les règles de syntaxe [HTML] pouvaient s'utiliser avec une telle balise dans un fichier HTML) :

[5]
p3p-link-tag
=
`<link rel="P3Pv1" href="` URI `">`
Ici, URI est défini selon RFC 2396 [URI].

Quand l'attribut href est un URI relatif, cet URI s'interprète relativement à l'URI de requête.

Pour illustrer à l'aide d'un exemple l'emploi de la balise link, on considère la référence 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 avec le fragment HTML suivant :

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

Finalement, remarquer que, étant donné que p3p-link-tag est incorporé dans un document HTML, son codage de caractères sera le même que celui du document HTML. À la différence des documents de politique P3P et de référence de politique (voir la section 2.3 et la section 3 ci-dessous), le p3p-link-tag n'a pas besoin d'être transcrit en [UTF-8]. Remarquer également que la balise link n'est pas sensible à la casse.

2.2.4 La balise XHTML link

De façon correspondante avec la balise HTML link, P3P gère également XHTML (cf. [XHTML-MOD]). Les serveurs PEUVENT renvoyer un contenu XHTML, en utilisant le module XHTML Link (cf. la Section 5.19 de [XHTML-MOD]), qui indique la localisation du fichier de référence de politique P3P concerné avec une balise XHTML link incorporée. Comme pour HTML, on peut utiliser une balise XHTML link pour encoder l'information de référence de politique, qui aurait pu être exprimée avec l'en-tête P3P :

2.2.5 Les ports HTTP et les autres protocoles

Les mécanismes décrits ici PEUVENT être utilisés pour des transactions HTTP sur tout protocole sous-jacent. Ceci comprend HTTP en texte plein sur des connexions TCP/IP ou HTTP encrypté sur des connexions SSL, tout comme HTTP sur tout autre protocole de communications que les concepteurs souhaitent implémenter.

Les URI PEUVENT contenir des numéros de port de réseau, comme spécifié dans RFC 2396 [URI]. Pour ce qui concerne P3P, les différents ports sur un seul hôte DOIVENT être considérés comme étant des « sites » distincts. Ainsi, par exemple, le fichier de référence de politique à l'endroit bien déterminé pour www.exemple.com sur le port 80 (http://www.exemple.com/w3c/p3p.xml) ne donnerait aucune information sur les politiques qui s'appliquent à www.exemple.com lors d'un accès via SSL (étant donné que la communication SSL prendrait part sur un port différent, 443 par défaut).

Ce document ne spécifie pas comment les politiques P3P peuvent être associées aux ressources ramenées par d'autres moyens que HTTP. Cependant, cela n'empêche pas le développement ultérieur de mécanismes d'association de politiques P3P avec des ressources ramenées via d'autres protocoles. De plus, des méthodes supplémentaires, associant des politiques P3P avec des ressources ramenées avec HTTP, peuvent être développées ultérieurement.

« errata-E1 »

2.3 La syntaxe et la sémantique du fichier de référence de politique

Cette section détaille le contenu des fichiers de référence de politique.

2.3.1 Exemple de fichier de référence de politique

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

  1. La politique P3P /P3P/Politiques.xml#un s'applique au site entier, sauf aux ressources dont le chemin d'accès commence par /catalogue, /cgi-bin ou /servlet ;
  2. La politique P3P /P3P/Politiques.xml#deux s'applique à toutes les ressources dont les chemins d'accèes commencent par /cgi-bin ou /servlet, sauf /servlet/inconnu.
  3. Aucune déclaration n'est faite sur quelle politique P3P s'applique à /servlet/inconnu ;
  4. Ces déclarations sont valides pour deux jours.

On peut représenter ces déclarations par 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>

Remarquer que cet exemple comprend également via <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 de référence de politique

Cette section définit la syntaxe et la sémantique des fichiers de référence de politique P3P. Tous les fichiers de références de politique DOIVENT être encodés avec [UTF-8]. Les serveurs P3P DOIVENT encoder leurs fichiers de référence de politique en utilisant cette syntaxe.

2.3.2.1 Le traitement du fichier de référence de politique

2.3.2.1.1 L'importance de l'ordre

Un fichier de référence 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 donné dans le fichier. Quand un agent utilisateur essaye de déterminer quelle politique s'applique à un URI donné, il DOIT utiliser le premier élément <POLICY-REF>, dans le fichier de référence de politique, qui concerne cet URI.

Remarquer que chaque élément <POLICY-REF> peut contenir de multiples éléments <INCLUDE>, <EXCLUDE>, <METHOD>, <COOKIE-INCLUDE> et <COOKIE-EXCLUDE > et que tous ces éléments d'un élément <POLICY-REF> DOIVENT être considérés ensemble pour déterminer si le <POLICY-REF> s'applique, ou non, à un URI donné. Ainsi, il n'est pas suffisant de trouver un élément <INCLUDE> qui corresponde à un URI donné, du fait que des éléments <EXCLUDE> ou <METHOD> peuvent intervenir comme modificateurs, l'élément <POLICY-REF> ne correspondant alors plus.

2.3.2.1.2 Les caractères joker dans les fichiers de référence de politique

Les fichiers de référence de politique déclarent quelle politique s'applique à un URI donné. Les fichiers de référence de politique reconnaissent un caractère joker simple permettant des déclarations sur des régions de l'espace d'URI. Le caractère astérisque « * » s'utiliser pour représenter une séquence de zéro ou plus autres caractères. Aucun autre caractère spécial (comme ceux trouvés dans les expressions régulières) n'est reconnu.

Remarquer, comme l'astérisque est aussi un caractère légal pour les URI ([URI]), que l'on doit suivre certaines conventions spéciales pour le codage de tels « URI étendus » dans un fichier de référence de politique :

Le masquage et le démasquage des URI dépendent en grande partie de la combinaison effective utilisée, pouvant même différer entre les composants individuels dans une seule combinaison, c'est pourquoi on ne peut donner ici aucune règle simple sur quels caractères doivent être masqués. Se reporter directement à [URI] pour des précisions sur le processus de masquage standard. Remarquer que les agents utilisateurs PEUVENT ignorer tout motif d'URI qui n'est pas 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 de référence 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 (voir 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> (référence 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 PCDATA est défini dans [XML].

2.3.2.3 La durée de vie d'un fichier de référence de politique et l'élément <EXPIRY>

2.3.2.3.1 La motivation et le mécanisme

Il est souhaitable que les serveur informent les agents utilisateurs sur la durée pendant laquelle ils peuvent utiliser les affirmations faites dans un fichier de référence de politique. Permettre aux clients de mettre en cache le contenu d'un fichier de référence réduit le temps requis pour traiter la politique de confidentialité associée à une ressource Web. Ceci réduit également la charge sur le réseau. De plus, les clients qui ne disposent pas d'un fichier de référence de politique valide pour un URI devront emprunter des pratiques de « zone sûre » pour leurs requêtes. Si les clients disposent de fichiers de référence de politique qu'ils savent être toujours valides, 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 de référence de politique DEVRAIENT contenir un élément <EXPIRY>, qui indique la durée de vie de ces fichiers. Si le fichier de référence ne contient pas d'élément <EXPIRY>, alors sa durée de vie par défaut est de 24 heures.

La durée de vie d'un fichier de référence de politique indique aux agents utilisateurs pendant combien de temps ils peuvent faire confiance aux affirmations faites dans le fichier de référence. En donnant une durée de vie pour un fichier de référence de politique, le site le publiant agrée que les politiques mentionnées dans le fichier de référence sont recevables pendant la durée de vie du fichier de référence. Par exemple, si un fichier de référence a une durée de vie de trois jours, alors un agent utilisateur n'a pas besoin de recharger ce fichier pendant trois jours et peut supposer que les références dans ce fichier sont justes pendant trois jours. Toutes les références de politiques données dans un seul fichier de référence de politique recevront la même durée de vie. La seule façon pour spécifier des durées de vie distinctes à différentes références de politique, c'est d'employer des fichiers de référence de politique séparés.

On utilise également le même mécanisme, donnant la durée de vie d'un fichier de référence de politique, pour indiquer la durée de vie d'une politique P3P. Ainsi, les éléments <POLICIES> DEVRAIENT également avoir un élément <EXPIRY> qui leur est associé. Cette durée de vie s'applique à toutes les politiques P3P contenues dans cet élément <POLICIES>. S'il n'y a pas d'élément <EXPIRY> associée à une politique P3P, alors sa durée de vie par défaut est de 24 heures.

Au moment de choisir la durée de vie des politiques et des fichiers de référence de politique, les sites doivent faire le choix de celle qui représente un compromis équilibré entre deux positions antagonistes. L'une, c'est que la durée de vie soit suffisante pour permettre aux agents utilisateurs de retirer un avantage significatif de la mise en cache. L'autre, c'est que le site puisse changer de politique, pour une nouvelle collecte de données, sans devoir attendre l'expiration d'une durée de vie trop longue. Une durée de vie dans une fourchette d'un à sept jours est sensée représenter un compromis raisonnable entre ces deux souhaits concurrents. Les sites doivent également se rappeler des exigences pour la mise à jour des politiques lors de leurs mises à jour de celles-ci.

Quand un fichier de référence de politique a expiré, les informations contenues dans ce fichier NE DOIVENT PAS être utilisées par un agent utilisateur jusqu'à tant que cet agent ait revalidé avec succès le fichier de référence ou ait ramené une nouvelle copie de celui-ci.

Remarquer, bien que les agents utilisateurs ne soient pas obligés de revalider les fichiers de référence de politiques ou ceux de politiques qui n'ont pas expiré, qu'ils PEUVENT choisir de le faire avant leur expiration pour réduire la probabilité de devoir utiliser des pratiques de « zone sûre ». Une implémentation d'agent utilisateur P3P valide n'est pas tenue de contenir un cache pour les politiques et les fichiers de référence de politique, même si l'implémentation serait plus performante si elle en avait un.

« errata-E2 »

2.3.2.3.2 L'élément <EXPIRY>

L'élément <EXPIRY> peut s'utiliser dans un fichier de référence de politique et/ou dans un élément <POLICIES> pour déclarer combien de temps le fichier de référence ou les politiques) restent valides. L'expiration est indiquée soit comme date d'expiration absolue, soit comme date relative. Une date d'expiration absolue est le moment, donné en temps GMT, juqu'à temps où le fichier de référence de politique ou les politiques sont valides. Une date d'expiration relative donne le nombre de secondes pendant lesquelles le fichier de référence ou les politiques sont valides. Cette date d'expiration est relative au moment où le fichier de référence ou les poliques ont été demandés par le client. Ce calcul DOIT être effectué en fonction 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 [HTTP1.1].

La quantié minimale de temps pour une date d'expiration relative est de 24 heures, ou 86400 secondes. Toute date d'expiration relative à moins de 86400 secondes DOIT être considérée comme étant égale à 86400 secondes dans l'implémentation d'un client. Si un client rencontre un date d'expiration absolue passée, il DOIT agir comme si AUCUN fichier de référence de politique (ou aucune politique) n'était disponible. Voir la section 2.4.7 sur L'absence d'un fichier de référence 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, HTTP-date est défini dans la section 3.3.1 de [HTTP1.1] et delta-seconds dans la section 3.3.2 de [HTTP1.1].
2.3.2.3.3 La requête des politiques et des fichiers de référence de politique

Dans la réalité physique d'un réseau, il peut se trouver des caches dans lesquels les contenus des politiques et des fichiers de référence de politique sont stockés. Ceci favorise l'amélioration des performances d'ensemble du réseau, mais présente des effets délétères pour les opérations de P3P quand l'utilisation en est incorrecte. On a deux problèmes spécifiques :

  1. Quand un agent utilisateur reçoit un fichier de référence de politique (ou une politique), si il provient d'un serveur cache (voir, par exemple, [CACHING]), l'agent utilisateur a besoin de connaître depuis combien de temps le fichier de référence ou la politique résidaient dans le serveur. Cette durée DOIT être soustraite de la duré de vie d'une politique ou d'un fichier de référence de politique ayant des dates d'expiration relatives ;
  2. Quand un agent utilisateur a besoin de revalider un fichier de de référence de politique (ou une politique), il doit être sûr que la revalidation ramène une version courante du fichier de référence ou de la politique. Par exemple, considérons qu'un agent utilisateur détienne un fichier de référence de politique avec une date d'expiration relative de un jour. Si l'agent utilisateur le recharge d'un serveur cache et que ce fichier y résidait depuis trois jours, alors le fichier résultant n'est d'aucune utilité.

HTTP 1.1 [HTTP1.1] possède des mécanismes de contrôle de cache puissants, qui autorisent les clients à effectuer des opérations conditionnelles sur les caches dans un réseau ; ces mécanismes peuvent résoudre les problèmes mentionnés ci-dessus. La méthode spécifique sera abordée plus loin.

HTTP 1.0, par contre, n'offre pas ces mécanismes de contrôle de cache plus sophistiqués. Un serveur cache HTTP 1.0, de toute évidence, va calculer une durée de vie de cache pour le fichier de référence de politique (ou les politiques) par rapport à la dernière date de modification du fichier ; la durée de vie de cache pourrait se trouver significativement plus longue que celle spécifiée par l'élément <EXPIRY>. À cause de ceci, le serveur cache pourrait renvoyer aux clients le fichier de référence de politique (ou les politiques) au-delà de la durée de vie indiquée par l'élément <EXPIRY> ; en conséquence, les agents utilisateurs recevraient un fichier de référence (ou des politiques) sans utilité.

Le second problème lié au serveur cache HTTP 1.0, c'est qu'un agent utilisateur ne dispose d'aucun moyen de connaˆtre depuis combien de temps le fichier de référence est stocké dans le serveur cache. Si le fichier de référence de politique (ou les politiques) s'appuie sur une date d'expiration relative, il serait alors impossible pour l'agent utilisateur de déterminer si la durée de vie du fichier est épuisée ou quand elle va l'être.

Ainsi, si un agent utilisateur demande un fichier de référence de politique ou une politique et s'il n'a aucune assurance de l'absence de caches HTTP 1.0 dans le trajet vers le serveur d'origine, alors la requête DOIT forcer une revalidation d'un bout à l'autre. Ceci peut être obtenu avec l'entête de requête HTTP Pragma: no-cache. Remarquer que ni HTTP ni P3P ne définissent de moyen pour déterminer s'il y a un serveur cache HTTP 1.0 dans une route dans un réseau, c'est pourquoi l'agent utilisateur, à moins de détenir cette information d'une source extérieure, DOIT forcer une revalidation d'un bout à l'autre.

Si l'agent utilisateur a la connaissance que tous les caches sur la route vers le serveur d'origine sont compatibles avec HTTP 1.1 (ou qu'il n'y a aucun cache sur la route vers le serveur d'origine), alors plutôt que de forcer une revalidation d'un bout à l'autre, le client PEUT effectuer ce qui suit :

  1. Utiliser des en-têtes de requête de gestion de cache pour garantir que le fichier reçu n'est pas plus vieux que sa durée de vie. Ceci est effectué avec le paramètre de gestion de cache max-age, avec un âge significativement moindre que la durée de vie du fichier de référence de politique (ou des politiques). Par exemple, un agent utilisateur pourrait envoyer Cache-Control: max-age=43200, garantissant ainsi une réponse pas plus âgée que 12 heures ;
  2. Soustraire l'âge de la réponse de la durée de vie du fichier de référence de politique (ou des politiques), si celui-ci utilise une date d'expiration relative. L'âge de la réponse est donnée par l'en-tête de réponse HTTP Age:.

Remarquer que le client est dans l'impossibilité de prédire avec acuité l'importance de la latence qui peut affecter une requête HTTP. Ainsi, si le fichier de référence de politique concernant une requête est sur le point d'expirer, le client PEUT vouloir avertir l'utilisateur et/ou revalider le fichier de référence avant de poursuivre dans la requête.

2.3.2.3.4 La gestion des erreurs pour les durées de vie des fichiers de référence de politique et des politiques

La sémantique des situations suivantes est spécifiquement définie :

  1. Une date d'expiration absolue situé dans le passé rend le fichier de référence de politique (ou les politiques) obsolète(s), tout comme une date d'expiration invalide ou malformée, que cette dernière soit relative ou absolue. Pour ce cas, les agents utilisateurs DOIVENT agir comme si AUCUN(E) fichier de référence de politique (ou politique) n'était disponible. Voir la section 2.4.7 L'absence d'un fichier de référence de politique pour la procédure à suivre dans de tels cas ;
  2. Une date d'expiration relative inférieure à 86400 secondes (un jour) est considérée être égale à 86400 secondes ;
  3. Quand un fichier de référence de politique contient plus d'un élément <EXPIRY>, le premier a préséance pour la détermination de la durée de vie du fichier de référence.

2.3.2.4 L'élément POLICY-REF

Un fichier de référence de politique peut appeler plusieurs politiques P3P, en donnant des précisions sur chacune d'elles. L'élément <POLICY-REF> décrit les attributs d'une seule politique P3P. Les éléments contenus dans l'élément <POLICY-REF> donnent la localisation de la politique et spécifient les régions de l'espace d'URI (et les cookies) que chacune des politiques couvre.

<POLICY-REF>
contient les informations concernant une seule politique P3P.
about (attribut obligatoire)
Référence d'URI ([URI]), la partie identifiant de fragment dénotant le nom de la politique (donné dans son attribut name) et la partie URI dénotant l'URI où la politique réside (un fichier de politique ou un fichier de référence de politique - voir la Section 3.2). S'il s'agit d'une référence d'URI relatif, elle s'interprète relativement à l'URI du fichier de référence de politique dans lequel elle réside.
[11]
policy-ref
=
`<POLICY-REF about="` URI-reference `">`
*include
*exclude
*cookie-include
*cookie-exclude
*method-element
*extension
`</POLICY-REF>`
Ici, URI-reference est défini selon RFC 2396 [URI].

2.3.2.5 Les éléments INCLUDE et EXCLUDE

Chacun des éléments <INCLUDE> ou <EXCLUDE> spécifie un URI local ou un jeu d'URI locaux. Un jeu d'URI est spécifié si le caractère joker « * » est utilisé dans le motif d'URI. Ces éléments sont utilisés pour spécifier la partie du site Web couverte par la politique appelée par l'élément <POLICY-REF> englobant.

Quand les éléments <INCLUDE> et, en option, <EXCLUDE> sont présents dans un élément <POLICY-REF>, cela signifie que la politique, spécifiée par l'attribut about de l'élément <POLICY-REF>, s'applique à tous les URI de l'hôte appelé correspondant à l'URI ou aux URI locaux retenus par l'un ou l'autre élément <INCLUDE>, mais non retenus par un élément <EXCLUDE>.

Une politique référencée dans un fichier de référence de politique ne peut s'appliquer qu'aux URI de l'hôte DNS (Domain Name System) qui la référence. Ainsi, par exemple, un fichier de référence de politique à l'endroit bien déterminé de l'hôte www.exemple.com ne peut appliquer de politiques qu'aux ressources sur www.exemple.com. Cependant, si foo.exemple.com comprend dans ses réponses une en-tête HTTP P3P qui référence un fichier de référence de politique sur bar.exemple.com, ce fichier de référence s'appliquerait aux ressources de foo.exemple.com (et non à celles de bar.exemple.com ou www.exemple.com). Le même fichier de référence de politique pourrait être référencé dans les en-têtes HTTP P3P envoyées par plusieurs hôtes, auquel cas il pourrait s'appliquer à chacun des hôtes qui le référencent. Les éléments <INCLUDE> et <EXCLUDE> DOIVENT spécifier les motifs d'URI par rapport à la racine de l'hôte DNS sur lequel ils sont appliqués. Cette obligation NE s'applique PAS à la localisation du fichier de politique P3P (l'attribut about de l'élément <POLICY-REF>).

Si un élément <METHOD> (section 2.3.2.8) spécifie une ou plusieurs méthodes pour une référence de politique englobante, il s'ensuit que toutes les méthodes non mentionnées sont en conséquence non couvertes par cette politique. Au cas où il s'agit de la seule référence de politique pour un préfixe d'URI donné, les agents utilisateurs DOIVENT supposer qu'AUCUNE politique n'est effective, pour toutes les méthodes NON mentionnées dans le fichier de référence de politique. Il est légal, mais inutile, de fournir un élément <METHOD> sans <INCLUDE> ni <COOKIE-INCLUDE>.

Il est légal, mais inutile, de fournir un élément <EXCLUDE> sans élément <INCLUDE> ; auquel cas, l'élément <EXCLUDE> DOIT être ignoré par les agents utilisateurs.

Remarquer que le jeu d'URI spécifié avec les éléments <INCLUDE> et <EXCLUDE> ne comprend pas de cookies, qui pourraient être placés ou resservis lors de la requête de l'un de ces URI ; pour associer des politiques aux cookies, les éléments <COOKIE-INCLUDE> et <COOKIE-EXCLUDE> sont nécessaires.

[12]
include
=
"<INCLUDE>" relativeURI "</INCLUDE>"
[13]
exclude
=
"<EXCLUDE>" relativeURI "</EXCLUDE>"
Ici, relativeURI est défini selon RFC 2396 [URI], avec en plus, le caractère « * » qui doit être traité comme un caractère joker, ainsi que défini dans la section 2.3.2.1.2.

2.3.2.6 L'élément HINT

Les suggestions de référence de politique apportent une optimisation des performances, qui peuvent être utilisés dans certaines conditions. Un site peut déclarer une référence de politique pour lui-même en utilisant l'endroit bien déterminé, l'en-tête de réponse P3P ou la balise HTML/XHTML link. Il PEUT en plus offrir des suggestions pour des références de politiques supplémentaires, comme celles déclarées par d'autres sites.

Par exemple, une page HTML pourrait suggérer des références de politique pour ses hyperliens, son contenu incorporé et ses URI d'action. Les agents utilisateurs PEUVENT employer le mécanisme de suggestion pour la découverte des fichiers de référence de politique avant de requérir les URI concernés, quand les références de politique ne sont pas disponibles à partir de l'endroit bien déterminé.

Les agents utilisateurs qui utilisent des suggestions pour ramener des politiques NE DOIVENT PAS les appliquer à d'autres sites que celui qui contient le fichier de référence de politique suggéré.

Tout fichier de référence de politique PEUT contenir zéro ou plus suggestions de référence de politique. Chaque suggestion est contenu dans un élément <HINT> avec deux attributs : scope et path.

L'attribut scope est utilisé pour spécifier un système d'URI et l'autorité sur laquelle la référence de politique peut s'appliquer. Si la composante autorité (cf. [URI]) est une composante 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 dans une autre position, DOIT être encodé selon les conventions de la section 2.3.2.1.2 et NE DOIT PAS contenir de chemin d'accès, de requête ou de fragment de composante d'URI. De surcroît, si l'autorité est un serveur, elle ne DEVRAIT PAS contenir une partie information sur l'utilisateur.

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

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

L'attribut path est utilisé pour la localisation du fichier de référence de politique sur le site suggéré. C'est un URI relatif dont la base est le système d'URI et l'autorité retenue dans l'attribut scope. L'attribut path NE DOIT PAS être un URI absolu, ce qui fait que le fichier de référence de politique est toujours ramené du site même sur lequel il est appliqué.

Exemple 2.3 :

<HINT scope="http://www.exemple.org" path="/mapolitique/p3.xml" />
<HINT scope="http://www.exemple.net:81" path="/w3c/prf.xml" />
<HINT scope="http://*.shop.exemple.com" path="/w3c/prf.xml" />
[14]
hint
=
`<HINT scope="` scheme ( `://` | `:/` ) authority `" path="` relativeURI `/>`
Ici, scheme, authority et relativeURI sont issus de RFC 2965 [STATE].

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

Les éléments <COOKIE-INCLUDE> et <COOKIE-EXCLUDE> sont utilisés pour associer les politiques aux cookies (cf. [COOKIES] et [STATE]).

Une politique de cookie DOIT couvrir toutes les données (dans le champs de P3P) qui sont stockées dans ce cookie ou en liaison avec celui-ci. Elle DOIT également référencer toutes les destinations des données stockées dans ce cookie ou exploitées par celui-ci. De surcroît, toutes les données/intentions stockées ou en liaison avec un cookie DOIVENT également être mentionnées dans la politique de cookie. Encore, si ces données reliées sont collectées par HTTP, alors la politique, qui couvre cette requête GET/POST/quoi que ce soit, doit 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 va annoncer que CatalogueExemple collecte ces données et expliquer ce qui va en être fait. Si l'entreprise CatalogueExemple place un cookie, de façon à pouvoir reconnaître ses clients et observer leurs comportements sur son site Web, elle aurait une politique distincte pour ce cookie. Cependant, si ce cookie est aussi relié au nom, à l'adresse de facturation et de livraison de l'utilisateur, peut-être pour que CatalogueExemple puisse générer des pages de catalogue personnalisées en fonction de l'endroit où le client habite, alors ces données doivent également être divulguées 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, spécifiés dans [COOKIES] et [STATE].

Chacun des éléments <COOKIE-INCLUDE> ou <COOKIE-EXCLUDE> peut être utilisé pour comparer (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 spécifiée par l'attribut about, quand les cookies sont mis à partir des ressources du site Web où le fichier de référence de politique réside :

<COOKIE-INCLUDE> (resp. <COOKIE-EXCLUDE>)
inclus (resp. exclus) 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 la valeur de l'attribut domain est le caractère point « . », le domaine ne correspondra qu'aux cookies qui omettent l'attribut domain (et ont ainsi un domaine équivalent à l'hôte de requête, selon RFC 2965 ([STATE]).

Les cookies qui omettent l'attribut path ont pour chemin d'accès par défaut celui de l'URI de requête qui a généré la réponse set-cookie, selon RFC 2965 [STATE]. L'attribut path d'un élément <COOKIE-INCLUDE> devrait être comparé avec cette valeur par défaut si un 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 aux cookies qui auront cet attribut, quelle que soit la valeur de celui-ci.

Quand les éléments <COOKIE-INCLUDE> et, en option, <COOKIE-EXCLUDE> sont présents dans un élément <POLICY-REF>, la politique spécifiée dans l'attribut about de l'élément <POLICY-REF> s'applique à chaque cookie correspondant à un élément <COOKIE-INCLUDE> et ne correspondant pas à un élément <COOKIE-EXCLUDE>.

Les agents utilisateurs DOIVENT interpréter les éléments <COOKIE-INCLUDE> et <COOKIE-EXCLUDE> dans un fichier de référence de politique pour déterminer la politique qui s'applique aux cookies placés ou resservis de l'hôte sur lequel le fichier de référence s'applique. Alors que l'attribut domain d'un élément <COOKIE-INCLUDE> peut avoir une correspondance plus large (par exemple, si l'attribut domain est omis, il correspond par défaut à toute valeur de domaine), les agents utilisateurs DOIVENT limiter leur application de la politique aux domaines qui pourraient être légalement utilisés dans un cookie placé par l'hôte sur lequel le fichier de référence de politique s'applique. Par exemple, si abc.xyz.exemple.com déclare une référence de politique avec <COOKIE-INCLUDE domain="*.xyz.*ple.com"/>, ceci correspondrait aux domaines tels que .abc.xyz.exemple.com et .xyz.exemple.com, mais non .exemple.com ou .xyz.sample.com.

On peut associer une politique P3P à un cookie par l'hôte qui a placé le cookie tout comme par l'un ou tous les hôtes sur lesquels il pourrait être lu. Un agent utilisateur PEUT rapporter une politique de cookie au moment de sa mise en place et l'appliquer plus tard quand le cookie est resservi, peut-être par les autres hôtes dans le domaine. Un agent utilisateur PEUT requérir un fichier de référence de politique d'un hôte avant de resservir un cookie à cet hôte et, si le fichier de référence contient un élément <COOKIE-INCLUDE> adéquat, une politique sera appliquée à ce cookie, même si ce cookie n'a pas été placé par cet hôte. Tout hôte, auquel le cookie peut être resservi, 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. Ainsi, les sites, qui placent des cookies susceptibles d'être resservis aux multiples hôtes d'un domaine, ont besoin d'une coordination pour s'assurer que tous les hôtes puissent suivre la politique déclarée. De surcroît, les sites devraient être prudents quant à leur utilisation de caractères joker et s'assurer que, par inadvertence, ils n'appliquent pas une politique à ceux des cookies qui ne seraient pas concernés (y compris les cookies précédemment placés toujours en activité et les cookies placés par les autres hôtes du domaine).

La politique qui concerne un cookie s'applique jusqu'à ce que la politique expire, même si le fichier de référence de politique associé expire avant celle-ci (mais après que le cookie est placé). Si la politique associée à un cookie a expiré, alors l'agent utilisateur DEVRAIT ré-évaluer la politique de cookie avant d'envoyer le cookie. De surcroît, les agents utilisateurs DOIVENT n'utiliser que des politiques et fichiers de référence de politique non expirés lors de l'évaluation de nouveaux événements set-cookie.

L'exemple 2.4 déclare que /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 /P3P/Politiques.xml#un s'applique à tous les cookies, sauf ceux ayant pour leurs attributs name la valeur de "cookie-repoussant", domain la valeur de ".exemple.com" et path la valeur de "/", et que /P3P/Politiques.xml#deux s'applique à tous les cookies ayant pour leurs attributs name la valeur de "cookie-repoussant", domain la valeur de ".exemple.com" et path la valeur de "/".

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=".exemple.com" path="/"/>
    </POLICY-REF>
    <POLICY-REF about="/P3P/Politiques.xml#deux">
       <COOKIE-INCLUDE name="cookie-repoussant" value="*" domain=".exemple.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, token, NAME, VALUE, Domain et Path sont définis selon RFC2965 [STATE], avec, de surcroît, que le caractère « * » doit être traité comme un caractère joker, ainsi que défini dans la section 2.3.2.1.2.

Remarquer que [STATE] déclare que les valeurs par défaut pour les attributs Domain et Path des cookies devraient être utilisés dans la comparaison, si ces attributs ne se trouvaient pas dans un cookie donné. Également, conformément à [STATE], si une valeur de Domain explicitement spécifiée ne commence par un caractère arrêt complet (« . »), l'agent utilisateur DOIT lui en ajouter un en préfixe ; remarquer que chaque valeur de Path commence par le caractère « / ».

2.3.2.8 L'élément METHOD

Par défaut, une référence de politique s'applique aux URI déclarés, quelle que soit la méthode employée pour accéder à la ressource. Cependant, 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 quand ceux-ci effectuent des méthodes PUT ou DELETE que quand ils effectuent des méthodes GET.

L'élément <METHOD> d'un fichier de référence de politique est utilisé pour déclarer que la référence de politique englobante ne s'applique que quand les méthodes spécifiées sont utilisées pour accéder aux ressources référencées. L'élément <METHOD> peut se répéter 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> couvre les ressources indiquées quelles que soient les méthodes utilisées pour y accéder.

Ainsi, pour déclarer que /P3P/Politiques.xml#un s'applique à toutes les ressources dont le chemin d'accès commence par /docs/, pour les méthodes GET et HEAD, alors que /P3P/Politiques.xml#deux s'applique aux méthodes PUT et DELETE, la référence de politique s'écrirait comme suit :

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>

Remarquer que HTTP requiert le même comportement pour les requêtes GET et HEAD, c'est pourquoi il est inutile de spécifier des politiques P3P pour ces méthodes. La syntaxe pour l'élément <METHOD> est :

[17]
method-element
=
`<METHOD>` Method `</METHOD>`
Ici, Method est défini dans la section 5.1.1 de [HTTP1.1].

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

2.3.3 L'application d'une politique à un URI

Un fichier de référence de politique spécifie la politique qui s'applique à un URI donné. En d'autres termes, la politique indiquée décrit tous les effets issus de la requête d'un URI donné (dans certains cas, avec l'élément <METHOD> spécifié adéquatement).

La règle générale qui décrit ce que signifie la couverture d'un URI par une politique P3P : la politique appelée DOIT couvrir les actions que le logiciel client d'un utilisateur est sensé effectuer en réponse à la requête de cet URI. De manière évidente, la politique doit décrire toute la collecte des données effectuée par le site en résultat du traitement de la requête de l'URI. Ainsi, si un URI donné est couvert pour ce qui concerne des requêtes GET, alors la politique donnée par le fichier de référence de politique DOIT décrire toute la collecte des données effectuée par le site quand cet URI est requis. De la même façon, si un URI est couvert pour des requêtes POST, alors toute collecte de données, qui survient en résultat du POSTage d'un formulaire ou d'un autre contenu, DOIT être décrite par la politique.

La notion de « actions que le logiciel client est sensé effectué » comprend le placement de cookies côté client ou autres mécanismes de gestion d'état invoqués par la réponse. Si un code exécutable est renvoyé suite à la requête d'un URI, alors la politique P3P, qui couvre cet URI, DOIT couvrir certaines actions qui vont survenir quand ce code est exécuté. Ces actions couvertes sont toutes celles qui surviendrait, sans que l'utilisateur ne les invoque explicitement. Si l'action explicite de l'utilisateur provoque la collecte de données, alors la politique P3P couvrant l'URI de cette action divulguerait cette collecte.

Quelques exemples spécifiques :

  1. L'appel d'un URI renvoie une page HTML qui contient un formulaire, le contenu de ce formulaire est envoyé à un deuxième URI quand l'utilisateur clique un bouton « Envoyer ». La politique P3P couvrant le deuxième URI DOIT divulguer toutes les donnés collectées par le formulaire. La politique P3P couvrant le premier URI (l'URI à partir duquel le formulaire a été chargé) PEUT ou NON divulguer des données qui seront collectées par le formulaire ;
  2. Une page HTML comprend un code JavaScript qui enregistre pendant combien de temps cette page est affichée, si l'utilisateur a déplacé, ou non, le pointeur de la souris sur un certain objet de la page ; au moment de quitter la page, le code JavaScript envoie ces renseignements au serveur d'où provient la page HTML. L'activité du code JavaScript DOIT être couverte par la politique P3P de la page HTML. Le raisonnement est que cette activité a lieu sans que l'utilisateur en ait connaissance ou y consente, et celle-ci survient automatiquement en résultat du chargement de la page ;
  3. Une ressource renvoie un code exécutable pour un logiciel de courrier électronique. Pour que l'utilisateur puisse utiliser le logiciel, il doit lancer un programme d'installation, lancer le logiciel de courrier et enfin utiliser les fonctionnalités de celui-ci. La politique P3P couvrant l'URI à partir duquel le logiciel de courrier est téléchargé n'est pas tenue de déclarer les données qui pourraient être collectées lors de l'utilisation de ce logiciel de courrier. L'installation et le lancement du logiciel de courrier électronique ne font clairement pas partie de la session de navigation Web, c'est pourquoi ce n'est pas abordé par cette spécification. On pourrait concevoir un protocole distinct pour permettre aux applications téléchargées de présenter une politique P3P, mais cela reste en-dehors du sujet de cette spécification ;
  4. Une page HTML, contenant un formulaire, comprend un appel vers un code exécutable qui fournit une interface personnalisée côté client. Les données de l'interface sont envoyées vers un site lors de la soumission du formulaire. Dans ce cas, l'URI de la page HTML et l'URI de l'interface personnalisée ne sont pas obligés de déclarer les données propres à l'interface personnalisée. Cependant, l'URI vers lequel le contenu du formulaire est posté DOIT couvrir les données issues de l'interface personnalisée, tout comme il devrait couvrir toutes les autres données collectées au cours du traitement du formulaire. Ce comportement est similaire à la manière dont les formulaires HTML sont gérés quand ceux-ci n'utilisent que les contrôles HTML standards : le contrôle en lui-même ne collecte aucune donnée et les données sont collectées lors du postage du formulaire. Remarquer que cet exemple suppose que le formulaire n'est seulement envoyé que quand l'utilisateur presse effectivement un bouton « envoi » ou apparenté. Si le formulaire était posté automatiquement (par exemple, par un code JavaScript dans la page), alors cet exemple serait semblable à l'exemple 2, les données collectées par le formulaire DEVANT être décrites par la politique P3P qui couvre le formulaire HTML ;
  5. Les requêtes vers un URI sont redirigées vers une tierce partie. Si le premier interlocuteur incorpore des données personnelles collectées précédemment dans la chaîne de requête ou dans d'autres parties de l'URI de redirection, la politique de confidentialité de l'URI de ce premier interlocuteur DOIT décrire les types des données transmises et inclure la tierce partie comme destinataire.

2.3.4 Les formulaires et les mécanismes associés

Les formulaires requiert une attention spéciale, étant donné qu'ils sont souvent reliés à des scripts CGI ou à d'autres applications côté serveur par leur URI d'action (l'action d'URI est l'URI donné dans l'attribut action de l'élément HTML <FORM>, comme défini dans la section 17.3 de [HTML]). Ces URI d'action sont très souvent couverts par une politique différente de celle du formulaire lui-même.

Si un agent utilisateur est incapable de trouver une règle include correspondant à un URI donné dans le fichier de référence de politique, référencé à partir de la page, il DEVRAIT supposer qu'aucune politique n'est active. Dans ces circonstances, les agents utilisateurs DEVRAIENT vérifier l'endroit bien déterminé sur l'hôte de l'URI d'action pour essayer de trouver un fichier de référence de politique couvrant l'URI d'action. Si cela ne donnait aucune politique P3P pour couvrir l'URI d'action, alors un agent utilisateur PEUT essayer de ramener le fichier de référence de politique en utilisant le mécanisme des éléments <HINT> sur l'URI d'action et/ou en émettant une requête HEAD vers l'URI d'action, avant la soumission effective de données, pour trouver la politique active. Les services DEVRAIENT s'assurer que les applications côté serveur puissent répondre correctement à de telles requêtes HEAD et renvoyer le lien de la référence de politique correspondante dans les en-têtes. Au cas où l'application sous-jacente ne comprend pas la requête HEAD et aucune politique n'est pré-déclarée pour l'URI d'action en question, l'agent utilisateur DOIT supposer qu'aucune politique n'est active et DEVRAIT en avertir l'utilisateur ou prendre les mesures correspondantes en fonction des préférences de l'utilisateur.

Remarquer que les services pourraient 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 ces circonstances, on peut accepter que l'application en question ne reconnaisse que les méthodes indiquées dans le fichier de référence de politique (par exemple, les requêtes PUT n'ont pas besoin d'être reconnues). Les agents utilisateurs NE DEVRAIENT PAS essayer de délivrer une requête HEAD à un URI d'action si les méthodes concernées, spécifiées par l'attribut method du formulaire, ont été correctement pré-déclarés dans le fichier de référence de politique de la page.

Dans certains cas, des données différentes sont collectées au même URI d'action en fonction d'une certaine sélection dans le formulaire. Par exemple, un service pourrait offrir de rechercher à la fois des personnes (par nom et/ou par email) et des images (arbitraires). En jouant sur un jeu de boutons radio du formulaire, une seule application côté serveur, située à un seul et même URI d'action, gère les deux cas et collecte les informations requises nécessaires à la recherche. Si un service veut 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 de référence de politique (en utilisant un élément <INCLUDE> correspondant à l'URI d'action). Auquel cas, les agents utilisateurs DOIVENT supposer que tous les éléments de données sont collectés en toutes circonstances. Cette solution offre la commodité d'une politique unique mais pourrait ne pas refléter le fait que seule une partie des éléments de données sont collectées à la fois. Les services DEVRAIENT s'assurer qu'une simple requête HEAD vers l'URI d'action (i.e., sans argument, particulièrement sans la valeur du bouton radio sélectionné) renverra une politique qui couvre tous les cas.

Remarquer que si un formulaire est géré au travers de l'utilisation de la méthode GET, alors l'URI d'action reflète le choix des éléments du formulaire sélectionnés par l'utilisateur. Dans certains cas, il sera possible d'utiliser la syntaxe du caractère joker, permis dans les fichiers de référence de politique, pour spécifier différentes politiques pour différentes utilisations du même gestionnaire d'URI d'action du formulaire. De ce fait, les agents utilisateurs DOIVENT inclure la partie chaîne de requête des URI lors des comparaisons avec les éléments <INCLUDE> et <EXCLUDE> dans les fichiers de référence de politique.

2.4 Les obligations supplémentaires

2.4.1 La non-ambiguïté

Les agents utilisateurs doivent être capables de déterminer sans ambiguïté quelle politique s'applique à un URI donné. Pour cela, les sites DEVRAIENT éviter de déclarer plus d'une politique non expirée par URI donné. Dans certains cas peu fréquents, les sites PEUVENT déclarer plusieurs politiques non expirées par URI, par exemple, lors d'une période de transition, quand le site est en cours de changement de politique. Dans ces cas, le site ne sera probablement pas capable de déterminer de manière fiable quelle politique un utilisateur donné a vue, et il DOIT alors honorer toutes les politiques (c'est aussi le cas pour les politiques compactes, cf. la section 4.1 et la section 4.6). Les sites DOIVENT être prudents dans leurs pratiques quand ils déclarent plusieurs politiques pour un URI donné et doivent pouvoir honorer effectivement toutes les politiques simultanément.

Si un fichier de référence de politique à l'endroit bien déterminé déclare une politique non expirée pour un URI donné, cette politique s'applique, indépendamment d'éventuels fichiers de référence conflictuels référencés au travers des en-têtes HTTP ou des balises HTML/XHTML link.

Si une en-tête de réponse HTTP comprend des références vers plus d'un fichier de référence de politique, les agents utilisateurs P3P DOIVENT ignorer toutes les références situées après la première.

Si un fichier HTML (ou XHTML) comprend des balises HTML (ou XHTML) link qui référencent plusieurs fichiers de référence de politique, les agents utilisateurs DOIVENT ignorer toutes les références situées après la première.

Si un agent utilisateur découvre plus d'une politique P3P non expirée pour un URI donné (par exemple, parce qu'une page a en même temps une en-tête P3P et une balise link qui référencent différents fichiers de référence de politique, ou parce que les en-têtes P3P pour deux pages du site référencent différents fichiers de référence déclarant différentes politiques pour un même URI), l'agent utilisateur PEUT supposer que l'une de ces politiques, ou toutes, s'applique, car le site DOIT toutes les honorer.

2.4.2 Les diverses langues

Des versions en diverses langues (traductions) de la même politique peuvent être offertes par le serveur en utilisant l'en-tête HTTP Content-Language pour indiquer correctement qu'une langue particulière est utilisée pour la politique. Ceci est pratique pour que des champs lisibles par un humain, tels que entité et conséquence, puissent être présentés en diverses langues. On peut utiliser le même mécanisme pour offrir des versions en diverses langues des schémas de données. Les serveurs DEVRAIENT renvoyer un politique localisée en réponse à une requête HTTP avec une en-tête HTTP Accept-Language, quand une politique correspondant aux préférences de langues données est disponible.

Toutes les fois où l'en-tête Content-Language est utilisée pour distinguer des politiques au même URI offertes en plusieurs langues, les politiques DOIVENT avoir la même signification dans chacune des langues. Deux politiques (ou deux schémas de données) sont considérées identiques si :

De par l'utilisation du mécanisme de Accept-Language, les impl&eaucute;menteurs devraient prendre en considération que les agents utilisateurs peuvent voir différentes traductions d'une politique ou d'un fichier de préférence de politique, malgré l'envoi d'une même en-tête de requête Accept-Language si une nouvelle version traduite d'une politique, ou d'un schéma de données, a été ajoutée.

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

[18]
xml-lang
=
` xml:lang="` language `"`
Ici, language est un identifiant de langue, comme défini dans [LANG].

2.4.3 La « zone sûre »

P3P définit un jeu spécial de pratiques de « zone sûre », qui DEVRAIENT être utilisées par tous les agents utilisateurs et les services mettant en œuvre P3P pour les communications qui interviennent dans le chargement d'une politique P3P ou d'un fichier de référence de politique. Notamment, les requêtes vers l'endroit bien déterminé, pour les fichiers de référence de politique, DEVRAIENT être couvertes par ces pratiques de « zone sûre ». Les communications couvertes par les pratiques de zone sûre DEVRAIENT mettre en œuvre une collecte minimale de données, toutes les données collectées n'étant utilisées que de manière non identifiable.

Pour gérer cette zone sûre, les agents utilisateurs P3P DEVRAIENT supprimer la transmission des donnés qui ne sont pas indispensables à la recherche de la politique d'un site, tant que la politique n'a pas été ramenée. Pour cela, les pratiques de zone sûre pour les agents utilisateurs revêtent les exigences suivantes :

Les pratiques de zone sûre pour les serveurs revêtent les exigences suivantes :

Remarquer que les exigences de zone sûre ne disent pas que les sites ne peuvent pas conserver une information identifiable, seulement qu'ils NE DEVRAIENT PAS utiliser de manière identifiable les informations collectées lors du service d'un fichier de politique ou de référence de politique. Pister la source d'une attaque en déni de service, par exemple, serait une raison légitime pour utiliser ces informations.

2.4.4 Le traitement fait par les agents utilisateurs des politiques et des fichiers de référence de politique

Les agents utilisateurs P3P ne DOIVENT rendre ou interagir avec des politiques P3P et des fichiers de référence de politique que si ceux-ci sont des fichiers XML bien formés.

Les agents utilisateurs P3P ne DEVRAIENT rendre ou interagir avec des politiques P3P et des fichiers de référence de politique que si ceux-ci sont conformes au schéma XML donné dans l'Appendice 4 et NE DEVRAIENT PAS considérer une partie de politique ou de fichier de référence qui n'est pas conforme à ce schéma XML.

Les agents utilisateurs NE DOIVENT PAS modifier localement une politique P3P ou un fichier de référence 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 de référence de politique NE DEVRAIENT PAS contenir d'informations sensibles. Ceci signifie qu'il n'existe aucune exigence de sécurité supplémentaire pour le transport d'une référence vers une politique P3P, en plus de ce qui est requis pour le document auquel cette référence est associée ; ainsi, si un document HTML est normalement servi dans une session non cryptée, alors P3P ne requiert pas ni ne recommande que le document soit servi dans une session cryptée quand une référence est comprise dans ce document.

2.4.6 Les mises à jour des politiques

Remarquer, quand un site Web change de politique P3P, que la politique antérieure s'applique aux données collectées quand celle-ci était active. Il est de la responsabilité du site de conserver un historique des politiques P3P et fichiers de référence de politique passés, tout comme les dates où ceux-ci étaient actifs, et d'appliquer ces politiques de manière appropriée.

Si un site souhaite appliquer une nouvelle politique P3P sur des données collectées précédemment, il DOIT fournir une notice et des mesures appropriées, pour l'acceptation par les utilisateurs de la nouvelle politique, qui soient cohérentes avec les lois en vigueur, les directives de l'industrie ou les autres accords ayant trait à la vie privée passés par le site.

2.4.7 L'absence d'un fichier de référence de politique

Si, pour un site donné, aucun fichier de référence de politique n'est disponible, les agents utilisateurs DOIVENT considérer qu'il en existe un (vide) à l'endroit bien déterminé, avec une durée de vie de 24 heures, et ainsi, si l'utilisateur retourne sur le site au-delà de ces 24 heures, l'agent utilisateur DOIT essayer à nouveau de ramener un fichier de référence de l'endroit bien déterminé. Les agents utilisateurs PEUVENT vérifier plus souvent l'endroit bien déterminé ou quand survient un certain événement tel que l'utilisateur cliquant le bouton de rafraîchissement du navigateur. Les sites PEUVENT placer un fichier de référence de politique, à l'endroit bien déterminé, indiquant aucune disponibilité de politique, tout en réglant la date d'expiration de manière à ce que les agents utilisateurs sachent qu'une vérification toutes les 24 heures n'est pas nécessaire.

2.4.8 L'évaluation asynchrone

Les agents utilisateurs PEUVENT, de manière asynchrone, ramener et évaluer des politiques P3P. C'est-à-dire que les politiques P3P ne sont pas forcément ramenées et évaluées avant d'autres transactions HTTP. Ce comportement peut dépendre des préférences de l'utilisateur et du type de requête effectuée. Tant qu'une politique n'est pas évaluée, l'agent utilisateur DEVRAIT considérer le site comme si celui-ci n'avait pas de politique de confidentialité. Une fois la politique évaluée, l'agent utilisateur DEVRAIENT considérer les préférences de l'utilisateur. Pour favoriser un comportement déterministe, l'agent utilisateur DEVRAIT reporter l'application d'une politique après un certain temps. Par exemple, un navigateur Web pourrait appliquer les préférences de l'utilisateur juste après avoir achevé une navigation ou au moment de confirmer l'envoi d'un formulaire.

2.5 Scénarios exemples

Pour aider au déploiement de P3P sur les sites, on présente plusieurs scénarios et on décrit comment P3P est utilisé sur ces sites.

Scénario 1 : Le site Web basique.exemple.com emploie une diversité d'images, toutes celles-ci sont hébergées sur le site. Il comprend également quelques formulaires, ceux-ci sont tous envoyés sur le site. Ce site 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). Étant donné que toutes les images et les URI d'action des formulaires se trouvent dans des répertoires couverts par la politique P3P du site, les agents utilisateurs vont automatiquement reconnaître la couverture des images et des formulaires par la politique du site.

Scénario 2 : Le site Web bourdonnant.exemple.com emploie un réseau de distribution du contenu appelé rdc.exemple.com pour héberger ses images, de manière à répartir la charge entre ses serveurs. Ainsi, toutes les images du site ont des URI à rdc.exemple.com. L'hôte Rdc se comporte, dans ce cas, comme un agent pour l'hôte Bourdonnant et 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 l'élément <HINT>, dans son fichier de référence de politique, pour désigner un fichier de référence de politique adéquat sur Rdc, indiquant que les images sont couvertes par la politique P3P de exemple.com.

Scénario 3 : Le site Web bourdonnant.exemple.com a également passé un contrat avec une entreprise de publicité, nommée cliquepub.exemple.com, pour la fourniture de bandeaux de publicité sur son site. Le contrat autorise Cliquepub à placer des cookies pour contrôler la présentation d'un bandeau de publicité au visiteur, ceci pas plus de trois fois. Cliquepub collecte des statistiques sur combien de visiteurs voient chaque publicité et établit un rapport à destination des sociétés dont les produits font l'objet des publicités. Cependant, ces rapports ne révèlent aucun renseignement individuel sur le visiteur. Comme pour le scénario 2, la politique de confidentialité de Bourdonnant s'applique à ces publicités hébergées par Cliquepub, c'est pourquoi Bourdonnant utilise l'élément <HINT>, dans son fichier de référence de politique, pour désigner un fichier de référence de politique adéquat sur Cliquepub, celui-ci indiqnant que la politique P3P de Bourdonnant s'applique aux contenus servis par cliquepub.exemple.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 que les seules données reçues par celles-ci sont des données composites.

Scénario 4 : Le site Web bourdonnant.exemple.com a également passé un contrat avec discussion.exemple.com pour héberger un espace de discussion pour ses utilisateurs. Quand les utilisateurs entrent dans l'espace de discussion, ceux-ci quittent en fait le site Bourdonnant. Cependant, l'espace de discussion a 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 l'élément <HINT>, dans son fichier de référence de politique, pour désigner un fichier de référence de politique adéquat de Discussion, celui-ci indiquant que l'espace de discussion de Discussion est couvert par la politique de confidentialité de Bourdonnant, facilitant ce faisant une transition en douceur vers l'espace de discussion.

Scénario 5 : Le site Web metarecherche.exemple.com a un formulaire qui permet aux utilisateurs de taper une requête de recherche, celle-ci étant effectuée sur le moteur de recherche de leur choix qui est situé sur un autre site. Quand un utilisateur clique le bouton « envoi », la requête de recherche est en fait directement soumise à ces moteurs de recherche, l'URI d'action n'étant pas situé sur recherche.exemple.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 l'élément <HINT> pour désigner leur fichier de référence de politique correspondant. Ainsi, quand l'utilisateur clique sur le bouton « envoi », son agent utilisateur peut vérifier sa politique de confidentialité avant de poster des données. Pour que ce mécanisme de choix fonctionne, Metarecherche pourrait en fait avoir un formulaire dont l'URI d'action est sur son propre site, 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 lors de la réception de la réponse de redirection.

Scénario 6 : Le site Web metarecherche.exemple.com a également un formulaire qui permet aux utilisateurs de taper une requête de recherche qui est soumise à dix moteurs de recherche en même temps. Metarecherche soumet les requêtes, reçoit en retour les résultats obtenus de 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. Ainsi, la seule politique P3P impliquée est celle qui couvre le site Web de Metarecherche. Cependant, le site Metarecherche doit annoncer qu'il partage les requêtes de recherche de l'utilisateur avec des tierces parties (les sites des moteurs de recherche), à moins que Metarecherche n'ait des contrats avec ces moteurs de recherche, auquel cas ils agissent comme des agents pour Metarecherche.

Scénario 7 : Le site Web metarecherche.exemple.com comporte également des bandeaux de publicité fournis par une société nommée reseaupub.exemple.com. Reseaupub utilise des cookies pour établir des profils d'utilisateur entre de nombreux sites différents, de manière à proposer à ceux-ci des bandeaux de publicité plus adaptés à leurs centres d'intérêt. Étant donné que la destination des données, concernant les sites visités par les utilisateurs, ne se limite pas à servir des publicités sur le site Web de Metarecherche, on ne peut pas considérer Reseaupub comme un agent dans un tel contexte. Reseaupub doit créer sa propre politique P3P et utiliser son propre fichier de référence de politique pour désigner le contenu auquel il s'applique. De surcroît, Metarecherche peut en option utiliser l'élément <HINT>, dans son fichier de référence de politique, pour indiquer que le fichier de référence de politique P3P de Reseaupub s'applique aux publicités. Metarecherche ne devrait faire cela que si Reseaupub lui a signifié quelle politique P3P s'applique aux publicités et a agréé de notifier Metarecherche quand la référence de politique nécessite un changement.

Scénario 8: Le site Web bourdonnant.exemple.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 l'élément <COOKIE-INCLUDE>, dans son fichier de référence de politique, pour déclarer la politique appropriée pour ceux-ci. Pour l'optimisation des performances, il dispose également d'une politique compacte, en envoyant une en-tête P3P, qui comprend cette politique compacte, toutes les fois où il place un cookie.

Scénario 9: Le site Web config.exemple.com fournit des services d'optimisation pour toutes sortes 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 encode et range ces réponses dans un cookie. Plus tard, quand l'utilisateur visite Bourdonnant, un site qui a passé des accords avec Config, toutes les fois où leur navigateur demande un contenu pouvant être optimisé (certaines images ou fichiers audio, etc.), Bourdonnant va rediriger l'utilisateur vers Config, qui va lire le cookie de l'utilisateur et délivrer le contenu adéquat. Dans ce cas, le site Config devrait déclarer une politique de confidentialité qui décrit les types de 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 de référence de politique, pour déclarer la politique pour les cookies. Il référencera é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 2. Le site Bourdonnant va probablement aussi utiliser des éléments <HINT>, dans son fichier de référence de politique, pour référencer la politique pour le contenu délivré par Config.

3. La syntaxe et la sémantique des politiques

Les politiques P3P sont encodées en XML avec espaces de nommage (voir [XML] et [XML-Name]). On fournit un codage potentiel utilisant le modèle de données RDF ([RDF]) dans [P3P-RDF].

La section 3.1 commence par un exemple de politique de confidentialité en anglais avec une politique P3P correspondante. Les politiques P3P comprennent des affirmations générales qui s'appliquent à la politique entière ainsi que des affirmations spécifiques, appelées déclarations, qui ne s'appliquent que pour la gestion de types de données particuliers, qu'on appelle références de données. La section 3.2 décrit l'élément <POLICY> et les affirmations faites au niveau de la politique. La section 3.3 décrit les déclarations et les références 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, devant être transcrites dans une politique P3P. Les deux politiques concernent une 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 anglais et dans une description plus formelle utilisant les noms des éléments et des attributs P3P.

Exemple 3.1 : Politique de confidentialité de CatalogueExemple pour les navigateurs
Chez CatalogueExemple, nous sommes concernés par le respect de votre vie privée. Quand vous venez sur notre site pour y chercher un article, nous n'utilisons les informations fournies que pour améliorer le site et nous ne les stockons pas avec des informations que nous pourrions utiliser pour vous identifier.
La société CatalogueExemple participe au programme SceauConfidentielExemple. Le programme SceauConfidentielExemple garantie votre vie privée, en soumettant les sites Web affiliés à des normes de confidentialité élevées et en certifiant par des audits indépendants que les pratiques vis-à-vis des informations recueillies sont suivies.
Adresser les questions concernant cette déclaration à :
CatalogueExemple
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email : catalogue@exemple.com
Telephone 248-EXEMPLE (248-392-6753)

Si nous n'avons pas répondu à vos attentes ou si nous n'avons pas répondu de manière satisfaisante à celles-ci, vous pouvez contacter SceauConfidentielExemple à http://www.sceauconfidentiel.exemple.org. La société CatalogueExemple corrigera toutes les erreurs ou les actions erronnées qui seraient survenues en relation avec la politique de confidentialité.
Les renseignements que nous collectons et pourquoi nous les collectons :
Lors de votre navigation dans notre site, nous collectons :


Rétention des données :
Nous purgeons toutes les deux semaines les informations de navigation que nous collectons.

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

Exemple 3.2 : Politique de confidentialité de CatalogueExemple pour les acheteurs
Chez CatalogueExemple, nous sommes concernés par votre vie privée. Nous ne partagerons jamais votre numéro de carte de crédit ou toute autre information financière avec une tierce partie. Avec votre accord seulement, nous partagerons les renseignements avec des partenaires commerciaux soigneusement sélectionnés, qui correspondent soit aux préférences que vous avez spécifiquement exprimées, soit à vos habitudes déduites de vos achats passés. Plus nous saurons ce qui vous plait et ce qui ne vous plait pas, plus nous pourrons affiner nos offres à vos besoins.

La société CatalogueExemple participe au programme SceauConfidentielExemple. Le programme SceauConfidentielExemple garantie votre vie privée, en soumettant les sites Web affiliés à des normes de confidentialité élevées et en certifiant par des audits indépendants que les pratiques vis-à-vis des informations recueillies sont suivies.

Adresser les questions concernant cette déclaration à :
CatalogueExemple
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email: catalogue@exemple.com
Telephone +1 248-EXAMPLE (+1 248-392-6753)


Si nous n'avons pas répondu à vos attentes ou si nous n'avons pas répondu de manière satisfaisante à celles-ci, vous pouvez contacter SceauConfidentielExemple à http://www.sceauconfidentiel.exemple.org. La société CatalogueExemple corrigera toutes les erreurs ou les actions erronnées qui seraient survenues en relation avec la politique de confidentialité.
Lors de votre navigation dans notre site, nous collectons :

Si vous choisisséz d'acheter un article, nous vous demanderons certains renseignements supplémentaires dont :

Sur cette page également, nous vous proposerons de choisir de recevoir des emails, des appels téléphoniques ou des annonces de CatalogueExemple, ou de nos partenaires commerciaux soigneusement sélectionnés qui ont des pratiques de confidentialité similaires. Si vous choisissez de recevoir ces offres, cocher simplement la case appropriée. Vous pouvez vous désinscrire à tout instant, simplement en modifiant vos préférences.
Modification et mise à jour des informations personnelles
Les consommateurs peuvent modifier toutes les informations de leur compte personnel en se rendant dans la section préférences de CatalogueExemple à http://catalogue.exemple.com/preferences.html. Vous pouvez modifier votre adresse, votre numéro de téléphone, votre email, votre mot de passe ainsi que vos réglages de confidentialité.
Cookies
CatalogueExemple n'emploie des cookies que pour déterminer si vous avez déjà été client chez nous dans le passé et, si c'est le cas, pour personnaliser nos services en fonction de vos habitudes de navigation et d'achat. Nous ne stockons aucune information personnelle dans les cookies ni ne partageons ou vendons une quelconque information à d'autres parties ou affiliés.
Rétention des données
Nous conservons les informations ayant trait à vous et vos achats aussi longtemps que vous restez notre client. Si vous ne passez aucune commande dans une période d'un an, nous retirerons les informations vous concernant 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.exemple.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@exemple.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.exemple.org"
     short-description="sceauconfidentiel.exemple.org">
    <IMG src="http://www.sceauconfidentiel.exemple.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>
   			<!-- Remarquer également que la politique
   			de confidentialité du site lisible
			par un humain DOIT mentionner que les données
			sont purgé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.exemple.com/Privacy/confidentialite_achat.html"
     opturi="http://catalogue.exemple.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@exemple.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.exemple.org"
     short-description="sceauconfidentiel.exemple.org">
    <IMG src="http://www.sceauconfidentiel.exemple.org/Logo.gif" alt="Logo de SceauConfidentiel"/>
    <REMEDIES><correct/></REMEDIES>
   </DISPUTES>
  </DISPUTES-GROUP>
  <STATEMENT>
   <CONSEQUENCE>
     Nous enregistrons certaines informations pour le service de 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 cette information 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 nous enverrons des offres commerciales soigneusement
     sélectionnées que nous pensons vous intéresseront.
   </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>
     Nous vous autorisons à donner un mot de passe pour que vous puissiez
     accéder à vos propres informations.
   </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 personnaliserons notre site et mettrons 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 encodées en utilisant [UTF-8].

Pour les 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 champs <CONSEQUENCE> et/ou leurs politiques lisibles par un humain. Néanmoins, les politiques NE DOIVENT PAS faire des 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. Ceci est offert pour l'optimisation des performances : de nombreuses politiques peuvent être réunies en une seule requête, améliorant le trafic réseau et la mise en cache.

Un élément <POLICIES> est l'élément racine des fichiers de politique. De surcroît, on peut placer des éléments <POLICIES> dans le fichier de référence de politique, dans l'élément <META> ; auquel cas, l'agent utilisateur n'a besoin que de ramener un seul fichier, contenant à la fois le fichier de référence de politique et les politiques.

L'élément <POLICIES> peut contenir en option un attribut xml:lang (voir 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> (voir la section 5).

Comme les politiques sont incluses dans un élément <POLICIES>, chacune d'elles DOIT avoir un attribut name unique dans le fichier. Ceci permet aux références de politique (dans les éléments <POLICY-REF>) d'appeler cette politique.

Exemple 3.3 :

Les fichiers dans http://www.exemple.com/magasin/politiques.xml pourraient avoir le contenu suivant :

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

Les fichiers dans http://www.exemple.com/magasin/CDs/* pourraient alors être associés à la deuxième politique ("politique2") en utilisant le fichier de référence de politique suivant, dans http://www.exemple.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 élément <POLICY>. L'élément <POLICY> DOIT contenir un élément <ENTITY> identifiant l'entié légale qui expose les pratiques de confidentialité contenues dans la politique. De surcroît, 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 jeu de divulgations, telles qu'elles sont appliquées à un jeu d'éléments de données.
name (attribut obligatoire)
le nom de la politique, utilisé comme identifiant de fragment pour pouvoir appeler la politique.
discuri (attribut obligatoire)
l'URI de la déclaration de confidentialité en langage naturel.
opturi
l'URI des instructions que les utilisateurs peuvent suivre pour requérir ou décliner que leurs données soient employées dans un but particulier (inscription ou désinscription). Cet attribut est obligatoire pour les politiques qui contiennent un élément <PURPOSE> avec un attribut required réglé sur la valeur opt-in ou opt-out. Remarquer que les procédures d'inscription ou de désinscription sont déterminées par chaque site et ne comprennent pas forcément de mécanisme centralisé pour le site entier ou de mécanisme automatisé en ligne.
xml:lang
la langue dans laquelle la politique est exprimée (voir 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, URI est défini selon RFC 2396 [URI].

3.2.3 L'élément TEST

L'élément <TEST> s'utilise pour effectuer des simulations : la présence d'un élément <TEST> dans une politique indique que celle-ci n'est qu'un exemple et, à ce titre, elle DOIT être ignorée et ne doit pas être considérée comme une politique P3P valide.

[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, consistant en éléments <DATA> appelant tous les champs, ou partie de ceux-ci, du jeu de données de l'entreprise : il DOIT contenir à la fois le nom de l'entité légale et un ou plusieurs champs d'information de contact, parmi les champs adresse postale, numéro de téléphone, adresse email, URI. Remarquer que certaines lois et codes de conduite exigent que les entités incluent une adresse postale ou d'autres informations spécifiques en information de contact.

[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, string est défini comme une séquence de caractères (les caractères « " » et « & » étant masqués) parmi les valeurs admises dans le jeu de données de l'entreprise. PCDATA est défini comme dans [XML].

3.2.5 L'élément ACCESS

L'élément <ACCESS> indique si le site offre, ou non, un accès à diverses sortes d'information.

<ACCESS>
la possibilité qu'a un individu de consulter des données identifiées et de faire part de ses questions ou de ses inquiétudes au fournisseur de services. Les fournisseurs de services DOIVENT annoncer une valeur pour l'attribut access. La méthode de l'attribut access n'est pas spécifiée. Une annonce (autre que <all/>) n'implique pas qu'il soit possible d'accéder à toutes les données, mais que seules certaines données sont accessibles, et que l'utilisateur devraient entrer en relation avec le fournisseur de services pour déterminer quelles sont ses possibilités.

Remarquer que les fournisseurs de services peuvent également vouloir offrir des moyens pour accéder aux informations collectées autrement que par le Web à l'URI donné par l'attribut discuri. La portée des déclarations P3P se limite aux données collectées au travers de HTTP ou d'autres protocoles de transport Web. Aussi, quand un accès est offert au travers du Web, on recommande l'utilisation de mécanismes d'authentification et de sécurité renforcés pour ces accès ; en outre, les questions de sécurité débordent du cadre de 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 donné pour toutes les données identifiées.
<contact-and-other/>
Informations de contact identifiées et autres données identifiées : l'accès est donné aux informations de contact en ligne et physiques comme à d'autres données identifiées.
<ident-contact/>
Informations de contact identifiable : l'accès est donné aux informations de contact identifiées en ligne et physiques (par exemple, les utilisateurs peuvent accéder à une adresse postale).
<other-ident/>
Autres données identifiées : l'accès est donné à certaines 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 donné.
[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/>" | ; Des informations de contact identifiées et
                           d'autres données identifiées
"<ident-contact/>"     | ; Des informations de contact 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 conflits qui peuvent être suivies pour les réclamations concernant les 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 ont plusieurs procédures de résolution de conflit, devraient employer un élément <DISPUTES> différent pour chacune d'elles. Comme des procédures de résolution différentes reçoivent un traitement en remède séparé, chacun des éléments <DISPUTES> nécessite des éléments <LONG-DESCRIPTION>, <IMG> et <REMEDIES> distincts, si ceux-ci sont utilisés.

<DISPUTES>
Décrit les procédures de résolution des conflits qui peuvent être suivies concernant les contestations survenant au sujet des pratiques de confidentialité d'un service ou en cas de violation de protocole.
resolution-type (attribut obligatoire)
Prend l'une des quatres valeurs suivantes :
Service clientèle [service]
Un individu peut se plaindre auprès du représentant du service clientèle d'un site Web, chargé de la résolution des conflits concernant l'utilisation des données collectées. La description DOIT inclure des renseignements sur les moyens de contacter le service clientèle.
Organisation indépendante [independent]
Un individu peut se plaindre auprès d'une organisation indépendante pour la résolution des conflits concernant l'utilisation des données collectées. La description DOIT inclure des renseignements sur les moyens de contacter la tierce partie.
Tribunal [court]
Un individu peut porter plainte à l'encontre du site Web.
Lois applicables [law]
Les conflits survenant par rapport à la déclaration de confidentialité seront résolus en fonction des lois référencées dans la description.
service (attribut obligatoire)
L'URI de la page Web du service clientèle, ou de l'organisation indépendante, ou l'URI vers des renseignements sur la juridiction ou les lois applicables concernées.
verification
L'URI ou le certificat à utiliser dans des buts de vérification. Il est prévu que les fournisseurs de labels offriront un mécanisme pour vérifier la certification dont un site prétend disposer.
short-description
Une brève description lisible par un humain des noms concernés de la juridiction légale, des règlements applicables, de la tierce partie ou des renseignements pour contacter le service clientèle, si ceux-ci n'étaient pas déjà mentionnés à l'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 : celle-ci devrait comprendre les noms concernés de la juridiction légale, des règlements applicables, de la tierce partie ou des renseignements pour contacter le service clientèle, si ceux-ci n'étaient pas déjà mentionnés à l'URI du service en question.

<LONG-DESCRIPTION>
Cet élément contient une description lisible par un humain (qui peut être détaillée).
<IMG>
L'image d'un logo (par exemple, celui de l'organisation indépendante ou celui de la cour de justice concernée).
src (attribut obligatoire)
L'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)
Une alternative textuelle très courte 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, string est défini comme une séquence de caractères (les caractères « " » et « & » devant être masqués) et PCDATA est défini comme dans [XML].

Remarquer qu'il peut y avoir plusieurs services de garantie, spécifiés au moyen de plusieurs éléments <DISPUTES> dans l'élément <DISPUTES-GROUP>. Il est attendu de ces champs qu'ils soient utilisés d'un certain nombre de façons, y compris l'indication que les pratiques de confidentialité des uns sont auto-garanties, contrôlées par une tierce partie ou sous la juridiction d'une autorité de régulation.

3.2.7 L'élément REMEDIES

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

<REMEDIES>
Les réparations au cas où une violation de politique survient.

L'élément <REMEDIES> doit contenir l'une ou plusieurs des actions suivantes :

<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 viole sa politique de confidentialité, celui-ci octroiera à l'individu un montant financier spécifié dans la politique de confidentialité lisible par un humain ou le montant des dommages causés.
<law/>
Les réparations pour violation de la déclaration de politique seront déterminées en fonction des lois référencé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 qui s'applique aux types de données particuliers.

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 gérées en fonctions des annonces faites dans les autres éléments contenus dans la déclaration. Ainsi, les sites peuvent regrouper des éléments qui se gèrent de la même manière et créer une déclaration pour chacun des regroupements. Les sites, qui préfère divulguer des intentions séparées et d'autres informations pour chaque sorte de données collectées, peuvent le faire en créant une déclaration distincte pour chaque élément de données.

<STATEMENT>
Les pratiques concernant les données telles qu'elles sont appliqé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 une déclaration de pratique, les fournisseurs de services peuvent rassembler l'une ou l'autre des divulgations (intentions, destinataires et rétention) dans une déclaration sur les éléments de données. Les fournisseurs de services DOIVENT, pour de tels ensembles, opérer additivement. Par exemple, un site, qui distribue votre âge selon le destinataire <ours> (nous-mêmes et nos agents), mais qui distribue votre code postal selon le destinataire <unrelated> (tierces parties sans rapport avec nous), PEUT dire qu'il distribue vos nom et code postal selon <ours> et <unrelated>. Une telle déclaration semble distribuer plus de données que ce qui se passe effectivement. Il est du ressort du fournisseur de services de déterminer si son annonce doit avoir le mérite de la spécifité ou dela brièveté. Remarquer que lors du rassemblement des annonces entre des déclarations qui comprennent un élément <NON-IDENTIFIABLE>, cet élément peut être inclus dans la déclaration globale seulement s'il apparaît dans chacune des déclarations, si celles-ci avaient été faites séparément.

De même, on doit toujours annoncer toutes les options qui s'appliquent. Considérons un site, dont le seul but est de collecter des informations selon une intention <contact/> (Le contact des visiteurs pour la commercialisation de services ou de produits). Bien que ceci soit considéré dans le contexte d'une intention <current/> (Accomplissement et gestion de l'activité pour laquelle des données sont fournies), le site doit déclarer les deux intentions <contact/> et <current/>. Condidérons un site qui distribue des informations selon le destinataire <ours> pour une redistribution selon le destinataire <public> : le site doit déclarer les destinataires selon <ours> et <public>.

Les fournisseurs de services agrègent souvent les données qu'ils collectent. Parfois, ces données composites peuvent être utilisées pour des buts différents de ceux des données originales, partagées plus largement ou retenues plus longuement que les données originales. Par exemple, de nombreux sites publient ou divulguent des statistiques à leurs annonceurs, comme le nombre des visiteurs sur leur site Web, les pourcentages de visiteurs rangés dans divers groupes démographiques, etc. Quand on utilise ou partage des statistiques composites, dont il est impossible de déduire des renseignements personnels sur un individu ou un foyer à partir de celles-ci, aucune annonce concernant ces statistiques n'est nécessaire dans un politique P3P. Néanmoins, les services DOIVENT divulguer le fait que les données originales sont collectées et déclarer toute utilisation de celles-ci avant leur agrégation.

3.3.2 L'élément CONSEQUENCE

Les éléments <STATEMENT> peuvent en option contenir un élément <CONSEQUENCE> qui peut être présenté à un utilisateur humain pour donner de plus amples informations sur les pratique d'un site.

<CONSEQUENCE>
Les conséquences qui peuvent être présentées à l'utilisateur pour exliquer en quoi la pratique suggérée peut être utile dans un contexte donné, même si l'utilisateur n'en permettait normalement pas la pratique.
[35]
consequence
=
"<CONSEQUENCE>"
PCDATA
"</CONSEQUENCE>"

3.3.3 L'élément NON-IDENTIFIABLE

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

<NON-IDENTIFIABLE/>
Cet élément signifie soit qu'aucune donnée n'est collectée (y compris les journaux Web), soit que l'organisme collectant les données rendra anonyme les données référencées dans l'élément <STATEMENT> les englobant. Pour que des données soient considérées anonymes, il ne doit pas y avoir de moyen raisonnable pour que l'entité ou une tierce partie puissent rattacher les données collectées à l'identité d'une personne. Certains types de données sont par essence anonymes, tels que les identifiants de session générés aléatoirement. Les données qui permettraient, dans certaines circonstances, l'identification des personnes, telles que les adresses IP, les noms ou les adresses, doivent recevoir une transformation non réversible pour être considérées anonymes.
En exemple d'une transformation irrémédiable : mettre les sept derniers bits d'une adresse IP à zéro. Cette transformation doit s'appliquer à tous les exemplaires des données, y compris ceux stockés sur un support de sauvegarde. Un algorithme, qui remplace des données identifiées par l'unique valeur correspondante d'une table, n'est pas considéré comme étant irrémédiable. De surcroît, un hachage cryptographique à un sens ne serait pas considéré irrémédiable si le jeu des valeurs possibles est trop petit, toutes les valeurs possibles hachées pouvant être générées puis comparées avec la valeur que quelqu'un essaye de rétablir.

Si l'élément <NON-IDENTIFIABLE> est présent dans un quelconque élément <STATEMENT> d'une politique, alors on DOIT inclure une explication lisible par un humain sur la manière dont les données ont été rendues anonymes ou bien relier celle-ci à un attribut discuri.

Également, si l'élément <NON-IDENTIFIABLE> est présent dans un élément <STATEMENT>, alors les autres éléments dans ce <STATEMENT> sont optionnels.

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

3.3.4 L'élément PURPOSE

Chaque élément <STATEMENT>, qui ne comprend pas d'élément <NON-IDENTIFIABLE>, DOIT contenir un élément <PURPOSE> qui exprime une ou plusieurs intentions par rapport à la collecte ou aux utilisations des données. Les sites DOIVENT ranger leurs pratiques quant aux données selon l'une ou plusieurs des intentions spécifiées ci-dessous.

<PURPOSE>
Les intentions pour le traitement des données concernant le Web.

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

<current/>
Accomplissement et gestion de l'activité pour laquelle des données sont fournies : L'information peut être utilisée par le fournisseur de services pour achever l'activité pour laquelle elle a été fournie, que ce soit une activité ponctuelle, telle que retourner le résultat d'une recherche sur le Web, faire suivre un email ou placer une commande, ou une activité récurrente, telle qu'offrir un service d'abonnement ou autoriser l'accès à un carnet d'adresses en ligne ou un portefeuille électronique.
<admin/>
Administration du site Web et du système : L'information peut être utilisée pour le support technique du site Web et de son système. Ceci comprend le traitement des informations sur le compte hébergé, les informations utilisées pour la sécurisation et la maintenance du site et la vérification de l'activité du site Web par le site ou ses agents.
<develop/>
Recherche et développement : L'information peut être utilisée pour l'amélioration, l'évaluation ou autrement pour l'examen du site du service, les produits ou le marché. Cela ne comprend pas les informations personnelles utilisées pour la personnalisation ou la modification du contenu en fonction de l'individu spécifique, ni les informations utilisées pour évaluer, cibler, profiler ou contacter la personne.
<tailoring/>
Ajustement ponctuelle : L'information peut être utilisée pour ajuster ou modifier le contenu ou l'aspect du site, cette information n'étant utilisée que pour une seule visite du site et pas pour une quelconque personnalisation ultérieure. Par exemple, un magasin en ligne pourrait suggérer d'autres articles qu'un visiteur est susceptible d'acheter, en fonction des articles déjà placés dans son panier d'achat.
<pseudo-analysis/>
Analyse pseudonyme : L'information peut être utilisée pour créer ou établir un enregistrement concernant un individu particulier, ou une machine, attaché à un identifiant pseudonyme, sans pour autant rattacher des données identifiées (comme le nom, l'adresse, le numéro de téléphone ou l'adresse email) à l'enregistrement. Ce profil sera utilisé pour déterminer les habitudes, les intérêts ou les autres caractéristiques d'individus dans un but de recherche, d'analyse et d'étude, mais pas pour essayer d'identifier des personnes spécifiques. Par exemple, un mercaticien peut vouloir étudier les intérêts des visiteurs pour diverses parties d'un site Web.
<pseudo-decision/>
Décision pseudonyme : L'information peut être utilisée pour créer ou établir un enregistrement concernant un individu particulier, ou une machine, attaché à un identifiant pseudonyme, sans pour autant rattacher des données identifiées (comme le nom, l'adresse, le numéro de téléphone ou l'adresse email) à l'enregistrement. Ce profil sera utilisé pour déterminer les habitudes, les intérêts ou les autres caractéristiques d'individus dans un processus décisionnel qui affecte directement un individu, mais pas pour essayer d'identifier des personnes spécifiques. Par exemple, un mercaticien peut vouloir ajuster ou modifier un contenu affiché sur le navigateur en fonctions des pages visitées lors de visites antérieures.
<individual-analysis/>
Analyse individuelle : L'information peut être utilisée pour déterminer les habitudes, les intérêts ou les autres caractéristiques d'individus en les combinant 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 comment les acheteurs en ligne achètent dans un magasin physique.
<individual-decision/>
Décision individuelle : L'information peut être utilisée pour déterminer les habitudes, les centres d'intérêts ou les autres caractéristiques d'individus en les combinant avec des données identifiées dans un processus décisionnel qui affecte directement un individu. Par exemple, un magasin en ligne suggère des articles à un visiteur qu'il serait susceptible d'acheter en fonction des articles déjà achetés lors de visites antérieures sur le site.
<contact/>
Contact des visiteurs pour la commercialisation de services ou de produits : L'information peut être utilisée pour contacter l'individu, au moyen d'un canal de communication autre que le téléphone, pour la promotion d'un produit ou d'un service. Ceci comprend la notification des mises à jour du site Web aux visiteurs. Ceci ne comprend pas une réponse directe à une question, à un commentaire ou au service clientèle pour une seule transaction - auxquels cas, on utiliserait la valeur <current/>. De surcroît, ceci ne comprend pas la commercialisation via un contenu Web ou les bandeaux publicitaires personnalisés incorporés aux sites que l'utilisateur visite - ces cas seraient couverts par les valeurs d'intention <tailoring/>, <pseudo-analysis/> et <pseudo-decision/>, ou <individual-analysis/> et <individual-decision/>.
<historical/>
Conservation historique : L'information peut être archivée ou stockée dans le but de conserver un historique social comme l'exigeraient une loi ou une politique existantes. Cette loi ou cette politique DOIVENT être référencées dans l'élément <DISPUTES> et DOIVENT inclure une définition spécifique du type de chercheur qualifié pour accéder à cette information, de l'endroit où celle-ci sera stockée et, notamment, en quoi cette collecte fait avancer la conservation de l'histoire.
<telemarketing/>
Le contact des visiteurs pour la commercialisation de services ou de produits via téléphone : L'information peut être utilisée pour contacter l'individu via des appels téléphoniques pour la promotion d'un produit ou d'un service. Ceci ne comprend pas une réponse directe à une question, à un commentaire ou au service clientèle pour une seule transaction - auxquels cas, la valeur d'intention <current/> serait utilisée.
<other-purpose> chaîne </other-purpose>
Autres usages : L'information peut être utilisée pour d'autres buts qui ne rentrent pas dans les définitions ci-dessus. (Pour ces cas, on DOIT fournir une explication lisible par un humain).

Chacun des types d'intention (sauf <current/>) admet les attributs optionnels suivants :

required
L'intention est une pratique requise, ou non, pour le site. L'attribut prend les valeurs suivantes :
[37]
 purpose
=
"<PURPOSE>"
*extension
1*purposevalue
*extension
"</PURPOSE>"
[38]
 purposevalue
=
"<current/>"                           | ; Accomplissement et gestion de l'activité pour laquelle les données sont 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] "/>"             | ; Le contact des visiteurs pour la commercialisation de services ou de 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 employer les éléments ci-dessus pour expliquer leurs intentions dans la collecte des données. Les fournisseurs de services DOIVENT divulguer toutes les intentions concernées. Si un fournisseur de services n'annonce pas qu'un élément de données sera utilisé pour une intention donnée, c'est une affirmation que ces données ne seront pas employées pour l'intention en question. Les fournisseurs de services qui annoncent utiliser des données pour une intention « Autres usages » DOIVENT donner des explications de ces intentions lisibles par un humain.

3.3.5 L'élément RECIPIENT

Chaque élément <STATEMENT>, qui ne comprend pas d'élément <NON-IDENTIFIABLE>, DOIT contenir un élément <RECIPIENT> qui contient un ou plusieurs destinataires des données collectées. Les sites DOIVENT doit ranger leurs destinataires parmi l'un ou plusieurs de ceux spécifiés suivants.

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

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

<ours>
Nous-même et/ou les entités agissants comme nos agents ou les entités pour lesquelles nous agissons en tant qu'agent : Dans ce contexte, un agent se définit comme une tierce partie qui traite les données pour le compte du fournisseur de services pour l'accomplissement des intentions déclarées. Par exemple, le fournisseur de services et sa division impression qui imprime les étiquettes des adresses, et ne fait rien de plus avec cette information.
<delivery>
Services de livraison qui ont éventuellement d'autres pratiques : Les entités légales effectuant un service de livraison, utilisant les données pour des intentions autres que l'accomplissement de l'intention déclarée. On pourrait aussi l'utiliser pour les services de livraison dont les pratiques vis-à-vis des données sont inconnues.
<same>
Entités qui suivent nos pratiques : Les entités légales qui utilisent les données pour leur propre compte selon des pratiques équivalentes. Par exemple, considérons un fournisseur de services qui garantit à l'utilisateur un accès aux informations personnelles collectées et qui propose également cet accès à un partenaire, qui ne l'utilise qu'une fois puis le jette. Étant donné que les destinataires, qui ont par ailleurs les mêmes pratiques, ne peuvent garantir à l'utilisateur cet accès à l'information jetée, ils ne sont pas considérés comme ayant les mêmes pratiques.
<other-recipient>
Entités légales qui suivent des pratiques différentes : Les entités légales qui sont soumises et redevables au fournisseur de services original, mais qui peuvent utiliser les données d'une manière non spécifiée dans les pratiques du fournisseur de services. (Par exemple, le fournisseur de services collecte des données qui sont partagées avec un partenaire les utilisant pour d'autres intentions. Néanmoins, il est de l'intérêt du fournisseur de services de s'assurer que les données ne sont pas utilisées de manière qui apparaîtrait abusive au regard de l'utilisateur comme pour ses propres intérêts).
<unrelated>
Tierces parties sans relation : Les entités légales dont les pratiques vis-à-vis de l'utilisation des données ne sont pas connues du fournisseur de services original.
<public>
Tribunes publiques : Des tribunes publiques, telles que les babillards, les annuaires publiques ou les annuaires de CD-ROM commerciaux.

Chacune des balises ci-dessus peuvent contenir en option :

[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 entités légales suivant nos pratiques
"<other-recipient" [required] ">" *recdescr
"</other-recipient>"             |  ; Les entités légales 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 tierces parties sans relation
[42]
recdescr
=
"<recipient-description>"
PCDATA                              ; description du destinataire
"</recipient-description>"

Les fournisseurs de services DOIVENT divulguer tous les destinataires concernés. P3P ne fait pas de différence sur la façon de délivrer les données au destinataire ; si des données sont partagées, P3P requiert alors simplement que ce partage soit divulgué dans la politique P3P. Des exemples de divulgations de données qui DOIVENT être couvertes par une politique P3P comprennent :

Remarquer, dans certains cas, que le jeu de destinataires ci-dessus peut ne pas décrire entièrement tous les destinataires des données. Par exemple, la question des auxilliaires de transaction, tels que le transport et les processeurs de paiement, qui sont nécessaires pour l'accomplissement et la gestion de l'activité mais qui peuvent suivre des pratiques différentes, posait problème. Actuellement, seuls les services de livraison peuvent être représentés explicitement dans une politique. Les autres auxilliaires de transaction de ce genre devraient être représentés dans celle des autres catégories qui reflète le mieux leurs pratiques en fonction du fournisseur de service original.

Un élément spécial pour les services de livraison est inclus, mais pas un seul pour les processeurs de paiement (tels que les banques ou les organismes de carte de crédit) pour les raisons suivantes : les institutions financières ont généralement des accords distincts avec leurs clients pour ce qui est de leurs données financières, alors que les destinataires des livraisons n'ont pas l'opportunité d'examiner la politique de confidentialité du service de livraison.

Remarquer que la balise <delivery> NE DEVRAIT PAS être employée pour des services de livraison qui admettent seulement utiliser des données pour le compte du fournisseur de services en vue de terminer la livraison.

3.3.6 L'élément RETENTION

Chaque élément <STATEMENT>, qui ne comprend pas d'élément <NON-IDENTIFIABLE>, DOIT contenir un élément <RETENTION> indiquant le genre de politique de rétention qui s'applique aux données référencées dans cette déclaration.

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

L'élément <RETENTION> DOIT contenir l'une des rétentions suivantes :

<no-retention/>
L'information est retenue pour la courte période de temps nécessaire à son utilisation lors d'une seule transaction en ligne. L'information DOIT être détruite en suite de cette interaction et NE DOIT PAS être écrite dans un journal, archivée ou stockée d'une autre manière. Ce type de politique de rétention s'appliquerait, par exemple, aux services qui ne gardent aucun journal des accès Web, qui ne placent un cookie que pour la durée d'une seule session ou qui collectent des informations pour effectuer une recherche sans conserver de journal des recherches effectuées.
<stated-purpose/>
Pour l'intention déclarée : l'information est retenue pour correspondre à l'intention déclarée. Ceci requiert que l'information soit jetée le plus tôt possible. Les sites DOIVENT avoir une politique de rétention qui établit un calendrier de destruction. La politique de rétention DOIT être inclue ou liée à la politique de confidentialité lisible par un humain.
<legal-requirement/>
Comme exigé par la loi ou responsabilité vis-à-vis des lois en vigueur : l'information est retenu pour correspondre à l'intention déclarée, mais la période de rétention est plus longue en raison de l'obligation ou de la responsabilité légales. Par exemple, une loi peut autoriser les consommateurs à contester les transactions pendant une certaine durée ; ainsi une entreprise peut décider, pour des raisons de responsabilité, de conserver les enregistrements des transactions, ou encore une loi peut exiger affirmativement d'une certaine entreprise de conserver des enregistrements pour un audit ou d'autres raisons de solvabilité. Les sites DOIVENT avoir une politique de rétention qui établit un calendrier de destruction. La politique de rétention DOIT être inclue ou liée à la politique de confidentialité lisible par un humain.
<business-practices/>
Déterminé par les pratiques commerciales du fournisseur de service : l'information est retenue sous les pratiques commerciales déclarées du fournisseur de services. Les sites DOIVENT avoir une politique de rétention qui établit un calendrier de destruction. La politique de rétention DOIT être inclue ou liée à la politique de confidentialité lisible par un humain.
<indefinitely/>
Indéfiniment : l'information est retenue pour une période de temps indéterminée. L'absence d'une politique de rétention serait reflétée sous cette option. Quand le destinataire est une tribune publique, c'est la politique de rétention appropriée.
[43]
retention
=
"<RETENTION>"
*extension
retentionvalue
*extension
"</RETENTION>"
[44]
retentionvalue
= 
"<no-retention/>"       | ; non retenue
"<stated-purpose/>"     | ; pour l'intention déclarée
"<legal-requirement/>"  | ; intention déclarée légale
"<indefinitely/>"       | ; période de temps indéterminée
"<business-practices/>"   ; pour des pratiques commerciales

3.3.7 Les éléments DATA-GROUP et DATA

L'élément <STATEMENT>, qui ne comprend pas d'élément <NON-IDENTIFIABLE>, DOIT au moins contenir un élément <DATA-GROUP> qui contient un ou plusieurs éléments <DATA>. Les éléments <DATA> sont utilisés pour décrire le type de données collecté 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)
La référence d'URI ([URI]), où la partie identifiant de fragment indique le nom d'un élément/jeu de données et la partie URI indique le schéma de données correspondant. Quand la partie URI n'est pas présente, si l'élément <DATA> est contenu dans un élément <DATA-GROUP>, alors l'URI de base par défaut est sensé être l'URI de l'attribut base. Pour les autres cas, comme toujours, l'URI de base par défaut est une référence au même document ([URI]).
Se rappeler que les noms des éléments et des jeux de données sont sensibles à la casse (ainsi, par exemple, user.gender diffère de USER.GENDER ou User.Gender).
optional
Indique si le site requiert des visiteurs, ou non, l'envoi de 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 (il est obligatoire), alors que la valeur "yes" indique que celui-ci est optionnel. La valeur par défaut est "no". L'attribut optional ne s'utilise que dans les politiques (non dans les définitions des schémas de données).

Remarquer que les agents utilisateurs devraient prendre des précautions quand ils utilisent l'attribut optional dans 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 (tel qu'une en-tête HTTP Referer ou des cookies), alors celui-ci devrait s'assurer que ces données ne soient pas transmises à des sites Web sur lesquels un élément de données est optionnel, si la politique du site ne correspondait pas aux préférences de l'utilisateur si l'élément de données était requis. En conséquence, pour les éléments de données que les utilisateurs tape généralement dans des formulaires, les agents utilisateurs devraient avertir les utilisateurs quand les pratiques d'un site concernant les données optionnelles ne correspondent pas à leurs préférences.

Les éléments <DATA> peuvent contenir les données réelles (comme déjà vu pour l'élément <ENTITY>) et contenir une informations sur la catégorie concerné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, URI-reference est défini comme dans [URI].

Par exemple, pour référencer la ville du foyer 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, le service enverrait dans une 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>

Quand la valeur réelle d'une donnée est connue, on peut l'exprimer dans l'élément <DATA>. Par exemple, comme vu dans 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, qui fournissent aux utilisateurs et aux agents utilisateurs des suggestions sur les usages prévus pour les données. Les catégories sont vitales pour faciliter l'implémentation et l'utilisation des agents utilisateurs P3P. Remarquer 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 l'échange de leurs données. Les catégories NE DEVRAIENT PAS être utilisées dans les éléments <DATA> d'un élément <ENTITY>.

Pour indiquer les catégories des données, on utilise les éléments suivants :

[47]
categories
=
"<CATEGORIES>" 1*category "</CATEGORIES>"
[48]
category
=
"<physical/>"    | ; Informations de contact physique
"<online/>"      | ; Informations de contact en ligne
"<uniqueid/>"    | ; Identifiants 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 d'emplacement
"<government/>   | ; Identifiants d'origine gouvernementale
"<other-category>" PCDATA "</other-category>" ; Autres
<physical/>
Informations de contact physique : Les informations qui permettent de contacter ou de localiser une personne dans le monde physique - telles que numéro de téléphone ou adresse.
<online/>
Informations de contact en ligne : Les informations qui permettent de contacter ou de localiser une personne sur l'Internet - telle que l'adresse email. Ces informations sont souvent indépendantes de l'ordinateur spécifique employé pour accéder au réseau. (Voir la catégorie « Informations sur le système »).
<uniqueid/>
Identifiants uniques : Les identifiants non financiers, excluant les identifiants d'origine gouvernementale, émis dans le but d'identifier ou de reconnaître un individu de manière fiable. Sont compris les identifiants délivrés par un site Web ou un service.
<purchase/>
Informations d'achat : Les informations générées activement par l'achat d'un produit ou d'un service, y compris l'information sur la méthode de paiement.
<financial/>
Informations financières : Les informations concernant les finances d'un individu, dont les informations sur l'état et l'activité du compte, tels que la situation du compte, l'historique des paiements ou des découverts, et les informations concernant l'achat ou l'utilisation d'instruments financiers d'un individu, y compris celles de sa carte de crédit ou de débit. Les informations concernant un achat discret, seul, par un individu, comme décrites dans la catégorie « Informations d'achat », n'entrent pas dans le cadre de « Informations financières ».
<computer/>
Informations sur le système : Les informations concernant le système informatique que l'individu utilise pour accéder au réseau - telles 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 dans le site Web - telles que les pages visitées et le temps passé sur chaque page.
<interactive/>
Données interactives : Les données générées activement à partir ou réfléchissant des interactions explicites avec un fournisseur de service au travers du site - telles que les requêtes vers un moteur de recherche ou les journaux de l'activité d'un compte.
<demographic/>
Données démographiques et socio-économiques : Les données concernant des caractéristiques individuelles - telles que le genre, l'âge et le revenu.
<content/>
Contenu : Les mots et expressions contenues dans le corps d'une communication -tels que le texte d'un email, les articles postés dans une tribune publique ou les discussions en ligne.
<state/>
Mécanismes de gestion d'état : Les mécanismes de maintien d'une session active avec un utilisateur ou de reconnaissance automatique des utilisateurs ayant visité un site ou accédé à un contenu particuliers précédemment - tels que les cookies HTTP.
<political/>
Informations politique : L'appartenance ou l'affiliation à des groupes telles que des organisations religieuses, des syndicats, des associations professionnelles, des partis politiques, etc.
<health/>
Informations de santé : Les informations concernant la santé physique ou mentale d'un individu, ses orientations sexuelles, l'utilisation ou la demande 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 - telles que la couleur favorite ou les goûts musicaux.
<location/>
Données de localisation : Les informations pouvant être utilisées pour identifier la localisation physique actuelle d'un individu et pour le suivi du changement de celle-ci - telles que les données de position GPS.
<<government/>>
Identifiants d'origine gouvernementale : Les identifiants délivrés par un gouvernement dans le but d'identifier un individu de manière fiable.
<other-category> string </other-category>
Autre : Les autres types de données qui n'entrent pas dans les cadres définis ci-dessus. (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 navigation décrivent le comportement effectif de l'utilisateur lors d'une navigation. Quand une adresse IP est stockée dans un fichier journal accompagnée d'informations concernant l'activité de navigation, les deux catégories computer et navigation devraient être utilisées. Interactive représente les données sollicitées activement pour fournir un certain service utile sur un site, en sus de la navigation. Content correspond à l'information échangée sur un site pour les besoins de la communication.

La catégorie other ne devrait être utilisée que si les données requises n'entrent dans aucune autre catégorie.

P3P utilise des catégories pour suggérer, aux utilisateurs et aux agents utilisateurs, le type d'information requis par un service. Alors 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. Les premiers sont appellées éléments de données de catégorie fixe (ou, en bref, « éléments de données fixes »), les derniers é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

P3P offre un mécanisme souple et puissant pour étendre sa syntaxe et sa sémantique à l'aide d'un élément : <EXTENSION>. Cet élément est utilisé pour indiquer les parties de la politique, du fichier de référence de politique ou du schéma de données appartenant à 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 à la syntaxe.
optional
Cet attribut détermine si l'extension est obligatoire ou optionnelle. Une extension obligatoire est indiquée en donnant à l'attribut optional la valeur no. Une extension obligatoire à la syntaxe P3P signifie que les applications ne comprenant pas cette extension ne peuvent comprendre la politique en entier (ou le fichier de référence de politique, ou le schéma de données) qui la contient. Une extension optionnelle, indiquée en donnant à l'attribut optional la valeur yes, signifie que les applications ne comprenant 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 le fichier de référence de politique, ou le schéma de données) comme si de rien n'était. L'attribut optional n'est pas requis ; sa valeur par défaut est yes.
[49]
extension
=
"<EXTENSION" [" optional=" `"` ("yes"|"no") `"`] ">" PCDATA "</EXTENSION>"

Par exemple, si www.catalogue.exemple.com souhaitait rajouter une fonctionnalité à P3P pour indiquer qu'un certain jeu d'éléments de données ne devait être collecté que pour les utilisateurs vivant aux États-Unis, au Canada ou au Mexique, il pourrait ajouter une extension obligatoire, comme celle-ci :

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

À l'inverse, si www.catalogue.exemple.com souhaitait ajouter une extension déclarant dans quel pays le serveur se trouve, une extension optionnelle serait plus appropriée, comme celle-ci :

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

L'attribut xmlns est significatif, étant donné qu'il spécifie les noms des éléments et attributs utilisés dans l'extension. Remarquer que, comme spécifié dans [XML-Name], l'URI d'espace de nommage sert juste d'identifiant unique pour les entités XML utilisées par l'extension. Néanmoins, les fournisseurs de services PEUVENT fournir une page décrivant l'extension à l'URI correspondant.

L'élément <EXTENSION> peut se trouver à diverses places dans la syntaxe P3P : ces positions font l'objet d'une spécification normative par le schéma XML présent dans l'appendice 4 (et d'une spécification informative par la syntaxe ABNF et par le DTD présent dans l'appendice 5).

3.6 Les préférences de l'utilisateur

Les agents utilisateurs DOIVENT documenter une méthode avec laquelle importer et traiter des préférences et DEVRAIENT documenter une méthode avec laquelle exporter des préférences.

Les agents utilisateurs P3P DOIVENT agir en fonction des réglages de préférence choisis par l'utilisateur. Cela suppose qu'ils soient capables de traiter une politique, ou un fichier de référence de politique, de manière appropriée pour évaluer chaque politique par rapport aux préférences ou aux autres critères de l'utilisateur spécifiés en paramètres. En fonction de ces paramètres, ceci peut vouloir dire, par exemple, que l'agent utilisateur vérifie la présence de parties requises de la politique P3P ou la validité de la syntaxe de la politique en entier.

4. Les politique compactes

Les politiques compactes sont des politiques P3P résumées qui suggèrent et permettent aux agents utilisateurs de prendre des décisions rapides et synchrones concernant l'application de la politique. Les politiques compactes représentent une optimisation des performances qui est OPTIONNELLE pour les agents utilisateurs comme pour les serveurs. Les agents utilisateurs, qui ne peuvent obtenir suffisamment d'information d'une politique compacte pour prendre une décision en fonction des préférences de l'utilisateur, DEVRAIENT ramener la politique complète.

Dans P3P, les politiques compactes contiennent des informations de politique concernant seulement les cookies (cf. [COOKIES] et [STATE]). Le serveur Web a la responsabilité de construire 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 dans une même réponse HTTP en tant que 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 Le référencement 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). Quand un site utilise des en-têtes P3P, il DEVRAIT l'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 qui un ou plusiers atomes délimités (d'où « politique compacte »). Les atomes peuvent survenir dans n'importe quel ordre, le caractère espace étant 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. La valeur du champs (i.e., le contenu de l'en-tête) est au contraire sensible à la casse.

Si une réponse HTTP comprend plus d'une politique compacte, les agents utilisateurs DOIVENT ignorer toutes les politiques compactes suivant la première.

4.2 Le vocabulaire des politiques compactes

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

Si un atome survient plus d'une fois dans une seule politique compacte, celle-ci a la même sémantique que si l'atome n'était survenu qu'une seule fois. Si un atome inconnu survient dans une politique compacte, celle-ci a la même sémantique que si cet atome était absent.

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

4.2.1 L'élément ACCESS compact

L'information dans l'élément <ACCESS> est représentée, dans les politiques compactes, par des atomes composés par un code de 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 contient un é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 champs de politique compacte P3P :

[54]
compact-disputes
=
"DSP" ; plusieurs DISPUTES

4.2.3 L'élément REMEDIES compact

L'information dans l'élément <REMEDIES> est représentée dans la politique compacte comme suit :

[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 l'atome "NID" (remarquer que l'atome "NID" NE DOIT PAS être utilisé à moins que l'élément <NON-IDENTIFIABLE> ne soit 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 s'expriment avec des atomes composés par un code de trois lettres, plus un attribut optionnel en une lettre. Ces attributs optionnels codent la valeur de l'attribut required dans une politique P3P complète : sa valeur peut être "a", "i" et "o", ce qui veut dire que l'attribut required dans la politique P3P correspondante doit avoir la valeur "always", "opt-in" et "opt-out" respectivement.

Si une politique P3P compacte a besoin de spécifier une ou plusieurs intentions <other-purpose> de la politique P3P complète, on utilise un seul drapeau "OTP" pour signaler à l'agent utilisateur que d'autres intentions <other-purpose> existent dans la politique P3P complète.

Les associations correspondantes entre les intentions P3P et une politique compacte ont les codes suivants :

[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"| ;"always"
"i"| ;"opt-in"
"o"  ;"opt-out"

4.2.6 L'élément RECIPIENT compact

Dans une politique P3P compacte, les destinataires s'expriment avec des atomes composés par un code de trois lettres, plus un attribut optionnel en une lettre. Ces attributs optionnels codent la valeur de l'attribut required dans une politique P3P complète : sa valeur peut être "a", "i" et "o", ce qui veut dire que l'attribut required dans la politique P3P correspondante doit avoir la valeur "always", "opt-in" et "opt-out" respectivement.

Les associations correspondantes entre les destinataires P3P et une politique compacte ont les codes suivants :

[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

L'information dans l'élément <RETENTION> est représentée dans une politique compacte comme suit :

[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/>

Remarquer que, si une politique P3P spécifie une ou plusieurs catégories <other-category/> dans sa politique P3P complète, on utilise un seul atome "OTC" pour signaler à l'agent utilisateur que <other-category/> existe 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

Quand une politique P3P compacte est inclue dans une en-tête de réponse HTTP, elle s'applique aux cookies placés par la réponse courante. Ceci comprend 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, la validité de la politique P3P compacte doit couvrir la durée de vie du cookie. Il n'existe pas de méthode pour indiquer que la politique est valide au-delà de la vie du cookie parce que la valeur de la mise en cache de l'agent utilisateur est marginale, étant donné que les sites ne sauraient pas quand optimiser en n'envoyant pas la politique compacte. Quand 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 elles s'appliquent.

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

Quand il utilise des politiques P3P compactes, le site Web est responsable de la construction d'une politique compacte en résumant la politique référencée par les éléments <COOKIE-INCLUDE> d'un fichier de référence de politique P3P. Si le fichier de référence de politique d'un site utilise des éléments <COOKIE-EXCLUDE>, alors le site aura besoin de gérer l'envoi des politiques P3P compactes à l'agent utilisateur, en fonction des cookies placés dans une réponse spécifique.

La transformation d'une politique P3P en une politique P3P compacte peut amener une perte d'information descriptive de politique - la politique compacte peut ne plus contenir toute l'information de politique spécifiée dans la politique P3P complète. Cette information de la politique complète qui est écartée lors de la construction de la politique compacte comprend la date d'expiration, les éléments du groupe/schéma de données, ainsi que les éléments <ENTITY>, <CONSEQUENCE> et <DISPUTES> qui sont réduits.

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

Tous les intentions, les destinataires et les catégories qui apparaissent dans diverses déclarations d'une politique complète DOIVENT être agrégées dans une politique compacte, comme décrit à la section 3.3.1. Lors de l'agrégation, un site Web DOIT annoncer tous les atomes concernés (par exemple, observer l'exemple 4.1 dans lequel plusieurs politiques de rétention sont spécifiées).

De surcroît, pour chaque élément de données de catégorie fixe survenant dans une déclaration, la catégorie associée, comme définie dans le schéma associé, DOIT être inclus dans la politique compacte.

Exemple 4.1 :

Considérons la politique P3P suivante :

 <POLICY name="echantillon" 
   discuri="http://www.exemple.com/politique_cookie.html"
   opturi="http://www.exemple.com/opt.html">
   <ENTITY>
     <DATA-GROUP>
       <DATA ref="#business.name">Exemple, Corp.</DATA>
       <DATA ref="#business.contact-info.online.email">confidentialite@exemple.com</DATA>
     </DATA-GROUP>
   </ENTITY>
   <ACCESS><none/></ACCESS>
   <DISPUTES-GROUP>
     <DISPUTES resolution-type="service"
      service="http://www.exemple.com/confidentialite.html"
      short-description="Pour les questions de confidentialité, merci de
                         contacter notre service clientèle en envoyant
                         un email à confidentialite@exemple.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 serait :

"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 peuvent essayer de générer une politique P3P complète à partir d'une politique compacte. Ils ne pourront pas fournir de valeurs pour les éléments <ENTITY> et <DISPUTES> tout comme pour un certain nombre d'attributs. Cependant :

Au cas où il n'y a pas plusieurs valeurs différentes de rétention compactes,
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 différentes de rétention compactes,
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.

Remarquer, en accord avec les exigences de non ambiguïté déclarées dans la section 2.4.1, qu'un site DOIT, dans tous les cas, honorer une politique compacte pour un URI donné (même si la politique complète référencée dans le fichier de référence de politique pour cet 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. P3P comprend un moyen de décrire des schémas de données, ainsi les services peuvent dialoguer avec les agents utilisateurs au sujet des données que ceux-ci collectent. Un schéma de données est construit à partir d'un certain nombre d'éléments de données, qui sont des items de données spécifiques que les services peuvent collecter.

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

Les éléments de données sont organisés selon une hiérarchie. Un élément de données inclut automatiquement tous ceux 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 basé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 enfants de l'élément de données user.name qui, à son tour, est un enfant de l'élément de données user.

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 utilisés couramment par les services.

Les services peuvent déclarer des nouveaux éléments de données en créant leurs propres schémas de données, ceux-ci étant créés en utilisant l'élément <DATASCHEMA>. Les schémas de données peuvent soit être publiés dans des fichiers XML autonomes (dont l'élément racine est alors <DATASCHEMA>), soit être incorporés dans un fichier de politique (éventuellement le même fichier de politique, avec des politiques appelant 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>"

Un schéma de données autonome a pour élément racine, dans le fichier XML, l'élément <DATASCHEMA>. Il doit avoir l'espace de nommage approprié, défini dans l'attribut xmlns, pour l'identifier comme schéma de données P3P, comme suit :

<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 (voir la section 2.4.2).

Quand un schéma de données est déclaré dans un fichier de politique, alors l'élément <DATASCHEMA> reste toujours utilisé (comme décrit dans la section 3.2.1 sur l'élément <POLICIES>).

5.1 La gestion en langage naturel des schémas de données

Les schémas de données contiennent un certain nombre de champs en langage naturel. Les services qui publient un schéma de données PEUVENT vouloir traduire ces champs dans diverses langues. Les noms longs et abrégés des éléments de données PEUVENT être traduits, mais le nom de l'élément de données NE DOIT PAS être traduit - ce champs nécessite de rester constant entre les traductions d'un schéma de données.

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, pour retenir la meilleur alternative disponible.

5.2 Les structures de données

Les schémas de données ont souvent besoin de réutiliser 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 définir celui-ci comme étant d'un type non structuré, auquel cas, il n'a pas d'élément enfant. On peut aussi le définir comme étant d'un type structuré spécifique, auquel cas l'élément de données 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 de la rencontre"
    structref="#date"/>
<DATA-DEF name="rendezvous.lieu"
    short-description="Lieu de la rencontre/>

Comme meeting.place ne référence pas de structure, il s'agit d'un type non structuré qui n'a pas d'élément enfant. 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

Une politique P3P peut maintenant déclarer qu'elle collecte l'élément de données meeting, ce qui implique la collecte de tous les sous-éléments de rendezvous, ou elle peut utiliser les éléments de données 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 type structuré réutilisables qu'on peut utiliser pour 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 pour décrire les données couvertes par cette déclaration.

Les attributs suivants sont communs à ces deux éléments :

name (attribut obligatoire)
Indique le nom de l'élément de données ou de la structure de données. Se rappeler que les noms des éléments de données et des structures de données sont sensibles à la casse, ainsi, par exemple, user.gender diffère de USER.GENDER ou de User.Gender. De plus, dans les noms des éléments et des structures de données, aucun caractère numérique ne peut survenir immédiatement après un point.
structref
Référence d'URI ([URI]), où la partie identifiant de fragment indique la structure et la partie URI indique le schéma de données correspondant où il est défini. L'URI de base par défaut est une référence 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, de 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, URI-reference est défini 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 s'effectue dans l'attribut name en utilisant un caractère point « . » comme séparateur.

P3P fournit le schéma de données P3P de base, qui intègre les définitions d'un certain nombre de structures et d'éléments de données largement répandus. Toutes les implémentations P3P sont tenues de reconnaître le schéma de données P3P de base, de cette façon les structures et les éléments qui y sont définis sont toujours disponibles pour les implémenteurs P3P.

Un schéma de données peut inclure plusieurs éléments <DATA-STRUCT> qui décrivent 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. Par contre, uri.authority, uri.stem et uri.querystring sont interprétés ensemble pour 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 :

  1. 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 comprend pas de catégorie, alors les catégories pour cette structure PEUVENT être définies quand celle-ci est utilisées dans une autre structure ou un autre élément de données. Autrement, 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 requiert que ses catégories soient listées dans la politique ;
  2. Un élément <DATA-DEF>, de type non structuré, est un élément de catégorie variable si aucune catégorie n'est définie dans celui-ci et il a exactement les catégories qui y sont listées, si des catégories sont incluses ;
  3. Un élément <DATA-DEF>, ou <DATA-STRUCT>, de type structuré, qui n'a pas de catégories définies sur cette structure, produit un élément de données, ou une structure, de catégorie variable si aucune catégorie n'est définie dans l'élément <DATA-DEF>, ou <DATA-STRUCT>. Si l'élément <DATA-DEF>, ou <DATA-STRUCT>, a des catégories listées, alors celles-ci s'appliquent à cet élément de données et tous ses sous-éléments. En d'autres termes, les catégories sont poussées vers le bas sur les sous-éléments lorsqu'on définit un élément de données comme étant d'un type structuré et que le type structuré ne définit aucune catégorie ;
  4. Un élément <DATA-DEF>, qui utilise un type structuré ayant des catégories définies sur cette structure, reprend toutes les catégories listées sur la structure. De surcroît, les catégories peuvent être listées dans l'élément <DATA-DEF>, et celles-ci sont ajoutées aux catégories définies dans la structure. Ces catégories ne sont définies qu'au niveau de cet élément de données et ne sont pas « poussées vers le bas » sur les sous-éléments ;
  5. Un élément <DATA-STRUCT>, auquel aucune catégorie n'est assignée et qui utilise un sous-type structuré ayant des catégories définies, retient toutes les catégories listées sur le sous-type ;
  6. Un élément <DATA-STRUCT>, auquel des catégories sont assignées et qui utilise un sous-type structuré, remplace toutes les catégories listées sur le sous-type ;
  7. Il existe une règle de « bouillonnement vers le haut » pour les catégories lorsqu'on référence des éléments de données : les éléments de données doivent au minimum inclure toutes les catégories définies par leurs enfants. Cette règle s'applique récursivement, ainsi, par exemple, toutes les catégories définies par les éléments foo.a.w, foo.a.y et foo.b.z DOIVENT être considérées comme s'appliquant aux éléments de données foo ;
  8. Un élément <DATA-STRUCT> ne peut être défini avec certains éléments étant de catégorie variable et d'autres de catégorie fixe. Soit tous les sous-éléments d'une structure doivent être dans la catégorie variable, soit tous doivent avoir une ou plusieurs catégories assignées ;
  9. Un élément <DATA-DEF>, avec certains éléments de catégorie variable et d'autres de catégorie fixe, NE DOIVENT PAS être référencés. Remarque : cela signifie que la structure dynamic (cf. section 5.6.4 "Les données dynamiques"), existant dans le schéma de données de base, ne peut pas être référencé dans une politique (chacun de ses sous-éléments dynamic.clickstream, dynamic.http, etc. pouvant l'être individuellement).

5.3.2 Exemple de schéma de données P3P

Considérons ce cas où la société GrandeVitesseExemple souhaite décrire les fonctionnalités d'un véhicule, en utilisant une structure appelée vehicule. Cette structure comprend :

Si GrandeVitesseExemple veut aussi inclure, dans la définition d'un véhicule, le lieu de construction, elle pourrait ajouter d'autres champs à la structure avec toutes les données concernées comme le pays, l'adresse, le code postal et ainsi de suite. Mais chaque partie de la structure peut tout aussi bien faire appel à d'autres structures : les structures peuvent être composées. Auquel cas, le schéma de données P3P de base offre déjà la structure postal, qui décrit toutes les informations postales d'une localisation. Ainsi, la définition finale de la structure vehicule est :

La structure postal comprend les champs postal.street, postal.city, etc. Étant donné que nous avons appliqué la structure postal sur vehicule.construction.lieu, elle peut accéder à la rue et la ville concernant un véhicule en utilisant, respectivement, les descriptions vehicule.construction.lieu.street et vehicule.construction.lieu.city. De cette manière, en appliquant une structure (dans ce cas, postal), on peut construire des descriptions très complexes de façon modulaire.

GrandeVitesseExemple veut déclarer que toutes les informations concernant le véhicule seront dans la catégorie <preference/>. Les champs vehicule.modele, vehicule.couleur, vehicule.prix et vehicule.construction.annee sont tous de type non structuré, c'est pourquoi, en leur assignant la catégorie <preference/>, cela est effectué pour tous les champs. Comme vehicule est une définition de structure, assigner la catégorie <preference/> à vehicule.construction.lieu va surclasser (remplacer) les catégories définies sur tous les sous-éléments de vehicule.construction.lieu, en les plaçant tous dans la catégorie <preference/>, bien que la structure postal soit définie à l'origine comme étant dans d'autres catégories.

Comme déjà dit, les structures ne contiennent pas d'élément de données ; ce sont justes 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 l'exemple, GrandeVitesseExemple a besoin de cette description abstraite des fonctionnalités d'un véhicule parce qu'elle veut en fait échanger des données sur des voitures et des motocyclettes. Pour cela, elle pourrait définir deux éléments de données, appelés auto et moto, les deux avec la structure vehicule ci-dessus.

Cette description des éléments et structures de données est transcrite en XML en utilisant un schéma de données. Dans le cas de GrandeVitesseExemple case, ce serait quelque chose comme :

<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>

Continuant avec l'exemple, pour référencer un modèle d'auto et l'année de construction, GrandeVitesseExemple ou n'importe quel autre service pourrait envoyer la référence suivante dans une politique P3P :

<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.exemple.com/modeles-schema
    -->
<DATA ref="http://www.GrandeVitesse.exemple.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.exemple.com/modeles-schema
    -->
<DATA ref="http://www.GrandeVitesse.exemple.com/modeles-schema#auto.construction.annee"/>
</DATA-GROUP>

En utilisant l'attribut base, on peut écrire les références ci-dessus d'une manière encore plus compacte :

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

Autrement, on pourrait incorporer le schéma de données directement dans un fichier de politique. Auquel cas, le fichier de politique ressemblerait à ceci :

<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.exemple.com/disc1">
...
<DATA-GROUP base="">
<DATA ref="#auto.modele"/>
<DATA ref="#auto.construction.annee"/>
</DATA-GROUP>
...
</POLICY>
<POLICY name="politique2" discuri="http://www.exemple.com/disc2"> .... </POLICY>
<POLICY name="politique3" discuri="http://www.exemple.com/disc3"> .... </POLICY>
</POLICIES>

Remarquer que, 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

Remarquer que les noms des éléments de données, spécifiés dans le schéma de données de base ou dans les schémas de données des extension, peuvent &ecir;tre employés pour des buts autres que les politiques P3P. Par exemple, les sites Web peuvent utiliser ceux-ci pour libeller des champs de formulaire HTML. En se référant aux données de la même manière dans les politiques P3P et les formulaires, les outils de remplissage de formulaire automatisés peuvent mieux s'intégrer aux agents utilisateurs P3P.

5.4 La persistance des schémas de données

Une exigence essentielle des schémas de données est la persistance : les schémas de données, qui peuvent être ramenés d'un certain URI, ne peuvent être changés qu'en étendant le schéma de données selon une compatibilité ascendante (c'est-à-dire, le changement du schéma de données ne modifie pas le sens d'une politique qui utilise ce schéma). Ainsi, l'URI d'une politique agit, d'une certaine façon, comme un identifiant unique pour les éléments et structures de données qui y sont contenus : tout schéma de données qui n'est pas compatible en arrière doit de ce fait utiliser un nouvel URI différent.

Remarquer qu'une application utile de la persistance du schéma de données est donnée, par exemple, pour le cas d'un site multilingue : le serveur peut offrir des versions en plusieurs langues (traductions) du même schéma de données, en utilisant le champs d'en-tête HTTP Content-Language pour indiquer correctement qu'une langue particulière est 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 basique, elles devraient éventuellement être réutilisées autant que possible par les autres schémas de données différents). Toutes les implémentations d'agent utilisateur conformes P3P DOIVENT reconnaître les structures de données de base. Chacun des tableaux ci-dessous spécifie 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 plus d'une catégorie à un élément de données fixe. Cependant, chaque élément de données de base est assigné à une seule catégorie chaque fois que c'est possible. On recommande aux concepteurs de schéma de données de faire la même chose.

5.5.1 Les dates

La structure date spécifie une date. Étant donné que les informations de date peuvent s'employer de plusieurs façons, selon le contexte, toutes les informations date sont marquées comme étant de catégorie « variable » (voir la section 5.7.2). Par exemple, les définitions de schéma peuvent indiquer explicitement la catégorie correspondante dans l'élément appelant cette structure, demander l'anniversaire d'un utilisateur pouvant relever de la catégorie « Données démographiques et socio-économiques », alors qu'une date d'expiration de carte de crédit 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

L'information de « fuseau horaire » est décrite par exemple dans le temps standard [ISO8601]. Remarquer qu'on peut utiliser date.ymd et date.hms pour l'appel rapide, respectivement, des blocs année/mois/jour et heure/minute/seconde.

5.5.2 Les noms

La structure personname spécifie 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 Informations de contact physique non structuré Prénom
family Informations de contact physique non structuré Nom de famille
middle Informations de contact physique 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 spécifie les informations (identifiant et mot de passe) pour les systèmes informatiques et les sites Web qui exigent une authentification. Remarquer que cet élément de données ne devraient pas être utilisé pour les systèmes ou les sites Web qui utilisent des certificats d'authentification numériques : pour ces cas, il faudrait utiliser la structure certificate.

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

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

Le champs "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 sont de manière générale considérés comme une information sensible.

5.5.4 Les certificats

La structure certificate est utilisée pour spécifier des certificats d'identité (comme par exemple X.509).

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

Le champs "format" s'utilise pour représenter l'informations d'une clé publique ou d'un certificat d'authentification enregistrés auprès de l'IANA, alors que le champs "key" est utilisé pour représenter la clé de certificat correspondante.

5.5.5 Les numéros de téléphone

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

telephonenum Catégorie Structure Nom abrégé
intcode Informations de contact physique non structuré Code téléphonique international
loccode Informations de contact physique non structuré Code téléphonique de zone locale
number Informations de contact physique non structuré Numéro de téléphone
ext Informations de contact physique non structuré Extension téléphonique
comment Informations de contact physique non structuré Commentaires téléphoniques optionnels

5.5.6 Les informations de contact

La structure contact est utilisée pour spécifier des informations de contact. Les services peuvent spécifier précisément quel jeu de données leur est nécessaire, entre les informations postales, de télécommunication ou d'adresse en ligne.

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

5.5.6.1 Informations postale

La structure postal spécifie une adresse de courrier postal.

postal Catégorie Structure Nom abrégé
name Informations de contact physique, Données démographiques et socio-économiques personname Nom
street Informations de contact physique 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é Organisme

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

5.5.6.2 Télécommunications

La structure telecom spécifie les informations de télécommunication concernant une personne.

telecom Catégorie Structure Nom abrégé
telephone Informations de contact physique telephonenum Numéro de téléphone
fax Informations de contact physique telephonenum Numéro de fax
mobile Informations de contact physique telephonenum Numéro de mobile
pager Informations de contact physique telephonenum Numéro de téléavertisseur

5.5.6.3 Informations en ligne

La structure online spécifie les informations en ligne concernant une personne ou une entité légale.

online Catégorie Structure Nom abrégé
email Informations de contact en ligne non structuré Adresse email
uri Informations de contact en ligne non structuré Adresse de page d'accueil

5.5.7 Les journaux des accès et les adresses Internet

Deux structures fournies sont utilisées pour représenter les formes d'adresse Internet. La structure uri couvre les identifiants de ressource universels (URI, définis dans [URI]. La structure ipaddr représente les adresses IP et les noms d'hôte du système de nom de domaine (DNS).

5.5.7.1 URI

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

L'autorité d'un URI se définit comme le composant authority dans [URI]. Le radical d'un URI se définit comme l'information contenue dans la partie de l'URI aprè l'autorité et jusqu'au premier caractère « ? » compris, la chaîne de requête est l'information contenue dans la portion de l'URI aprè le premier caractère « ? ». Pour les URI qui ne contiennent pas de caractère « ?, le radical est l'URI entier et la chaîne de requête est vide.

Comme les informations d'URI peuvent s'utiliser de différentes manières, selon le contexte, tous les champs dans la structure uri sont marqués comme étant de catégorie « variable ». Les définitions de schéma DOIVENT explicitement mettre la catégorie correspondante dans l'élément appelant cette structure de données.

5.5.7.2 ipaddr

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 champs hostname est utilisé pour représenter une collection soit du simple nom d'hôte d'un système, soit le nom d'h&ocir;cte complet comprenant le nom de domaine. Le champs partialhostname représente l'information d'un nom d'hôte entièrement qualifié, dont au moins la partie hôte est retirée du nom d'hôte. En d'autres termes, tout ce qui va jusqu'au premier caractère « . », dans le nom d'hôte entièrement qualifié, DOIT être retiré pour qu'une adresse soit qualifiée de « nom d'hôte partiel ».

Le champs fullip représent l'information d'une adresse IP version 4, ou IP version 6, entière. Le champs partialip représente une adresse IP version 4 (exclusivement, non une adresse de version 6), dont au moins les sept derniers bits d'information ont été retirés. Ce retrait DOIT avoir lieu en remplaçant ces bits par un motif fixe pour tous les visiteurs (par exemple, que des 0 ou que des 1).

Certains sites Web sont connus pour ne pas utiliser l'adresse IP ou le nom d'hôte entiers du visiteur, seulement d'une forme réduite. En ne collectant qu'un sous-ensemble des informations d'adresse, le visiteur du site bénéficie d'un certain anonymat. Cette spécification ne prétend certainement pas que ces adresses IP ou noms d'hôte « dépouillés » sont impossibles à associer à un utilisateur individuel, mais plutôt qu'il est significativement plus difficile de le faire. Les sites qui effectuent cette réduction des données PEUVENT déclarer cette pratique pour refléter plus précisément leurs pratiques.

5.5.7.3 Les informations du journal d'accès

La structure loginfo est utilisée pour représenter les informations stockées typiquement dans le journal des accès au serveur Web.

loginfo Catégorie Structure Nom abrégé
uri Données de navigation et de parcours uri URI de la ressource requise
timestamp Données de navigation et de parcours date Estampille de 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é Octets de données en réponse
other.statuscode Données de navigation et de parcours non structuré Code de statut de la réponse

Dans la requête HTTP, la ressource est capturée par le champs uri. Le moment auquel le serveur traite la requête est représenté par le champs timestamp. Les implémentations de serveur sont libres de définir ce champs comme l'instant de réception de la requête, l'instant où le serveur a entamé l'envoi de la réponse, l'instant où l'envoi de la réponse est terminé ou toute représentation commode de l'instant où la requête a été traitée. L'adresse IP du système client ayant fait la requête est donnée par le champs clientip.

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

5.5.7.4 Les autres informations du protocole HTTP

La structure httpinfo représente l'information véhiculée par le protocole HTTP qui n'est pas couverte par la structure loginfo.

httpinfo Catégorie Structure Nom abrégé
referer Navigation and click-stream data uri Dernier URI requis par l'utilisateur
useragent Informations de système non structuré Agent utilisateur

Le champs useragent représente l'information contenue dans l'en-tête HTTP User-Agent (qui renseigne sur le type et la version du navigateur Web de l'utilisateur) et/ou les en-têtes HTTP accept*.

Le champs referer représente l'information contenue dans l'en-tête HTTP Referer, qui renseigne sur la page précédente visitée par l'utilisateur. Remarquer que l'intitulé de ce champs comporte une erreur orthographique comme pour l'en-tête HTTP correspondante.

5.6 Le schéma de données de base

Toutes les implémentations 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 qui sont automatiquement générés au cours de la session de navigation d'un utilisateur. Les agents utilisateurs peuvent gérer divers mécanismes qui permettent aux utilisateurs de fournir des valeurs aux éléments du jeu user et de stocker celles-ci dans un dépôt de données, dont les mécanismes gérant plusieurs utilisateurs. Les utilisateurs peuvent choisir de ne pas fournir de valeurs pour ces éléments de données.

La définition XML formelle du schéma de données P3P de base est donnée dans l'appendice 3. Dans les sections suivantes, les éléments et jeux de données de base sont expliqués individuellement. À l'avenir, il y aura vraisemblablement une demande pour la création d'autres jeux et éléments de données. Les applications évidentes 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 ci-dessous spécifie un jeu, les éléments de ce jeu, la catégorie associée à l'élément, la structure de celui-ci et le nom abrégé affiché à l'utilisateur. On peut associer plus d'une catégorie à un élément de données fixe. Néanmoins, si c'est possible, chaque élément de données de base est associé à une seule catégorie. On recommande aux concepteurs de schéma de données de faire de même.

5.6.1 Les données de l'utilisateur

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

user Catégorie Structure Nom abrégé
name Informations de contact physique, 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 Identifiants uniques login Information de connexion de l'utilisateur
cert Identifiants uniques certificate Certificat d'identité de l'utilisateur
gender Données démographiques et socio-économiques non structuré Genre (mâle ou femelle)
employer Données démographiques et socio-économiques non structuré Employeur de l'utilisateur
department Données démographiques et socio-économiques non structuré Département ou service de l'organisme qui emploie l'utilisateur
jobtitle Données démographiques et socio-économiques non structuré Désignation de l'emploi de l'utilisateur
home-info Informations de contact physique, Informations de contact en ligne, Données démographiques et socio-économiques contact Contact de l'utilisateur au domicile
business-info Informations de contact physique, Informations de contact en ligne, Données démographiques et socio-économiques contact Contact de l'utilisateur au bureau

Remarquer que ce jeu de données comprend des éléments qui, en fait, sont 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. Le nom abrégé, pour un élément individuel contenu dans un jeu de données, est défini comme étant la concaténation du nom abrégé qui a été défini pour le jeu et l'élément, avec le délimiteur approprié pour la langue ou l'écriture en question, comme la virgule pour le français. Par exemple, le nom abrégé pour user.home-info.postal.postalcode pourrait être « Utilisateur, Contact au domicile, Adresse postale, Code postal ». Les implémentations d'agent utilisateur peuvent développer leurs propres noms abrégés plutôt que d'utiliser les noms concaténés quand l'information s'affiche pour l'utilisateur.

5.6.2 Les données d'une tierce partie

Le jeu de données thirdparty permet aux utilisateurs et aux entreprises de fournir des valeurs pour une tierce partie concernée. Ceci peut se révéler utile quand on a besoin d'échanger les informations d'une tierce partie, par exemple, quand on commande un cadeau en ligne qui doit être envoyé à une autre personne ou lors de la fourniture de renseignements concernant un(e) époux(se) ou un(e) associé(e). Ces renseignements pourraient être stockés dans le compte de l'utilisateur en marge du jeu de données user. Les agents utilisateurs peuvent offrir de stocker plusieurs jeux de données thirdparty de ce genre et autoriser les utilisateurs à sélectionner, au besoin, les valeurs appropriées à partir d'une liste.

Le jeu de données thirdparty est identique au jeu de données user. Voir la section 5.6.1 Les données de l'utilisateur pour le détail.

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 pour la description des entités légales. Dans P3P1.0, ce jeu de données est principalement employé pour déclarer l'entité présentant la politique, bien que cela devrait aussi s'appliquer aux interactions d'entreprise-à-entreprise.

business Catégorie Structure Nom abrégé
name Données démographiques et socio-économiques non structuré Nom de l'organisme
department Données démographiques et socio-économiques non structuré Département ou service de l'organisme
cert Identifiants uniques certificate Certificat d'identité de l'organisme
contact-info Informations de contact physique, Informations de contact en ligne, Données démographiques et socio-économiques contact Information pour contacter l'organisme

5.6.4 Les données dynamiques

Dans certains cas, il est nécessaire de spécifier des éléments de données, n'ayant pas de valeurs fixes, qu'un utilisateur pourrait entrer ou stocker dans un compte. Dans le schéma de données P3P de base, tous les éléments de ce genre 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, plutôt que 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 Information de parcours
http Données de navigation et de parcours, Informations de système httpinfo Information 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 la transaction stocké par le serveur

Ces éléments sont souvent implicites dans la navigation ou les interactions Web. Ils devraient être employés avec des catégories pour décrire le type d'information collecté par ces méthodes. Voici une brève description de chacun d'eux :

clickstream
L'élément clickstream est sensé s'appliquer sur pratiquement 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'URI de la ressource demandée, le moment où la requête est faite, la méthode HTTP employée pour la requête, la taille de la réponse et le code de statut de celle-ci. Les sites Web qui collectent les journaux d'accès standards des serveurs, comme les sites qui font l'analyse des chemins d'accès aux URI, peuvent employer cet élément de données pour décrire comment les données sont utilisées. Les sites Web, qui ne collectent que certains des éléments de données listés pour l'élément clickstream, PEUVENT choisir de lister ces éléments spécifiques plutôt que l'élément dynamic.clickstream en entier. Ceci permet aux sites, ayant des pratiques de collecte des données plus limitées, de présenter précisément ces pratiques à leurs visiteurs.
http
L'élément http contient des informations supplémentaires issues du protocole HTTP. Voir la définition de la structure httpinfo pour les descriptions 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, s'ils le souhaitent, ou ils PEUVENT référencer les éléments spécifiques de la structure httpinfo.
clientevents
L'élément clientevents représente des données ayant trait aux interactions des utilisateurs avec leur navigateur Web lors d'une interaction avec une ressource. Par exemple, une application souhaite collecter des informations telles que : l'utilisateur a-t-il déplacé le pointeur sur une image d'une page donnée, ou a-t-il fait apparaître la fenêtre d'aide dans un applet Java. Ce genre d'information est représenté par l'élément de données dynamic.clientevents. Une grande partie de cet enregistrement d'interaction est représentée par les événements et les données, définis par le modèle objet du document (DOM) niveau 2 - Événements [DOM2-Events]. L'élément clientevents couvre également toutes les autres données concernant l'interaction de l'utilisateur avec son navigateur, pendant que celui-ci affiche une ressource. À l'exception des événements qui sont couverts par les autres éléments du schéma de données de base. Par exemple, la requête d'une page en cliquant sur un lien fait partie des interactions de l'utilisateur avec son navigateur dans la consultation d'une page, mais la simple collecte de l'URL vers lequel l'utilisateur a cliqué ne nécessite pas de déclarer cet élément de données ; c'est clickstream qui couvre cet événement. Cependant, l'événement DOM DOMFocusIn (qui représente l'utilisateur déplaçant le pointeur sur un objet sur une page) n'est couvert par aucun élément existant, c'est pourquoi, si un site collecte la survenue de cet événement, alors il doit déclarer qu'il collecte l'élément dynamic.clientevents. Les items couverts par cet élément de données sont typiquement collectés par des langages de script côté client, tel que JavaScript, ou par des applets côté client, tels que des applets ActiveX ou Java. Remarquer, bien que la discussion précédente ait eu lieu du point de vue d'un utilisateur voyant une ressource, que cet élément de données s'applique également aux applications Web qui n'affichent pas les ressources visuellement - par exemple, les navigateurs Web auditifs.
cookies
L'élément cookies devrait être utilisé toutes les fois où des cookies HTTP sont placés ou ramenés par un site. Remarquer que cookies étant un élément de données variable, il requiert la déclaration explicite de catégories d'usage dans une politique.
miscdata
L'élément miscdata référence les informations collectées par un service, celui-ci ne les référençant pas en utilisant un élément de données spécifique. On doit employer des catégories pour décrire au mieux ces données : les sites DOIVENT référencer, dans leurs politiques, un élément miscdata pour chaque catégorie de données diverses qu'ils collectent.
searchtext
L'élément searchtext référence un type spécifique de sollicitation, utilisé pour la recherche et l'indexation des sites. Par exemple, si les seuls champs de la page d'un moteur de recherche sont des champs de recherche, le site n'a besoin que d'annoncer cet élément de données.
interactionrecord
L'élément interactionrecord devrait s'utiliser quand le serveur garde la trace des interactions avec un utilisateurs (i.e., des informations autres que des données de parcours, par exemple, les transactions sur un compte, etc.).

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

5.7.1 Les éléments ou 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 au plus deux classes de catégorie. En assignant une catégorie invariablement aux éléments ou structures du schéma de donnés de base, les services et les utilisateurs ont la possibilité de se référer à des groupes d'éléments entiers, simplement en référençant la catégorie correspondante. Par exemple, en utilisant [APPEL], le langage d'échange de préférences de confidentialité, les utilisateurs peuvent écrire des règles qui les avertissent lors de la visite d'un site qui collecte 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="Nome 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 qui référencent les catégories appropriées. Par exemple, le fragment XML suivant peut être utilisé pour 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> 

Remarquer que les classes de catégorie des éléments/structures de données fixes ne peuvent pas être surclassées, par exemple en écrivant des règles ou des politiques qui assignent une catégorie différente à un élément de données de base fixe connu. Les agents utilisateurs DOIVENT ignorer de telles catégories et, à la place, utiliser celle d'origine (ou le jeu de catégories d'origine) listée dans la définition du schéma. Les agents utilisateurs PEUVENT, de préférence, avertir l'utilisateur qu'un élément de données fixe est utilisé conjointement avec une classe de catégorie non standard.

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

Les éléments ou structures de données dans le schéma de données de base n'appartiennent pas tous à une classe de catégorie pré-déterminée. Certains peuvent contenir des informations provenant d'un éventail de catégories, en fonction d'une situation donnée. De tels éléments ou structures de données sont appelés éléments ou structures de données de catégorie variable (ou, en bref, « éléments ou 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 soient combinés dans le jeu d'éléments dynamic, ils peuvent apparaître dans n'importe quel jeu de données, 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 de tels éléments et/ou structures, les auteurs NE DOIVENT PAS lister d'attribut de catégorie explicite, autrement l'élément/structure devient fixe. Par exemple, quand on spécifie la structure de données « year », pouvant entrer dans diverses catégories selon le contexte (par exemple, une date d'expiration de carte de crédit comparée à 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 --> 

Ceci permet aux nouvelles extensions de schéma, qui référence de telles 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 de commerce en ligne pourrait de cette manière définir la date d'expiration d'une carte de crédit, comme suit :

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

Dans ces conditions, la structure de données variable date se voit assigner la catégorie fixe « Informations d'achat », quand elle est utilisée pour spécifier une date d'expiration de carte de crédit.

Remarquer, alors que les préférences de l'utilisateur peuvent lister de tels éléments de données variables sans information de catégorie supplémentaire (exprimant effectivement des préférences sur toute utilisation de cet élément), que les services DOIVENT toujours spécifier 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 apparaître comme élément <CATEGORIES> dans l'élément <DATA> listé dans la politique, par exemple, comme dans :

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

Ici, un service déclare que les cookies sont utilisés pour reconnaître un utilisateur sur le site (i.e., catégorie Identifiants uniques).

Si un service veut déclarer un élément de données qui se range dans plusieurs catégories, il déclare simplement les catégories correspondantes (comme illustré dans la section ci-dessus) :

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

Avec la déclaration ci-dessus, un service annonce l'utilisation de cookies pour reconnaître l'utilisateur sur le site et pour stoker les données des préférences de l'utilisateur. Remarquer que, pour P3P, il n'y a pas de différence entre le fait que ces informations soient stockées sur deux cookies distincts ou sur un seul.

Enfin, remarquer que les catégories peuvent aussi s'hériter : les catégories héritent en descendant quand un champs est structuré, mais seulement dans les champs qui n'ont pas de catégories pré-définies. C'est pourquoi, on suggère aux auteurs de schéma de faire de leur mieux pour s'assurer que toutes les catégories concernées s'appliquent aux nouveaux éléments de données qu'ils créent.

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

P3P offre une grande souplesse aux sites Web sur la façon de décrire les types de données qu'ils collectent.

N'importe laquelle de ces trois méthodes peut être combinée dans une seule politique.

En utilisant l'élément dynamic.miscdata, les sites peuvent spécifier les types de données qu'ils collectent, sans avoir à énumérer chaque élément de données individuel. Ceci peut être commode pour les sites qui collectent beaucoup de données ou pour ceux appartenant à de grands organismes qui veulent offrir une seule politique P3P couvrant l'organisme entier. Cependant, le désavantage de cette approche, c'est que les agents utilisateurs devront supposer que le site pourrait 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 que celui-ci collecte dynamic.miscdata de la catégorie « Informations de contact physique », mais que la seule information de contact physique que le site collecte est l'adresse de bureau, les agents utilisateurs vont néanmoins supposer que le site pourrait aussi collecter les numéros de téléphone. Si le site souhaite clarifier qu'il ne collecte pas les numéros de téléphone ou une quelconque information de contact physique autre que l'adresse de bureau, alors il devrait annoncer qu'il collecte user.business-info.contact.postal. De plus, comme les agents utilisateurs sont développés avec des fonctionnalités de remplissage de formulaire automatique, il est vraisemblable que les sites, qui énumèrent les données qu'ils collectent, seront capable de mieux s'intégrer avec ces outils.

En définissant des nouveaux schémas de données, les sites peuvent spécifier précisément les données qu'ils collectent au-delà du jeu de données de base. Cependant, si les agents utilisateurs ne sont pas familiers avec les éléments définis dans ces schémas, ils ne pourront offrir à l'utilisateur qu'une information minimale sur ces nouveaux éléments. L'information fournie sera basée sur la catégorie et les noms abrégés spécifiés pour chaque élément.

Sans se soucier qu'un site souhaite faire des divulgations de données générales ou spécifiques, il y a des avantages supplémentaires à divulguer des éléments spécifiques à partir du jeu de données dynamic. Par exemple, en annonçant dynamic.cookies, un site peut indiquer qu'il utilise des cookies et exposer le but de cet usage. Les implémentations d'agent utilisateur, qui offrent des interfaces de contrôle des cookies en fonction de cette information, sont encouragées. De la même façon, les agents utilisateurs qui, par défaut, n'envoient pas l'en-tête HTTP Referer, pourraient chercher l'élément dynamic.http.referer dans les politiques P3P et envoyer l'en-tête, si celle-ci était utilisée pour une intention que l'utilisateur trouve acceptable.


6. Appendices

Appendice 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. (Eds.), « Le 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, and I. Jacobs (Eds.). « 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, and 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. (Eds.). « 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 (Eds.). « 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 (Eds.). « 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, and N. Mendelsohn (Eds.). « 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 Part 2: Datatypes » World Wide Web Consortium Recommendation. 2 mai 2001.
Disponible à http://www.w3.org/TR/xmlschema-2/.

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

[APPEL]
M. Langheinrich (Ed.). « 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 (Eds.), "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 (Eds.). « 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.

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

Pour faciliter la consultation, le schéma de données correspondant au schéma de données P3P de base est présenté à la suite. Le schéma est également disponible en fichier séparé à l'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="Code téléphonique international">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.loccode"
    short-description="Code téléphonique de zone locale">
    <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="Extension téléphonique">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.comment"
    short-description="Commentaires téléphoniques optionnels">
    <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'organisme">
    <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 fax"
    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 email">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="online.uri"
    short-description="Adresse de la 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="Informations de télécommunication"
    structref="#telecom">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="contact.online"
    short-description="Informations d'adresse en ligne"
    structref="#online">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

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

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

<DATA-STRUCT name="uri.querystring"
    short-description="Partie chaîne de requête 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="URI de la ressource requise"
    structref="#uri">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.timestamp"
    short-description="Estampille de 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="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="Dernier URI requis par l'utilisateur"
    structref="#uri">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="httpinfo.useragent"
    short-description="Information 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="Information 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 la transaction 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="Information 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="Désignation de l'emploi de l'utilisateur">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

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

<DATA-DEF name="user.business-info"
    short-description="Information de contact au bureau de l'utilisateur"
    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="Départment ou service de l'organisme où l'utilisateur est employé">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

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

<DATA-DEF name="thirdparty.bdate"
    short-description="Date d'anniversaire de la tierce partie"
    structref="#date">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.login"
    short-description="Information de connexion de la tierce partie"
    structref="#login">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

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

<DATA-DEF name="thirdparty.gender"
    short-description="Genre de la tierce partie">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.jobtitle"
    short-description="Profession de la tierce partie">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.home-info"
    short-description="Information de contact au domicile de la tierce partie"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.business-info"
    short-description="Information de contact au bureau de la tierce partie"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

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

<DATA-DEF name="thirdparty.department"
    short-description="Départment ou service de l'organisme où la tierce partie est employée">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

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

<DATA-DEF name="business.department"
    short-description="Départment ou service de l'organisme">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

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

<DATA-DEF name="business.contact-info"
    short-description="Information de contact pour l'organisme"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

</DATASCHEMA>

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

Cette appendice contient le schéma XML pour les fichiers de référence de politique P3P, pour les documents de politique P3P et pour les documents de schéma de données P3P. Les fichiers de référence 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>


<!-- *********** Référence 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>

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

Cet appendice contient le DTD pour les fichiers de référence de politique P3P, pour les documents de politiques P3P et pour les documents de schéma de données P3P. Ce DTD PEUT être utilisé pour 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 en fichier séparé à l'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" >

Appendice 6 : La notation ABNF (normatif)

La grammaire formelle de P3P est donnée dans cette spécification en utilisant une version légèrement modifiée de [ABNF]. Ce qui suit est une simple description de ABNF.

nom = (é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 fournis ci-dessous. 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, leur contenu étant 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> ou plus éléments.
(4*<élément> signifie quatre ou plus éléments).
*<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.

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

Cette appendice décrit les raisons du développement P3P et recommande des directives pour l'utilisation responsable de la technologie P3P. Une version antérieure 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é élaboré pour être souple et pour gérer un jeu varié de préférences de l'utilisateur, de politiques publiques, de politiques de fournisseur de services et d'applications. Cette souplesse sera l'occasion d'utiliser P3P dans une grande diversité d'applications innovantes que les concepteurs n'avaient même pas imaginé. Les principes directeurs de P3P ont été élaborés pour exprimer les intentions des membres du groupe de travail P3P lors de la conception de cette technologie et suggérer comment utiliser P3P le plus efficacement pour maximiser la confidentialité ainsi que l'assurance et la confiance de l'utilisateur sur le Web. Pour garder notre objectif de souplesse, ce document ne place aucune exigence sur une quelconque partie. Plutôt, il émet des recommandations concernant 1) ce qui devrait être fait pour rester cohérent avec les objectifs des concepteurs de P3P et 2) sur la manière de maximiser la confiance de l'utilisateur dans les implémentations P3P et les services Web. P3P est destiné à favoriser la protection de la vie privée sur le Web. Nous encourageons les organismes, les individus, les concepteurs de politique et les sociétés qui utilisent P3P à suivre les principes directeurs pour atteindre cet objectif.

Confidentialité de l'information

P3P est conçu pour promouvoir la confidentialité et la confiance sur le Web, en permettant aux fournisseurs de services d'annoncer leurs pratiques vis-à-vis des informations et en permettant aux individus de prendre des décisions en connaissance de cause concernant la collecte et l'utilisation de leurs informations personnelles. Les agents utilisateurs P3P agissent pour le compte d'individus, pour qu'ils s'accordent avec les fournisseurs de services sur la collecte et l'utilisation des informations personnelles. La confiance naît de la compréhension mutuelle que chacune des parties respectera l'accord établi.

Les fournisseurs de services devraient préserver la confiance et protéger la vie privée en appliquant les lois et les principes de protection des données et de confidentialité concernés à leurs pratiques vis-à-vis des informations. Ce qui suit est une liste des principes et des directives de confidentialité qui ont présidés au développement de P3P et qui peuvent être utiles à ceux qui utilisent P3P :

De surcroît, les fournisseurs de services et les implémenteurs P3P devraient reconnaître et aborder les aspects particuliers entourant la vie privée des enfants.

Notification et communication

Les fournisseurs de services devraient effectuer des notifications effectives, en temps et en heure, de leurs pratiques vis-à-vis des informations et les agents utilisateurs devraient offrir des outils effectifs aux utilisateurs pour qu'ils puissent accéder à ces notifications et pour qu'ils puissent prendre des décisions en fonction de celles-ci.

Les fournisseurs de services devraient :

Les agents utilisateurs devraient :

Choix et contrôle

Les utilisateurs devraient avoir la possibilité de faire des choix significatifs concernant la collecte, l'utilisation et la divulgation d'informations personnelles. Les utilisateurs devraient garder le contrôle de leurs informations personnelles et décider des conditions selon lesquelles ils les partageront.

Les fournisseurs de services devraient :

Les agents utilisateurs devraient :

Loyauté et intégrité

Les fournisseurs de services devraient traiter les utilisateurs et leurs informations personnelles avec loyauté et intégrité. Ceci est essentiel pour la protection de la vie privée et la promotion de la confiance.

Les fournisseurs de services devraient :

Les agents utilisateurs devraient :

Sécurité

Bien que P3P ne comprenne pas de mécanismes de sécurité, il est destiné à être employé conjointement 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 rapport avec leur sensibilité.

Les fournisseurs de services devraient :

Les agents utilisateurs devraient :

Appendice 8 : Les contributeurs au Groupe de Travail (non normatif)

Cette spécification a été produite par le Groupe de Travail de la spécification P3P. Les personnes suivantes ont participé au groupe de travail de la spécification P3P, présidé par Lorrie Cranor (AT&T) : 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 de la spécification P3P a hérité une grande part de la spécification des précédents groupes de travail P3P. Le groupe de travail voudrait remercier les membres de ces groupes précédents pour leurs contributions (les affiliations indiquées sont celles des membres au moment de leur participation dans chaque groupe de travail).

Le Groupe de Travail pour l'implémentation 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, formerly of 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'appendice 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.).