Format fondé sur le langage de balisage extensible (XML) pour les informations d’observateur

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 (2004).

Résumé

Les observateurs sont définis comme des entités qui demandent (c’est-à-dire qui s’abonnent à) des informations sur une ressource. Il y a un état très complexe associé à ces abonnements. L’union de l’état de tous les abonnements à une ressource particulière est appelée les informations d’observateur pour cette ressource. Cet état est dynamique, et change lorsque les abonnés vont et viennent. Il en résulte qu’il est possible, et bien sûr utile, de s’abonner aux informations d’observateur pour une ressource particulière. Afin de le permettre, un format est nécessaire pour décrire l’état d’observateur d’une ressource. La présente spécification décrit un format de document en langage de balisage extensible (XML, Extensible Markup Language) pour un tel état.

1. Introduction

Les observateurs sont définis comme des entités qui demandent (c’est-à-dire, qui s’abonnent à) des informations sur une ressource, en utilisant le cadre d’événement SIP de la [RFC3265]. Il y a un état très complexe associé à ces abonnements. Cet état comporte l’identité de l’abonné, l’état de l’abonnement, et ainsi de suite. L’union des états pour tous les abonnements à une ressource particulière est appelé les informations d’observateur pour cette ressource. Cet état est dynamique, et est changé lorsque les abonnés vont et viennent. Par suite, il est possible, et bien sûr utile, de s’abonner aux informations d’observateur pour une ressource particulière. Une importante application en est la capacité pour un usager de découvrir l’ensemble des abonnés à leur présentité [RFC2778]. Cela permettrait à l’usager de fournir une décision d’autorisation pour l’abonnement.

Pour prendre en charge les abonnements aux informations d’observateur, deux composantes sont nécessaires. La première est la définition d’un gabarit de paquetage d’événement SIP pour les informations d’observateur. L’autre est la définition d’un format de données pour représenter les informations d’observateur. La première est spécifiée dans la [RFC3857], et la seconde est spécifiée ici.

2. Terminologie

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

Le présent document utilise aussi les termes abonné, observateur, abonnement, notification, abonnement aux informations d’observateur, abonné aux informations d’observateur et notification d’informations d’observateur avec la signification décrite dans la [RFC3857].

3. Structure des informations d’observateur

Les informations d’observateur sont un document XML [XML] qui DOIT être bien formé et DEVRAIT être valide. Les documents d’informations d’observateur DOIVENT se fonder sur XML 1.0 et DOIVENT être codés en utilisant UTF-8. La présente spécification utilise les espaces de noms XML pour identifier les documents d’informations d’observateur (watcherinfo) et les fragments de document. L’URI d’espace de nom pour les éléments définis par cette spécification est un URN [RFC2141], utilisant 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:watcherinfo

Un document d’informations d’observateur commence par l’étiquette d’élément racine "watcherinfo". Il consiste en un nombre quelconque de sous éléments "watcher-list", dont chacun est une liste des observateurs pour une certaine ressource. D’autres éléments provenant d’espaces de noms différents PEUVENT être présents pour des besoins d’extensibilité ; les éléments ou attributs provenant d’espaces de noms inconnus DOIVENT être ignorés. Il y a deux attributs associés à l’élément "watcherinfo", qui DOIVENT être tous deux présents :

version : Cet attribut permet au receveur des documents d’informations d’observateur de les ordonner de façon appropriée. Les versions commencent à 0, et s’incrémentent de un pour chaque nouveau document envoyé à un abonné aux informations d’observateur. Les versions ont pour portée l’abonnement aux informations d’observateur. Les versions DOIVENT pouvoir être représentées par un entier de 32 bits. Cependant, les versions ne reviennent pas à zéro.

état : Cet attribut indique si le document contient l’état d’informations d’observateur complet, ou si il ne contient que les informations sur les observateurs qui ont changé depuis le précédent document (partiel).

Chaque élément "watcher-list" contient une liste des éléments "watcher", dont chacun décrit un observateur sur une certaine ressource. D’autres éléments provenant d’espaces de noms différents PEUVENT être présents pour les besoins de l’extensibilité ; les éléments ou attributs provenant d’espaces de noms inconnus DOIVENT être ignorés. Il y a deux attributs qui sont associés à l’élément "watcher-list", qui DOIVENT tous deux être présents :

ressource : Cet attribut contient un URI pour la ressource observée par cette liste d’observateurs. Il est obligatoire.

