Groupe de travail Réseau	P. Kyzivat, Cisco Systems	
Request for Comments : 5628	octobre 2009	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de l'Isle	

Extension de paquetage d'événement d'enregistrement pour les URI d'agent d'utilisateur mondialement acheminables (GRUU) du protocole d'initialisation de session (SIP)

Résumé
La RFC 3680 définit un paquetage d’événement du protocole d’initialisation de session (SIP, Session Initiation Protocol) pour l’état d’enregistrement. Ce paquetage permet à un observateur d’apprendre les informations mémorisées par un registraire SIP, incluant son contact enregistré.

Cependant, le contact enregistré est fréquemment inaccessible et donc inutile pour les observateurs. L’URI d’agent d’utilisateur mondialement acheminable (GRUU, Globally Routable User Agent URI) défini dans la RFC 5627, est un URI capable d’accéder à un contact particulier. Cependant cet URI n’est pas inclus dans le format de document défini dans la RFC 3680. La présente spécification définit une extension au paquetage d'événement d'enregistrement pour inclure les GRUU alloués par le registraire.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5628 

Notice de droits de reproduction
Copyright (c) 2012 IETF Trust et les personnes identifiée comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Description	2
4. Traitement par le notificateur des demandes SUBSCRIBE	3
5. Génération par le notificateur des demandes NOTIFY	3
6. Traitement par l’abonné des demandes NOTIFY	3
6.1 Gestion de la durée de vie de GRUU temporaire	3
7. Exemple de document reginfo	4
8. Exemples	5
8.1 Exemple : notice d’accueil	5
8.2 Exemple : enregistrement implicite	5
9. Définition du schéma XML	7
10. Considérations relatives à l'IANA	8
10.1 Enregistrement du sous espace de noms d’URN	8
10.2 Enregistrement du schéma XML	8
11. Considérations sur la sécurité	8
12. Remerciements	9
13. Références	9
13.1 Références normatives	9
13.2 Références pour information	9
Adresse de l'auteur	9

1.	Introduction

La [RFC3680] définit un paquetage d'événements du protocole d’initialisation de session (SIP, Session Initiation Protocol) [RFC3261] pour l’état d’enregistrement. Ce paquetage permet à un observateur d’apprendre les informations mémorisées par un registraire SIP, incluant les contacts enregistrés.

Cependant, un contact enregistré est fréquemment inaccessible aux hôtes en-dehors du domaine de l’agent d'utilisateur (UA). C’est couramment une adresse privée, ou, quand c’est une adresse publique, son accès peut être bloqué par des pare-feu.

L’URI d’agent d'utilisateur mondialement acheminable (GRUU) défini dans la [RFC5627], est un URI qui accède à une instance d’UA particulière, mais est accessible par tout hôte de l’Internet. Les GRUU alloués par le registraire représentent un état d’enregistrement supplémentaire. Cependant, les GRUU alloués par le registraire ne sont pas inclus dans les notifications fournies par la RFC 3680. Pour de nombreuses applications de paquetage d'événement d'enregistrement, un GRUU est nécessaire, et pas le contact enregistré.

Par exemple, l’exemple de notices d’accueil dans la [RFC3680] va seulement opérer correctement si l’adresse de contact dans la notification d'événement d'enregistrement est accessible par l’envoyeur de la notice d’accueil. Quand l’appareil qui s’enregistre utilise l’extension GRUU, il est probable que l’adresse du contact enregistré ne va pas être mondialement adressable, et qu’un GRUU devrait être utilisé comme adresse cible du MESSAGE.

Un autre cas où cette caractéristique peut être utile est dans le sous système multimédia IP (IMS, IP Multimedia Subsystem) du projet en partenariat de troisième génération (3GPP, Third Generation Partnership Project). IMS emploie une technique où un REGISTER d’une adresse de contact à une adresse d’entretien (AOR, Address of Record) cause l’enregistrement implicite du même contact à d’autres AOR associées. Si des GRUU sont demandés et obtenus au titre de la demande d’enregistrement, des GRUU supplémentaires vont aussi être nécessaires pour les enregistrements implicites. Alors que l’allocation des GRUU supplémentaires est directe, en informer l’UA qui s’enregistre ne l’est pas. Dans l’IMS, les UA s’abonnent normalement aux événements d’enregistrement, et les abonnements à l’événement d’enregistrement pour une AOR résultent en notifications, chacune contenant l’état d’enregistrement de toutes les AOR associées. L’extension proposée fournit un moyen de livrer facilement les GRUU pour les AOR associées.

