Groupe de travail Réseau	H. Khartabil, Telio	
Request for Comments : 4661	E. Leppanen, Nokia	
Catégorie : Sur la voie de la normalisation	M. Lonnfors, Nokia	
Traduction Claude Brière de L'Isle	J. Costa-Requena, Nokia	
	septembre 2006	

Format fondé sur le langage de balisage extensible (XML) pour filtrage de notification d'événement

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2006).

Résumé
Le cadre SIP de notification d'événement décrit l'usage du protoocle de description de session (SIP, Session Initiation Protocol ) pour les abonnements et les notifications des changements de l'état d'une ressource. Ce document ne décrit pas le mécanisme par lequel le filtrage des informations de notification d'événement peut être réalisé. Le filtrage est un mécanisme pour définir les informations de notification préférées à livrer et pour spécifier les déclencheurs qui causent la livraison de ces informations. Afin de permettre cela, un format est nécessaire pour permettre à l'abonné de décrire les changements d'état d'une ressource qui causent l'envoi des notifications et ce que ces notifications doivent contenir. Ce document présente un format en forme de document XML.
Table des matières
1. Introduction	2
2. Conventions	2
3. Structure de filtre simple codé en XML	2
3.1 Type MIME pour document Simple-Filter	2
3.2 Élément racine <filter-set>	3
3.3 Élément <ns-bindings>	3
3.4 Élément <filter>	3
3.5 Élément <what>	4
3.6 Élément <trigger>	4
3.6.1.4 Combinaison d'attributs	5
4. Extensibilité du schéma XML	6
5. Syntaxe de référence des éléments XML et de construction des expressions logiques	6
6. Exemples	7
6.1 Critères de filtre utilisant l'élément <what>	7
6.2 Critères de filtre utilisant l'élément <trigger>	8
6.3 Critères de filtre utilisant les éléments <what> et <trigger>	8
6.4 Filtre de contenu utilisant Namespaces	8
6.5 Filtre de contenu utilisant seulement des éléments <include>	9
6.6 Deux filtres de contenu comme critères de filtre	9
7. Schéma XML pour critères de filtre	10
8. Considérations sur la sécurité	12
9. Considérations relatives à l'IANA	12
9.1 Type MIME application/simple-filter+xml	12
9.2 Enregistrement de sous espace de noms d'URN pour urn:ietf:params:xml:ns:simple-filter	13
9.3 Enregistrement de schéma	13
10. Remerciements	13
11. Références	13
11.1 Références normatives	13
11.2 Références pour information	14
Adresse des auteurs	14
Déclaration complète de droits de reproduction	14

 	1.	Introduction

Le cadre de notification d'événement SIP [RFC3265] décrit l'usage du protocole d'initialisation de session (SIP, Session Initiation Protocol) pour les abonnements et notifications de changements de l'état d'une ressource. Le document ne décrit pas le mécanisme par lequel le filtrage des informations de notification d'événement peut être réalisé.

Le filtrage est un mécanisme pour définir les informations de notification préférées, qu'on appelle le contenu, à livrer et pour spécifier les règles sur quand ces informations devraient être livrées.

Le mécanisme de filtrage est supposé être particulièrement précieux et principalement applicable aux utilisateurs d'appareils mobiles à accès sans fil. Les caractéristiques des appareils incluent normalement une forte latence, une faible bande passante, de faibles capacités de traitement de données, un petit affichage, et une puissance de batterie limitée. De tels appareils peuvent bénéficier de la capacité de filtrer la quantité d'informations générées à la source de la notification d'événement. Cependant, les mises en œuvre doivent savoir la charge de calcul sur la source de la notification d'événement.  Ceci est discuté plus en détails à la Section 8.

La structure du critère de filtre est décrite en utilisant le schéma XML. Le critère de filtre est présenté comme un document XML. Le document XML contient la préférence de l'utilisateur quant au moment où les notifications sont à lui envoyer et ce qu'elles vont contenir. La portée de la partie "when" est déclenchante.

Le déclenchement est défini comme permettant à un abonné de spécifier les règles de déclenchement pour les notifications où les critères se fondent sur les changements des informations d'état spécifiques du paquetage d'événement [RFC3265], par exemple, pour le document d'informations de présence [RFC3856], le changement de la valeur de l'élément <status>.

La fonction de filtrage concernant les notifications d'événement SIP est spécifiée dans la [RFC4660].

 	2.	Conventions

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119] et indiquent les niveaux d'exigence pour les mises en œuvre conformes.

Dans ce document, le "document XML résultant" se réfère au document XML final qui porte les informations d'état à livrer à l'abonné après que les filtres y ont été appliqués.

"Contenu" se réfère au document XML qui apparaît dans une notification reflétant l'état d'une ressource.

 	3.	Structure de filtre simple codé en XML

