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

Recommandation du W3C du 16 avril 2002

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

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

Voir aussi d'éventuelles traductions.

Résumé

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

Statut de ce document

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

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

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

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

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

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

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

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

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

Table des matières

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

1. Introduction

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

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

1.1 La spécification P3P1.0

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

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

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

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

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

1.1.2 Exemple d'utilisation de P3P

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

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

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

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

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

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

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

1.1.3 Les politiques P3P

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

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

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

1.1.4 Les agents utilisateurs P3P

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

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

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

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

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

1.1.6 Les futures versions de P3P

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

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

1.2 À propos de cette spécification

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

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

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

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

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

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

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

1.3 La terminologie

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

2. L'appel des politiques

2.1 Vue d'ensemble et utilisation des appels de politique

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

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

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

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

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

2.2 La localisation des fichiers d'appel de politique

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

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

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

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

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

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

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

2.2.1 L'emplacement notoire

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

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

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

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

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

2.2.2 Les en-têtes HTTP

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

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

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

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

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

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

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

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

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

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

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

Exemple 2.1 :

1. Le client effectue une requête GET :

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

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

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

2.2.3 La balise HTML `link`

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

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

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

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

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

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

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

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

2.2.4 La balise XHTML `link`

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

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

2.2.5 Les ports HTTP et les autres protocoles

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

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

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

errata E1

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

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

2.3.1 Exemple de fichier d'appel de politique

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

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

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

Exemple 2.2 :

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

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

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

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

 </POLICY-REFERENCES>
</META>

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

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

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

2.3.2.1 Le traitement du fichier d'appel de politique

2.3.2.1.1 L'importance de l'ordre

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2.3.1 La motivation et le mécanisme

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

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

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

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

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

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

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

errata E2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2.6 L'élément `HINT`

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

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

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

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

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

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

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

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

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

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

Exemple 2.3 :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exemple 2.4 :

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

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

Exemple 2.5 :

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

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

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

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

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

2.3.2.8 L'élément `METHOD`

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

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

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

Exemple 2.6 :

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

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

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

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

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

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

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

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

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

Quelques exemples caractéristiques :

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

2.3.4 Les formulaires et les mécanismes apparentés

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

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

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

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

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

2.4 Les autres conditions requises

2.4.1 La non-ambiguïté

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

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

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

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

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

2.4.2 Les diverses langues

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

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

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

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

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

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

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

2.4.3 La zone sûre

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

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

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

Les pratiques de zone sûre pour le