Groupe de travail Réseau	G. Vaudreuil, Lucent Technologies	
Request for Comments : 4237		
Catégorie : Sur la voie de la normalisation		
Traduction Claude Brière de L'Isle	octobre 2005	

Service de répertoire de messagerie vocale

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (2005).

Résumé
Le présent document fournit les détails du service de répertoire du profil vocal pour la messagerie Internet (VPIM, Voice Profile for Internet Mail). Le service fournit l'adresse de messagerie électronique du receveur auquel est donné un numéro de téléphone. Il fournit facultativement le nom prononcé du receveur et les capacités de support du receveur.

Le schéma de répertoire VPIM donne les attributs supplémentaires essentiels pour recréer l'expérience de l'utilisateur de messagerie vocale en utilisant des répertoires standardisés. L'expérience de l'utilisateur fournit, au moment de l'adressage, les assurances de base que le message sera délivré comme prévu. Le présent document combine deux documents antérieurs, l'un de Anne Brown et l'autre de Greg Vaudreuil, qui définissent un schéma de messagerie vocale en une seule soumission du groupe de travail.
Table des matières
1. Domaine d'application	2
1.1 Objectifs de conception	2
1.2 Contraintes de performances	2
1.3 Contraintes d'adaptabilité	2
1.4 Contraintes de fiabilité	2
2. Schéma de répertoire VPIMUser	2
2.1 vPIMTelephoneNumber	2
2.2 vPIMRfc822Mailbox	3
2.3 vPIMSpokenName	3
2.4 vPIMTextName	3
2.5 vPIMSupportedAudioMediaTypes	3
2.6 vPIMSupportedMessageContext	4
2.7 vPIMExtendedAbsenceStatus	4
2.8 vPIMSupportedUABehaviors	4
2.9 vPIMMaxMessageSize	5
2.10 vPIMSubMailboxes	5
3. Considérations sur la sécurité	5
4. Considérations relatives à l'IANA	6
4.1 Identifiants d'objet	6
4.2 Descripteurs d'identifiant d'objet	6
5. Références	6
5.1 Références normatives	6
5.2 Références pour information	7
Remerciements	7
Adresse de l'auteur	7
Déclaration complète de droits de reproduction	7

 	1.	Domaine d'application
 	1.1	Objectifs de conception
Le schéma de répertoire VPIM (VPIMDIR, VPIM directory Schema) est accédé de l'extérieur du domaine du fournisseur de service de l'entreprise ou du service en utilisant le numéro de téléphone du receveur.

 	1.2	Contraintes de performances
Une fois que l'identité du serveur de répertoire VPIM est connue, les informations de confirmation d'adresse de messagerie, des capacités, et du nom parlé peuvent être restituées. Cette interrogation est supposée utiliser LDAP [RFC3377], un protocole en mode connexion. La transaction de protocole inclut plusieurs allers-retours de paquets pour exécuter l'interrogation et la restitution et elle est considérée comme étant l'élément de plus forte latence du service de messagerie. De plus, la restitution des informations de confirmation peut exiger le retour d'un segment de nom parlé de jusqu'à 20  k  octets (5 secondes à 4 k octets/s). Sur une connexion Internet suffisamment élaborée, un temps de réponse de 1250 ms est estimé être réalisable sur l'Internet en général.

 	1.3	Contraintes d'adaptabilité
L'espace de noms d'un fournisseur de services est supposé inclure des entrées pour des dizaines de millions d'abonnés dans un espace de noms fondé sur la forme d'adresse VPIM inter domaines : numéro_de_téléphone@nom_de_domaine. Une grande entreprise peut avoir cent mille entrées, tandis qu'un grand fournisseur de services peut avoir des dizaines de millions d'entrées dans un seul domaine. On suppose qu'il y aura un seul service de validation d'adresses publiques pour le réseau d'un certain fournisseur de services. On estime que la technologie existante de répertoires, incluant l'adaptabilité horizontale par la duplication, va fournir un débit de transactions suffisant dans les exigences de latence requises pour satisfaire ce besoin. La seule exigence fondamentale nouvelle qu'impose cette application aux serveurs de répertoires, au delà des services similaires existants, est la capacité de retourner le nom parlé du receveur. Des investigations préliminaires suggèrent que la mémorisation et la restitution d'un nom parlé ne va pas ajouter une latence appréciable ; cependant, cela va ajouter au besoin de capacités de mémorisation.

 	1.4	Contraintes de fiabilité