Comme spécifié dans la [RFC5627], les GRUU temporaires sont invalidés quand les liens d’adresse de contact pour l’AOR et l’identifiant d'instance correspondants ne sont pas rafraîchis, ou quand un enregistrement à l’AOR et identifiant d'instance est effectué avec un nouvel identifiant d’appel. Un UA ne peut pas toujours déterminer avec certitude quels GRUU temporaires sont valides sur la seule base de la réponse aux demandes REGISTER qu’il a produites, ou des notifications selon la [RFC3680]. L’extension définie dans le présent document donne des informations suffisantes pour qu’un UA détermine quels GRUU temporaires sont valides.

Le paquetage d'événement d'enregistrement a des dispositions pour inclure des éléments d’extension au sein de l’élément <contact>. Le présent document définit de nouveaux éléments qui peuvent être utilisés dans ce contexte pour livrer les GRUU publics et temporaires correspondants au contact.

2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

3.	Description

Deux nouveaux éléments (<pub-gruu> et <temp-gruu>) sont définis, dont chacun contient un GRUU. L’élément <temp-gruu> identifie aussi le plus vieux GRUU temporaire actuellement valide.

Ces éléments facultatifs peuvent être inclus dans le corps d’un NOTIFY pour le paquetage d'événement d'enregistrement quand des GRUU sont associés au contact. L’URI de contact et les GRUU sont alors tous disponibles à l’observateur.

4.	Traitement par le notificateur des demandes SUBSCRIBE

Il ne présente pas de changement par rapport à la [RFC3680].

5.	Génération par le notificateur des demandes NOTIFY

Un notificateur pour le paquetage d'événement d'enregistrement [RFC3680] DEVRAIT inclure l’élément <pub-gruu> quand un contact a un identifiant d'instance et qu’un GRUU public est associé à la combinaison de l’AOR et de l’identifiant d'instance. Quand il est présent, l’élément <pub-gruu> DOIT être positionné comme enfant de l’élément <contact>.

Un notificateur pour le paquetage d'événement d'enregistrement [RFC3680] PEUT inclure l’élément <temp-gruu> quand un contact a un identifiant d'instance et qu’un GRUU temporaire est associé à la combinaison de l’AOR et de l’identifiant d'instance. Cet élément DEVRAIT être inclus si l’abonné est aussi autorisé à s’enregistrer à l’AOR. Cet élément NE DEVRAIT PAS être inclus si l’abonné n’est pas autorisé à s’enregistrer à l’AOR, sauf si il y a une politique explicitement configurée qui impose qu’il soit inclus. Quand il est présent, l’élément <temp-gruu> DOIT être positionné comme un enfant de l’élément <contact>.

Noter qu’il est possible que plusieurs contacts enregistrés partagent le même identifiant d'instance. Dans ce cas, chaque élément <contact> va avoir des éléments fils <pub-gruu> et <temp-gruu>, qui sont identiques aux éléments fils correspondants dans les autres éléments <contact> qui partagent le même identifiant d'instance. Comme un contact particulier ne peut pas être associé à plus d’un identifiant d'instance, un élément <contact> ne va jamais avoir plus d’un élément fils <pub-gruu> et un élément fils <temp-gruu>.

Si le notificateur inclut l’élément <pub-gruu>, il DOIT remplir l’élément avec le GRUU public associé à l’identifiant d'instance et AOR du contact enregistré.

Si le notificateur inclut l’élément <temp-gruu>, il DOIT remplir l’élément avec le GRUU temporaire le plus récemment alloué qui est associé à l’identifiant d'instance et AOR du contact enregistré. Il DOIT aussi remplir l’élément avec un attribut "cseq" correspondant au premier (plus ancien) GRUU temporaire actuellement actif associé à l’identifiant d'instance et AOR du contact enregistré. La valeur de l’attribut "cseq" est réglée à la valeur du champ d’en-tête CSeq de la demande REGISTER qui a causé l’allocation du premier GRUU temporaire.

6.	Traitement par l’abonné des demandes NOTIFY

Quand un abonné reçoit une notification d'événement d'enregistrement avec un <contact> contenant un <pub-gruu>, il PEUT associer le GRUU public à l’AOR et identifiant d'instance correspondants. Tout GRUU public reçu précédemment pour le même AOR et identifiant d'instance DOIT être éliminé. (Il ne va plus fonctionner.)

