Groupe de travail Réseau	H. Schulzrinne, Columbia U.
Request for Comments : 3994
Catégorie : Normes
Janvier 2005	Traduction Claude Brière de L'Isle

Indication de la composition du message pour l’échange de messages instantané

Statut du présent Mémo

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restrictions.

Déclaration de copyright

Résumé

Dans les systèmes d’échange de messages instantané (IM, instant messaging), il est utile de savoir pendant une conversation IM si l’autre partie est en train de composer un message ; par exemple, en dactylographiant ou en enregistrant un message audio. Le présent document définit un nouveau type de contenu de message d’état et l’espace de nom XML qui porte les informations sur un message en cours de composition. Le message d’état peut indiquer la composition d’un message de tout type, y compris texte, voix, ou vidéo. Les messages d’état sont livrés au récepteur d’échange de message instantané de la même façon que les messages instantanés eux-mêmes.

Table des matières

1 Introduction

Par définition, l’échange de messages instantané (IM) est fondé sur le message : un utilisateur compose un message, par exemple, en le dactylographiant, en parlant, ou en enregistrant un clip vidéo. Ce message est alors envoyé à un ou plusieurs destinataires. A la différence de la messagerie électronique, l’échange de messages instantané est souvent conversationnel, et l’autre partie attend donc une réponse. Si aucune réponse n’arrive, un participant à une conversation d’échange de messages instantané peut être amené à penser que le partenaire de la communication a abandonné ou que c’est à son tour d’écrire à nouveau, conduisant à ce que deux messages "se croisent en l’air".

Pour éviter cette incertitude, un certain nombre de systèmes commerciaux d’échange de messages instantané mettent en œuvre une indication "is-typing" (frappe en cours) qui est envoyée dès qu’une des parties commence à dactylographier un message. Dans le présent document, on décrit une version généralisée de cette indication, appelée le message d’état isComposing (composition en cours). Comme décrit plus en détail à la Section 3, un message d’état est livré au récepteur d’échange de messages instantané de la même façon que le sont les messages eux-mêmes. Le message d’état isComposing peut annoncer la composition de tout type de support, et pas seulement du texte. Par exemple, il pourrait être utilisé si quelqu’un est en train d’enregistrer un clip audio ou vidéo. De plus, il peut être élargi pour convoyer à l’avenir d’autres états d’utilisateur d’échange de messages instantané. Ci-dessous, pour faire bref, nous appelons ces messages "messages d’état" (status messages).

Les messages d’état sont transportés en XML, comme instances du schéma XML défini à la Section 6, et étiquetés comme un type de contenu application/im-iscomposing+xml.

Ces messages d’état peuvent être considérés comme quelque peu analogues aux paquets de bruit de confort qui sont transmis dans les conversations vocales interactives avec suppression du silence.

Les événements et extensions à la présence, tels que PIDF [6], ont aussi été considérés mais ils ont trop d’inconvénients. Ils ajoutent plus de redondance, car une souscription explicite et périodique est nécessaire. Pour la livraison en mode page, il peut n’être pas facile de faire la souscription au bon agent d’utilisateur et au bon ensemble de messages. Un mécanisme dans la bande, fondé sur le message, est aussi plus facile à traduire entre des systèmes hétérogènes d’échange de messages instantané.

Le mécanisme décrit ici vise à satisfaire les prescriptions du document [7].

2 Terminologie et conventions

Le présent mémo utilise le vocabulaire défini dans le document modèle IMPP [1]. Dans le présent mémo, des termes tels que CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, et WATCHER USER AGENT sont utilisés avec la même signification que ce qui y est défini. Les mots clé DOIT, NE DOIT PAS, EXIGE, DEVRAIT, NE DEVRAIT PAS, RECOMMENDE, PEUT, et FACULTATIF dans le présent document sont à interpréter comme décrit au BCP 14, RFC 2119 [2].