Le DNS fournit des capacités bien documentées de redondance et d'équilibrage de charge pour le VPIMDIR. Cependant, les exigences de latence pour l'utilisateur final ne peuvent pas permettre la reprise sur défaillance du côté client sur un serveur secondaire et peuvent exiger que le serveur de répertoire soit mis en œuvre comme un service à forte disponibilité.

 	2.	Schéma de répertoire VPIMUser

(IANA-ASSIGNED-OID.1.1 NAME 'vPIMUser'
        SUP 'top'
        AUXILIARY
        MUST ( vPIMRfc822Mailbox $
               vPIMTelephoneNumber )
        MAY  ( vPIMSpokenName $
               vPIMSupportedUABehaviors $
               vPIMSupportedAudioMediaTypes $
               vPIMSupportedMessageContext $
               vPIMTextName $
               vPIMExtendedAbsenceStatus $
               vPIMMaxMessageSize $
               vPIMSubMailboxes ) )

Lorsque il est présent, l'objet vPIMUser contient des informations utiles pour vérifier que le numéro de téléphone composé correspond au receveur voulu. Cet objet fournit aussi des informations de capacité et des informations sur l'état de la boîte aux lettres utiles pour guider la composition par l'envoyeur et pour régler les attentes en matière de livraison au moment de l'envoi.

 	2.1	vPIMTelephoneNumber
L'attribut vPIMTelephoneNumber est la forme complète E.164 du numéro de téléphone [E164], incluant toute portion de sous adressage. La recherche normale pour cet attribut sera :

(IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber'
                    EQUALITY caseIgnoreMatch
                    SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} )

Exemple : un numéro de téléphone d'Amérique du Nord avec la sous adresse 12 sera représenté par "+12145551212+12".

Noter que vPIMTelephoneNumber est, par défaut, un attribut multi valeurs. Mais si une entrée a plusieurs valeurs pour cet attribut, ces valeurs DOIVENT être distinctes de toutes les autres dans la portion numéro de téléphone. Il est prévu que chaque sous boîte aux lettres d'un même numéro de téléphone ait sa propre entrée de vPIMUser.

Le vPIMTelephoneNumber diffère du telephoneNumber dans la [RFC3377] par sa prise en charge des informations de sous adressage et son utilisation comme adresse de messagerie vocale. Dans la plupart des cas, ces valeurs seront les mêmes.

Le numéro de téléphone est mémorisé sans parenthèses, espaces, points, ou tirets. Le '+' en tête et le '+' délimitant la sous boîte aux lettres sont des marquages exigés.

 	2.2	vPIMRfc822Mailbox
L'attribut vPIMRfc822Mailbox mémorise l'adresse inter domaines SMTP de la boîte aux lettres vocale associée à un certain numéro de téléphone. Il est défini comme un attribut distinct pour le distinguer de l'attribut rfc822Mailbox qui peut être utilisé à d'autres fins. Bien qu'il soit préférable de définir vPIMRfc822Mailbox comme un sous type de rfc822Mailbox, il est défini ici comme un attribut entièrement nouveau parce que certaines mises en œuvre de répertoires ne prennent pas en charge les sous types.

(IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox'
                  EQUALITY caseIgnoreIA5Match
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

 	2.3	vPIMSpokenName
L'attribut vPIMSpokenName est une chaîne d'octets et DOIT être codée en ADPCM à 32 kbit/s exactement, comme défini dans la [RFC3802]. vPIMSpokenName devra contenir le nom parlé de l'utilisateur dans la voix de l'utilisateur. La longueur du segment de nom parlé NE DOIT PAS excéder cinq secondes.

Les types de codage privés ou supplémentaires sortent du domaine de la présente version.

(IANA-ASSIGNED-OID.2.3 NAME 'vPIMSpokenName'
                  EQUALITY octetStringMatch
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000}
                  SINGLE-VALUE )

 	2.4	vPIMTextName
Le nom de texte est conçu pour être cohérent avec les bases de données de nom en texte non structuré utilisées pour invoquer le service de livraison de nom de l'identifiant appelant.

(IANA-ASSIGNED-OID.2.4 NAME 'vPIMTextName'
                  EQUALITY caseIgnoreMatch
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20}
                  SINGLE-VALUE )

 	2.5	vPIMSupportedAudioMediaTypes
