Groupe de travail Réseau	G. Camarillo, Ericsson
Request for Comments : 5366	A. Johnston, Avaya
Catégorie : Sur la voie de la normalisation	
Traduction Claude Brière de L'Isle	octobre 2008

Établissement de conférence en utilisant des listes contenues dans des demandes dans le protocole d'initialisation de session (SIP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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.

Résumé
Le présent document décrit comment créer une conférence en utilisant les services SIP URI-list. En particulier, il décrit un mécanisme qui permet à un client d’agent d’utilisateur de fournir à un serveur de conférence la liste initiale des participants en utilisant une liste d’URI contenue dans INVITE.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Procédures du client d’agent d’utilisateur	2
3.1 Traitement de la réponse	2
3.2 Génération de la demande Re-INVITE	2
4. Format du document URI-List	2
5. Procédures du serveur de conférence	3
5.1 Traitement de la demande Re-INVITE	4
6. Exemple	4
7. Considérations sur la sécurité	6
11. Considérations relatives à l’IANA	6
9. Remerciements	7
10. Références	7
10.1 Références normatives	7
10.2 Références pour information	7
Adresse des auteurs	8
Déclaration complète de droits de reproduction	8

 	1.	Introduction

Le paragraphe 5.4 de la [RFC4579] décrit comment créer une conférence en utilisant des méthodes SIP ad hoc [RFC3261].  Le client envoie une demande INVITE à un URI de fabrique de conférences et reçoit l’URI de conférence réel, qui contient l’étiquette de dispositif "isfocus", dans le champ d'en-tête Contact d’une réponse -- normalement une réponse 200 (OK).

Une fois que le client d’agent d’utilisateur (UAC, User Agent Client) a obtenu l’URI de conférence, il peut ajouter des participants à la conférence nouvellement créée de plusieurs façons, qui sont décrites dans la [RFC4579].

Certains environnements ont des exigences fortes en ce qui concerne l’heure d’établissement de la conférence. Ils exigent que l’UAC soit capable de demander la création d’une conférence ad hoc et de fournir au serveur de conférence l’ensemble initial de participants dans une seule opération. Le présent document décrit comment satisfaire cette exigence en utilisant le mécanisme de transport des listes d’URI dans les messages SIP décrits dans la [RFC5363].

 	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.	Procédures du client d’agent d’utilisateur

Un UAC qui veut inclure l’ensemble initial de participants dans sa demande INVITE initiale de créer une conférence ad hoc ajoute un corps dont le type de disposition est "recipient-list", comme défini dans la [RFC5363], avec une liste d'URI qui contient les participants que l’UAC veut que le serveur de conférence invite. De plus, l’UAC DOIT inclure l’étiquette d’option "recipient-list-invite" (qui est enregistrée par l’IANA à la Section 8) dans un champ d'en-tête Require. L’UAC envoie cette demande INVITE à l’URI de fabrique de conférences.

La transaction INVITE fait aussi partie d’un échange offre/réponse qui va établir une session entre l’UAC et le serveur de conférence, comme spécifié dans la [RFC4579]. Donc, la demande INVITE peut avoir besoin de porter un corps multi parties : une description de session et une liste d'URI.

 	3.1	Traitement de la réponse
Le code d’état dans la réponse à la demande INVITE ne fournit aucune information sur si le serveur de conférence est ou non capable d’amener les utilisateurs de la liste d'URI dans la conférence. C'est-à-dire, une réponse 200 (OK) signifie que la conférence a bien été créée, que l’UAC qui a généré la demande INVITE est dans la conférence, et que le serveur comprend la liste d'URI. Si l’UAC souhaite obtenir des informations l’état des autres utilisateurs dans la conférence, il DEVRAIT utiliser les mécanismes généraux de conférence, comme le paquetage de conférence, qui est défini dans la [RFC4575].

 	3.2	Génération de la demande Re-INVITE
Le paragraphe précédent a spécifié comment inclure une liste d'URI dans une demande INVITE initiale à un serveur de conférence. Une fois que le dialogue initié par l’INVITE entre l’UAC et le serveur de conférence a été établi, l’UAC peut envoyer des demandes INVITE suivantes (normalement appelées des re-demandes INVITE) au serveur de conférence pour, par exemple, modifier les caractéristiques des supports échangés avec le serveur.