Un simple filtre est un document XML [XML] qui DOIT être bien formé et DOIT être valide en accord avec les schémas, incluant les schémas d'extension, disponibles pour le valideur, et applicables au document XML. Les documents de simple filtre DOIVENT être fondés sur XML 1.0 et DOIVENT être codés en utilisant UTF-8.

L'identifiant d'espace de noms pour les éléments définis par la présente spécification est un URN [RFC2141], qui utilise l'identifiant d'espace de noms 'ietf' défini par la [RFC2648] et étendu par la [RFC3688]. 
Cet urn est : urn:ietf:params:xml:ns:simple-filter.

Cette déclaration d'espace de noms indique l'espace de noms sur lequel se fonde le critère de filtre.

 	3.1	Type MIME pour document Simple-Filter
Le type MIME pour le document simple-filter est "application/simple-filter+xml". Tout protocole de transport (SIP [RFC3261], par exemple) utilisé pour porter les filtres qui porte aussi les informations de type de charge utile DOIT identifier la charge utile comme type MIME "application/simple-filter+xml" (par exemple, un champ d'en-tête Content-Type).

 	3.2	Élément racine <filter-set>
L'élément racine du critère de filtre est <filter-set>.

L'élément <filter-set> contient la définition d'espace de noms mentionnée ci-dessus. Avec l'attribut facultatif 'package', il est possible de définir le paquetage auquel le critère de filtre est appliqué. Cela pourrait être particulièrement utile dans les cas où le document XML contenant le critère de filtre est séparé des événements qui l'utilisent ou du protocole qui le porte habituellement.

L'élément <filter-set> peut contenir un élément <ns-bindings>.

L'élément <filter-set> contient un ou plusieurs éléments <filter>.

 	3.3	Élément <ns-bindings>
L'élément <ns-bindings> est utilisé pour lier les espaces de noms aux préfixes locaux utilisés dans les expressions qui choisissent les éléments ou attributs en utilisant la syntaxe de la Section 5. Ces préfixes s'appliquent aux éléments <include>, <exclude>, <changed>, <added>, et <removed>.

L'élément <ns-bindings> contient un ou plusieurs éléments <ns-binding>. Chaque élément <ns-binding> a un attribut 'prefix'. La valeur de l'attribut 'prefix' est un préfixe utilisé pour qualifier les éléments pointés par l'expression. L'élément <ns-binding> a aussi un attribut 'urn' qui identifie l'espace de noms que le préfixe représente.

 	3.4	Élément <filter>
L'élément <filter> est utilisé pour spécifier le contenu d'un filtre individuel.

L'élément <filter> a un attribut 'id'. La valeur de l'attribut 'id' DOIT être unique au sein de l'élément <filter-set>. Le <filter> PEUT avoir un attribut 'uri'. La valeur de l'attribut 'uri' est l'URI de la ressource à laquelle le filtre s'applique. Le <filter> PEUT avoir un attribut 'domain'. La valeur de l'attribut 'domain' est le domaine des ressources auxquelles le filtre s'applique. L'attribut 'uri' et l'attribut 'domain' NE DOIVENT PAS apparaître ensemble dans le <filter>.

L'URI de la ressource est utile dans les cas où l'extension 'event list' [RFC4662] est utilisée avec un paquetage. Comme un abonnement à un paquetage d'événements peut être adressé à une liste d'événements, l'attribut 'uri' permet à l'abonné de définir un filtre spécifique pour une ressource individuelle dans cette liste. Cette ressource peut être une autre liste. L'attribut 'uri' peut, bien sûr, porter l'URI de la liste elle-même. Si le <filter> ne contient pas l'attribut 'uri', le filtre s'applique à la ressource identifiée dans la demande d'abonnement.

L'attribut 'domain' porte un domaine. Dans ce cas, le filtre s'applique aux ressources dont l'URI a une partie domaine qui correspond à ce domaine. Cela peut être utilisé quand un abonnement est pour une ressource qui est une liste d'événements avec de nombreuses ressources provenant de différents domaines.

La correspondance d'URI est faite en accord avec les règles de correspondance définies pour un schéma particulier. Quand il confronte les domaines, la partie utilisateur de l'URI est ignorée pour les besoins de la confrontation.

Le <filter> PEUT avoir un attribut 'remove' qui avec l'attribut 'id' indique le filtre existant à supprimer. La valeur de l'attribut 'remove' est de type "booléen". La valeur par défaut est "faux".

Le <filter> PEUT avoir un attribut 'enabled' qui indique si un filtre est activé ou désactivé. La valeur de l'attribut 'enabled' est de type "booléen". La valeur par défaut est "vrai".

L'élément <filter> PEUT contenir un élément <what> et PEUT contenir un ou plusieurs éléments <trigger>, mais il DOIT contenir soit l'élément <what> soit l'élément <trigger> quand le filtre est activé pour la première fois. Quand un filtre est désactivé en réglant l'attribut 'enabled' à "faux", les éléments <what> et <trigger> PEUVENT être omis. De même, quand un filtre est réactivé en réglant l'attribut 'enabled' à "vrai", les éléments <what> et <trigger> PEUVENT être omis.

Le contenu du filtre peut être changé en changeant le contenu dans les éléments <what> et <trigger> et en conservant la valeur de l'attribut 'id' du filtre.

 	3.5	Élément <what>
L'élément <what> est utilisé pour spécifier le contenu à livrer à l'utilisateur. Il ne spécifie pas le contenu exact mais les règles qui sont utilisées pour construire ces informations.

L'élément <what> peut contenir un ou plusieurs éléments <include> et un ou plusieurs éléments <exclude>. Quand plus d'un élément <include> a été défini, les résultats sont additifs. C'est-à-dire, chaque élément <include> ajoute un élément ou attribut au document XML résultant. Quand plus d'un élément <exclude> a été défini, chaque valeur d'élément <exclude> diminue le contenu du document XML résultant.

 	3.5.1	Élément <include>
L'élément <include> est utilisé pour choisir le contenu à livrer. Sa valeur peut identifier un élément XML, un attribut, ou un espace de noms d'un document XML à filtrer. Ceci est indiqué en utilisant l'attribut 'type'.

Noter que le document XML résultant DOIT être valide. Donc, en plus d'inclure les éléments identifiés avec la valeur de l'élément <include>, tous les autres éléments et/ou attributs XML obligatoires doivent être incorporés dans le document XML résultant afin de le rendre valide. Cela signifie en pratique qu'un abonné qui définit un filtre a seulement besoin d'inclure des éléments et/ou attributs facultatifs, mais peut aussi inclure des éléments et/ou attributs obligatoires. Il y a aussi des cas où un filtre choisit un attribut qui appartient à un élément facultatif. Dans ce cas, l'élément facultatif a besoin d'apparaître dans le document XML résultant.

La syntaxe définie à la Section 5 (voir la définition de "selection") DOIT être utilisée. L'exemple suivant choisit l'élément <basic> défini dans le PIDF [RFC3863]. Il en résulte le choix de l'élément <basic> ainsi que de tous ses ancêtres, c'est-à-dire, <status> et <tuple>.

<include type="xpath">/presence/tuple/status/basic</include>.

 	3.5.2	Élément <exclude>
L'élément <exclude> est utilisé pour définir les exceptions à l'ensemble d'éléments et/ou attributs XML choisis par l'éléments <include>. Donc, les éléments XML (incluant leurs éléments "fils" de niveau inférieur) et/ou attributs définis par l'élément <exclude> ne sont pas livrés. Ceci est particulièrement utile quand un élément <include> identifie un espace de noms.

L'élément <exclude> a l'attribut facultatif 'type' (voir la définition de 'type' au paragraphe 3.5.3).

Noter que le document XML résultant DOIT être valide. Donc, si l'étape d'application de la valeur d'élément <exclude> à un document XML résulte en un document invalide selon le schéma, cette étape DOIT être inversée, résultant en la réintroduction des éléments et/ou attributs dans le document XML résultant avec leurs valeurs précédentes afin de le rendre valide. Ceci signifie en pratique qu'un abonné qui définit un filtre a seulement besoin d'exclure les éléments et/ou attributs facultatifs, mais NE DEVRAIT PAS exclure les éléments et/ou attributs obligatoires.

La syntaxe DOIT suivre la Section 5.

 	3.5.3	Attribut 'type'
L'attribut 'type' est utilisé pour décrire la valeur des éléments <include> et <exclude>. Les valeurs suivantes sont prédéfinies : "xpath" et "namespace". L'attribut 'type' est facultatif, et, si il est omis, la valeur par défaut est "xpath".

La valeur "xpath" est utilisée quand l'élément <include> ou <exclude> contient une valeur qui suivant la syntaxe de la Section 5 choisit un élément ou un attribut.

La valeur "namespace" est utilisée quand l'élément <include> ou <exclude> contient une valeur d'un espace de noms. La valeur est l'URI de l'espace de noms. Le document XML résultant se compose des éléments définis dans l'espace de noms.

 	3.6	Élément <trigger>
L'élément <trigger> est utilisé pour identifier les changements spécifiques de paquetage qu'une ressource va subir avant que le contenu soit livré à l'abonné. Il peut apparaître plus d'une fois dans un élément <filter>. Plusieurs apparitions de cet élément notent l'opération "OU". Cela signifie que des mises à jour à une ressource qui satisfont à tout critère de l'élément <trigger> constituent le contenu à livrer.

L'élément <trigger> PEUT contenir les éléments <changed>, <added>, ou <removed>, mais il DOIT contenir au moins un des trois éléments. Toute combinaison des trois éléments est possible. Plusieurs apparitions de ces éléments au sein d'un élément <trigger> notent l'opération "ET". Cela signifie que des mises à jour d'une ressource qui satisfont TOUS les critères de l'élément <changed>, <added>, et <removed> au sein de l'élément <trigger> constituent le contenu à livrer.

 	3.6.1	Élément <changed>
L'élément <changed> est utilisé pour identifier l'élément ou attribut XML, à partir du document XML spécifique du paquetage, dont la valeur DOIT changer par rapport à celle du "document XML précédent", afin d'activer le déclencheur et causer la livraison du contenu. Le "document XML précédent" dans ce contexte se réfère à la version brute la plus récente du document XML qui a été envoyée à l'abonné, avant que les filtres y aient été appliqués. L'élément ou attribut XML DOIT être exprimé en utilisant la syntaxe définie à la Section 5 pour l'ABNF de "référence".

L'élément <changed> PEUT contenir l'attribut 'from', l'attribut 'to', l'attribut 'by', ou toute combinaison des trois. L'absence de tous ces attributs signifie qu'un changement de n'importe quelle sorte de la valeur de l'élément ou attribut active le déclencheur. Une mise à jour de la valeur de l'élément ou attribut avec une valeur identique n'est pas un changement.

La comparaison d'un changement est faite conformément aux règles lexicales de l'élément ou attribut.

 	3.6.1.1	Attribut 'from'
Un déclencheur est actif quand l'élément ou attribut XML identifié avec l'élément <changed> a changé de la valeur indiquée par cet attribut en une valeur différente.

 	3.6.1.2	Attribut 'to'
Un déclencheur est actif quand l'élément ou attribut XML identifié avec l'élément <changed> a changé en la valeur indiquée par cet attribut à partir d'une valeur différente.

 	3.6.1.3	Attribut 'by'
Un déclencheur est actif quand l'élément ou attribut XML identifié avec l'élément <changed> a changé d'au moins la quantité indiquée par cet attribut à partir d'une valeur différente. C'est-à-dire, l'attribut 'by' ne s'applique qu'aux valeurs numériques et indique un delta par rapport à la valeur courante qu'un attribut ou élément (identifié dans l'élément <changed>) a besoin de changer avant qu'il soit choisi. Par exemple, si l'attribut 'by' est réglé à 2 et si la valeur courante de l'élément/attribut est 6, l'élément/attribut est choisi quand il atteint (ou excède) la valeur 8 ou quand il diminue à 4 ou une valeur inférieure.

 	3.6.1.4	Combinaison d'attributs
