Network Working Group J

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.

Présence et la messagerie instantanée sont définis dans la RFC2778. Le profil commun pour Présence et la messagerie instantanée définit deux schémas d’identifiant de ressource universel (URI, Universal Resource Identifier) : 'im' pour BOITE AUX LETTRES INSTANTANÉE et 'pres' pour PRÉSENTITÉ. Le présent document donne des lignes directrices pour localiser les ressources associées à des URI qui emploient ces schémas.

Table des Matières

1. Introduction 1

2. Terminologie 2

3. Résolution d’adresse 2

4. Recherche de nom de domaine 2

5. Traitement des RR SRV 3

6. Traitement d’adresses multiples 3

7. Considérations pour la sécurité 3

8. Considérations relatives à l’IANA 3

9. Contributeurs 4

10. Références normatives 4

11. Adresse de l’auteur 4

12. Déclaration complète de droits de reproduction 4

Présence et messagerie instantanée sont définies dans la [RFC2778]. Les profils communs pour Présence (CPP, Common Profile for Presence) [RFC3859] et pour la messagerie instantanée (CPIM, Common Profile for Instant Messaging) [RFC3860] définissent deux schémas d’identifiant de ressource universel (URI) : 'im' pour BOITE AUX LETTRES INSTANTANÉE et 'pres' pour PRÉSENTITÉ. Le présent document donne des règles pour localiser les ressources associées aux URI qui emploient ces schémas via le service des noms de domaine (DNS, Domain Name Service) [RFC1034]. Ces règles pourraient sans doute être appliquées à la résolution d’autres schémas d’URI qui sont sans relation avec la messagerie instantanée et présence.

CPIM et CPP spécifient tous deux des opérations qui ont des attributs de 'source' et de 'destination'. Alors que seule la sémantique, et non la syntaxe, de ces attributs est définie par CPIM et CPP, de nombreux protocoles de messagerie instantanée et présence prennent aujourd’hui en charge l’utilisation des URI pour refléter la source et la destination de leurs opérations. Les schémas d’URI 'im' et 'pres' permettent à de tels protocoles d’exprimer les identités des principaux associés à un échange de protocole. Lorsque ces opérations passent à travers une passerelle de CPIM ou CPP, ces URI pourraient être relayés sans modification, ce qui a un certain nombre de propriétés souhaitables pour les besoins de l’interopérabilité.

Ces schémas d’URI sont aussi utiles dans les cas où il n’y a pas de passage par une passerelle CPIM/CPP. Si le point d’extrémité d’un principal particulier prend, par exemple, en charge plusieurs applications de messagerie instantanée, un domaine qui identifie cet hôte pourrait alors utiliser le tri des enregistrements DNS décrit dans le présent document pour assurer une plus grande compatibilité avec les clients qui prennent en charge seulement un protocole de messagerie instantanée. Un client chercherait l’enregistrement correspondant au protocole pris en charge, et apprendrait comment contacter le point d’extrémité pour ce protocole. Le principal dans cette instance utiliserait un URI IM comme adresse canonique.

Dans certaines architectures, ces URI pourraient aussi être utilisés pour localiser une passerelle CPIM ou CPP qui dessert un domaine particulier. Si un fournisseur de service IM particulier souhaite faire fonctionner dans son propre domaine des passerelles CPIM/CPP qui transposent les protocoles standard Internet en un protocole propriétaire interne, cette passerelle pourrait être identifiée par un URI IM. Dans ce cas, l’enregistrement DNS utilisé pour déréférencer l’URI IM servirait à un objet similaire à celui des enregistrements d’échange de messagerie (MX, Mail Exchange).

Le système décrit dans le présent document s’appuie sur l’utilisation des enregistrement de service du DNS (SRV) [RFC2782] et des enregistrements d’adresse (A).

Dans ce document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "NON RECOMMANDÉ", "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 mémoire utilise le vocabulaire défini dans la [RFC2778]. Les termes tels que CLOS, BOITE AUX LETTRES INSTANTANÉE, MESSAGE INSTANTANÉ, et OUVERT sont utilisés avec la même signification.

Un client détermine l’adresse d’un système approprié qui fait fonctionner un serveur, au nom du système référencé par le domaine, en résolvant le nom du domaine de destination qui fait partie de l’identifiant soit à un système relais intermédiaire, soit à un système cible final.

Seuls les noms de domaine résolubles pleinement qualifiés (FQDN, fully qualified domain name) sont permis lorsque des noms de domaine sont utilisés dans un URI des messagerie instantanée (IM, Instant Messaging) (c’est-à-dire les noms de domaine qui peuvent être résolus en enregistrement de ressource (RR, Resource Record) SRV [RFC2782] ou A).

Le nom symbolique utilisé dans le champ Service de l’enregistrement SRV est "_im" pour la messagerie instantanée et "_pres" pour présence (correspondant à leurs schémas d’URI respectifs). Cependant, l’annonce de ces services dans le DNS est incomplète si elle ne comporte pas le protocole qui sera utilisé pour instancier l’opération de messagerie instantanée ou de présence. Donc, le champ Protocole de l’enregistrement SRV contient une étiquette enregistrée par l’IANA qui correspond au protocole sous-jacent de messagerie instantanée ou de présence qui est annoncé (voir à la Section 8 d’autres informations sur les champs de protocole valides).