Le présent document traite de deux sortes de message ; à savoir le message instantané (IM) qui convoie le contenu réel entre deux ou plus usagers engagés dans une conversation d’échange de messages instantané et le message d’état, décrit dans le présent document, qui indique l’état de composition en cours aux autres participants d’une conversation. On utilise les termes "message de contenu" et "message d’état" pour ces deux types de message.

3 Description

3.1 Généralités

On modélise l’utilisateur d’un système d’échange de messages instantané comme étant dans un état parmi plusieurs, limités dans le présent document à "inactif" et "actif". Par défaut, l’utilisateur est dans l’état "inactif", avant de commencer à composer un message aussi bien qu’après l’avoir envoyé.

3.2 Comportement du composeur de message

Seul l’agent d’utilisateur d’échange de message instantané qui compose activement un message de contenu génère des messages d’état qui indiquent l’état en cours. Lorsque l’usager commence à composer un message de contenu (le message instantané réel), l’état devient "actif", et un message d’état isComposing contenant un élément <état> indiquant "actif" est envoyé au récepteur du message de contenu en cours de composition. Tant que l’usager continue de produire le contenu du message instantané, l’usager reste dans l’état "actif".

Il y a deux temporisateurs d’envoi : celui d’intervalle de rafraîchissement d’état actif, et celui d’intervalle de fin de temporisation d’inactivité.

L’intervalle de rafraîchissement d’état actif détermine la fréquence d’envoi de messages d’état "actif" lorsque le composeur reste dans l’état "actif". L’intervalle est choisi par l’usager qui compose et qui est indiqué dans l’élément <refresh> du message d’état, exprimé en durées entières du temporisateur. L’intervalle DEVRAIT n’être pas inférieur à 60 secondes. Un composeur de message PEUT décider de ne pas envoyer de messages de rafraîchissement d’état actif du tout. Cela est indiqué en omettant l’intervalle de rafraîchissement ; le récepteur supposera alors qu’il est devenu inactif après 120 secondes. (Dans la plupart des cas, le message de contenu aura été envoyé avant.) Aucun message de rafraîchissement n’est envoyé dans l’état "inactif".

Le mécanisme de rafraîchissement d’état actif traite le cas dans lequel l’usager se déconnecte ou où l’application a une défaillance avant que le message de contenu ne soit terminé.

Si l’utilisateur arrête de composer pendant plus longtemps que l’intervalle de temps configuré, la fin de temporisation d’inactivité, les transitions d’état à "inactif", et un message d’état "inactif" sont envoyés. Si l’utilisateur recommence à composer pendant l’état "inactif", l’état passe à "actif", et le message d’état correspondant est envoyé. A moins que l’usager ne l’ait configuré autrement, le temporisateur d’inactivité DEVRAIT avoir une valeur par défaut de 15 secondes.

Si un message de contenu est envoyé avant l’expiration du seuil d’inactivité, aucune indication d’état "inactif" n’est nécessaire. Et donc, dans la plupart des cas, un seul message d’état est généré pour chaque message de contenu. Dans tout événement, le taux de messages est limité à un message d’état par intervalle de seuil de rafraîchissement.

Les transitions d’état sont indiquées à la Figure 1.

Figure 1. Diagramme d’état de l’envoyeur

3.3 Comportement du récepteur de message d’état

Le récepteur du message d’état utilise les messages d’état pour déterminer l’état de l’envoyeur du message de contenu. Si le plus récent message d’état "actif" contenait une valeur <refresh>, la temporisation de rafraîchissement est réglée à cette valeur ; autrement, elles est de 120 secondes. L’état au récepteur passe de "actif" à "inactif" dans trois conditions :

1. Réception d’un message avec l’état "inactif".

2. Réception d’un message de contenu.

3. Expiration de l’intervalle de rafraîchissement.

Les récepteurs DOIVENT être capables de traiter plusieurs messages isComposing consécutifs avec l’état "actif", sans considération de l’intervalle de rafraîchissement.

La Figure 2 indique les transitions d’état.

Figure 2. Diagramme d’état du récepteur

3.4. Contenu du message

Décrivons brièvement le contenu de message pour résumer la discussion ci-dessus. Cette description est non normative. Le schéma de la Section 6 devrait être consulté pour ce qui est du format de message normatif.

Le message consiste en un élément <isComposing>, avec un élément obligatoire <state> qui indique l’état du composeur ; c’est-à-dire, inactif ou actif. De plus, il y a trois éléments facultatifs : <lastactive>, qui indique le dernier temps d’activité ; <contenttype>, le type de message en cours de création ; et <refresh>, qui est l’intervalle de temps après lequel le récepteur peut espérer une mise à jour de la part du composeur. Des précisions sont données au paragraphe suivant.

3.5. Informations d’état supplémentaires

Le message d’état contient des éléments facultatifs supplémentaires pour fournir d’autres précisions sur l’activité de composition. Tous peuvent apparaître aussi bien dans les messages d’état "actif" que "inactif".

L’élément facultatif <lastactive> décrit le temps absolu auquel l’usager a pour la dernière fois ajouté ou édité du contenu.

L’élément facultatif <contenttype> indique le type de support sur lequel le terminal d’échange de message est en train de composer. Il peut contenir soit un simple type de support MIME, tel que "audio" ou "texte", soit un type et sous-type de support, tel que "text/html". Il est plutôt compris comme un conseil à l’usager, et non une garantie, que le contenu réel du message de contenu ne contiendra que le contenu indiqué. Il permet au récepteur humain de se préparer au format de message vraisemblable.

Pour continuer à décrire la composition du message, le schéma XML ou l’ensemble des noms d’états disponibles pourra être étendu dans les documents futurs. Les récepteurs de messages d’état qui mettent en œuvre la présente spécification sans extensions DOIVENT traiter les jetons d’état autres que "inactif" et "actif" comme "inactif". Les éléments supplémentaires DOIVENT utiliser leurs propres espaces de nom et DOIVENT être conçus de telle sorte que les récepteurs puissent ignorer de telles extensions en toute sécurité. L’ajout d’éléments à l’espace de nom défini dans le présent document n’est pas autorisé.

Le message d’état isComposing PEUT être porté dans des messages CPIM [3].

Une telle enveloppe est particulièrement utile si les messages sont relayés par un serveur de conférence car le message CPIM maintient l’identité du composeur d’origine.

4. Utilisation du message d’état

Le message d’état isComposing peut être utilisé avec le mode page ou le mode session, bien que le mode session convienne plus naturellement. En mode session, le message d’état est envoyé en tant que partie du courant d’échange de message. Son utilisation est négocié exactement comme tout autre type de support dans ce courant, avec les détails selon le protocole du mode de session.

L’envoi des messages d’état au sein du courant d’échange de messages en mode session présente au moins trois avantages. D’abord, il garantit une mise en ordre et une synchronisation appropriée avec les messages de contenu réels qui sont en cours de composition. Dans les systèmes d’échange de messages qui garantissent une livraison des messages dans l’ordre, cette approche évite d’avoir l’apparition d’une indication active chez le receveur après la livraison du message réel, du fait du réarrangement de message à travers deux mécanismes de livraison. Deuxièmement, la sécurité de bout en bout peut s’appliquer aux messages. Troisièmement, les mécanismes de négociation de session peuvent être utilisés pour l’arrêter à tout moment, et même de négocier son utilisation dans une seule direction à la fois.

L’utilisation avec le mode page est aussi directe. Le message d’état est porté comme le corps d’un message en mode page. Dans un IM fondé sur SIP, le composeur DOIT cesser de transmettre des messages d’état si le receveur retourne un code d’état 415 (type de support non pris en charge) en réponse à une demande MESSAGE qui contient l’indication d’état.

L’envoyeur ne peut pas être assuré que le message d’état soit livré avant que n’arrive le contenu réel en cours de composition. Cependant, le mode page SIP est limité à un seul message sans accusé de réception, et donc la livraison dans le désordre est peu vraisemblable, bien que toujours possible si des mandataires sont impliqués.

5. Exemples

<?xml version="1.0" encoding="UTF-8"?>
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
iscomposing.xsd">
<state>active</state>
<contenttype>text/plain</contenttype>
<refresh>90</refresh>
</isComposing>

<?xml version="1.0" encoding="UTF-8"?>
<isComposing xmlns="urn:ietf:params:xml:ns:im-iscomposing"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:im-composing
iscomposing.xsd">
<state>idle</state>
<lastactive>2003-01-27T10:43:00Z</lastactive>
<contenttype>audio</contenttype>
</isComposing>

6. Format de document XML

Un document isComposing est un document XML qui DOIT être bien conformé et DEVRAIT être valide. Les documents isComposing DOIVENT être fondés sur XML 1.0 et DOIVENT être codés en utilisant UTF-8. La présente spécification fait usage des espaces de nom XML pour identifier les documents isComposing. L’URI d’espace de nom pour les éléments définis à cette fin est un URN qui utilise l’identifiant d’espace de nom 'ietf'. Cet URN est :

urn:ietf:params:xml:ns:im-iscomposing

6.1. Schéma XML

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:im-iscomposing"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:im-iscomposing">
<xs:element name="isComposing">
<xs:complexType>
<xs:sequence>
<xs:element name="state" type="xs:string"/>
<xs:element name="lastactive" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="contenttype" type="xs:string"
minOccurs="0"/>
<xs:element name="refresh" type="xs:positiveInteger"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

7. Considérations de sécurité

L’indication isComposing donne une vision fine de l’activité de l’entité qui compose et donc mérite une protection de confidentialité particulièrement soignée afin que seul celui qui est destiné à recevoir le message reçoive l’indication isComposing.

Dans la mesure où les messages d’état sont transportés à l’aide du protocole IM lui-même, toutes les considérations de sécurité du protocole IM sous-jacent s’appliquent aussi aux messages d’état isComposing.

Il peut y avoir des problèmes de confidentialité dans l’envoi des messages d’état isComposing avant qu’une conversation réelle ait été établie entre les utilisateurs de la communication. Un message d’état peut être envoyé même si l’usager abandonne ensuite le message. Il est RECOMMANDÉ que les indications isComposing en mode page ne soit envoyées que lorsqu’un message est en cours de composition en réponse à un message antérieur. Le présent document ne prescrit pas la façon dont une mise en oeuvre détecte si un message est en réponse à un message antérieur en mode page, mais le temps écoulé ou le comportement de l’interface d’utilisateur peuvent être utilisés comme indication.

8. Considérations relatives à l’IANA

8.1. Enregistrement du contenu-type pour 'application/im-iscomposing+xml'

A : ietf-types@iana.org
Sujet : enregistrement du type de support MIME application/im-iscomposing+xml
Nom du type de support MIME : application
Nom de sous-type MIME : im-iscomposing+xml
Paramètres : (aucun)
Paramètres facultatifs : charset ; indique le codage de caractères du XML inclus. Par défaut, UTF-8.
Considérations sur le codage : utilise XML, qui peut employer des caractères de 8 bits, selon le codage de caractères utilisé. Voir la RFC 3023 [4], paragraphe 3.2.
Considérations sur la sécurité : Ce type de contenu est conçu pour porter des informations sur l’activité en cours de l’utilisateur, qui peuvent être considérées comme des informations privées. On devrait adopter les précautions appropriées pour limiter la divulgation de ces informations.
Considérations d’interopérabilité : Ce type de contenu procure un format commun pour les échanges d’informations d’activité de composition.
Spécification publiée : RFC 3994
Applications qui utilisent ce type de support : Systèmes d’échanges de messages instantanés.
Information supplémentaires : aucune

Adresse personnelle & email à contacter pour des informations complémentaires : Henning Schulzrinne, hgs@cs.columbia.edu

Usage des destination : UTILISATION LIMIITÉE

Auteur/Contrôle des amendements : la présente spécification est un élément de travail du groupe de travail SIMPLE de l’IETF, dont l’adresse de liste de diffusion est simple@ietf.org.

Autres informations : Ce type de support est une spécialisation de application/xml RFC 3023 [4], et nombre des considérations décrites ici s’appliquent aussi à application/im-iscomposing+xml.

8.2. Enregistrement de sous-espace de nom d’URN pour 'urn:ietf:params:xml:ns:im-iscomposing'

URI : urn:ietf:params:xml:ns:im-iscomposing

Description : Ceci est l’espace de nom XML pour les éléments XML définis par la RFC 3994 pour décrire l’activité de composition par un client de l’échange de message instantané utilisant le type de contenu application/im-iscomposing+xml.

Contact d’enregistrement : IETF, groupe de travail SIMPLE, simple@ietf.org,
Henning Schulzrinne, hgs@cs.columbia.edu
XML :
BEGIN
<?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>Is-composing Indication for Instant Messaging</title>
</head>
<body>
<h1>Namespace for SIMPLE iscomposing extension</h1>
<h2>urn:ietf:params:xml:ns:im-composing</h2>
<p>See <a href="[URL of published RFC]">RFC3994</a>.</p>
</body>
</html>
END

8.3. Enregistrement de schéma

Le présent paragraphe enregistre un nouveau schéma XML selon les procédures de [5].

URI : urn:ietf:params:xml:schema:im-composing
Contact d’enregistrement : IETF, groupe de travail SIMPLE, (simple@ietf.org),
Henning Schulzrinne (hgs@cs.columbia.edu).

On peut trouver le XML pour ce schéma dans le contenu intégral du paragraphe 6.1.

9. Remerciements

Ben Campbell, Miguel Garcia, Scott Hollenbeck, Christian Jansson, Cullen Jennings, Hisham Khartabil, Allison Mankin, Aki Niemi, Jonathan Rosenberg, et Xiaotao Wu ont beaucoup aidé par leurs commentaires.

10. Références

10.1 Références normatives

[1] Day, M., Rosenberg, J., et H. Sugano, "A Model for Presence and Instant Messaging" (Modèle pour l’échange de messages instantané et de présence), RFC 2778, février 2000.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels" (Mots clé à utiliser dans les RFC pour indiquer les niveaux d’exigence), BCP 14, RFC 2119, mars 1997.

[3] Klyne, G. et D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format" (Echange de messages de présence commune et instantané (CPIM) : format de message) , RFC 3862, août 2004.

[4] Murata, M., St. Laurent, S., et D. Kohn, "XML Media Types" (Types de support XML), RFC 3023, janvier 2001.

[5] Mealling, M., "The IETF XML Registry" (Référentiel XML de l’IETF), BCP 81, RFC 3688, janvier 2004.

10.2. Références informatives

[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., et J. Peterson, "Presence Information Data Format (PIDF)" (Format des données d’informations de présence), RFC 3863, August 2004.

[7] Rosenberg, J., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)" (Exigences évoluées d’échange de messages instantané pour le protocole d’initialisation de session (SIP)), Travail en cours, février 2004.

Adresse de l’auteur

Henning Schulzrinne Téléphone : +1 212 939 7004
Columbia University mél : hgs@cs.columbia.edu
Department of Computer Science URI : http://www.cs.columbia.edu/~hgs
450 Computer Science Building
New York, NY 10027
US

Déclaration de copyright

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.

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 actuellement fourni par Internet Society.