paquetage : Cet attribut contient un jeton qui indique le paquetage d’événements pour lequel les informations d’observateur sur cette ressource sont fournies. Il est obligatoire.

L’élément "watcher" décrit un observateur dans la liste des observateurs. La valeur de l’élément "watcher" est un URI pour l’observateur. Cet URI DEVRAIT être l’identité authentifiée de l’observateur, telle que déterminée par le serveur qui traite l’abonnement. À ce titre, cet URI va normalement être un enregistrement d’adresse (par exemple, sip:joe@example.com) par opposition à une adresse d’appareil (par exemple, sip:joe@192.0.2.3). Il y a trois attributs obligatoires qui DOIVENT être présents :

id : Identifiant univoque pour l’abonnement décrit dans l’élément observateur. Le id DOIT pouvoir être représenté en utilisant la grammaire des jetons telle que spécifiée dans la [RFC3261]. Il DOIT être unique parmi tous les autres observateurs rapportés dans les documents envoyés en notification pour un abonnement d’informations d’observateur particulier.

état : C’est l’état de l’abonnement. La signification des divers états est définie dans le paquetage d’événement des informations d’observateur [RFC3857].

événement : C’est l’événement qui a causé la transition à l’état actuel. Les événements sont définis dans le paquetage d’événements des informations d’observateur [RFC3857].

Il y a aussi des attributs facultatifs, pour information, de l’élément watcher. Ce sont :

display-name (nom d’affichage) : représentation textuelle du nom du souscripteur.

expiration : la durée, en secondes à partir du temps présent, après laquelle la souscription va arriver à expiration.

duration-subscribed (durée souscrite) : durée, exprimée en secondes, entre l’heure à laquelle le SUBSCRIBE qui a créé la souscription a été reçue, et l’instant présent.

L’attribut xml:lang PEUT être utilisé avec l’élément "watcher" pour spécifier le langage du "nom d’affichage".

Le nombre d’observateurs présents pour chaque ressource, et l’ensemble des ressources énumérées, dépend du type de données fournies, et à qui elles le sont.

Par exemple, considérons un système de présence qui utilise des informations d’observateur. Dans un scénario, un usager A souscrit à la présence d’un autre usager, B. A aimerait trouver l’état de leur abonnement. Pour ce faire, A souscrit aux informations d’observateur pour la présence de B. A n’a pas l’autorisation d’apprendre l’état de tous les observateurs pour la présence de B. Il en résulte que les informations d’observateur envoyées à A vont seulement contenir un seul observateur - A lui-même.

Dans un autre scénario, un usager, B, souhaite connaître l’ensemble des gens qui ont souscrit à la présence de B. Pour ce faire, B souscrit aux informations d’observateur pour la présence de B. Ici, B est autorisé à voir tous les observateurs de la présence de B. Par suite, les informations d’observateur envoyées à B vont contenir tous les observateurs de la présence de B.

Dans le cas où un administrateur souhaite connaître l’état actuel dans le système, les informations d’observateur pourraient contenir tous les observateurs pour toutes les ressources.

4. Calcul des listes d’observateur à partir du document

Normalement, le NOTIFY watcherinfo va seulement contenir des informations sur les observateurs dont l’état a changé. Pour construire une vision cohérente de l’état total de tous les observateurs, un abonné à watcherinfo va avoir besoin de combiner les NOTIFY reçus au fil du temps. L’abonné watcherinfo tient un tableau pour chaque liste d’observateurs sur lesquels il reçoit des informations. Chaque liste d’observateurs est identifiée de façon univoque par l’URI dans l’attribut "resource" de l’élément "watcher-list". Chaque tableau contient une rangée pour chaque observateur de cette liste d’observateurs. Chaque rangée est indexée par l’identifiant univoque de cet observateur. Il est porté dans l’attribut "id" de l’élément "watcher". Le contenu de chaque rangée contient l’état de cet observateur tel que porté dans l’élément "watcher". Les tableaux sont aussi associés à un numéro de version. Le numéro de version DOIT être initialisé avec la valeur de l’attribut "version" provenant de l’élément "watcherinfo" dans le premier document reçu. Chaque fois qu’un nouveau document est reçu, la valeur du numéro de version local, et l’attribut "version" dans le nouveau document, sont comparés. Si la valeur dans le nouveau document est supérieure de un au numéro de version locale, le numéro de version locale est augmenté de un, et le document est traité. Si la valeur dans le document est supérieure de plus de un à celle du numéro de version locale, celui–ci est réglé à la valeur du nouveau document, le document est traité, et l’abonné watcherinfo DEVRAIT générer une demande de rafraîchissement pour déclancher une notification d’état complet. Si la valeur dans le document est inférieure à celle de la version locale, le document est éliminé sans traitement.