En prenant l’URI IM comme exemple concret, une recherche est effectuée pour les SRV pour le domaine cible, un service désiré (en utilisant l’étiquette de service "_im") et un protocole de transfert IM désiré. Si la BOÎTE AUX LETTRES INSTANTANÉE de destination est "im:fred@example.com", et si l’envoyeur souhaite utiliser un protocole de transfert IM appelé "BIP" (et en supposant que "_bip" a été enregistré auprès de l’IANA comme étiquette de protocole valide pour le service IM) une recherche de SRV est alors effectuée pour :

La même procédure est utilisée pour les URI PRES, avec l’étiquette de service "_pres".

Certains clients peuvent prendre en charge plusieurs protocoles de messagerie instantanée ou de présence ; dans ce cas, ils peuvent faire plusieurs interrogations de SRV, dans un ordre spécifique de l’application, jusqu’à ce qu’ils en trouvent un qui est pris en charge en commun par le domaine cible.

Une fois qu’un client a identifié lexicalement un domaine auquel les opérations de messagerie instantanée ou de présence seront livrées pour traitement, une recherche DNS DOIT être effectuée pour résoudre le domaine. Les noms DOIVENT être des noms de domaine pleinement qualifiés (FQDN) – les mécanismes pour déduire les FQDN de noms partiels ou d’alias locaux sont une affaire locale.

La recherche tente d’abord de localiser les RR SRV associés au domaine. Si un RR de nom canonique (CNAME) est trouvé à la place, le domaine résultant est traité comme si il était le domaine initial.

Si un ou plusieurs RR SRV sont trouvés pour un certain domaine, un envoyeur NE DOIT PAS utiliser un RR A associé à ce domaine sauf si il est localisé en utilisant le RR SRV. Si on ne trouve pas de RR SRV, mais si on trouve un RR A, alors ce RR A est traité comme si il était associé à un RR SRV implicite, avec une préférence de 0, pointant sur ce domaine.

Les RR DNS retournés, si il y en a, spécifient le serveur de prochain bond, qui peut être une passerelle de protocole ou un point d’extrémité.

Les systèmes receveurs qui sont enregistrés pour ce service de résolution de SRV fondé sur le DNS font la liste des protocoles de transfert par lesquels ils peuvent être atteints, soit directement, soit à travers une passerelle de traduction (en utilisant des combinaisons d’étiquettes de service et de protocole, comme décrit ci-dessus). Le choix de l’instant de transfert du protocole de transfert IM à utiliser (et donc, à résoudre) est une option de configuration locale pour chaque système envoyeur.

En utilisant ce mécanisme, un acheminement sans à-coups du trafic IM est possible, sans considération de la nécessité d’une passerelle pour l’inter fonctionnement. Pour réaliser cette transparence, un RR distinct doit être, pour une passerelle, présent pour chaque paire protocole de transfert/domaine qu’elle dessert.

Lorsque la recherche réussit, la transposition peut résulter en une liste d’adresses de livraison de remplacement plutôt qu’en une seule adresse, à cause des enregistrements multiples de SRV. Pour un fonctionnement fiable, le client DOIT être capable d’essayer dans l’ordre chacune des adresses pertinentes de la liste, jusqu’à ce que réussisse une tentative de livraison. Cependant, il PEUT aussi y avoir une limite configurable au nombre d’adresses de remplacement qui peuvent être essayées. Dans tous les cas, le client DEVRAIT essayer au moins deux adresses.

Les résolveurs doivent suivre les procédures standard de la [RFC2782] pour le traitement des champs de priorité et de pondération dans les enregistrements SRV.

Dans le présent document, l’usage des URI IM et PRES, et les procédures du DNS, n’introduisent pas de considérations de sécurité au delà de celles décrites dans les exigences pour la messagerie instantanée et présence ([RFC2779]) et dans la spécification de SRV ([RFC2782]).

Les enregistrements ultérieurs d’étiquettes de protocole à utiliser avec les étiquettes de service "_im" ou "_pres" DOIVENT cependant expliquer toutes les considérations de sécurité qui surviennent suite à l’utilisation du protocole en question avec SRV.

Le présent document réserve l’utilisation des étiquettes de service "_im" et "_pres". Comme elles se rapportent à un service qui peut passer des messages sur un certain nombre de transports de message différents, elles doivent être associées à un service spécifique de messagerie instantanée ou de présence.

Afin d’assurer que l’association entre "_im" et "_pres" et leurs services sous-jacents respectifs est déterministe, l’IANA a créé deux registres indépendants : le registre des étiquettes de protocole SRV de messagerie instantanée et le registre des étiquettes de protocoles de présence. Pour chaque registre, une entrée devra consister en un nom d’étiquette et un pointeur sur une spécification décrivant comment le protocole désigné dans l’étiquette utilise SRV. Les spécifications devraient se conformer aux exigences énumérées dans la [RFC2434] pour "spécification requise".

Les étiquettes de protocole conformes à la présente spécification DOIVENT commencer par le caractère tiré bas "_" et suivre toutes les autres règles pour les étiquettes de protocole SRV décrites dans la [RFC2782].

Dave Crocker a été l’éditeur des versions antérieures du présent document.

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

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[RFC2782] A. Gulbrandsen, P. Vixie et L. Esibov, "RR DNS pour la spécification de la localisation des services (DNS SRV)", février 2000.

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

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

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