Quand un abonné reçoit une notification d'événement d'enregistrement avec un <contact> contenant un <temp-gruu>, il PEUT associer le GRUU temporaire, avec les attributs "callid" et "cseq", à l’AOR et identifiant d'instance correspondants.

Les abonnés qui ignorent la présente extension vont, comme exigé par la [RFC3680], ignorer les éléments <pub-gruu> et <temp-gruu>.

6.1	Gestion de la durée de vie de GRUU temporaire
Le paragraphe 4.2 de la [RFC5627] donne des lignes directrices aux développeur d’UA sur la façon de s’assurer que seuls des GRUU temporaires valides sont conservés et utilisés par l’UA. Un UA ne peut pas toujours déterminer avec certitude quels GRUU temporaires sont valides sur la seule base des informations contenues dans les réponses aux demandes REGISTER qu’il a produites ou des informations contenues dans les notifications qui se conforment seulement à la [RFC3680]. L’extension définie dans le présent document donne des informations supplémentaires suffisantes pour qu’un UA détermine quels GRUU temporaires sont valides. Les extensions à la RFC 3680 définies dans ce document donnent les informations supplémentaires pour aider à ce processus. Les étapes que l’UA PEUT suivre pour s’assurer qu’il garde seulement les GRUU valides sont les suivantes :

o	L’UA devrait s’abonner au paquetage d'événement d'enregistrement pour l’AOR où il s’enregistre.

o	Quand un UA reçoit une réponse 2xx à une demande REGISTER, il peut extraire et conserver les GRUU temporaires provenant de la réponse pour des utilisations futures, tant qu’elles restent valides. Les GRUU appropriés à conserver sont ceux qui correspondent à l’adresse de contact et identifiant d'instance qu’il a enregistré. (Normalement, l’UA va enregistrer seulement une adresse de contact, et donc recevoir au plus un GRUU temporaire.)

o	L’UA peut ajouter le GRUU temporaire à l’ensemble des GRUU temporaires valides associé à l’AOR. (Noter que dans ce cas l’AOR est la "To-address" de la demande REGISTER.) Pour aider à retracer la validité, l’UA devrait aussi associer un attribut "callid" et un attribut "cseq" au GRUU temporaire, avec les valeurs obtenues respectivement des valeurs de Call-ID et CSeq de la réponse REGISTER contenant le GRUU temporaire.

o	Si l’UA reçoit une notification d'événement d'enregistrement avec un AOR (qu’il prend en charge) et un <contact>, pour une adresse de contact et identifiant d'instance (qu’il a enregistré et qui contient un <temp-gruu>) il peut mettre à jour son ensemble de GRUU temporaires valides associé à l’AOR, comme suit :
*	Il peut ajouter le GRUU temporaire à l’ensemble. Pour aider à retracer la validité, l’UA devrait associer les attributs "callid" et "cseq" du <contact> au GRUU dans l’ensemble.
*	Il devrait supprimer tous les GRUU temporaires avec une valeur d’attribut "callid" différente de celle de l’attribut "callid" du <contact>, ou avec un attribut "cseq" d’une valeur inférieure à la valeur de l’attribut "first-cseq" du <temp-gruu>.

o	Si l’UA reçoit une notification d'événement d'enregistrement avec une AOR qu’il prend en charge, et qu’il n’y a pas d’entrées <contact> pour cet identifiant d'instance, il devrait alors éliminer tous les GRUU temporaires qu’il a sauvegardés pour cette AOR.

7.	Exemple de document reginfo

Note : cet exemple et les autres dans la section suivante sont affichés avec des retraits pour améliorer la lisibilité par l’ajout d’un nombre fixe d’espaces au début de chaque ligne. Ces espaces ne font pas partie de l’exemple. Les conventions de la [RFC4475] sont utilisées pour décrire la représentation des lignes longues de message.

Voici un exemple de document d’informations d’enregistrement qui inclut le nouvel élément :

<?xml version="1.0"?>
    <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
        xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
        version="0" state="full">
      <registration aor="sip:user@exemple.com" id="as9"
           state="active">
        <contact id="76" state="active" event="registered"
           duration-registered="36001" expires="3599"
           callid="1j9FpLxk3uxtm8tn@192.0.2.1" cseq="54321"
           q="0.8">
             <uri>sip:user@192.0.2.1</uri>