Toute combinaison des attributs 'from', 'to', et 'by' dans l'élément <changed> est possible. Par exemple, si l'attribut 'from' est combiné avec l'attribut 'to', il est interprété comme signifiant que le déclencheur est actif quand l'élément ou attribut XML identifié avec l'élément <changed> a changé de la valeur 'from' à la valeur 'to'. Noter que si l'attribut 'by' est utilisé en combinaison avec les autres attributs, les autres types d'attribut DOIVENT correspondre au type de décimal 'by'.

 	3.6.2	Élément <added>
L'élément <added> déclenche la livraison de contenu quand l'élément XML qu'il identifie a été ajouté au document qui est filtré (c'est-à-dire, cette instance de cet élément apparaît dans le document en cours, mais pas dans le document précédent).  Il peut être utilisé, par exemple, pour apprendre de nouveaux services et/ou capacités souscrits par l'utilisateur, ou des services et/ou capacités que l'utilisateur a maintenant permis à l'abonné de voir. L'élément ou attribut XML DOIT être exprimé en utilisant la syntaxe définie à la Section 5 pour l'ABNF de "référence".

Noter que si un filtre inclut à la fois la partie filtre de contenu (<what>) et l'élément <added>, alors les définitions de la partie <what> DEVRAIENT aussi couvrir les éléments ajoutés. Autrement, le contenu est livré sans les éléments définis dans l'élément <added>.

 	3.6.3	Élément <removed>