L'attribut vPIMSupportedAudioMediaTypes indique le ou les types de codage audio qui peuvent être reçus à l'adresse spécifiée dans vPIMRfc822Mailbox.

(IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes'
                  EQUALITY caseIgnoreIA5Match
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

C'est un attribut multi valeurs. Les valeurs admises pour cet attribut sont les sous types audio MIME enregistrés par l'IANA. Les types de codage non standard et privés doivent être indiqués en faisant précéder le nom du nouveau type de "X-" ou "x-".

Comme ADPCM est un format exigé, la valeur audio/32kadpcm doit figurer si cet attribut est présent.

 	2.6	vPIMSupportedMessageContext
Le contexte de message donne des lignes directrices à l'envoyeur sur les contextes de message que le receveur va probablement accepter. Le contexte de message donne des informations moins précises sur les capacités d'un certain receveur qu'une liste de types de supports. Cependant, étant donné le rôle croissant des passerelles de conversion de supports, l'indicateur de contexte fournit des lignes directrices plus utiles à un envoyeur dans un environnement de "messagerie unifiée".

(IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext'
                  EQUALITY caseIgnoreIA5Match
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

C'est un attribut multi valeurs. L'ensemble des valeurs de contexte de message valides est défini dans la [RFC3458].

 	2.7	vPIMExtendedAbsenceStatus
Il est courant d'avoir un attribut qui indique à l'abonné si le receveur accepte les messages en son absence. Cette caractéristique -- appelée "absence étendue" -- fournit un message d'avis au moment de l'envoi. C'est un concept similaire aux "notices de vacance" courantes dans la messagerie textuelle, mais a ses propres nuances culturelles et opérationnelles.

(IANA-ASSIGNED-OID.2.7 NAME 'vPIMExtendedAbsenceStatus'
                  EQUALITY caseIgnoreIA5Match
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
                  SINGLE-VALUE )

Les trois valeurs définies sont :  "Off", "On", "MsgBlocked"

"Off" indique que le receveur soit ne prend pas en charge l'absence étendue, soit n'a pas établi un tel indicateur. "Off" est la condition par défaut si cet attribut n'est pas retourné.

"On" indique que le receveur a établi un indicateur d'absence étendue, mais la boîte aux lettres accepte toujours les messages pour une lecture à un moment futur non spécifié.

"MsgBlocked" indique que le receveur a établi un indicateur d'absence étendu et que la boîte aux lettres est actuellement configurée à rejeter les messages entrants. Les messages NE DEVRAIENT PAS être envoyés au receveur si cette valeur est retournée dans l'attribut vPIMExtendedAbsenceStatus.

 	2.8	vPIMSupportedUABehaviors
La messagerie Internet ne fournit pas à l'envoyeur de facilités pour savoir si le receveur prend en charge un certain nombre de caractéristiques facultatives qui peuvent être demandées ou indiquées dans les en-têtes RFC822. Cet attribut donne une liste des attributs, considérés comme facultatifs par VPIM, et d'autres attributs spécifiques de fabricant, qui peuvent être pris en charge par le receveur. Si cet attribut n'est pas pris en charge, seuls les attributs marqués comme obligatoires dans VPIM sont supposés être pris en charge. Des comportements non divulgués peuvent être indiqués dans le message RFC822 ; cependant, il n'est pas garanti que le système receveur les prenne en charge.

(IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors'
                  EQUALITY caseIgnoreIA5Match
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Les comportements suivants sont définis :
MessageDispositionNotification
MessageSensitivity
MessageImportance

La présence de la valeur MessageDispositionNotification indique que le receveur va envoyer un MDN en réponse à une demande MDN.

MessageSensitivity indique que le receveur prend pleinement en charge l'indication de sensibilité définie dans VPIM [RFC3801].

MessageImportance indique que le receveur prend pleinement en charge l'indication d'importance définie dans VPIM [RFC3801].

Ces comportements peuvent être étendus sans normalisation pour inclure des extensions fonctionnelles d'interface d'utilisateur propriétaires. Ces valeurs d'extension propriétaire doivent avoir un préfixe de "X-" ou"x-".

 	2.9	vPIMMaxMessageSize
Au moment de sa composition, on peut vérifier que la longueur du message est acceptable en utilisant l'attribut de taille maximum de message. La taille maximum de message est un attribut généralement configuré par la politique du système receveur, normalement en minutes. Bien que ESMTP fournisse un mécanisme pour déterminer si un message est trop long en octets, c'est un guide non fiable pour le composeur quand plusieurs codages, supports, ou cages de débit binaire sont pris en charge.

(IANA-ASSIGNED-OID.2.9 NAME 'vPIMMaxMessageSize'
                  EQUALITY integerMatch
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
                  SINGLE-VALUE )

L'attribut indique en secondes la longueur maximum de message que la boîte aux lettres receveuse peut accepter.

 	2.10	vPIMSubMailboxes
Cet attribut indique la présence de sous boîtes aux lettres pour le numéro de téléphone demandé. Cette information peut être utilisée pour fournir à l'envoyeur un menu de sous adressage après la numérotation.

(IANA-ASSIGNED-OID.2.10 NAME 'vPIMSubMailboxes'
                  EQUALITY numericStringMatch
                  SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} )

Les valeurs admissibles incluent une liste de numéros de sous boîte aux lettres avec une gamme numérique de 1 à 9999. L'interface d'utilisateur peut utiliser cette information pour inviter l'envoyeur à choisir une sous boîte aux lettres. Les noms parlés associés à chaque sous boîte aux lettres peuvent être restitués individuellement par des interrogations ultérieures au services VPIMDIR du receveur.

 	3.	Considérations sur la sécurité

Les problèmes de sécurité connus sont les suivants.

1)	Les informations sur les consommateurs des fournisseurs de service sont très sensibles, en particulier dans cette période de compétition entre fournisseurs de téléphonie locale. Les fournisseurs de services ont besoin d'une souplesse maximale pour protéger ces données. À cause de la nature dense des allocations de numéros de téléphone, ces données sont soumises à des interrogations "à l'aveugle" via des interrogations LDAP répétées pour déterminer une liste complète des abonnées actuels ou actifs de messagerie. Pour réduire la valeur de ces données restituées, les fournisseurs de services peuvent limiter la divulgation des données qui sont utiles pour le télédémarchage, comme le nom textuel, et peuvent ne divulguer que les informations utiles à l'envoyeur, comme le nom parlé du receveur, un élément de données qui est beaucoup plus difficile à auto traiter.

2)	Dans de nombreux pays, il y a des lois ou règlements sur la confidentialité qui interdisent de divulguer certaines sortes d'informations descriptives (par exemple les noms textuels). Donc, les mises en œuvre de serveur sont encouragées à prendre en charge les règles structurelles de DIT et les formes de nom [RFC4512] car elles fournissent un mécanisme pour que les administrateurs choisissent les attributs de dénomination appropriés pour les entrées. Les administrateurs sont encouragés à utiliser ces mécanismes, les contrôles d'accès, et autres contrôles administratifs, qui peuvent être disponibles pour interdire l'utilisation des attributs contenant des informations sensibles lors des désignations d'entrées.