<allOneLine>
             <unknown-param name="+sip.instance">
             "&lt;urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;"</unknown-param>
</allOneLine>
             <gr:pub-gruu uri="sip:user@exemple.com;gr=hha9s8d-999a"/>
             <gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@exemple.com ;gr" first-cseq="54301"/>
        </contact>
      </registration>
    </reginfo>

8.	Exemples

Note : dans les exemples suivants, les messages SIP ont été simplifiés en supprimant les en-têtes qui ne sont pas pertinents pour l’exemple.

Quand la valeur du champ d’en-tête Content-Length est "...", cela signifie que la valeur devrait être la longueur calculée du corps.

8.1	Exemple : notice d’accueil
Considérons l’exemple de notices d’accueil de la [RFC3680]. Quand le serveur d’application reçoit une notification d’un nouvel enregistrement contenant les reginfo montrées à la Section 7, il devrait adresser les messages en utilisant le GRUU public contenu comme suit :

MESSAGE sip:user@exemple.com;gr=hha9s8d-999a SIP/2.0
To: <sip:user@exemple.com>
From: "SIPland Notifier" <sip:notifier@exemple.com>;tag=7xy8
Content-Type: text/plain
Content-Length: ...
Bienvenue à SIPland !
Bla, bla, bla.

8.2	Exemple : enregistrement implicite
Dans un dispositif d’IMS 3GPP, un UA peut envoyer un seul message REGISTER, demandant l’allocation de GRUU, comme suit :

REGISTER sip:exemple.net SIP/2.0
From: <sip:user_aor_1@exemple.net>;tag=5ab4
To: <sip:user_aor_1@exemple.net>
Call-ID: faif9a@ua.exemple.com
CSeq: 23001 REGISTER
Contact: <sip:ua.exemple.com>
;expires=3600
;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
Supported: path, gruu
Content-Length: 0

La réponse rapporte le succès de l’enregistrement et retourne les GRUU alloués pour la combinaison de AOR, identifiant d'instance, et Contact. Elle indique aussi (via l’en-tête P-Associated-URI [RFC3455]) qu’il y a deux autres AOR associées qui peuvent avoir été implicitement enregistrées en utilisant le même contact. Chacune de ces AOR implicitement enregistrée va avoir un GRUU unique alloué. La réponse REGISTER ne va pas inclure ces GRUU ; elle va seulement inclure les GRUU pour l’AOR et l’identifiant d'instance explicitement inclus dans l’enregistrement.

SIP/2.0 200 OK
From: <sip:user_aor_1@exemple.net>;tag=5ab4
To: <sip:user_aor_1@exemple.net>;tag=373392
Call-ID: faif9a@ua.exemple.com
CSeq: 23001 REGISTER
Path: <sip:mandataire.exemple.net;lr>
Service-Route: <sip:mandataire.exemple.net;lr>
Contact: <sip:ua.exemple.com>
  ;expires=3600
  ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"
  ;pub-gruu="sip:user_aor_1@exemple.net;gr=hha9s8d-999a"
  ;temp-gruu="sip:8ffkas08af7fasklzi9@exemple.net;gr"
P-Associated-URI: <sip:user_aor_2@exemple.net>,
  <sip:+358504821437@exemple.net;user=phone>
Content-Length: 0

L’UA s’abonne alors au paquetage d'événement d'enregistrement comme suit :

SUBSCRIBE sip:user_aor_1@exemple.net SIP/2.0
From: <sip:user_aor_1@exemple.net>;tag=27182
To: <sip:user_aor_1@exemple.net>
Call-ID: gbjg0b@ua.exemple.com
CSeq: 45001 SUBSCRIBE
Route: <sip:mandataire.exemple.net;lr>
Event: reg
Expires: 3600
Accept: application/reginfo+xml
Contact: <sip:user_aor_1@exemple.net;gr=hha9s8d-999a>
Content-Length: 0

(La réponse de succès à l’abonnement n’est pas montrée.) Une fois l’abonnement établi, une notification initiale est envoyée qui donne l’état de l’enregistrement. Dans les déploiements d’IMS, la réponse inclut, en plus de l’état pour l’URI demandé, l’état des autres URI associés.

NOTIFY sip:user_aor_1@exemple.net;gr=hha9s8d-999a SIP/2.0
From: <sip:user_aor_1@exemple.net>;tag=27182
To: <sip:user_aor_1@exemple.net>;tag=262281
Call-ID: gbjg0b@ua.exemple.com
CSeq: 633 NOTIFY
Subscription-State: active;expires=3600
Event: reg
Content-Type: application/reginfo+xml
Contact: <sip:registrar.exemple.net>
Content-Length: ...

<?xml version="1.0"?>
    <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
        xmlns:gr="urn:ietf:params:xml:ns:gruuinfo"
        version="1" state="full">
      <registration aor="sip:user_aor_1@exemple.net" id="a7"
           state="active">
        <contact id="92" state="active" event="registered"
           duration-registered="1" expires="3599"
           callid="faif9a@ua.exemple.com" cseq="23001">
             <uri>
                sip:ua.exemple.com
             </uri>
<allOneLine>
             <unknown-param name="+sip.instance">"&lt;urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;"
     </unknown-param>
</allOneLine>
             <gr:pub-gruu uri="sip:user_aor_1@exemple.net;gr=hha9s8d-999a"/>
             <gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@exemple.net;gr" first-cseq="54301"/>
        </contact>
      </registration>
      <registration aor="sip:user_aor_2@exemple.net" id="a8"
           state="active">
       <contact id="93" state="active" event="created"
           duration-registered="1" expires="3599"
           callid="faif9a@ua.exemple.com" cseq="23001">
             <uri>
                sip:ua.exemple.com
             </uri>
  <unknown-param name="+sip.instance">"&lt;urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;"</unknown-param>
            <gr:pub-gruu uri="sip:user_aor_2@exemple.net;gr=hha9s8d-999b"/>
             <gr:temp-gruu uri="sip:07hcovy36vp6vngvbia@exemple.net;gr" first-cseq="54301"/>
        </contact>
      </registration>
      <registration
           aor="sip:+358504821437@exemple.net;user=phone"
           id="a9"
           state="active">
       <contact id="94" state="active" event="created"
           duration-registered="1" expires="3599"
          callid="faif9a@ua.exemple.com" cseq="23001">
             <uri>
               sip:ua.exemple.com
             </uri>
<allOneLine>
     <unknown-param name="+sip.instance">
     "&lt;urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6&gt;"
     </unknown-param>
</allOneLine>
             <gr:pub-gruu uri="sip:+358504821437@exemple.net;user=phone;gr=hha9s8d-999c"/>
             <gr:temp-gruu uri="sip:h99egjbv17fe8ibvlka@exemple.net;gr" first-cseq="54301"/>
        </contact>
      </registration>
    </reginfo>

L’état indique que les URI associés ont tous le même contact enregistré. Il inclut aussi les GRUU uniques qui ont été alloués à chacun. L’UA peut alors retenir ces GRUU pour les utiliser à établir des dialogues utilisant les AOR correspondantes.

9.	Définition du schéma XML

Les éléments <pub-gruu> et <temp-gruu> sont définis dans un nouvel URI d’espace de noms XML. Cet espace de noms est "urn:ietf:params:xml:ns:gruuinfo". Le schéma pour ces éléments est :

<?xml version="1.0" encoding="UTF-8"?>
  <xs:schema targetNamespace="urn:ietf:params:xml:ns:gruuinfo"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:tns="urn:ietf:params:xml:ns:gruuinfo">
    <xs:complexType name="pubGruu">
      <xs:attribute name="uri" type="xs:anyURI" use="required"/>
    </xs:complexType>
    <xs:complexType name="tempGruu">
      <xs:complexContent>
        <xs:extension base="tns:pubGruu">
          <xs:attribute name="first-cseq" type="xs:unsignedLong" use="required"/>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
    <xs:element name="pub-gruu" type="tns:pubGruu"/>
    <xs:element name="temp-gruu" type="tns:tempGruu"/>
  </xs:schema>

10.	Considérations relatives à l'IANA

Deux points à considérer pour l’IANA sont associés à cette spécification.

10.1	Enregistrement du sous espace de noms d’URN
Ce paragraphe enregistre un nouvel espace de noms XML, selon les lignes directrices de la [RFC3688].

URI : l’URI de cet espace de noms est urn:ietf:params:xml:ns:gruuinfo

Contact d’enregistrement : IETF, groupe de travail SIPPING, <sipping@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>

XML :

DÉBUT
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type"
     content="text/html;charset=iso-8859-1"/>
  <title>Reg Information GRUU Extension Namespace</title>
</head>
<body>
   <h1>Namespace for Reg Information GRUU Extension</h1>
   <h2>urn:ietf:params:xml:ns:gruuinfo</h2>
   <p>See <a href="http://www.rfc-editor.org/rfc/rfc5628.txt">
      RFC5628</a>.</p>
 </body>
</html>
FIN

10.2	Enregistrement du schéma XML
Ce paragraphe enregistre un schéma XML selon les procédures de la [RFC3688].

URI : urn:ietf:params:xml:schema:gruuinfo.

Contact d’enregistrement : IETF, groupe de travail SIPPING, <sipping@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>

Le XML pour ce schéma se trouve à la Section 9.

11.	Considérations sur la sécurité

Les considérations sur la sécurité pour le paquetage d'événement d'enregistrement sont discutées dans la [RFC3680], et ces considérations s’appliquent ici.

Si une adresse de contact obtenue via un abonnement au paquetage d'événement d'enregistrement n’est pas accessible par l’abonné, sa divulgation peut difficilement être considérée comme un risque de sécurité minimal. Dans ce cas, l’inclusion d’un GRUU peut être considérée comme augmentant le risque en fournissant une adresse accessible. Par ailleurs, les demandes adressées à un GRUU sont toujours d’abord traitées par le mandataire de service avant qu’elles atteignent l’agent d'utilisateur prévu. Le mandataire peut contrôler l’accès comme désiré, tout comme il le peut pour l’AOR. Par exemple, le mandataire qui dessert un GRUU peut accepter des demandes provenant d’envoyeurs dont l’identité apparaît sur une liste blanche, et rejeter les autres demandes. À cet égard, la divulgation d’un GRUU ne présente pas plus de risques que celle de l’AOR.

Les GRUU temporaires posent un problème de sécurité supplémentaire. L’intention du GRUU temporaire est de fournir une adresse de contact qui ne peut pas être corrélée à l’identité de l'appelant. Le receveur d’un appel qui utilise un GRUU temporaire peut deviner l’identité de l'appelant et ensuite tenter d’obtenir les GRUU temporaires alloués à cet appelant pour confirmer la conjecture. Deux approches possibles pour obtenir les GRUU temporaires sont :
o	envoyer une demande REGISTER à un appelant supposé  ;
o	envoyer une demande SUBSCRIBE pour le paquetage d'événement d'enregistrement à l’appelant supposé.

Normalement, REGISTER est restreint aux appareils ou utilisateurs qui sont autorisés à générer et recevoir des appels avec l’AOR. L’anonymat parmi les utilisateurs de la même AOR est difficile à réaliser et normalement n’est pas nécessaire. Il est recommandé (voir la Section 5) que la politique d'autorisation pour le paquetage d'événement d'enregistrement permette seulement aux abonnés qui sont autorisés à s’enregistrer à l’AOR de recevoir des GRUU temporaires. Avec cette politique, la confidentialité du GRUU temporaire va être la même avec et sans le paquetage d'événement d'enregistrement. Les agents d'utilisateur qui utilisent un GRUU temporaire devraient noter que la confidentialité ne s’étend pas aux parties à qui il est permis de s’enregistrer à l’AOR ou d’obtenir le GRUU temporaire quand elles s’abonnent au paquetage d'événement d'enregistrement.

12.	Remerciements

L’auteur tient à remercier Jonathan Rosenberg de son aide pour ce document, et Jari Urpalainen pour son assistance sur le XML.

13.	Références
13.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. (MàJ par RFC8174)

[RFC3680]	J. Rosenberg, "Paquetage d'événements du protocole d'initialisation de session (SIP) pour les enregistrements", mars  2004. (P.S.)

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

[RFC5627]	J. Rosenberg, "Obtention et utilisation des URI d'agent d'utilisateur mondialement acheminable (GRUU) dans le protocole d'initialisation de session (SIP)", octobre 2009. (P. S.)

13.2	Références pour information

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3455]	M. Garcia-Martin, E. Henrikson, D. Mills, "Extensions d'en-têtes privés (P-Header) au protocole d'initialisation de session (SIP) pour le projet en partenariat de 3ème génération (3GPP)", janvier 2003. (Information)

[RFC4475]	R. Sparks et autres, "Messages d'essais de résistance du protocole d'initialisation de session (SIP)", mai 2006. (Info.)

Adresse de l'auteur
Paul H. Kyzivat
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA  01719
USA
mél : pkyzivat@cisco.com