À ce point, il n’y a pas de signification associée au corps "recipient-list" dans les re-demandes INVITE (bien due de futures extensions puissent en définir). Donc, les UAC NE DEVRAIENT PAS inclure de corps "recipient-list" dans des re-demandes INVITE envoyées à un serveur de conférence.

Noter qu’une différence entre une demande INVITE initiale et une re-demande INVITE est que alors que la demande INVITE initiale est envoyée à l’URI de fabrique de conférences, les re-demandes INVITE sont envoyées à l’URI fourni par le serveur dans un champ d'en-tête Contact quand le dialogue est établi. Donc, du point de vue de l’UAC, la ressource identifiée par l’URI précédent prend en charge le corps "recipient- list", tandis que la ressource identifiée par le dernier ne le prend pas en charge.

 	4.	Format du document URI-List

Comme décrit dans la [RFC5363], les spécifications de services de liste d'URI individuels, comme le service de conférence décrit ici ont besoin de spécifier un format par défaut pour le corps "recipient-list" utilisé dans le service particulier

Le format par défaut pour le corps "recipient-list" pour les UA de conférence est le format XML de liste de ressources (qui est spécifié dans la [RFC4826]) étendu par "Extension de format du langage de balisage extensible (XML) pour la représentation des attributs de contrôle de copie dans les listes de ressources" [RFC5364]. Par conséquent, les UAC de conférence qui génèrent des corps "recipient-list" DOIVENT prendre en charge ces deux formats et PEUVENT prendre en charge d’autres formats. Les serveurs de conférence capables de traiter les corps "recipient-list" DOIVENT prendre en charge ces deux formats et PEUVENT prendre en charge d’autres formats.

Comme décrit dans la [RFC5364], chaque URI peut être étiqueté avec un attribut "copyControl" réglé à "to", "cc", ou "bcc", qui indique le rôle dans lequel le receveur va obtenir la demande INVITE. De plus, les URI peuvent être étiquetés avec l’attribut "anonymize" pour empêcher le serveur de conférence de divulguer l’URI cible dans une liste d'URI.

De plus, la [RFC5364] définit un corps "recipient-list-history" qui contient la liste de receveurs. Le format par défaut pour le corps "recipient-list-history" pour les UA de conférence est aussi le format de document XML de liste de ressources spécifié dans la [RFC4826] étendu par la [RFC5364]. Par conséquent, les UAC de conférence capables de générer un corps "recipient-list-history" DOIVENT prendre en charge ces formats et PEUVENT en supporter d’autres. Les UA de conférence capables de comprendre "recipient-list-history" DOIVENT prendre en charge ces formats et PEUVENT en prendre en charge d’autres. Les serveurs de conférence capables de traiter les corps "recipient-list-history" DOIVENT prendre en charge ces formats et PEUVENT en supporter d’autres.