L'élément <removed> déclenche la livraison du contenu quand l'élément XML qu'il identifie a été supprimé du document filtré (c'est-à-dire, cette instance de cet élément qui apparaissait dans le document précédent, mais pas dans le présent document). L'élément ou attribut XML DOIT être exprimé en utilisant la syntaxe définie à la Section 5 pour l'ABNF de "référence".

 	4.	Extensibilité du schéma XML

Le document simple-filter est destiné à être étendu. Une extension a lieu en définissant un nouvel ensemble d'éléments dans un nouvel espace de noms, gouverné par un nouveau schéma. Chaque extension DOIT avoir un espace de noms XML approprié qui lui est alloué. L'espace de noms XML de l'extension DOIT être différent des espaces de noms définis dans la présente spécification. L'extension NE DOIT PAS changer la syntaxe ou la sémantique des schémas définis dans le présent document. Toutes les étiquettes et attributs XML qui font partie de l'extension DOIVENT être qualifiés de façon appropriée pour se placer dans l'espace de noms et DOIVENT être conçus de façon à ce que les receveurs puissent ignorer de telles extensions en toute sécurité.

La présente spécification définit des endroits explicites où de nouveaux éléments ou attributs provenant d'une extension peuvent être placés. Ils sont explicitement indiqués dans les schémas par les éléments <any> et <anyAttribute>. Les extensions à la présente spécification DOIVENT spécifier où leurs éléments peuvent être placés dans le document.

