Groupe de travail Réseau

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Au moment de la rédaction de ce document, de nombreux protocoles de détection de présence étaient en usage (dans une grande mesure comme composants de services commerciaux de messagerie instantanée) et peu d'interopérabilité avait été réalisée entre les services sur la base de ces protocoles. La présente spécification définit une sémantique et des formats de données communs pour la détection de présence pour faciliter la création de passerelles entre les services de détection de présence.

Table des Matières

1. Introduction 1

2. Terminologie 2

3. Service de présence abstrait 2

3.1 Généralités sur le service de présence 2

3.2 Identification de PRÉSENTITÉ et de OBSERVATEUR 4

3.3 Format des informations de présence 4

3.4 Service Presence 4

4. Considérations pour la sécurité 5

5. Considérations pour l'IANA 6

6. Contributeurs 6

7. Références 6

7.1 Références normatives 6

7.2 Références pour information 6

Appendice A Gabarit d’enregistrement de l’URI PRES auprès de l’IANA 6

A.1 Nom du schéma d’URI 7

A.2 Syntaxe du schéma d’URI 7

A.3 Considérations de codage des caractères 7

A.4 Utilisation prévue 7

A.5 Applications et/ou protocoles qui utilisent ce nom de schéma d’URI 7

A.6 Considérations d’interopérabilité 7

A.7 Considérations de sécurité 7

A.8 Publications pertinentes 7

A.9 Adresse personnelle et de messagerie à contacter pour des informations complémentaires 7

A.10 Auteur/contrôleur de changements 7

A.11 Applications et/ou protocoles qui utilisent ce nom de schéma d’URI Scheme Name 7

Appendice B Questions intéressantes 8

B.1 Transposition d'adresse 8

B.2 Transposition de route de source 8

Appendice C. Remerciements 8

Presence est défini dans la [RFC2778]. Au moment de la rédaction du présent document, de nombreux protocoles de présence sont utilisés (dans une grande mesure, comme composants de services commerciaux de messagerie instantanée), et peu d'interopérabilité a été réalisée entre les services fondés sur ces protocoles. La présente spécification définit une sémantique et des formats de données pour des services communs de présence pour faciliter la création de passerelles entre les services de présence : un profil commun pour présence (CPP).

Le comportement du service est décrit de façon abstraite en termes d'opérations invoquées entre l'usager et le fournisseur du service. En conséquence, chaque service de présence doit spécifier comment ce comportement est transposé en ses propres interactions de protocole. Le choix d'une stratégie est une affaire locale, pourvu qu'il y ait une relation claire entre les comportements abstraits du service (comme les spécifie le présent mémoire) et la façon dont il est réalisé par un service de présence particulier. Par exemple, une stratégie pourrait transmettre les informations de présence comme des paires de clés/valeurs, un autre pourrait utiliser une représentation binaire compacte, et une troisième pourrait utiliser des conteneurs incorporés.

Les paramètres pour chaque opération sont définis en utilisant une syntaxe abstraite. Bien que la syntaxe spécifie la gamme de valeurs possibles des données, chaque service de présence doit spécifier comment des instances bien formées de la représentation abstraite sont codées en une série de bits concrète.

Afin de fournir un moyen de préserver les caractéristiques de bout en bout (en particulier de sécurité) pour passer à travers les passerelles d'interfonctionnement de présence, la présente spécification fournit aussi des recommandations pour les formats des documents de présence qui pourraient être employés par les protocoles de présence.

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

Le présent mémoire utilise le vocabulaire défini dans la [RFC2778]. Les termes tels que CLOS, BOITE AUX LETTRES INSTANTANÉE, PRESENCE, et OUVERT sont utilisés avec la même signification que celle qui y est définie.