3)	Le service de répertoires LDAP doit être correctement sécurisé pour cette utilisation. La [RFC2829] décrit un certain nombre de considérations qui s'appliquent à cette utilisation. En particulier, ce service fournit des accès publics non authentifiés aux données de répertoires, et à ce titre, il est vulnérable aux attaques qui redirigent l'interrogation sur un serveur félon et offrent des données malveillantes.

 	4.	Considérations relatives à l'IANA

Se référer à "Autorité d'allocation des numéros de l'Internet (IANA) : Considérations sur le protocole léger d'accès à un répertoire (LDAP)" [RFC3383].

 	4.1	Identifiants d'objet
L'IANA a enregistré un identifiant d'objet LDAP à utiliser dans cette spécification technique, conformément au gabarit qui suit. Cet identifiant d'objet, 1.3.6.1.1.11, est mentionné comme "IANA-ASSIGNED-OID" dans le corps de ce mémoire.

Sujet : Demande d'enregistrement d'OID pour LDAP
Adresse personnelle & de messageris à contacter pour information : Greg Vaudreuil (gregv@ieee.org)
Spécification : RFC 4237
Auteur/contrôleur des changements : IESG
Commentaires : l'OID alloué sera utilisé comme base d'identification d'éléments de schéma définis dans ce document.

 	4.2	Descripteurs d'identifiant d'objet
L'IANA a enregistré les descripteurs LDAP utilisés dans cette spécification technique, comme précisé dans le gabarit suivant :