Par suite, un document qui contient des extensions va exiger plusieurs schémas afin de déterminer sa validité - un schéma défini dans ce document, avec ceux définis par les extensions présentes dans le document. Parce que les extensions surviennent en ajoutant de nouveaux éléments et attributs gouvernés par de nouveaux schémas, les schémas définis dans ce document sont fixés et ne vont être changés que par une révision de cette spécification. Une telle révision, si elle devrait avoir lieu, devrait s'efforcer de permettre que les documents conformes au précédent schéma restent conformes au nouveau.  Par suite, les schémas définis ici ne fournissent pas de version de schéma explicite, car il n'est pas prévu qu'il en soit besoin.

 	5.	Syntaxe de référence des éléments XML et de construction des expressions logiques

L'ABNF [RFC4234] est utilisé pour décrire la syntaxe des expressions. La syntaxe est définie comme étant compatible à XPATH [XPath] mais a seulement un ensemble restreint de capacités de XPATH. Plus d'informations sur la signification des éléments de la syntaxe peuvent être trouvées dans [XPath]. La "syntaxe abrégée" du "nœud en essais" est utilisée dans les références ("reference"). L'expression dans la syntaxe se rapporte au prédicat, à la comparaison, et aux expressions logiques de XPATH. Si une expression XPATH s'évalue comme plus d'un élément à une certaine étape, le filtre s'applique à tous les éléments qui sont évalués. C'est-à-dire, si un filtre incluant un élément s'évalue comme deux éléments, les deux éléments sont inclus dans un résultat.

selection = reference [expression]
expression = "[" (elem-expr / attr-expr) 1*[oper (elem-expr / attr-expr)] "]"
elem-expr = (elem-path / "." / "..") compar value
elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]
attr-expr = [elem-path "/"] attribute compar value
reference = elem-reference / attr-reference
elem-reference =  "/" 1*("/" / "/*" / ("/" element))
attr-reference = reference attribute
oper = "et" / "ou"
compar = "=" / "<" / ">"
element = [ns] string
attribute = "@" [ns] string
ns = string ":"
string = <toute séquence de données prise en charge par XML dans les noms d'élément XML, et/ou attribut ou préfixes d'espaces de noms>
value = <toute séquence de données prise en charge par XML comme valeur de l'élément et/ou attribut XML>

Quand on identifie des éléments ou attributs XML, la valeur peut consister en deux parties : le sélecteur d'élément/attribut XML et la condition (comparaison et expressions logiques). Le sélecteur d'élément XML apparaît en premier suivi par la partie condition entre crochets carrés. Dans la partie sélecteur d'élément XML, les éléments XML peuvent être référencés en donnant le chemin hiérarchique complet comme : "/presence/tuple/status/basic", en notant la sélection comme couvrant tout niveau hiérarchique par son nom comme : "//tuple/status/basic", ou en utilisant le caractère générique "*", qui note toute valeur dans un certain niveau comme "/*/watcher".

Des exemples de références sont donnés comme suit :

o	Choisir un élément en utilisant un élément XML comme condition :
*  //*[status/basic="open"]
*  /presence/tuple[*/basic="open"]