Le terme de 'passerelle' utilisé dans le présent document note un élément de réseau chargé de l’inter fonctionnement entre divers protocoles de présence. Bien que les protocoles de présence soient eux-mêmes divers, sous le modèle du présent document, ces protocoles peuvent porter une charge utile commune qui est relayée par la passerelle. On peut donc débattre de la question de savoir si ces intermédiaires d’inter fonctionnement devraient être appelés des 'passerelles' ou des 'relais' ; pour les besoins du présent document, on les appelle 'passerelles CPP'.

Le terme de 'service de présence' dérive aussi de la RFC2778, mais sa signification change légèrement à cause de l’existence de passerelles dans le modèle CPP. Lorsque un client envoie une opération à un service de présence, ce service peut soit être un point d’extrémité, soit un intermédiaire tel qu’une passerelle CPP – en fait, le client ne devrait pas avoir à connaître auquel il s’adresse, car les réponses de l’un ou l’autre vont paraître les mêmes.

Le présent document définit des opérations et des attributs d’un protocole de présence abstrait. Afin qu’un protocole conforme s’interface avec une passerelle de présence, il doit prendre en charge toutes les opérations décrites dans le présent document (c’est-à-dire que le protocole de présence doit avoir un message ou capacité qui fournit la fonction décrite par toutes les opérations concernées). De même, les attributs définis pour ces opérations doivent correspondre aux informations disponibles dans le protocole de présence afin que le protocole s’interface avec les passerelles définies par la présente spécification. Noter que ces attributs ne fournissent que le minimum d’informations possibles qui ont besoin d’être spécifiées pour l’interopérabilité – dans un protocole de présence, les fonctions qui correspondent aux opérations décrites dans le présent document peuvent contenir des informations supplémentaires qui ne seront pas transposées par CPP.

Lorsque une application veut souscrire aux informations de présence associées à une PRÉSENTITÉ (afin de recevoir les notifications périodiques d’informations de présence) elle invoque l’opération subscribe, par exemple,

L’opération subscribe a les attributs suivants : observateur, cible, durée, SubscriptID et TransID. Les attributs 'observateur' et 'cible' identifient respectivement OBSERVATEUR et PRÉSENTITÉ, en utilisant les identifiants décrits au paragraphe 3.2. L’attribut durée spécifie le nombre maximum de secondes pendant lequel la SOUSCRIPTION devrait être active (qui peut être zéro, auquel cas c’est une demande à usage unique pour les informations de présence). L’attribut SubscriptID crée une référence à la SOUSCRIPTION qui est utilisée lors du désabonnement. L’attribut TransID est un identifiant unique utilisé pour corréler l’opération subscribe avec une opération de réponse. Les passerelles devraient être capables de traiter les TransID et les SubscriptID jusqu’à 40 octets de long.

À réception d’une opération subscribe, le service répond immédiatement en invoquant l’opération de réponse qui contient le même TransID, par exemple,

L’opération de réponse a les attributs suivants :état, TransID, et durée. L’attribut 'état' indique si l’opération subscribe a réussi ou échoué. L’attribut TransID de l’opération de réponse correspond au TransID de l’opération subscription à laquelle il répond. L’attribut 'durée' spécifie le nombre de secondes pendant lequel la souscription sera active (qui peut différer de la valeur demandée dans l’opération subscribe).

Si l’opération de réponse indique le succès, le service invoque immédiatement l’opération notifie pour communiquer les informations de présence à l’OBSERVATEUR, par exemple,

L’opération notifie a les attributs suivants : observateur, cible, et TransID. Les valeurs de 'observateur' et de 'cible' sont identiques à celles données dans l’opération subscribe qui déclanchent cette opération notifie. L’attribut TransID est un identifiant unique pour cette notification.

L’opération notifie a aussi un contenu, à savoir PRESENCE INFORMATION. Les détails du contenu sont spécifiés au paragraphe 3.3.

Si le paramètre durée est différent de zéro, alors pour jusqu’à la durée spécifiée, le service invoque l’opération notifie chaque fois qu’il y a un changement dans les informations de présence de la PRÉSENTITÉ. Autrement, exactement une opération notifie est invoquée, réalisant une interrogation à usage unique des informations de présence. Néanmoins, il n’y a pas de réponse de l’application à l’opération notifie (c’est-à-dire, l’application n’invoque pas une opération de réponse lorsque une opération notifie survient) définie dans CPP.