Le traitement du document watcherinfo dépend de si il contient un état complet ou partiel. Si il contient l’état complet, indiqué par la valeur de l’attribut "state" dans l’élément "watcherinfo", le contenu de tous les tableaux associés à cet abonnement watcherinfo est purgé. Ils sont remplis à partir du document. Un nouveau tableau est créé pour chaque élément "watcher-list", et une nouvelle rangée dans chaque tableau est créée pour chaque élément "watcher". Si le watcherinfo contient un état partiel, comme indiqué par la valeur de l’attribut "state" dans l’élément "watcherinfo", le document est utilisé pour mettre à jour les tableaux existants. Pour chaque élément "watcher-list", l’abonné watcherinfo vérifie pour voir si un tableau existe pour cette liste. Cette vérification est faite en comparant l’URI dans l’attribut "resource" de l’élément "watcher-list" avec l’URI associé au tableau. Si un tableau n'existe pas pour cette liste, il en est créé un. Pour chaque élément "watcher" dans la liste, l’abonné watcherinfo vérifie pour voir si une rangée existe pour cet observateur. Cette vérification est faite en comparant l’identifiant dans l’attribut "id" de l’élément "watcher" avec l’identifiant associé à la rangée. Si l’observateur n’existe pas dans le tableau, une rangée est ajoutée, et son état est réglé sur les informations provenant de cet élément "watcher". Si l’observateur existe, son état est mis à jour pour être l’information provenant de cet élément "watcher". Si une rangée est mise à jour ou créée, de telle sorte que son état soit maintenant terminé, cette entrée PEUT être supprimée du tableau à tout moment.

5. Exemple

Voici un exemple d’informations d’observateur pour une présentité, qui est un professeur. Il y a deux observateurs, l’usagerA et l’usagerB.

<?xml version="1.0"?>

<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"

version="0" state="full">

<watcher-list resource="sip:professeur@example.net" package="presence">

<watcher status="active"

id="8ajksjda7s"

duration-subscribed="509"

event="approved" >sip:usagerA@example.net</watcher>

<watcher status="pending"

id="hh8juja87s997-ass7"

display-name="Mr. Subscriber"

event="subscribe">sip:usagerB@example.org</watcher>

</watcher-list>

</watcherinfo>

6. Schéma XML

Ce qui suit est la définition schématique du format de document watcherinfo :

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:ietf:params:xml:ns:watcherinfo"

xmlns:tns="urn:ietf:params:xml:ns:watcherinfo" >

<!-- Cette importation apporte l’attribut de langage XML xml:lang-->

<xs:import namespace="http://www.w3.org/XML/1998/namespace"

schemaLocation="http://www.w3.org/2001/03/xml.xsd" />

<xs:element name="watcherinfo">

<xs:complexType>

<xs:sequence>

<xs:element ref="tns:watcher-list" minOccurs="0"

maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="version" type="xs:nonNegativeInteger"

use="required"/>

<xs:attribute name="state" use="required">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="full"/>

<xs:enumeration value="partial"/>

</xs:restriction>

</xs:simpleType>

</xs:attribute>

</xs:complexType>

</xs:element>

<xs:element name="watcher-list">

<xs:complexType>

<xs:sequence>

<xs:element ref="tns:watcher" minOccurs="0" maxOccurs=

"unbounded"/>

<xs:any namespace="##other" processContents="lax"

minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="resource" type="xs:anyURI" use="required"/>

<xs:attribute name="package" type="xs:string" use="required"/>

</xs:complexType>

</xs:element>

<xs:element name="watcher">

<xs:complexType>

<xs:simpleContent>

<xs:extension base="xs:anyURI">

<xs:attribute name="display-name" type="xs:string"/>

<xs:attribute name="status" use="required">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="pending"/>

<xs:enumeration value="active"/>

<xs:enumeration value="waiting"/>

<xs:enumeration value="terminated"/>

</xs:restriction>

</xs:simpleType>

</xs:attribute>

<xs:attribute name="event" use="required">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="subscribe"/>

<xs:enumeration value="approved"/>

<xs:enumeration value="deactivated"/>

<xs:enumeration value="probation"/>

<xs:enumeration value="rejected"/>

<xs:enumeration value="timeout"/>

