Groupe de travail Réseau	R. Mahy, Cisco Systems, Inc.	
Request for Comments : 3842	août 2004	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Paquetage d’événement Résumé de message et Indication de message en instance pour le protocole d’initialisation de session (SIP)

Statut de ce mémoire
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.

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

Résumé
Le présent document décrit un paquetage d’événements du protocole d’initialisation de session (SIP) pour porter l’état d’attente de message et les résumés de message d’un système de messagerie à un agent d’utilisateur intéressé.

Table des Matières
1. Conventions	2
2. Fondements et applicabilité	2
3. Définition formelle du paquetage d’événement	2
3.1 Nom du paquetage d’événement	2
3.2 Paramètres du paquetage d’événement	2
3.3 Corps SUBSCRIBE	3
3.4 Durée de l’abonnement	3
3.5 Corps NOTIFY	3
3.6 Génération par l’abonné des demandes SUBSCRIBE	4
3.7 Traitement par le notificateur des demandes SUBSCRIBE	4
3.8 Génération par le notificateur des demandes NOTIFY	4
3.9 Traitement par l’abonné des demandes NOTIFY	4
3.10 Traitement des demandes multiples	5
3.11 Taux de notifications	5
3.12 Agents et listes d’état	5
3.13 Comportement d’un serveur mandataire	5
4. Exemples d’utilisation	5
4.1 Exemple de flux de message	5
4.2. Exemple d’utilisation avec les capacités de l’appelé et les préférences de l’appelant	9
5. Syntaxe formelle	10
5.1. Nouvelle définition du paquetage d’événement	10
5.2 Syntaxe du format du corps	10
6. Considérations pour la sécurité	10
7. Considérations relatives à l’IANA	10
7.1 Enregistrement de paquetage d’événement SIP pour Résumé de message	10
7.2 Enregistrement MIME pour application/résumé de message simple	10
8. Contributeurs	11
9. Remerciements	11
10. Références	11
10.1. Références normatives	11
10.2 Références pour information	11
11. Adresse de l’auteur	12
12. Déclaration complète de droits de reproduction	12

1.	Conventions

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

2.	Fondements et applicabilité

L’indication de message en instance est un dispositif courant dans les réseaux téléphoniques. Elle implique normalement une indication audible ou visible que des messages sont en attente, comme d’exécuter une tonalité de numérotation spéciale (que dans les réseaux téléphoniques on appelle une tonalité de message en instance) de faire clignoter une lumière ou un indicateur sur le téléphone, d’afficher des icônes ou un texte, ou une combinaison de ces moyens.

La tonalité de message en instance est similaire à, mais distincte, de la tonalité de manœuvre cadencée. Toutes deux sont définies dans [GR-506].

Les méthodes de la spécification SIP de base [RFC3261] n’ont été conçues que pour résoudre le problème de l’initialisation des sessions multimédia, et des rendez-vous. Comme l’indication de message en instance est réellement une information d’état orthogonale à une session, il n’était pas clairement établi comment un téléphone IP agissant dans un agent d’utilisateur SIP mettrait en œuvre une fonctionnalité comparable. Les membres de la communauté de la téléphonie voyaient cela comme une des insuffisances de SIP.

Les usagers veulent conserver les parties utiles des fonctionnalités qu’ils ont utilisées dans leurs téléphones traditionnels analogiques, mobiles, et leurs autocommutateurs privés. Il est aussi souhaitable de fournir des fonctionnalités comparables d’une façon souple qui permette plus de personnalisation ainsi que de nouvelles caractéristiques. La notification d’événement spécifique de SIP [RFC3265] est un mécanisme approprié dans cet environnement, car il préserve les dispositifs de mobilité de l’usager et de rendez-vous que fournit SIP.