L’application peut annuler prématurément une souscription en invoquant à nouveau l’opération subscribe (comme décrit ci-dessus) avec une durée de 0 et le même SubscriptID que dans l’opération subscribe d’origine, par exemple,

Noter qu’une opération notifie sera invoquée lorsque une souscription est annulée prématurément de cette façon ; cette notification peut être annulée par l’observateur.

Le service répond immédiatement en invoquant l’opération de réponse contenant le même TransID ; par exemple,

Noter que la présente spécification suppose que les protocoles de présence conformes à CPP fournissent une livraison fiable de messages ; il n’y a pas de dispositions d’assurance de livraison de message de couche application dans la présente spécification.

Une PRÉSENTITÉ est spécifiée en utilisant le schéma d’URI PRES, qui est décrit plus en détails dans l’Appendice A. Un exemple serait : "pres:fred@exemple.com"

Un OBSERVATEUR s’identifie lui-même de la même manière qu’une PRÉSENTITÉ ; c’est-à-dire, avec un URI pres.

Un client de service de présence détermine le prochain bond pour transmettre une opération en résolvant la portion de nom de domaine de la destination du service. Les mises en œuvre conformes DEVRAIENT suivre les lignes directrices pour le déréférencement des URI données dans la [RFC3861].

La présente spécification définit un mécanisme abstrait d’interopérabilité pour les protocoles de présence; la définition du contenu de message donnée ici relève de la sémantique plutôt que de la syntaxe. Cependant, certaines propriétés importantes pour l’interopérabilité ne peuvent être fournies que si un format commun de bout en bout pour la présence est employé par les protocoles de présence qui interopèrent, en particulier par rapport à la sécurité. Afin de conserver les propriétés de sécurité de bout en bout, les applications qui envoient des opérations de notification à travers une passerelle CPP DOIVENT prendre en charge le format défini dans PIDF [RFC3863]. Les applications PEUVENT prendre en charge d’autres formats de contenu.

Les passerelles CPP DOIVENT être capables de relayer le corps d’une opération de notification entre les protocoles de présence pris en charge sans avoir besoin de modifier ou inspecter le contenu.

Une mise en œuvre du service doit conserver les informations à la fois sur la présence et sur les opérations continuelles (comme les notifications périodiques) dans une mémorisation persistante.

Noter que l’attribut abonnement-identifiant utilisé par l’opération subscribe (s’abonner) est potentiellement de longue durée. En conséquence, les valeurs générées pour ce paramètre devraient être uniques sur une durée significative. Le paramètre SubscriptID devrait être intrinsèquement unique au monde dans la durée, et pas simplement unique parmi les opérations envoyée de ou vers un OBSERVATEUR et PRÉSENTITÉ particulier.

Lorsque une application veut s’abonner aux informations de présence associées à une PRÉSENTITÉ, elle invoque l’opération subscribe.

Lorsque le service est informé de l’opération subscribe, il effectue les étapes suivantes :

1. Si le paramètre observateur ou cible ne se réfère pas à une PRÉSENTITÉ valide, une opération de réponse ayant l’état de "échec" est invoquée.

2. Si le contrôle d’accès ne permet pas à l’application de demander cette opération, une opération de réponse ayant l’état de "échec" est invoquée.

3. Si le paramètre durée est différent de zéro, et si les paramètres observateur et cible se réfèrent à une opération subscribe en cours pour l’application, une opération de réponse ayant l’état de "échec" est invoquée.

Une opération réponse ayant l’état de "succès" est immédiatement invoquée. (Si le service choisit une durée différente pour l’abonnement, elle transporte alors cette information dans l’opération de réponse.)