Néanmoins, le document XML de liste de ressources spécifié dans la [RFC4826] donne des caractéristiques, telles que des listes hiérarchiques et la capacité d’inclure des entrées par référence relatives à l’URI racine du protocole d’accès à la configuration XML (XCAP, XML Configuration Access Protocol) qui ne sont pas nécessaires pour le service de conférence défini dans ce document, qui a seulement besoin de transférer une liste plate des URI entre un UA (agent d’utilisateur) et le serveur de conférence. Donc, quand on utilise le document de liste de ressources par défaut, les UA de conférence DEVRAIENT utiliser des listes plates (c'est-à-dire, pas des listes hiérarchiques) et NE DEVRAIENT PAS utiliser des éléments <entry-ref>. Une application de fabrique de conférence qui reçoit une liste d'URI avec plus d’informations que ce qui vient d’être décrit PEUT éliminer toutes les informations supplémentaires.

La Figure 1 montre un exemple d’une liste plate qui suit le document XML de liste de ressources (spécifié dans la [RFC4826]) étendue par la [RFC5364].

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
          xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
  <list>
    <entry uri="sip:bill@exemple.com" cp:copyControl="to"  />
    <entry uri="sip:joe@exemple.org" cp:copyControl="cc" />
    <entry uri="sip:ted@exemple.net" cp:copyControl="bcc" />
  </list>
</resource-lists>

Figure 1 : Liste d’URI

 	5.	Procédures du serveur de conférence

Les serveurs de conférences qui sont capables de recevoir et traiter les demandes INVITE avec un corps "recipient-list'" DEVRAIENT inclure une étiquette d’option "recipient-list-invite" dans un champ d'en-tête Supported quand ils répondent aux demandes OPTIONS.

À réception d’une demande INVITE contenant un corps "recipient-list" comme décrit à la Section 3, un serveur de conférence DOIT suivre les règles décrites dans la [RFC4579] pour créer des conférences ad hoc. Une fois la conférence ad hoc créée, le serveur de conférence DEVRAIT tenter d’ajouter les participants dans la liste d'URI à la conférence comme si leur ajout avait été demandé en utilisant une des méthodes décrites dans la [RFC4579].

La transaction INVITE fait aussi partie d’un échange offre/réponse qui va établir une session entre l’UAC et le serveur de conférence, comme spécifié dans la [RFC4579]. Donc, la demande INVITE peut porter un corps multi parties : une description de session et une liste d'URI.

Une fois que le serveur de conférence a créé la conférence ad hoc et a tenté d’ajouter l’ensemble initial de participants, le serveur de conférence se comporte comme un serveur de conférence régulier et DOIT suivre les règles de la [RFC4579].

La demande INVITE entrante va contenir un corps ou une référence de liste d’URI (comme spécifié dans la [RFC5363]) avec la liste réelle des receveurs. Si cette liste d'URI inclut des ressources étiquetées avec l’attribut "copyControl" réglé à une valeur de "to" ou "cc", le serveur de conférence DEVRAIT inclure une liste d'URI dans chacune des demandes INVITE sortantes. Cette liste DEVRAIT être formatée conformément au format XML pour représenter les listes de ressources (spécifié dans la [RFC4826]) et l’extension copyControl spécifiée dans la [RFC5364].

Le service de liste d'URI DOIT suivre les procédures spécifiées dans la [RFC5364] à l’égard du traitement des attributs "anonymize", "count", et "copyControl".

Si le serveur de conférence inclut une liste d'URI dans une demande INVITE sortante, il DOIT inclure un champ d'en-tête Content-Disposition (qui est spécifié dans la [RFC2183]) avec la valeur réglée à "recipient-list-history" et un paramètre "handling" (comme spécifié dans la [RFC3204]) réglé à "optional".

 	5.1	Traitement de la demande Re-INVITE
À ce point, il n’y a pas de signification associée au corps "recipient-list" dans les re-demandes INVITE (bien que de futures extensions puissent en définir une). Donc, un serveur de conférence qui reçoit une re-demande INVITE avee un corps "recipient-list" et, par conséquent, une étiquette d’option "recipient-list-invite", suivant les procédures standard de SIP, la rejette avec un 420 (Mauvaise extension) qui porte un champ d'en-tête Unsupported faisant la liste des étiquettes d’option "recipient-list-invite".

C’est parce que la ressource identifiée par l’URI de conférence ne prend en fait pas cette extension. Par ailleurs, la ressource identifiée par l’URI de fabrique de conférences prend en charge cette extension et, par conséquent, inclurait l’étiquette d’option "recipient-list-invite" dans, par exemple, des réponses aux demandes OPTIONS.

 	6.	Exemple

La Figure 2 montre un exemple du fonctionnement. Un UAC envoie une demande INVITE (F1) qui contient un corps SDP et une liste d'URI au serveur de conférence. Le serveur de conférence répond avee un 200 (OK) et génère une demande INVITE à chacun des UAS (serveurs d’agent d’utilisateur) identifié par les URI inclus dans la liste d'URI. Le serveur de conférence inclut le SDP et une liste d'URI manipulée dans chacune des demandes INVITE sortantes.

   +--------+        +---------+      +--------+ +--------+ +--------+
   |UAC SIP |        | Serveur |      |UAS SIP | |UAS SIP | |UAS SIP |
   |        |        |de conf. |      |   1    | |   2    | |   n    |
   +--------+        +---------+      +--------+ +--------+ +--------+
       |                  |               |          |          |
       | F1 INVITE        |               |          |          |
       | ---------------->|               |          |          |
       | F2 200 OK        |               |          |          |
       |<---------------- |  F3 INVITE    |          |          |
       |                  | ------------->|          |          |
       |                  |  F4 INVITE    |          |          |
       |                  | ------------------------>|          |
       |                  |  F5 INVITE    |          |          |
       |                  | ----------------------------------->|
       |                  |  F6 200 OK    |          |          |
       |                  |<------------- |          |          |
       |                  |  F7 200 OK    |          |          |
       |                  |<------------------------ |          |
       |                  |  F8 200 OK    |          |          |
       |                  |<----------------------------------- |
       |                  |               |          |          |
       |                  |               |          |          |

Figure 2 : Exemple de fonctionnement

La Figure 3 montre un exemple de la demande INVITE F1, qui porte un corps multi parties/mixte composé de deux autres corps : un corps application/sdp qui décrit la session et un corps application/resource-lists+xml qui contient la liste des URI cibles.

INVITE sip:conf-fact@exemple.com SIP/2.0
Via: SIP/2.0/TCP atlanta.exemple.com; branch=z9hG4bKhjhs8ass83
Max-Forwards: 70
To: "Conf Factory" <sip:conf-fact@exemple.com>
From: Alice <sip:alice@exemple.com>;tag=32331
Call-ID: d432fa84b4c76e66710
CSeq: 1 INVITE
Contact: <sip:alice@atlanta.exemple.com>
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog
Accept: application/sdp, message/sipfrag
Require: recipient-list-invite
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690

--boundary1
Content-Type: application/sdp

v=0
o=alice 2890844526 2890842807 IN IP4 atlanta.exemple.com
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 20000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 20002 RTP/AVP 31
a=rtpmap:31 H261/90000

--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cp="urn:ietf:params:xml:ns:copyControl">
  <list>
    <entry uri="sip:bill@exemple.com" cp:copyControl="to" />
    <entry uri="sip:randy@exemple.net" cp:copyControl="to" cp:anonymize="true"/>
    <entry uri="sip:eddy@exemple.com" cp:copyControl="to" cp:anonymize="true"/>
    <entry uri="sip:joe@exemple.org" cp:copyControl="cc" />
    <entry uri="sip:carol@exemple.net" cp:copyControl="cc" cp:anonymize="true"/>
    <entry uri="sip:ted@exemple.net" cp:copyControl="bcc" />
    <entry uri="sip:andy@exemple.com" cp:copyControl="bcc" />
  </list>
</resource-lists>
--boundary1--

Figure 3 : Demande INVITE reçue au serveur de conférence

Les demandes INVITE F3, F4, et F5 sont de nature similaire. Toutes ces demandes INVITE contiennent un corps multipart/mixed qui est composé de deux autres corps : un corps application/sdp qui décrit la session et un corps application/resource-lists+xml qui contient la liste des receveurs. Le corps application/resource-lists+xml n’est pas égal au application/resource-lists+xml inclus dans la demande INVITE F1 reçue, parce que le serveur de conférence a anonymisé ces URI étiquetés avee l’attribut "anonymize" et a supprimé les URI étiquetés avee un attribut "copyControl" de "bcc". La Figure 4 montre un exemple du message F3.

INVITE sip:bill@exemple.com SIP/2.0
Via: SIP/2.0/TCP conference.exemple.com ;branch=z9hG4bKhjhs8as454
Max-Forwards: 70
To: <sip:bill@exemple.com>
From: serveur de conférence <sip:conf34@exemple.com>;tag=234332
Call-ID: 389sn189dasdf
CSeq: 1 INVITE
Contact: <sip:conf34@conference.exemple.com>;isfocus
Allow: INVITE, ACK, CANCEL, BYE, REFER
Allow-Events: dialog, conference
Accept: application/sdp, message/sipfrag
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 690

--boundary1
Content-Type: application/sdp

v=0
o=conf 2890844343 2890844343 IN IP4 conference.exemple.com
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 40000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 40002 RTP/AVP 31
a=rtpmap:31 H261/90000

--boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list-history; handling=optional

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
  <list>
    <entry uri="sip:bill@exemple.com" cp:copyControl="to" />
    <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to" cp:count="2"/>
     <entry uri="sip:joe@exemple.org" cp:copyControl="cc" />
    <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc" cp:count="1"/>
  </list>
</resource-lists>
--boundary1--

Figure 4  : Demande INVITE envoyée par le serveur de conférence

 	7.	Considérations sur la sécurité

Le présent document discute de l’établissement de conférences SIP en utilisant une liste d'URI contenus dans la demande.  Les services de conférence et de liste d'URI ont des exigences de sécurité spécifiques, qui sont résumées ici. Les conférences ont généralement des règles d’autorisation sur qui peut ou ne peut pas se joindre à une conférence, quels types de supports peuvent ou ne peuvent pas être utilisés, etc. Ces informations sont utilisées par le point de concentration pour admettre ou refuser la participation à une conférence. Il est RECOMMANDÉ que ces types de règles d’autorisation soient utilisés pour assurer la sécurité d’une conférence SIP.

Pour que ces informations d’autorisation soient utilisées, le point de concentration doit être capable d’authentifier les participants potentiels. Les mécanismes SIP normaux, incluant l’authentification par résumé et les certificats, peuvent être utilisés. Ces exigences de sécurité spécifiques de la conférence sont discutées plus en détails dans les documents d’exigences et de cadre – les [RFC4245] et [RFC4353].

Pour la création de conférence utilisant une liste, il y a des considérations de sécurité supplémentaires. La [RFC5363] "Cadre et considérations sur la sécurité pour les services de liste d’URI du protocole d’initialisation de session (SIP)" discute les questions relatives aux services de liste d'URI SIP. Étant donné qu’un serveur de conférence qui envoie des demandes INVITE à un ensemble d’utilisateurs agit comme un service de liste d'URI, les mises en œuvre de serveur de conférences qui traitent des listes DOIVENT suivre les règles relatives à la sécurité de la [RFC5363]. Ces règles incluent des listes d’inclusion et l’authentification et l’autorisation obligatoires des clients.

 	11.	Considérations relatives à l’IANA

Le présent document définit l’étiquette d’option "recipient-list-invite" SIP. Elle a été enregistrée dans le sous registre Étiquettes d’option du registre des paramètres SIP. Voici la description utilisée dans l’enregistrement :

Nom	Description	Référence	
recipient-list- invite	Le corps contient une liste d’URI qui indique les receveurs de la demande SIP INVITE	[RFC5366]	

Tableau 1 : Enregistrement de l’étiquette d’option "recipient-list-invite" dans SIP

 	9.	Remerciements

Cullen Jennings, Hisham Khartabil, Jonathan Rosenberg, et Keith Drage ont fourni des commentaires utiles sur ce document. Miguel Garcia-Martin a rassemblé les dépendances à l’extension d’attribut "copyControl".

 	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. (MàJ par RFC8174)

[RFC2183]	R. Troost, S. Dorner, K. Moore, éd., "Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition", août 1997. (MàJ par RFC2184, RFC2231) (P.S.)

[RFC3204]	E. Zimmerer et autres, "Types de support MIME pour objets ISUP et QSIG", décembre 2001. (MàJ par RFC3459) (P.S.)

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

[RFC4579]	A. Johnston, O. Levin, "Commande d'appel du protocole d'initialisation de session (SIP) – Conférence pour agents d'utilisateur", août 2006. (BCP0119)

[RFC4826]	J. Rosenberg, "Formats du langage de balisage extensible (XML) pour représenter des listes de ressources", mai 2007. (P.S.)

[RFC5363]	G. Camarillo, A.B. Roach, "Cadre et considérations sur la sécurité pour les services URI-List du protocole d'initialisation de session (SIP)", octobre 2008. (P.S.)

[RFC5364]	M. Garcia-Martin, G. Camarillo, "Extension de format du langage de balisage extensible (XML) pour la représentation des attributs de contrôle de copie dans les listes de ressources", octobre 2008. (P.S.)

 	10.2	Références pour information

[RFC4245]	O. Levin, R. Even, "Exigences de haut niveau pour la conférence SIP à couplage étroit", novembre 2005. (Information)

[RFC4353]	J. Rosenberg, "Cadre pour les conférences avec le protocole d'initialisation de session (SIP)", février 2006. (Information)

[RFC4575]	J. Rosenberg et autres, "Paquetage d'événement du protocole d'initialisation de session (SIP) pour l'état Conference", août  2006. (P.S.)

 	Adresse des auteurs

Gonzalo Camarillo	Alan Johnston	
Ericsson	Avaya	
Hirsalantie 11	St. Louis, MO  63124	
Jorvas  02420	USA	
Finland	mél : alan@sipstation.com	
mél : Gonzalo.Camarillo@ericsson.com		

 	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2008)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole 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.