En utilisant la notification d’événement spécifique de SIP, un agent d’utilisateur d’abonné (normalement agent d’utilisateur de téléphone IP ou de logiciel SIP) s’abonne à l’état de ses messages. Un agent d’utilisateur SIP qui agit au nom du système de messagerie de l’usager notifie alors à l’abonné chaque changement d’état du compte de messagerie de l’abonné. (Ce notificateur pourrait être composé d’un agent d’utilisateur qui fournit une interface de support en temps réel pour envoyer ou recevoir les messages, ou ce pourrait être une entité autonome.) Le notificateur envoie un résumé de message dans le corps d’un NOTIFY, codé dans un nouveau type MIME défini plus loin dans le présent document. Un agent d’utilisateur peut aussi aller explicitement chercher l’état actuel.

Un agent d’utilisateur SIP PEUT s’abonner à plusieurs comptes (distingués par l’URI de demande). Plusieurs agents d’utilisateur SIP PEUVENT s’abonner au même compte.

Avant l’envoi de tout abonnement ou notification, chaque agent d’utilisateur intéressé doit connaître ses notificateurs de messagerie. Cela PEUT être configuré manuellement sur les agents d’utilisateur intéressés, configuré manuellement sur un mandataire SIP approprié, ou découvert de façon dynamique sur la base des préférences demandées par l’appelant [RFC3841] et les capacités enregistrées de l’appelé [RFC3840]. (Voir au paragraphe 4.2 plus d’informations sur l’usage des capacités du demandé)

3.	Définition formelle du paquetage d’événement
3.1	Nom du paquetage d’événement
Le présent document définit un paquetage d’événement SIP comme défini dans la [RFC3265]. Le nom du jeton de paquetage d’événement pour ce paquetage est :

"message-summary"

3.2	Paramètres du paquetage d’événement
Ce paquetage ne définit aucun paramètre de paquetage d’événement.

3.3	Corps SUBSCRIBE
Ce paquetage ne définit aucun corps SUBSCRIBE.

3.4	Durée de l’abonnement
Les abonnements à ce paquetage d’événement PEUVENT aller de quelques minutes à plusieurs semaines. L’abonnement en heures ou jours est plus normal et est RECOMMANDÉ. La durée d’abonnement par défaut pour ce paquetage d’événement est d’une heure.

3.5	Corps NOTIFY
Un format simple fondé sur le texte est proposé pour empêcher qu’une charge trop lourde pèse sur les agents d’utilisateur d’extrémité, par exemple, des téléphones IP bas de gamme sans affichage. Bien que ce format soit fondé sur le texte, il n’est destiné qu’aux besoins de la machine.

Une extension future POURRA définir d’autres corps NOTIFY. Si aucun en-tête "Accept" n’est présent dans le SUBSCRIBE, le type de corps défini dans le présent document DOIT être supposé.

Le format spécifié dans la présente proposition tente de séparer autant que possible les attributs orthogonaux des messages. Les messages sont séparés par une classe de contexte de message (message-context-class) (par exemple : message vocal, message de télécopie, message papier, message multimédia, message de texte, et aucun) par un état de message (nouveau et ancien) et un type urgent et non urgent.

Le format de texte commence par une simple ligne d’état, et facultativement une ligne de résumé par classe de contexte de message. Les classes de contexte de message sont définies dans la [RFC3458]. Pour chaque classe de contexte de message, le nombre total de messages anciens et nouveaux est rapporté dans les champs Nouveau et Ancien.

Dans certains cas, des résumés de message détaillés ne sont pas disponibles. La ligne d’état permet aux systèmes de messagerie ou aux passerelles de messagerie de fournir la notification traditionnelle booléenne de message en instance.

Messages en attente : oui

Si l’URI de demande ou l’en-tête To dans un abonnement de résumé de message correspond à un groupe ou une collection de comptes individuels de messagerie, le notificateur DOIT spécifier à quel compte correspond le corps du résumé de message. Noter que l’URI du compte NE DOIT PAS être délimité par des crochets angulaires ("<" et ">").

Message-Account: sip:alice@example.com

Dans l’exemple qui suit, plus d’une information de résumé de message booléenne est disponible pour l’agent d’utilisateur. Il y a deux nouveaux messages de télécopie et quatre anciens messages.

Fax-Message: 2/4

Après le résumé, le format peut facultativement faire la liste d’un compte sommaire de messages urgents. Dans le prochain exemple, il y a un nouveau message vocal et trois anciens messages, aucun des nouveaux messages n’est urgent, mais un des anciens messages l’est. Tous les compteurs ont une valeur maximum de 4  294  967  295 ((2^32) - 1). Les notificateurs NE DOIVENT PAS générer une demande d’une valeur supérieure. Les abonnés DOIVENT traiter une valeur supérieure comme 2^32-1.

Voice-Message: 1/3 (0/1)

Facultativement, après le compte des résumés, le système de messagerie PEUT ajouter les en-têtes de message de style RFC2822 [RFC2822], qui décrivent plus en détails les nouveaux messages. Les en-têtes de message NE DOIVENT PAS être inclus dans un NOTIFY initial, car les nouveaux messages pourraient ne pas être limités en taille. Les en-têtes de message inclus dans les notifications suivantes DOIVENT seulement correspondre aux messages ajoutés depuis la précédente notification pour cet abonnement. Un système de messagerie qui inclut les en-têtes de message dans un NOTIFY DOIT fournir un mécanisme configurable par l’administrateur pour choisir quels en-têtes sont envoyés. Les en-têtes à inclure sont To, From, Date, Subject, et identifiant de message. Noter que le formatage de ces en-têtes dans ce corps est identique à celui des en-têtes d’extension SIP, et non le format (similaire) défini dans la RFC2822.

Les mises en œuvre qui génèrent de grandes notifications doivent respecter les restrictions sur la taille de message pour les transports non fiables exposées au paragraphe 18.1.1 de SIP [RFC3261].

La transposition de l’état de message local en état de nouveau/ancien message et urgent est une question de mise en œuvre du système de messagerie. Cependant, le notificateur de messagerie NE DOIT PAS considérer un message comme "ancien" simplement parce qu’il a généré une notification, car cela pourrait empêcher un autre abonnement de recevoir en temps utile les notifications de résumé de message. De même, le système de messagerie PEUT utiliser tout algorithme convenable pour déterminer qu’un message est "urgent".

Les systèmes de messagerie PEUVENT utiliser tout algorithme pour déterminer la classe de contexte de message appropriée pour un message spécifique. Les systèmes qui utilisent la messagerie Internet DEVRAIENT utiliser le contenu de l’en-tête Message-Context (défini dans la [RFC3458]) si il est présent, comme une indication pour la détermination du contexte. Noter qu’un système de messagerie composé n’a pas besoin de prendre en charge un certain contexte afin de générer les notifications identifiées avec ce contexte.

3.6	Génération par l’abonné des demandes SUBSCRIBE
Les agents d’utilisateur abonnés vont normalement faire SUBSCRIBE aux informations de résumé de message pour des périodes allant de quelques heures ou jours, et tenter automatiquement de re-SUBSCRIBE bien avant que l’abonnement soit complètement expiré. Si le réabonnement échoue, l’abonné DEVRAIT réessayer périodiquement jusqu’à ce qu’un abonnement réussisse, en prenant soin d’introduire un retard entre les tentatives pour éviter d’encombrer le réseau. Si un abonnement est arrivé à  expiration, les nouveaux réabonnements DOIVENT utiliser un nouvel identifiant d’appel.

L’abonné DEVRAIT SUBSCRIBE à ces résumés de messages d’utilisateur chaque fois qu’un nouvel utilisateur est associé à l’appareil (une nouvelle connexion). L’abonné PEUT aussi aller chercher explicitement l’état en cours à tout moment. L’abonné DEVRAIT renouveler son abonnement immédiatement après une réinitialisation, ou lorsque la connexité du réseau de l’abonné vient juste d’être rétablie.