Une opération notifie , correspondant aux informations de présence de la cible est immédiatement invoquée pour l(observateur.

Pour jusqu’à la quantité de temps indiquée par le paramètre durée de l’opération notifie (mesurée à partir du moment où l’opération d’abonnement a été reçue) et les informations de présence de la cible changent, et si le contrôle d’accès le permet, une opération notifie est invoquée pour l’observateur.

Noter que si le paramètre durée a la valeur zéro, l’opération d’abonnement fait alors une interrogation à usage unique des informations de présence. En conséquence, la dernière étape ci-dessus (notifications continuelles pour la durée de l’abonnement) ne se fait pas.

Lorsque le service invoque une opération de réponse par suite de ce traitement, le paramètre transID est identique à la valeur qui se trouve dans l’opération d’abonnement invoquée par l’application.

Le service invoque l’opération notifie chaque fois que changent les opérations de présence associées à une PRÉSENTITÉ et qu’il y a des abonnés qui demandent des notifications pour cette PRÉSENTITÉ.

Lorsque une application veut terminer un abonnement, elle produit un SUBSCRIBE 0 avec le SubscriptID d’un abonnement existant. Noter qu’une opération notifie sera invoquée par la présentité lorsque un abonnement est annulé de cette façon ; cette notification peut être supprimée par l’observateur. Il n’y a pas d’opération UNSUBSCRIBE indépendante.

Lorsque une application veut demander directement que des informations de présence soient fournies immédiatement sans initier d’abonnement persistant, elle produit un SUBSCRIBE 0 avec un nouveau SubscriptID. Il n’y a pas d’opération FETCH (aller chercher) indépendante.

Les considérations détaillées de sécurité pour les protocoles de présence sont données dans la [RFC2779] (en particulier, les exigences figurent dans les paragraphes 5.1 à 5.3 avec un exposé des motivations en 8.2).

CPP définit une fonction d’interopérabilité qui est employée par les passerelles entre les protocoles de présence. Les passerelles CPP DOIVENT se conformer aux exigences minimum de sécurité des protocoles de présence avec lesquels elles s’interfacent.

L’introduction de passerelles au modèle de sécurité de présence dans la RFC2779 introduit aussi de nouveaux risques. Les propriétés de sécurité de bout en bout (en particulier la confidentialité et l’intégrité) entre les présentités et les observateurs qui s’interfacent à travers une passerelle CPP ne peuvent être fournies que si un format de présence commun (tel que celui décrit dans la [RFC3863]) est pris en charge par les protocoles qui s’interfacent avec la passerelle CPP.

Lorsque la sécurité de bout en bout est exigée, l’opération notifie DOIT utiliser PIDF, et DOIT sécuriser le corps MIME PIDF avec S/MIME [RFC3851], avec le chiffrement (CMS EnvelopeData) et/ou des signatures S/MIME (CMS SignedData).

Les algorithmes S/MIME sont établis par CMS [RFC3852]. L’algorithme AES [RFC3565] devrait être préféré, car on pense qu’il convient le mieux aux capacités de nombreuses plateformes. Les mises en œuvre PEUVENT utiliser AES comme algorithme de chiffrement, mais il est EXIGÉ qu’elle prennent seulement en charge les algorithmes de base rendus obligatoires par S/MIME et CMS.

Lorsque des URI PRES sont utilisés dans les protocoles de présence, ils transportent l’identité des observateurs et/ou des présentités. Les certificats qui sont utilisés pour les opérations de présence S/MIME DEVRAIENT, pour les besoins de l’intégrité de référence, contenir un champ subjectAltName contenant l’URI PRES de leur sujet. Noter que de tels certificats peuvent aussi contenir d’autres identifiants, y compris ceux qui sont spécifiques de protocoles de présence particuliers. Pour faciliter encore l’interopérabilité des services de présence sécurisés à travers les passerelles CPP, les usagers et les fournisseurs de services sont invités à employer pour les certificats des ancres de confiance largement acceptées plutôt que des ancres de confiance spécifiques d’un service de présence ou fournisseur particulier.

Dans certains cas, des services de présence anonymes peuvent être souhaités. Une telle facilité sort du domaine d’application de la présente spécification.

Le schéma d'URI Presence (PRES) désigne une ressource Internet, à savoir PRESENTITY ou WATCHER.

Les personnes suivantes ont apporté des textes de contributions substantiels à ce document :

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

[RFC2396] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", août 1998. (Obsolète, voir RFC3986)

[RFC2846] C. Allocchio, "Extensions d'élément d'adresse GSTN dans les services de messagerie électronique", juin 2000. (MàJ par RFC3191, RFC3192) (P.S.)

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

[RFC3852] R. Housley, "Syntaxe de message cryptographique (CMS)", juillet 2004. (Remplacée par la RFC5652)

Cette section donne les informations pour enregistrer l’URI de présence pres:.

La syntaxe suit celle qui existe pour l’URI mailto: spécifiée dans la RFC2368. L’ABNF est :

Ici, le symbole "boîte-aux-lettres" représente un nom codé de boîte-aux-lettres comme défini dans la [RFC2822], et le symbole "uric" note tout caractère valide dans un URL (défini dans la [RFC2396]).

La représentation de jeux de caractères non ASCII dans les chaîne de partie locale est limitée aux méthodes standard fournies comme extensions à la [RFC2822].

L’utilisation de l’URI pres: suit de près celle de l’URI mailto:. C’est-à-dire que l’invocation d’un URI PRES va causer le lancement de l’application de messagerie instantanée de l’utilisateur, avec l’adresse de destination et les en-têtes de message remplis conformément aux informations fournies dans l’URI.

Il est prévu que les protocoles conformes à la RFC2779, et qui satisfont aux exigences d’interopérabilité spécifiées ici, utiliseront ce nom de schéma d’URI.

Le protocole d’échange sous-jacent utilisé pour envoyer un message instantané peut varier d’un service à l’autre. Donc l’interopérabité complète, à l’échelle de l’Internet, ne peut être garantie. Cependant, un service conforme à la présente spécification permet aux passerelles de réaliser une interopérabilité suffisante pour les exigences de la RFC2779.

A.9 Adresse personnelle et de messagerie à contacter pour des informations complémentaires

Ce schéma est enregistré dans l’arborescence de l’IETF. À ce titre, l’IETF assure le contrôle des changements.

A.11 Applications et/ou protocoles qui utilisent ce nom de schéma d’URI Scheme Name

Le présent appendice expose brièvement des questions qui peuvent être intéressantes lors de la conception d'une passerelle d'inter fonctionnement.

Lors de la transposition du service décrit dans le présent mémoire, les transpositions qui placent des informations spéciales dans la partie locale im: address DOIVENT utiliser la métasyntaxe définie dans la [RFC2846].

La technique de transposition la plus facile est une forme d'acheminement de source qui est habituellement la moins familière aux humains qui doivent entrer la chaîne au clavier. L'acheminement de source a aussi une longue histoire de problèmes de fonctionnement.

L'utilisation de l'acheminement de source pour les échanges entre différents services se fait par une transformation qui place la chaîne entière d'adresse d'origine dans la partie locale im: address et désigne la passerelle dans la partie domaine.

Par exemple, si la destination INSTANT INBOX est "pepp://example.com/fred", alors, après avoir effectué les conversions de caractères nécessaires, la transposition résultante est :

L'expérience montre qu'il est largement préférable de cacher – si possible – cette transposition aux utilisateurs finaux, le logiciel sous-jacent devrait effectuer automatiquement la transposition.

L'auteur tient à remercier John Ramsdell de ses commentaires, de ses suggestions et de son enthousiasme. Merci à Derek Atkins pour ses corrections rédactionnelles.

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 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, le 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.

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.

Le financement de la fonction d'édition des RFC est actuellement assuré par la Internet Society.

Groupe de travail Réseau	J. Peterson, NeuStar
Request for Comments 3859	août 2004
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle