�Lisez-moi S.V.P.�
W3C

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

Recommandation du W3C du 16 avril 2002

Cette version�:
http://www.w3.org/TR/2002/REC-P3P-20020416/
Derni�re version�:
http://www.w3.org/TR/P3P/
Version pr�c�dente�:
http://www.w3.org/TR/2002/PR-P3P-20020128/
�diteurs�:
Massimo Marchiori, W3C / MIT / University of Venice, ([email protected])
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.

Copyright ©2002 W3C™ (MIT, INRIA, Keio), Tous droits r�serv�s. Les r�gles de responsabilit�, de nom de marque, d'utilisation du document et d'octroi de licence logicielle du W3C s'appliquent.

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 [email protected] (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

  1. Introduction
    1. La sp�cification P3P1.0
      1. Les buts et les possibilit�s de P3P1.0
      2. Exemple d'utilisation de P3P
      3. Les politiques P3P
      4. Les agents utilisateurs P3P
      5. La mise en œuvre de P3P1.0 sur les serveurs
      6. Les futures versions de P3P
    2. � propos de cette sp�cification
    3. La terminologie
  2. L'appel des politiques
    1. Vue d'ensemble et utilisation des appels de politique
    2. La localisation des fichiers d'appel de politique
      1. L'emplacement notoire
      2. Les en-t�tes HTTP
      3. La balise HTML link
      4. La balise XHTML link
      5. Les ports HTTP et les autres protocoles
    3. La syntaxe et la s�mantique du fichier d'appel de politique
      1. Exemple de fichier d'appel de politique
      2. La d�finition du fichier d'appel de politique
        1. La traitement du fichier d'appel de politique
          1. L'importance de l'ordre
          2. Les caract�res jokers dans les fichiers d'appel de politique
        2. Les �l�ments META et POLICY-REFERENCES
        3. La dur�e de vie d'un fichier d'appel de politique et l'�l�ment EXPIRY
          1. La motivation et le m�canisme
          2. L'�l�ment EXPIRY
          3. L'utilisation des en-t�tes HTTP
          4. La gestion d'erreurs pour les dur�es de vie des fichiers d'appel de politique et des politiques
        4. L'�l�ment POLICY-REF
        5. Les �l�ments INCLUDE et EXCLUDE
        6. L'�l�ment HINT
        7. Les �l�ments COOKIE-INCLUDE et COOKIE-EXCLUDE
        8. L'�l�ment METHOD
      3. L'application d'une politique � une adresse URI
      4. Les formulaires et les m�canismes apparent�s
    4. Les autres conditions requises
      1. La non-ambigu�t�
      2. Les diverses langues
      3. La zone s�re
      4. Le traitement des politiques et des fichiers d'appel de politique par les agents utilisateurs
      5. La s�ret� du transport des politiques
      6. Les mises � jour des politiques
      7. L'absence d'un fichier d'appel de politique
      8. L'�valuation asynchrone
    5. Exemples de sc�narios
  3. La syntaxe et la s�mantique des politiques
    1. Exemples de politiques
      1. Les politiques en langage naturel
      2. Le codage XML des politiques
    2. Les politiques
      1. L'�l�ment POLICIES
      2. L'�l�ment POLICY
      3. L'�l�ment TEST
      4. L'�l�ment ENTITY
      5. L'�l�ment ACCESS
      6. L'�l�ment DISPUTES
      7. L'�l�ment REMEDIES
    3. Les d�clarations
      1. L'�l�ment STATEMENT
      2. L'�l�ment CONSEQUENCE
      3. L'�l�ment NON-IDENTIFIABLE
      4. L'�l�ment PURPOSE
      5. L'�l�ment RECIPIENT
      6. L'�l�ment RETENTION
      7. Les �l�ments DATA-GROUP et DATA
    4. Les cat�gories et l'�l�ment CATEGORIES
    5. Le m�canisme d'extension�: l'�l�ment EXTENSION
    6. Les pr�f�rences de l'utilisateur
  4. Les politiques compactes
    1. L'appel des politiques compactes
    2. Le vocabulaire des politiques compactes
      1. L'�l�ment ACCESS compact
      2. L'�l�ment DISPUTES compact
      3. L'�l�ment REMEDIES compact
      4. L'�l�ment NON-IDENTIFIABLE compact
      5. L'�l�ment PURPOSE compact
      6. L'�l�ment RECIPIENT compact
      7. L'�l�ment RETENTION compact
      8. L'�l�ment CATEGORIES compact
      9. L'�l�ment TEST compact
    3. La port�e d'une politique compacte
    4. La dur�e de vie d'une politique compacte
    5. La transformation d'une politique P3P en une politique compacte
    6. La transformation d'une politique compacte en une politique P3P
  5. Les sch�mas de donn�es
    1. La gestion des langues des sch�mas de donn�es
    2. Les structures de donn�es
    3. Les �l�ments DATA-DEF et DATA-STRUCT
      1. Les cat�gories dans les sch�mas de donn�es P3P
      2. Exemple de sch�ma de donn�es P3P
      3. L'utilisation des noms des �l�ments de donn�es
    4. La persistance des sch�mas de donn�es
    5. Les structures de donn�es de base
      1. Les dates
      2. Les noms
      3. Les connexions
      4. Les certificats
      5. Les num�ros de t�l�phone
      6. Les coordonn�es
        1. Les coordonn�es postales
        2. Les coordonn�es de t�l�communication
        3. Les coordonn�es en ligne
      7. Les journaux d'acc�s et les adresses Internet
        1. Les adresses URI
        2. Les adresses IP
        3. Les informations du journal d'acc�s
        4. Les autres informations du protocole HTTP
    6. Le sch�ma de donn�es de base
      1. Les donn�es de l'utilisateur
      2. Les donn�es d'un tiers
      3. Les donn�es de l'entreprise
      4. Les donn�es dynamiques
    7. Les cat�gories et les �l�ments/structures de donn�es
      1. Les �l�ments/structures de donn�es de cat�gorie fixe
      2. Les �l�ments/structures de donn�es de cat�gorie variable
    8. L'utilisation des �l�ments de donn�es
  6. 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�:

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

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

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

  1. se trouver dans un emplacement notoire pr�d�fini, ou
  2. �tre indiqu� dans un document HTML par une balise link, ou
  3. �tre indiqu� dans un document XHTML par une balise link, ou
  4. �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)�:

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

  1. 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�;
  2. 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.
  3. Aucune d�claration sur la politique P3P qui s'applique � /servlet/inconnu�;
  4. 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�:

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

  1. 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�;
  2. 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�:

  1. 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�;
  2. 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�:

  1. 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�;
  2. Une �ch�ance relative inf�rieure � 86400�secondes (un jour) est cens�e valoir 86400�secondes�;
  3. 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�:

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

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

  1. 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�;
  2. 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�;
  3. 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�;
  4. 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�;
  5. 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�:

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 pratiques de zone s�re pour les serveurs comprennent les contraintes suivantes�:

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

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

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

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

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

2.4.5 La s�ret� du transport des politiques

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

2.4.6 Les mises � jour des politiques

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

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

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

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

2.4.8 L'�valuation asynchrone

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

2.5 Exemples de sc�narios

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

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

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

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

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

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

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

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

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

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

3. La syntaxe et la s�mantique des politiques

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

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

3.1 Exemples de politiques

3.1.1 Les politiques en langage naturel

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

Exemple 3.1�: Politique de confidentialit� de CatalogueExemple pour les navigateurs
Chez CatalogueExemple, nous sommes attach�s au respect de votre vie priv�e. Lorsque vous venez chez nous pour chercher un article, les renseignements recueillis � cette occasion servent uniquement � am�liorer le site et ils ne sont pas stock�s avec des informations permettant de vous identifier.
La soci�t� CatalogueExemple participe au programme SceauConfidentielExemple. Le programme SceauConfidentielExemple garantit le respect de votre vie priv�e en soumettant les sites Web affili�s � des r�gles de confidentialit� strictes et en certifiant par des audits ind�pendants que les pratiques vis-�-vis des renseignements recueillis sont respect�es.
Veuillez adresser les questions concernant cette d�claration �:
CatalogueExemple
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email�: [email protected]
Telephone 248-EXAMPLE (248-392-6753)
Si nous n'avons pas r�pondu � vos demandes ou alors d'une mani�re non satisfaisante, vous pouvez contacter SceauConfidentielExemple � http://www.sceauconfidentiel.example.org. La soci�t� CatalogueExemple corrigera toutes les erreurs ou les actions erronn�es qui auraient pu survenir conform�ment � la politique de confidentialit�.
Les renseignements que nous collectons et pourquoi nous les collectons�:
Au cours de votre navigation sur notre site, nous collectons�:


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

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

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

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

Veuillez adresser les questions concernant cette d�claration �:
CatalogueExemple
4000 Lincoln Ave.
Birmingham, MI 48009 USA
email: [email protected]
Telephone +1 248-EXAMPLE (+1 248-392-6753)

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

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

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

3.1.2 Le codage XML des politiques

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

Le codage XML de l'exemple 3.1�:

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

Codage XML de l'exemple 3.2�:

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

3.2 Les politiques

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

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

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

3.2.1 L'�l�ment POLICIES

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

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

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

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