L’abonné DOIT être prêt à recevoir et traiter un NOTIFY avec le nouvel état immédiatement après l’envoi d’un nouveau SUBSCRIBE, d’un renouvellement de SUBSCRIBE, d’un désabonnement, d’une récupération (fetch), ou à tout autre moment durant l’abonnement.

Lorsque un utilisateur se désenregistre d’un appareil (déconnexion, perte d’alimentation d’un appareil mobile, etc.) les abonnés DEVRAIENT se désabonner en envoyant un message SUBSCRIBE avec un en-tête Expires de zéro.

3.7	Traitement par le notificateur des demandes SUBSCRIBE
Lorsque un système de messagerie SIP reçoit des messages SUBSCRIBE avec un type d’événement message-summary, il DEVRAIT authentifier la demande d’abonnement. Si l’authentification réussit, le notificateur PEUT limiter la durée de l’abonnement à un temps défini par l’administrateur comme décrit dans Événements SIP [RFC3265].

3.8	Génération par le notificateur des demandes NOTIFY
Immédiatement après l’acceptation d’un abonnement, le notificateur DOIT envoyer un NOTIFY avec les informations de résumé de message actuelles. Cela permet à l’abonné de resynchroniser son état. Ce NOTIFY de synchronisation initial NE DOIT PAS inclure les en-têtes facultatifs de message de style RFC 2822 [RFC2046].

Lorsque l’état des messages change suffisamment pour qu’un compte de messagerie change le nombre de nouveaux ou anciens messages, le notificateur DEVRAIT envoyer un message NOTIFY à tous les souscripteurs actifs de ce compte. Les messages NOTIFY envoyés aux abonnés d’un groupe ou alias, DOIVENT contenir le nom du compte de message dans le corps de la notification.

Un système de messagerie PEUT envoyer un NOTIFY avec un en-tête "Expires" de "0" et un en-tête "Subscription-State" de "terminé" avant une fermeture en douceur.

3.9	Traitement par l’abonné des demandes NOTIFY
À réception d’une demande NOTIFY valide, l’abonné DEVRAIT immédiatement rendre l’état du message et les informations de résumé à l’utilisateur final d’une façon spécifique de la mise en œuvre.

L’abonné DOIT être prêt à recevoir des NOTIFY de différents contacts correspondant au même SUBSCRIBE. (Le SUBSCRIBE peut avoir été fourché).

3.10	Traitement des demandes multiples
Les demandes fourchées sont admises pour ce type d’événement et peuvent installer plusieurs abonnements. L’abonné PEUT rendre plusieurs résumés correspondant au même compte directement à l’usager, ou il PEUT les fusionner comme décrit ci-dessous.

Si une des lignes d’état "Messages-Waiting" rapporte "oui", l’état fusionné est alors "oui" ; autrement, l’état fusionné est "non".

L’abonné PEUT fusionner les lignes de résumé d’une façon spécifique de la mise en œuvre si toutes les notifications contiennent au moins une ligne msg-summary.

3.11	Taux de notifications
Un notificateur PEUT choisir de mettre les demandes NOTIFY en "quarantaine" pour une courte période définie par l’administrateur (secondes ou minutes) lorsque l’état du message change rapidement. Les demandes en quarantaine qui deviennent invalides sont remplacées par des notifications plus récentes, réduisant ainsi le volume total des notifications. Ce comportement est encouragé pour les mises en œuvre qui ont une forte utilisation interactive. Noter que la notification à temps résultant en un changement de l’état global (messages en instance ou non) et la notification des messages nouvellement ajoutés est probablement plus significative pour l’utilisateur final que la notification de messages nouvellement supprimés qui n’affectent pas l’état global des messages en instance (par exemple, il y a encore de nouveaux messages).

Les notificateurs NE DEVRAIENT PAS générer des demandes NOTIFY plus souvent qu’une par seconde.

3.12	Agents et listes d’état
Un souscripteur PEUT utiliser un "alias" ou "groupe" dans l’URI de demande d’un abonnement si ce nom est significatif pour le système de messagerie. Les mises en œuvre PEUVENT créer un service qui consolide et résume les NOTIFY provenant de nombreux contacts. Le présent document n’interdit pas que les mises en œuvre construisent des agents d’état qui prennent en charge ce paquetage d’événements. Une façon de mettre ce service en œuvre est l’extension de liste d’événement [RFC4662].

3.13	Comportement d’un serveur mandataire
Il n’y a pas d’exigence supplémentaire pour les mandataires SIP, autre que de transmettre de façon transparente les méthodes SUBSCRIBE et NOTIFY comme exigé dans SIP. Cependant, les mandataires DEVRAIENT permettre des URL non SIP. Les serveurs mandataires et de redirection DEVRAIENT être capables de diriger la demande SUBSCRIBE vers un agent d’utilisateur de notificateur de messagerie approprié.

4.	Exemples d’utilisation
4.1	Exemple de flux de message
Les exemples ci-dessous ne sont que pour information. Pour une description normative du paquetage d’événements, voir les sections 3 et 5 de ce document.

Dans l’exemple de flux d’appel ci-dessous, le téléphone IP d’Alice souscrit à l’état des messages d’Alice. Les en-têtes Via sont omis pour la clarté du schéma.

      Souscripteur           Notificateur
          |                         |
          | A1: SUBSCRIBE (nouveau) |
          |------------------------>|
          | A2: 200 OK              |
          |<------------------------|
          |                         |
          | A3: NOTIFY (synchro)    |
          |<------------------------|
          | A4: 200 OK              |
          |------------------------>|
          |                         |
          |  A5: NOTIFY (change)    |
          |<------------------------|
          |  A6: 200 OK             |
          |------------------------>|
          |                         |
          |  A7: (re)SUBSCRIBE      |
          |------------------------>|
          |  A8: 200 OK             |
          |<------------------------|
          |                         |
          |  A9: NOTIFY (synchro)   |
          |<------------------------|
          |  A10: 200 OK            |
          |------------------------>|
          |                         |
          |  A11: (dé)SUBSCRIBE     |
          |------------------------>|
          |  A12: 200 OK            |
          |<------------------------|
          |                         |
          |  A13: NOTIFY (synchro)  |
          |<------------------------|
          |  A14: 200 OK            |
          |------------------------>|

A1 :	Souscripteur (téléphone d’Alice) -> Notificateur (passerelle de messagerie vocale d’Alice) souscrit à l’état de sommaire de message d’Alice pour un jour.

      SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
      To: <sip:alice@example.com>
      From: <sip:alice@example.com>;tag=78923
      Date: Mon, 10 Jul 2000 03:55:06 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 4 SUBSCRIBE
      Contact: <sip:alice@alice-phone.example.com>
      Event: message-summary
      Expires: 86400
      Accept: application/simple-message-summary
      Content-Length: 0

A2 : Notificateur -> Souscripteur

      SIP/2.0 200 OK
      To: <sip:alice@example.com>;tag=4442
      From: <sip:alice@example.com>;tag=78923
      Date: Mon, 10 Jul 2000 03:55:07 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 4 SUBSCRIBE
      Expires: 86400
      Content-Length: 0

A3 : Notificateur -> Souscripteur (synchronisation immédiate de l’état actuel : 2 nouveaux messages et 8 vieux [2 urgents] 

      NOTIFY sip:alice@alice-phone.example.com SIP/2.0
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 03:55:07 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 20 NOTIFY
      Contact: <sip:alice@vmail.example.com>
      Event: message-summary
      Subscription-State: active
      Content-Type: application/simple-message-summary
      Content-Length: 99

      Messages-Waiting: yes
      Message-Account: sip:alice@vmail.example.com
      Voice-Message: 2/8 (0/2)

A4 : Souscripteur -> Notificateur

      SIP/2.0 200 OK
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 03:55:08 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 20 NOTIFY
      Content-Length: 0

A5 : Notificateur -> Souscripteur. C’est une notification de nouveaux messages. Certains en-têtes de chacun des nouveaux messages sont joints.

      NOTIFY sip:alice@alice-phone.example.com SIP/2.0
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 04:28:53 GMT
      Contact: <sip:alice@vmail.example.com>
      Call-ID: 1349882@alice-phone.example.com
      CSeq: 31 NOTIFY
      Event: message-summary
      Subscription-State: active
      Content-Type: application/simple-message-summary
      Content-Length: 503

      Messages-Waiting: yes
      Message-Account: sip:alice@vmail.example.com
      Voice-Message: 4/8 (1/2)

      To: <alice@atlanta.example.com>
      From: <bob@biloxi.example.com>
      Subject: carpool tomorrow?
      Date: Sun, 09 Jul 2000 21:23:01 -0700
      Priority: normal
      Message-ID: 13784434989@vmail.example.com

      To: <alice@example.com>
      From: <cathy-the-bob@example.com>
      Subject: AU SECOURS ! malade chez moi, fais la présentation à ma place
      Date: Sun, 09 Jul 2000 21:25:12 -0700
      Priority: urgent
      Message-ID: 13684434990@vmail.example.com

A6 : Souscripteur -> Notificateur

      SIP/2.0 200 OK
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 04:28:53 GMT
      Call-ID: 1349882@alice-phone.example.com
      CSeq: 31 NOTIFY
      Content-Length: 0

A7 : Souscripteur  ->  Notificateur. Rafraîchissement de souscription.

      SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
      To: <sip:alice@example.com>;tag=4442
      From: <sip:alice@example.com>;tag=78923
      Date: Mon, 10 Jul 2000 15:55:06 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 8 SUBSCRIBE
      Contact: <sip:alice@alice-phone.example.com>
      Event: message-summary
      Expires: 86400
      Accept: application/simple-message-summary
      Content-Length: 0

A8 : Notificateur -> Souscripteur

      SIP/2.0 200 OK
      To: <sip:alice@example.com>;tag=4442
      From: <sip:alice@example.com>;tag=78923
      Date: Mon, 10 Jul 2000 15:55:07 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 8 SUBSCRIBE
      Contact: <sip:alice@alice-phone.example.com>
      Expires: 86400
      Content-Length: 0

A9 : Notificateur -> Souscripteur. (synchronisation immédiate de l’état actuel)

      NOTIFY sip:alice@alice-phone.example.com SIP/2.0
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 15:55:07 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 47 NOTIFY
      Contact: <sip:alice@vmail.example.com>
      Event: message-summary
      Subscription-State: active
      Content-Type: application/simple-message-summary
      Content-Length: 99
      Messages-Waiting: yes
      Message-Account: sip:alice@vmail.example.com
      Voice-Message: 4/8 (1/2)

A10 : Souscripteur -> Notificateur

      SIP/2.0 200 OK
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 15:55:08 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 47 NOTIFY
      Contact: <sip:alice@vmail.example.com>

A11 : Souscripteur  ->  Notificateur. Désabonnement après la déconnexion de "alice".

      SUBSCRIBE sip:alice@vmail.example.com SIP/2.0
      To: <sip:alice@example.com>;tag=4442      From: <sip:alice@example.com>;tag=78923
      Date: Mon, 10 Jul 2000 19:35:06 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 17 SUBSCRIBE
      Contact: <sip:alice@alice-phone.example.com>
      Event: message-summary
      Expires: 0
      Accept: application/simple-message-summary
      Content-Length: 0

A12 : Notificateur -> Souscripteur

      SIP/2.0 200 OK
      To: <sip:alice@example.com>;tag=4442
      From: <sip:alice@example.com>;tag=78923
      Date: Mon, 10 Jul 2000 19:35:07 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 17 SUBSCRIBE
      Contact: <sip:alice@alice-phone.example.com>
      Expires: 0
      Content-Length: 0

A13 : Notificateur -> Souscripteur. (Synchronisation immédiate de l’état actuel, que le souscripteur peut maitenant ignorer)

      NOTIFY sip:alice@alice-phone.example.com SIP/2.0
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 19:35:07 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 56 NOTIFY
      Contact: <sip:alice@vmail.example.com>
      Event: message-summary
      Subscription-State: terminated;reason=timeout
      Content-Type: application/simple-message-summary
      Content-Length: 99
      Messages-Waiting: yes
      Message-Account: sip:alice@vmail.example.com
      Voice-Message: 4/8 (1/2)

A14 : Souscripteur -> Notificateur

      SIP/2.0 200 OK
      To: <sip:alice@example.com>;tag=78923
      From: <sip:alice@example.com>;tag=4442
      Date: Mon, 10 Jul 2000 19:35:08 GMT
      Call-Id: 1349882@alice-phone.example.com
      CSeq: 56 NOTIFY
      Event: message-summary
      Content-Length: 0

4.2.	Exemple d’utilisation avec les capacités de l’appelé et les préférences de l’appelant
L’utilisation des capacités de l’appelé est facultative mais encouragée. Si on utilise les capacités de l’appelé, un notificateur de messagerie PEUT enregistrer avec REGISTER un contact avec une méthode et des étiquettes d’événements appropriées comme le montre l’exemple ci-dessous. Pour mieux se distinguer, le notificateur de messagerie PEUT aussi faire un REGISTER comme contact avec l’étiquette actor="msg-taker". Un exemple de cette sorte d’enregistrement suit.

       REGISTER sip:sip3-sj.example.com SIP/2.0
       To: <sip:alice@example.com>
       From: <sip:alice@example.com>;tag=4442
       ...
       Contact: <sip:alice@vm13-sj.example.com>
        ;actor="msg-taker";methods="SUBSCRIBE"
        ;automata;events="message-summary"

Le message SUBSCRIBE suivant trouverait le contact qui s’est enregistré dans l’exemple ci-dessus.

       SUBSCRIBE sip:alice@example.com SIP/2.0
       ...
       Accept: application/simple-message-summary
       Event: message-summary
       Accept-Contact: *;automata;actor="msg-taker"

5.	Syntaxe formelle

La spécification de syntaxe suivante utilise le format Backus-Naur augmenté (ABNF) décrit dans la [RFC2234].

5.1.	Nouvelle définition du paquetage d’événement
Le présent document définit un nouveau paquetage d’événement dont le nom de paquetage est :

message-summary

5.2	Syntaxe du format du corps
La syntaxe formelle pour le type MIME application/simple-message-summary est décrit ci-dessous. La production de la classe de contexte de message message-context-class est définie au paragraphe 6.2 de la [RFC3458]. Noter que toutes les productions décrites ici sont insensibles à la casse.

message-summary = msg-status-line CRLF	; résumé de message = ligne d’état de message
                      [msg-account CRLF]	; compte de message
                      [*(msg-summary-line CRLF)]	; ligne de résumé de message
                      [ *opt-msg-headers ]	; en-têtes de message facultatifs

msg-status-line  = "Messages-Waiting" HCOLON msg-status	; messages en instance
msg-status = "yes" / "no"	; état des messages = oui/non
msg-account = "Message-Account" HCOLON Account-URI	; compte de messagerie : URI du compte
Account-URI = SIP-URI / SIPS-URI / absoluteURI
msg-summary-line = message-context-class HCOLON newmsgs SLASH oldmsgs
                   [ LPAREN new-urgentmsgs SLASH old-urgentmsgs RPAREN ]

opt-msg-headers = CRLF 1*(extension-header CRLF)

newmsgs = msgcount
oldmsgs = msgcount
new-urgentmsgs = msgcount
old-urgentmsgs  = msgcount
msgcount = 1*DIGIT 	; NE DOIT PAS excéder 2^32-1

6.	Considérations pour la sécurité

Les résumés de message et les corps de message facultatifs contiennent des informations qui sont normalement très confidentielles. Au minimum, les souscriptions à ce paquetage d’événement DEVRAIENT être authentifiées et autorisées correctement. De plus les notifications DEVRAIENT être chiffrées et leur intégrité protégée en utilisant des mécanismes de bout en bout ou la protection saut par saut accordée aux messages envoyés aux URI SIPS.

Des considérations supplémentaires de sécurité et de confidentialité sont discutées en détail dans SIP [RFC3261] et dans Événements SIP [RFC3265].

7.	Considérations relatives à l’IANA
7.1	Enregistrement de paquetage d’événement SIP pour Résumé de message
Nom de paquetage : message-summary
Type : paquetage
Contact : [Mahy]
Spécification publiée : Le présent document.

7.2	Enregistrement MIME pour application/résumé de message simple
Nom de type de support MIME : application
Nom de sous-type MIME : simple-message-summary
Paramètres exigés : aucun.
Paramètres facultatifs : aucun
Considérations de codage : Ce type MIME a été conçu pour être utilisé avec des protocoles qui peuvent porter des données codées en binaire. Bien que le format de ce type MIME soit similaire à celui de la RFC2822, il n’est pas identique. (Précisément, les règles de saut à la ligne sont spécifiques de SIP et les URI inclus peuvent contenir des caractères non ASCII.) Les protocoles qui ne portent pas de données binaires (qui ont des restrictions quant à la longueur de ligne ou au jeu de caractères par exemple) DOIVENT utiliser un codage de transfert réversible (comme base64) pour porter ce type MIME.
Considérations pour la sécurité : voir la section "Considérations pour la sécurité" du présent document.
Considérations d’interopérabilité : aucune
Spécification publiée : Le présent document.
Applications qui utilisent ce support : Le sous-type d’application simple-message-summary prend en charge l’échange d’informations de message en instance et de résumé de message dans les réseaux SIP.
Information supplémentaires 
1. Numéro magique : N/A
2. Extensions de fichier : N/A
3. Code de type de fichier Macintosh : N/A

8.	Contributeurs

Ilya Slain a établi le format initial du corps de texte contenu dans le présent document. Il était précédemment cité comme co-auteur , cependant, on ne sait plus où le joindre.

9.	Remerciements

Merci à Dan Wing, Dave Oran, Bill Foster, Steve Levy, Denise Caballero-McCann, Jeff Michel, Priti Patil, Satyender Khatter, Bich Nguyen, Manoj Bhatia, David Williams, et Bryan Byerly de Cisco, à Jonathan Rosenberg et Adam Roach de Dynamicsoft, à Eric Burger de Snowshore, à Nir Chen de Comverse, et à Eric Tremblay de Mediatrix.

10.	Références
10.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.

[RFC2234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234, STD068)

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

[RFC3458]	E. Burger et autres, "Contexte de message pour la messagerie Internet", janvier 2003. (MàJ par RFC3938) (P.S.)

[RFC3840]	J. Rosenberg, H. Schulzrinne et P. Kyzivat, "Indication des capacités d'agent d'utilisateur dans le protocole d'initialisation de session (SIP)", août 2004

[RFC3841]	J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Préférences de l'appelant pour le protocole d'initialisation de session (SIP)", août 2004. (P.S.)

10.2	Références pour information

[GR-506]	Telcordia, "GR-506: Signaling for Analog Interfaces, Issue 1, Revision 1", novembre 1996.

[RFC2046]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657.)

[RFC2822]	P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

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

11.	Adresse de l’auteur

Rohan Mahy
Cisco Systems, Inc.
5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066
USA
mél : rohan@cisco.com 

12.	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 à 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 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 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 le 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.