o 	Choisir un élément en utilisant des attributs XML comme condition :
*  //watcher[@duration-subscribed<500]
*  /*/watcher[@event="rejected"]

o	Choisir un élément en utilisant deux éléments XML comme condition :
*  //tuple[status/basic="open" et type="device"]

o	Choisir un attribut :
*  //watcher/@duration-subscribed

Dans certains cas, du fait de la conception du schéma XML, l'expression de type XPATH résulte en l'identification de plus d'un élément avec le même nom (l'expression XPATH peut n'avoir pas identifié de façon univoque un élément à chaque étape). Dans ces cas, tous les éléments identifiés sont sélectionnés.

Quand on évalue les étapes de localisation XPATH, l'expansion d'espace de noms suit la sémantique de XPATH 1.0 [XPath], c'est-à-dire, si le QName n'a pas de préfixe, alors l'URI d'espace de noms dans le nom étendu est nul. Avec des espaces de noms qui ne sont pas par défaut, l'expansion est faite en accord avec les définitions de <ns-bindings> données. Quand un espace de noms par défaut est utilisé dans le document, l'élément <ns-binding> DEVRAIT être utilisé pour définir un URI égal avec un préfixe afin d'avoir une évaluation de XPATH valide dans les étapes de localisation.

 	6.	Exemples

Le schéma XML pour les exemples de document XML est spécifié à la Section 7.

 	6.1	Critères de filtre utilisant l'élément <what>
Un utilisateur souhaite commaître la disponibilité et la volonté de son ami pour la messagerie (SMS, IM, et MMS) afin de savoir si l'ami est capable de recevoir un message, l'adresse à contacter, et le type de message à utiliser.

Cet exemple montre comment définir un filtre de contenu. L'élément <basic> ainsi que tous ses éléments parents sont choisis sur la base d'une condition définie par une expression logique. La condition est que les éléments <class> aient une valeur de "MMS", "SMS", ou "IM".

L'élément <class> est défini dans la [RFC4480] comme une extension à PIDF [RFC3863].

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
    <ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <what>
      <include type="xpath">
        /pidf:presence/pidf:tuple[rpid:class="IM" ou rpid:class="SMS"
        ou rpid:class="MMS"]/pidf:status/pidf:basic
      </include>
    </what>
  </filter>
</filter-set>

 	6.2	Critères de filtre utilisant l'élément <trigger>
Un utilisateur demande d'être informé quand son collègue devient disponible par un moyen de communication. L'utilisateur obtient l'état de présence complet du collègue quand un certain tuplet PIDF [RFC3863] <basic> change d'état de "closed" à "open".

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <trigger>
      <changed from="CLOSED" to="OPEN">
        /pidf:presence/pidf:tuple/pidf:status/pidf:basic
      </changed>
    </trigger>
  </filter>
</filter-set>

 	6.3	Critères de filtre utilisant les éléments <what> et <trigger>
Un utilisateur souhaite obtenir des informations sur les abonnements en cours et en attente afin d'être capable d'autoriser les observateurs à voir ses informations de présence.

Le filtre choisit les notifications d'informations d'observateur [RFC3858] à envoyer quand un état d'abonnement a changé de "pending" ou "waiting". Dans la notification, seuls les observateurs qui ont un état de "pending" ou "waiting" sont inclus.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="wi" urn="urn:ietf:params:xml:ns:watcherinfo"/>
  </ns-bindings>
  <filter id="123" uri="sip:presentity@example.com">
    <what>
      <include>
        /wi:watcherinfo/wi:watcher-list/wi:watcher[@status="pending" ou @status="waiting"]
      </include>
    </what>
    <trigger>
      <changed to="pending">
        /wi:watcherinfo/wi:watcher-list/wi:watcher/@status
      </changed>
    </trigger>
    <trigger>
      <changed to="waiting">
        /wi:watcherinfo/wi:watcher-list/wi:watcher/@status
      </changed>
    </trigger>
  </filter>
</filter-set>

 	6.4	Filtre de contenu utilisant Namespaces
Un utilisateur allume son terminal, et le terminal va automatiquement chercher les informations générales d'état de présence et les informations sur les moyens de communication à partir d'un certain ensemble prédéfini de ses copains.

Le filtre est défini pour choisir les éléments XML qui appartiennent à l'espace de noms PIDF.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <filter id="123" uri="sip:buddylist@example.com">
    <what>
      <include type="namespace">
        urn:ietf:params:xml:ns:pidf
      </include>
    </what>
  </filter>
</filter-set>

 	6.5	Filtre de contenu utilisant seulement des éléments <include>
Un utilisateur veut savoir si un groupe de ses amis est disponible pour un jeu. Il demande des notifications sur l'état courant et les futurs changements des informations de présence spécifiques du jeu.

Ce filtre est défini pour choisir le tuplet spécifique du jeu à livrer.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" >
  <ns-bindings>
    <ns-binding prefix="game-ext" urn="urn:ietf:params:xml:ns:game-ext"/>
  </ns-bindings>
  <filter id="123">
    <what>
      <include>
        /pidf:presence/pidf:tuple/pidf:status[game-ext:label="game-X"]
      </include>
    </what>
  </filter>
</filter-set>

 	6.6	Deux filtres de contenu comme critères de filtre
L'utilisateur est intéressé à obtenir des informations à jour sur le moyen de communication et les adresses de contact de ses amis. L'utilisateur veut aussi obtenir plus d'informations (par exemple, de localisation) sur un de ses amis dans la liste, nommé Bob. L'élément PIDF <note> est filtré, c'est-à-dire, exclu. La liste est prédéfinie comme buddies@example.com.

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
  <ns-bindings>
    <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
    <ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/>
  </ns-bindings>
  <filter id="8439" uri="sip:buddies@example.com">
    <what>
      <include>
        /pidf:presence/pidf:tuple[rpid:class="service"]/pidf:status/pidf:basic
      </include>
    </what>
    </filter>
  <filter id="999" uri="sip:bob@example.com">
    <what>
      <include type="namespace">
        urn:ietf:params:xml:ns:pidf
      </include>
      <exclude>
        /pidf:presence/pidf:tuple/pidf:note
      </exclude>
    </what>
  </filter>
</filter-set>

 	7.	Schéma XML pour critères de filtre

Mise en œuvre de schéma XML (normative)

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
       xmlns="urn:ietf:params:xml:ns:simple-filter"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified">

<xs:import namespace="http://www.w3.org/XML/1998/namespace"
                   schemaLocation="http://www.w3.org/2001/xml.xsd"/>

<xs:annotation>
  <xs:documentation xml:lang="en">
    XML Schema Definition for Filter Criteria.
  </xs:documentation>
</xs:annotation>

<xs:element name="filter-set" type="FilterSetType"/>
    <xs:complexType name="FilterSetType">
     <xs:sequence>
       <xs:element name="ns-bindings" type="NSBindings" minOccurs="0" maxOccurs="1"/>
        <xs:element name="filter" type="FilterType" minOccurs="1" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="package" type="xs:string" use="optional"/>
     <xs:anyAttribute namespace="##other" processContents="lax"/>
    </xs:complexType>

     <xs:complexType name="NSBindings">
       <xs:sequence>
         <xs:element name="ns-binding" type="NSBinding"
                             minOccurs="1" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:complexType name="NSBinding">
       <xs:attribute name="prefix" type="xs:string" use="required"/>
       <xs:attribute name="urn" type="xs:anyURI" use="required"/>
     </xs:complexType>

     <xs:complexType name="FilterType">
       <xs:sequence>
         <xs:element name="what" type="WhatType" minOccurs="0" maxOccurs="1"/>
         <xs:element name="trigger" type="TriggerType" minOccurs="0" maxOccurs="unbounded"/>
         <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="id"  type="xs:string" use="required"/>
       <xs:attribute name="uri" type="xs:anyURI" use="optional"/>
       <xs:attribute name="domain" type="xs:string" use="optional"/>
       <xs:attribute name="remove" type="xs:boolean" use="optional" default="false"/>
       <xs:attribute name="enabled" type="xs:boolean" use="optional" default="true"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>

     <xs:complexType name="WhatType">
       <xs:sequence>
         <xs:element name="include" type="InclType" minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="exclude" type="ExclType" minOccurs="0" maxOccurs="unbounded"/>
         <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:complexType name="InclType">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="type" type="TypeType" default="xpath" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

   <xs:complexType name="ExclType">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="type" type="TypeType" default="xpath" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:simpleContent>
   </xs:complexType>

     <xs:simpleType name="TypeType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="xpath"/>
         <xs:enumeration value="namespace"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:complexType name="TriggerType">
       <xs:sequence>
       <xs:element name="changed" type="ChangedType" minOccurs="0" maxOccurs="unbounded"/>
       <xs:element name="added" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
       <xs:element name="removed" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:complexType name="ChangedType">
       <xs:simpleContent>
         <xs:extension base="xs:string">
           <xs:attribute name="from" type="xs:anySimpleType" use="optional"/>
           <xs:attribute name="to" type="xs:anySimpleType" use="optional"/>
           <xs:attribute name="by" type="xs:decimal" use="optional"/>
           <xs:anyAttribute namespace="##other" processContents="lax"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
   </xs:schema>

 	8.	Considérations sur la sécurité

Les filtres dans le corps d'un message SIP ont un effet significatif sur la façon dont la demande est traitée au serveur. Par suite, il est particulièrement important que les messages qui contiennent cette extension soient authentifiés et autorisés. L'authentification peut être réalisée en utilisant le mécanisme d'authentification par résumé décrit dans la [RFC3261]. La décision d'autorisation se fonde sur les permissions que la ressource (notificateur) a donné à l'observateur. Un exemple d'une telle politique d'autorisation se trouve dans la [RFC5025].

Les demandes peuvent révéler des informations sensibles sur les capacités d'un agent d'utilsateur. Si ces informations sont sensibles, elles DEVRAIENT être chiffrées en utilisant les capacités S/MIME de SIP [RFC3851].

Toutes les mesures de sécurité relatives au filtrage discutées dans la [RFC3265] DOIVENT être suivies avec la sécurité spécifique du paquetage.

 	9.	Considérations relatives à l'IANA

Ce document enregistre un nouveau type MIME, "application/simple-filter+xml", et enregistre un nouvel espace de noms XML.

La présente spécification suit les lignes directrices de la [RFC3023].

 	9.1	Type MIME application/simple-filter+xml
Type de support MIME : application
Nom de sous type MIME : simple-filter+xml
Paramètres obligatoires : aucun
Paramètres facultatifs : les mêmes que le paramètre de jeu de caractères de application/xml, comme spécifié dans la [RFC3023].
Considérations de codage : les mêmes que les considérations de codage de application/xml, comme spécifié dans la [RFC3023].
Considérations de sécurité : voir la Section 10 de la [RFC3023] et la Section 8 du présent document.
Considérations d'interopérabilité : aucune.
Spécification publiée : le présent document.
Applications qui utilisent ce type de support : ce type de document a été utilisé pour prendre en charge le cadre de notification d'événement fondé sur SIP et ses paquetages.
Informations supplémentaires :
Numéro magique : aucun
Extension de fichier : .cl ou .xml
Code de type de fichier Macintosh : "TEXT"
Adresse personnelle et de messagerie à contacter pour plus d'informations : Hisham Khartabil (hisham.khartabil@telio.no)
Usage prévu : COMMUN
Auteur/contrôleur des changements : IETF

 	9.2	Enregistrement de sous espace de noms d'URN pour urn:ietf:params:xml:ns:simple-filter
Ce paragraphe enregistre un nouvel espace de noms XML, selon les lignes directrices du registre XML IETF [RFC3688].

URI : l'URI pour cet espace de noms est urn:ietf:params:xml:ns:simple-filter.
Contact de l'enregistrant : IETF, goupe de travail SIMPLE, Hisham Khartabil (hisham.khartabil@telio.no)

 	9.3	Enregistrement de schéma
Ce paragraphe enregistre un nouveau schéma XML selon les procédures de la [RFC3688].

URI : urn:ietf:params:xml:ns:simple-filter
Contact de l'enregistrant : IETF, goupe de travail SIMPLE, Hisham Khartabil (hisham.khartabil@telio.no)

Le schéma XML est le seul contenu de la Section 7.

 	10.	Remerciements

Les auteurs remercient Jonathan Rosenberg, Henning Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla, Miguel-Angel Garcia Martin, Mary Barnes, Paul Kyzivat, Robert Sparks, et Elwyn Davies de leurs précieux apports et commentaires.

 	11.	Références
 	11.1	Références normatives

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

[RFC2141]	R. Moats, "Syntaxe des URN", mai 1997. (Obsolète, voir RFC8141)

[RFC2648]	R. Moats, "Espace de nom d'URN pour les documents de l'IETF", août 1999. (Information)

[RFC3023]	M. Murata, S. St.Laurent et D. Kohn, "Types de support XML", janvier 2001. (Obsolète, voir RFC7303)

[RFC3265]	A.B. Roach, "Notification d'événement spécifique du protocole d'initialisation de session (SIP)", juin 2002. (MàJ par RFC6446) (Remplacée par la RFC6665) 

[RFC3688]	M. Mealling, "Registre XML de l'IETF", BCP 81, janvier 2004.

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC4334]	R. Housley, T. Moore, "Extensions de certificat et attributs prenant en charge l'authentification dans le protocole point à point (PPP) et les réseaux de zone locale sans fils (WLAN)", février 2006. (Remplace RFC3770) (P.S.)

[RFC4660]	H. Khartabil et autres, "Description fonctionnelle du filtrage de notification d'événement", septembre 2006. (P.S. ; MàJ par la RFC6665) 

[XML]	Bray, T., "Exensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, octobre 2000.

[XPath]	Clark, J., "XML Path Language (XPath) Version 1.0", W3C REC REC-xpath-19991116, novembre 1999.

 	11.2	Références pour information

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3863]	H. Sugano et autres, "Format des données d'information de présence (PIDF)", août 2004.

[RFC3856]	J. Rosenberg, "Paquetage d'événement Presence pour le protocole d'initialisation de session (SIP)", août 2004.

[RFC3858]	J. Rosenberg, "Format fondé sur le langage de balisage extensible (XML) pour les informations d'observateur", août  2004. (P.S.)

[RFC4480]	H. Schulzrinne et autres, "RPID : Extensions Rich Presence au format de données d'information Presence (PIDF)", juillet  2006. (P.S.)

[RFC4662]	A. B. Roach et autres, "Extension de notification d'événement du protocole d'initialisation de session (SIP) pour les listes de ressources", août 2006. (P.S.)

[RFC5025]	J. Rosenberg, "Règles d'autorisation de présence", décembre 2007. (P.S.)

 	Adresse des auteurs

Hisham Khartabil	Eva Leppanen	Mikko Lonnfors	
Telio	Nokia	Nokia	
P.O. Box 1203 Vika	P.O BOX 785	P.O BOX 321	
Oslo	Tampere	Helsinki	
Norway	Finland	Finland	
téléphone : +47 2167 3544	téléphone : +358 7180 77066	téléphone : + 358 71800 8000	
mél : hisham.khartabil@telio.no 	mél : eva-maria.leppanen@nokia.com 	mél : mikko.lonnfors@nokia.com 	

Jose Costa-Requena
Nokia
P.O. Box 321
FIN-00045 NOKIA GROUP
Finland
téléphone : +358 71800 8000
mél : jose.costa-requena@nokia.com 

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administatif (IASA) de l'IETF.