Sujet : demande de mise à jour d'enregistrement de descripteur pour LDAP
Descripteur (vPIM) : voir le commentaire
Identifiant d'objet : voir le commentaire
Adresse personnelle & de messageris à contacter pour information : Greg Vaudreuil (gregv@ieee.org)
Usage : voir le commentaire
Spécification : RFC 4237
Auteur/contrôleur des changements : IESG
Commentaires :  les descripteurs suivants ont été ajoutés :

Nom	Type	OID
vPIMUser	O	IANA-ASSIGNED-OID.1.1
vPIMTelephoneNumber	A	1.3.6.1.1.11.2.1
vPIMRfc822Mailbox	A	1.3.6.1.1.11.2.2
vPIMSpokenName  	A	IANA-ASSIGNED-OID.2.3
vPIMSupportedUABehaviors	A	IANA-ASSIGNED-OID.2.4
vPIMSupportedAudioMediaTypes	A	IANA-ASSIGNED-OID.2.5
vPIMSupportedMessageContext	A	IANA-ASSIGNED-OID.2.6
vPIMTextName	A	IANA-ASSIGNED-OID.2.7
vPIMExtendedAbsenceStatus	A	IANA-ASSIGNED-OID.2.8
vPIMMaxMessageSize	A	IANA-ASSIGNED-OID.2.9
vPIMSubMailboxes	A	IANA-ASSIGNED-OID.2.10

Où le type A est "Attribut" et le type O est "Classe d'objet".

 	5.	Références
 	5.1	Références normatives

[E164]	Recommandation UIT-T E.164, "Fonctionnement du réseau téléphonique et du RNIS, numérotation, acheminement et service mobile - Plan de numérotage pour l'ère du RNIS". (1991)

[RFC3377]	J. Hodges, R. Morgan, "Protocole léger d'accès à un répertoire (v3) : Spécification technique", septembre 2002. Obsolète, voir RFC4510) (P.S.)

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

[RFC3802]	G. Vaudreuil, G. Parsons, "Voix de qualité supérieure – enregistrement du sous-type MIME en modulation par impulsions et codage différentiel adaptatif à 32 kbit/s (MICDA)", juin 2004. (D.S.)

 	5.2	Références pour information

[RFC2829]	M. Wahl et autres, "Méthodes d'authentification pour LDAP", mai 2000. (Obsolète, voir RFC4513, RFC4510) (P.S.)

[RFC3383]	K. Zeilenga, "Autorité d'allocation des numéros de l'Internet (IANA) : Considérations sur le protocole léger d'accès à un répertoire (LDAP)", septembre 2002. (Obsolète, voir RFC4520)

[RFC3801]	G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2 (VPIMv2)", juin 2004. (D.S.)

[RFC4512]	K. Zeilenga, "Protocole léger d’accès à un répertoire (LDAP) : Modèle d’informations de répertoires", juin 2006.

 	Remerciements
Le présent schéma de répertoire s'appuie sur un travail antérieur de Carl Malamud et Marshall Rose dans leur expérience d'impression à distance et sur le travail conduit par Anne Brown au titre de l'essai sur les répertoires du comité pour la messagerie vocale de l'EMA. Anne Brown a assuré la direction et était co-auteur de la version originale du présent document.

Bernhard Elliot, travaillant avec le TMIA, a fourni la plus grande partie de l'impulsion organisationnelle pour faire avancer ce projet, ce qui était une tâche substantielle étant donnée la nature parfois lente et bureaucratique de l'industrie de la messagerie vocale et de l'environnement réglementaire.

Merci à Dave Dudley et à l'Alliance pour la messagerie (TMA, The Messaging Alliance) pour leurs travaux de pioniers sur un service partagé de répertoires pour la messagerie vocale et pour leurs efforts soutenus à la poursuite de ce travail.

Greg White et Jeff Bouis, de Lucent Technologies, ont fourni une assistance précieuse de relecture et de vérification. D'innombrables erreurs et incohérences ont été corrigées gràace à leur relecture attentive.

Comme président du groupe de travail VPIM, Glenn Parsons a fourni un soutien essentiel pendant les nombreuses années où ce document a été en développement.

 	Adresse de l'auteur
Prière d'envoyer les commentaires sur ce document à la liste de diffusion du groupe de travail VPIM à <vpim@ietf.org>.

Gregory M. Vaudreuil
Lucent Technologies
9489 Bartgis Ct
Frederick, MD 21702
US
mél : GregV@ieee.org

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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 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 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 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 la Internet Society.