<xs:enumeration value="giveup"/>

<xs:enumeration value="noresource"/>

</xs:restriction>

</xs:simpleType>

</xs:attribute>

<xs:attribute name="expiration" type="xs:unsignedLong"/>

<xs:attribute name="id" type="xs:string" use="required"/>

<xs:attribute name="duration-subscribed"

type="xs:unsignedLong"/>

<xs:attribute ref="xml:lang"/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

</xs:element>

</xs:schema>

7. Considérations pour la sécurité

Les informations d’observateur sont des informations sensibles. Le protocole utilisé pour les distribuer DEVRAIT assurer la confidentialité, l’intégrité du message, et l’authentification. De plus, le protocole devrait fournir des contrôles d’accès qui restreignent qui peut voir qui d’autre observe les informations.

8. Considérations relatives à l’IANA

Le présent document enregistre un nouveau type MIME, application/watcherinfo+xml, et enregistre un nouvel espace de noms XML.

8.1 Enregistrement MIME application/watcherinfo+xml

Nom du type de support MIME : application

Nom du sous type MIME : watcherinfo+xml

Paramètres obligatoires : aucun

Paramètres facultatifs : les mêmes que les paramètres de jeu de caractères 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 pour la sécurité : voir la Section 10 de la [RFC3023] et la Section 7 de la présente spécification.

Considérations d’interopérabilité : aucune.

Spécification publiée : le présent document.

Applications qui utilisent ce type de support : le présent type de document a été utilisé pour prendre en charge les fonctions d’autorisation de l’abonné pour la présence fondée sur SIP [RFC3856], [RFC3857].

Informations supplémentaires : Numéro magique : aucun.

Extension: de fichier .wif or .xml

Code de type de fichier Macintosh : "TEXT"

Adresse personnelle et de messagerie pour des informations : Jonathan Rosenberg, <jdrosen@jdrosen.net>

Utilisation prévue : COURANTE

Auteur/Contrôleur des changements : IETF.

8.2 Enregistrement de sous espace de noms d’URN pour urn:ietf:params:xml:ns:watcherinfo

Ce paragraphe enregistre un nouvel espace de noms XML, selon les lignes directrices de la [RFC3688].

URI : urn:ietf:params:xml:ns:watcherinfo.

Contact du déposant : IETF, groupe de travail SIMPLE, <simple@ietf.org>, Jonathan Rosenberg <jdrosen@jdrosen.net>.

XML:

DÉBUT

<?xml version="1.0"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"

"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta http-equiv="content-type"

content="text/html;charset=iso-8859-1"/>

<title>Watcher Information Namespace</title>

</head>

<body>

<h1>Namespace for Watcher Information</h1>

<h2>urn:ietf:params:xml:ns:watcherinfo</h2>

<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc3858.txt">

RFC3858</a>.</p>

</body>

</html>

FIN

9. Références normatives

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

[RFC2141] R. Moats, "Syntaxe des URN", mai 1997.

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

[RFC3261] J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC6665) )

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

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

[RFC3857] J. Rosenberg, "Paquetage-gabarit d'événement d'information d'observateur pour le protocole d'initialisation de session (SIP)", août 2004. (P.S.)

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

[XML] T. Bray, J. Paoli, and C. M. Sperberg-McQueen, "Extensible Markup language (XML) 1.0 (second edition)", Recommandation W3C REC-xml-20001006, World Wide Web Consortium (W3C), Oct. 2000. Disponible à http://www.w3.org/XML/ .

10. Références pour information

[RFC2778] M. Day, J. Rosenberg et H. Sugano, "Modèle pour Presence et la messagerie instantanée", février 2000.

11. Remerciements

L’auteur tient à remercier Sean Olson, Steve Donovan, et Cullen Jennings de leurs commentaires détaillés et de leur assistance pour le schéma XML.

12. Contributeurs

Les personnes suivantes faisaient partie de l’équipe de conception originale qui a développé la première version de la présente spécification:

Jonathan Lennox a contribué au texte pour le DTD et son usage qui faisait partie de versions précédentes de la présente spécification.

13. Adresse de l’auteur

Jonathan Rosenberg

dynamicsoft

600 Lanidex Plaza

Parsippany, NJ 07054

USA

mél : jdrosen@dynamicsoft.com

14. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004)

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

Le présent document et les informations qui y sont contenues sont fournies 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, l’IETF TRUST 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 ci encloses ne violent 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 pourraient ê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 actuellement assuré par la Internet Society.