Exemple 3.3�:

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

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

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

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
<POLICY-REFERENCES>
    <POLICY-REF about="/magasin/politiques#politique2">
      <INCLUDE>/magasin/CDs/*</INCLUDE>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>
[19]    policies  =  `<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `>`
                     [expiry]
                     [dataschema]
                     *policy
                     "</POLICIES>"

3.2.2 L'�l�ment POLICY

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

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

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

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

3.2.3 L'�l�ment TEST

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

[22]    test  =  "<TEST/>"

3.2.4 L'�l�ment ENTITY

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

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

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

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

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

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

3.2.5 L'�l�ment ACCESS

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

<ACCESS>
la possibilit� offerte � un individu de consulter des donn�es identifi�es et d'adresser ses questions ou ses inqui�tudes au fournisseur de services. Les fournisseurs de services DOIVENT fixer une valeur de divulgation pour l'attribut access. La m�thode d'acc�s n'est pas sp�cifi�e. Une annonce (autre que <all/>) n'implique pas qu'on puisse acc�der � toutes les donn�es mais seulement � certaines, et les utilisateurs devraient entrer en relation avec le fournisseur de services pour d�terminer quelles sont les possibilit�s dont ils disposent.

Remarquez que les fournisseurs de services peuvent aussi autoriser un acc�s aux informations collect�es via d'autres moyens que par le Web � l'adresse URI indiqu�e par l'attribut discuri. La port�e des d�clarations P3P est limit�e aux donn�es collect�es au travers du protocole HTTP ou d'autres protocoles de transport Web. En outre, lorsque cet acc�s a lieu par le Web, on recommande l'utilisation de m�canismes d'authentification et de s�curit� forts pour ces �changes�; les questions de s�curit� ne sont toutefois pas abord�es par ce document.

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

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

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

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

3.2.6 L'�l�ment DISPUTES

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

<DISPUTES>
D�crit les proc�dures de r�solution des litiges � observer en cas de contestation des pratiques de confidentialit� d'un service ou en cas de violation du protocole.
resolution-type (attribut obligatoire)
Prend l'une des quatres valeurs suivantes�:
service
Service client�le : Un individu peut se plaindre aupr�s du repr�sentant du service client�le du site Web charg� de la r�solution des litiges concernant l'utilisation des donn�es collect�es. La description DOIT inclure des renseignements sur les moyens de contacter le service client�le.
independent
Organisation ind�pendante : Un individu peut se plaindre aupr�s d'une organisation ind�pendante pour la r�solution des litiges concernant l'utilisation des donn�es collect�es. La description DOIT inclure des renseignements sur les moyens de contacter ce tiers.
court
Tribunal : Un individu peut porter plainte � l'encontre du site Web.
law
Lois applicables : Les litiges en rapport avec la d�claration de confidentialit� seront r�solus selon les lois cit�es dans la description.
service (attribut obligatoire)
L'adresse URI de la page Web du service client�le, ou de l'organisation ind�pendante, ou l'adresse URI renseignant sur la juridiction ou les lois applicables concern�es.
verification
L'adresse URI ou le certificat � utiliser dans un but de v�rification. Il est pr�vu de mettre en place un m�canisme permettant aux organismes de labellisation de v�rifier le label auquel un site pr�tend.
short-description
Une description br�ve, lisible par un humain, indiquant le nom de la juridiction concern�e, les r�glements applicables ou une organisation tierce, ou bien les coordonn�es du service client�le si celles-ci ne sont pas d�j� mentionn�es � l'adresse URI du service en question. La description ne doit pas faire plus de 255�caract�res.

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

<LONG-DESCRIPTION>
Cet �l�ment contient une description lisible par un humain (qui peut �tre tr�s d�taill�e).
<IMG>
L'image d'un logo (par exemple, celui de l'organisation ind�pendante ou celui de la juridiction concern�e).
src (attribut obligatoire)
L'adresse URI de l'image du logo
width
La largeur en pixels de l'image du logo.
height
La hauteur en pixels de l'image du logo.
alt (attribut obligatoire)
Un remplacement textuel tr�s court pour l'image du logo.
[27]    disputes-group   =  "<DISPUTES-GROUP>"
                            *extension
                            1*dispute
                            *extension
                            "</DISPUTES-GROUP>"

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

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

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

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

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

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

3.2.7 L'�l�ment REMEDIES

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

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

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

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

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

3.3 Les d�clarations

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

3.3.1 L'�l�ment STATEMENT

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

<STATEMENT>
Les pratiques concernant les donn�es telles qu'appliqu�es aux �l�ments de donn�es.
[34]    statement-block  =  "<STATEMENT>"
                            *extension
                            [consequence]
                            ((purpose recipient retention 1*data-group) |
                            (non-identifiable [purpose] [recipient] [retention] *data-group))
                            *extension
                            "</STATEMENT>"

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

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

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

3.3.2 L'�l�ment CONSEQUENCE

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

<CONSEQUENCE>
Les cons�quences qui peuvent �tre pr�sent�es � l'utilisateur afin d'expliquer l'int�r�t de la pratique sugg�r�e dans un contexte donn�, m�me si, normalement, l'utilisateur ne l'aurait pas autoris�e.
[35]    consequence  =  "<CONSEQUENCE>"
                        PCDATA
                        "</CONSEQUENCE>"

3.3.3 L'�l�ment NON-IDENTIFIABLE

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

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

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

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

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

3.3.4 L'�l�ment PURPOSE

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

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

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

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

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

required
La caract�ristique d'obligation de la pratique pour le site. L'attribut prend les valeurs suivantes�: 
[37]    purpose       =  "<PURPOSE>"
                         *extension
                         1*purposevalue
                         *extension
                         "</PURPOSE>"

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

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

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

3.3.5 L'�l�ment RECIPIENT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3.6 L'�l�ment RETENTION

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

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

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

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

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

3.3.7 Les �l�ments DATA-GROUP et DATA

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

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

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

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

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

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

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

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

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

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

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

3.4 Les cat�gories et l'�l�ment CATEGORIES

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

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

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

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

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

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

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

3.5 Le m�canisme d'extension�: l'�l�ment EXTENSION

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

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

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

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

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

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

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

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

3.6 Les pr�f�rences de l'utilisateur

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

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

4. Les politique compactes

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

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

4.1 L'appel des politiques compactes

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

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

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

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

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

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

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

4.2 Le vocabulaire des politiques compactes

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

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

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

4.2.1 L'�l�ment ACCESS compact

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

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

4.2.2 L'�l�ment DISPUTES compact

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

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

4.2.3 L'�l�ment REMEDIES compact

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

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

4.2.4 L'�l�ment NON-IDENTIFIABLE compact

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

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

4.2.5 L'�l�ment PURPOSE compact

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

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

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

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

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

4.2.6 L'�l�ment RECIPIENT compact

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

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

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

4.2.7 L'�l�ment RETENTION compact

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

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

4.2.8 L'�l�ment CATEGORIES compact

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

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

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

4.2.9 L'�l�ment TEST compact

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

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

4.3 La port�e d'une politique compacte

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

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

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

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

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

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

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

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

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

Exemple 4.1�:

Supposons la politique P3P suivante�:

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

La politique compacte correspondante sera la suivante�:

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

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

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

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

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

5. Les sch�mas de donn�es

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2 Les structures de donn�es

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

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

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

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

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

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

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

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

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

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

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

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

5.3 Les �l�ments DATA-DEF et DATA-STRUCT

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3.2 Exemple de sch�ma de donn�es P3P

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4 La persistance des sch�mas de donn�es

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

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

5.5 Les structures de donn�es de base

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

5.5.1 Les dates

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

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

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

5.5.2 Les noms

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

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

5.5.3 Les connexions

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

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

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

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

5.5.4 Les certificats

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

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

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

5.5.5 Les num�ros de t�l�phone

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

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

5.5.6 Les coordonn�es

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

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

5.5.6.1 Les coordonn�es postales

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

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

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

5.5.6.2 Les coordonn�es de t�l�communication

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

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

5.5.6.3 Les coordonn�es en ligne

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

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

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

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

5.5.7.1 Les adresses URI

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

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

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

5.5.7.2 Les adresses IP

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

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

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

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

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

5.5.7.3 Les informations du journal d'acc�s

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

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

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

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

5.5.7.4 Les autres informations du protocole HTTP

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

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

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

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

5.6 Le sch�ma de donn�es de base

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

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

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

5.6.1 Les donn�es de l'utilisateur

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

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

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

5.6.2 Les donn�es d'un tiers

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

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

5.6.3 Les donn�es de l'entreprise

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

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

5.6.4 Les donn�es dynamiques

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Annexes

Annexe�1�: R�f�rences (normatif)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

</DATASCHEMA>

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

 <complexType name='access-value'/>

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

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

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

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

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

 <complexType name='remedies-value'/>

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

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

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

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

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

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

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

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

 <complexType name='retention-value'/>

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

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

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

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

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

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

 <complexType name='categories-value'/>

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

</schema>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Annexe�6�: La notation ABNF (normatif)

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

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

Les autres notations utilis�es dans les productions�:

; ou /* ... */
commentaire.

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

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

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

La confidentialit� des informations

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

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

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

La notification et la transmission

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

Les fournisseurs de services devraient�:

Les agents utilisateurs devraient�:

Le choix et le contr�le

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

Les fournisseurs de services devraient�:

Les agents utilisateurs devraient�:

La loyaut� et l'int�grit�

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

Les fournisseurs de services devraient�:

Les agents utilisateurs devraient�:

La s�curit�

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

Les fournisseurs de services devraient�:

Les agents utilisateurs devraient�:

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

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

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

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

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

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

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

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

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

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