Network Working Group R

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.

Le présent document définit un nouvel en-tête à utiliser dans les applications multi parties et le contrôle d’appel du protocole d’initialisation de session (SIP). L’en-tête Replaces est utilisé pour remplacer logiquement un dialogue SIP existant par un nouveau dialogue SIP. Cette primitive peut être utilisée pour permettre diverses caractéristiques, par exemple : "Transfert " et "Prise d’appel". Noter que la définition de ces exemples de caractéristiques n’est pas normative.

Table des Matières

1. Généralités 1

2. Conventions 3

3. Comportement du serveur d’agent d’utilisateur : réception d’un en-tête Replaces 3

4. Comportement du client d’agent d’utilisateur : envoi d’un en-tête Replaces 4

5. Comportement du mandataire 4

6. Syntaxe 4

6.1 En-tête Replaces 4

6.2 Nouvelle étiquette d’option pour les en-têtes Require et Supported 5

7. Exemples d’usage 5

7.1 Remplacement d’un dialogue précoce chez l’origine 5

8. Considérations pour la sécurité 7

9. Considérations relatives à l’IANA 8

9.1 Enregistrement de l’en-tête SIP "Replaces" 8

9.2 Enregistrement de l’étiquette d’option SIP "replaces" 8

10. Remerciements 8

11. Références 8

11.1 Références normatives 8

11.2 Références pour information 9

12. Adresse des auteurs 9

13. Déclaration complète de droits de reproduction 9

Le présent document décrit un champ d’extension SIP [RFC3261] au titre du cadre d’architecture d’application SIP multiparties [CCMP]. L’en-tête Replaces est utilisé pour remplacer logiquement un dialogue SIP existant par un nouveau dialogue SIP. Ceci est particulièrement utile dans des environnements de commande d’appel d’homologue à homologue.

Une utilisation de l’en-tête "Replaces" est de remplacer un participant par un autre dans une conversation multimédia. Bien que cette fonctionnalité soit déjà disponible en utilisant la commande d’appel de style commande d’appel de tiers [RFC3725], le modèle 3pcc requiert un point central de contrôle qui peut n’être pas désirable dans de nombreux environnements. À ce titre, une méthode pour effectuer ces mêmes primitives de commande d’appel d’une façon répartie, d’homologue à homologue est très souhaitable.

L’utilisation d’un nouvel INVITE avec un nouvel en-tête pour la correspondance des dialogues a été choisie plutôt que de faire des associations implicites dans un INVITE entrant sur la base d’un identifiant d’appel ou d’autres champs pour les raisons suivantes :

o Utiliser un en-tête Replaces explicite dans une nouvelle demande rend évidente l’intention de la demande.

o Un identifiant d’appel unique peut être donné à l’appel de remplacement. Cela évite les problèmes de correspondance de dialogue chez tous les agents d’utilisateur concernés.

o Il n’y a pas d’effet contraire si l’en-tête n’est pas pris en charge.

L’en-tête Replaces permet des services tels que la participation au transfert d’appel, la reprise d’un appel en attente, et la transition de conférences mélangées en local en appels à deux parties d’une façon répartie d’homologue à homologue. Cette liste de services n’est pas exhaustive. Bien que l’en-tête Replaces soit fréquemment utilisé combiné avec la méthode REFER [RFC3515] comme utilisée dans un transfert [RFC5589], elles peuvent être utilisées indépendamment.

Par exemple, Alice parle à Bob à partir du téléphone1. Elle transfère Bob au parking pendant qu’elle va au laboratoire. Lorsque elle y arrive, elle reprend l’appel "parqué" du téléphone2 en envoyant un INVITE avec un champ d’en-tête Replaces à Bob avec les informations de dialogue que Bob partageait avec le parking. Alice obtient ces informations en utilisant un mécanisme hors bande. Peut être s’est elle abonnée à ces informations à partir du parking (en utilisant le paquetage de dialogue de session [RFC4325]) ou elle est allée sur un site de la Toile et a cliqué sur un URI. On donne ci-dessous un court exemple de ce flux d’appels. (Les en-têtes Via et Max-Forwards sont omis pour simplifier.)

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].

Le présent document se réfère fréquemment aux termes "dialogue confirmé" et "dialogue précoce". Ils sont définis à la Section 12 de SIP [RFC3261].

3. Comportement du serveur d’agent d’utilisateur : réception d’un en-tête Replaces

L’en-tête Replaces contient des informations utilisées pour faire correspondre un dialogue SIP existant (call-id, to-tag, et from-tag). À réception d’un INVITE avec un en-tête Replaces, l’agent d’utilisateur (UA, User Agent) tente de faire correspondre ces informations avec un dialogue confirmé ou précoce. Le serveur d’agent d’utilisateur (UAS, User Agent Server) fait correspondre les paramètres to-tag et from-tag comme si c’étaient des étiquettes présentes dans une demande entrante. En d’autres termes, le paramètee to-tag est comparé à l’étiquette locale, et le paramètre from-tag est comparé à l’étiquette distante.

Si plus d’un champ d’en-tête Replaces est présent dans un INVITE, ou si un champ d’en-tête Replaces est présent dans une demande autre que INVITE, l’UAS DOIT rejeter la demande avec une réponse 400 Mauvaise demande.

L’en-tête Replaces a une sémantique spécifique de commande d’appel. Si un champ d’en-tête Replaces et un autre champ d’en-tête avec une sémantique contradictoire sont présents tous deux dans une demande, la demande DOIT être rejetée avec une réponse 400 "Mauvaise demande".

Si le champ s’en-tête Replaces correspond à plus d’un dialogue, l’UA DOIT agir comme si aucune correspondance n’avait été trouvée.

Si aucune correspondance n’est trouvée, l’UAS rejette l’INVITE et retourne une réponse 481 Transaction/appel non existant. De même, si le champ d’en-tête Replaces correspond à un dialogue qui n’a pas été créé par un INVITE, l’UAS DOIT rejeter la demande avec une réponse 481.

Si le champ d’en-tête Replaces correspond à un dialogue qui est déjà terminé, l’UA DEVRAIT refuser la demande avec une réponse 603 Refusé. (Si l’invitation correspondante vient juste de se terminer, la demande de remplacement devrait échouer aussi. Refuser la demande avec une réponse de classe 600 empêche une irritante condition de compétition où l’UA sonne ou fait une alerte en réclamant un appel de remplacement qui n’est pas voulu.)

Si le champ d’en-tête Replaces correspond à un dialogue actif, l’UA DOIT vérifier que l’initiateur du nouvel INVITE est autorisé à remplacer le dialogue correspondant. Si l’initiateur du nouvel INVITE a été bien authentifié comme équivalent à l’usager qui est remplacé, le remplacement est alors autorisé. Par exemple, si l’usager à remplacer et l’initiateur du dialogue de remplacement partagent les mêmes accréditifs pour l’authentification par résumé [RFC2617], ou si il signe la demande de remplacement avec S/MIME [RFC3851] avec la même clé privée et présente le (même) certificat correspondant qu’utilisé dans le dialogue d’origine, le remplacement est alors autorisé.

Autrement, le mécanisme Referred-By [RFC3892] définit un moyen que l’UAS peut utiliser pour vérifier qu’une demande de remplacement a été envoyée au nom de l’autre participant au dialogue correspondant (dans ce cas, déclanché par une demande REFER). Si la demande de remplacement contient un en-tête Referred-By qui correspond à l’usager remplacé, l’UA DEVRAIT traiter le remplacement comme si il avait été autorisé par la partie remplacée. L’en-tête Referred-By DEVRAIT faire référence à un corps d’identité authentifié Refererred-By valide [RFC3893].

L’UA PEUT appliquer une autre politique locale pour autoriser le reste de la demande. En d’autres termes, l’UAS peut appliquer au dialogue de remplacement une politique différente de celle appliquée au dialogue remplacé.

De plus, l’UA PEUT utiliser d’autres mécanismes d’autorisation définis à cette fin dans des extensions en cours de normalisation. Des extensions pourraient définir d’autres mécanismes pour assurer la transitivité de l’autorisation d’un remplacement.

Si l’autorisation réussit, l’UA tente d’accepter le nouvel INVITE, réalloue l’interface d’utilisateur et les autres ressources du dialogue correspondant au nouvel INVITE, et ferme le dialogue remplacé. Si l’UA ne peut pas accepter le nouvel INVITE (par exemple, il ne peut pas établir la QS requise ou le changement de clés ou il a un support incompatible) l’UA DOIT retourner une réponse d’erreur appropriée et DOIT laiser inchangé le dialogue correspondant.

Si le champ d’en-tête Replaces correspond à un dialogue confirmé, il vérifie la présence du fanion "early-only" dans le champ d’en-tête Replaces. (Ce fanion permet à l’UAC d’empêcher une condition de compétition potentiellement indésirable décrite au paragraphe 7.1.) Si le fanion est présent, l’UA rejette la demande avec une réponse 486 Occupé. Autrement, il accepte le nouvel INVITE en envoyant une réponse de classe 200, et ferme le dialogue remplacé en envoyant un BYE. Si le champ d’en-tête Replaces correspond à un dialogue précoce qui était initié par l’UA, il accepte le nouvel INVITE en envoyant une réponse de classe 200, et ferme le dialogue remplacé par l’envoi d’un CANCEL.

Si le champ d’en-tête Replaces corespond à un dialogue précoce qui n’était pas initié par cet UA, il retourne une réponse 481 (Appel/transaction non existant) au nouvel INVITE, et laisse le dialogue correspondant inchangé. Noter que comme Replaces correspond à un seul dialogue, le dialogue de remplacement ne sera pas reciblé conformément à la même logique de fourchement que la demande originale qui a créé le dialogue précoce.

(Actuellement, aucun cas d’utilisation n’a été identifié pour remplacer juste un seul dialogue dans ces circonstances.)

4. Comportement du client d’agent d’utilisateur : envoi d’un en-tête Replaces

Un agent d’utilisateur qui souhaite remplacer un seul dialogue précoce ou confirmé existant par un nouveau dialogue à lui PEUT envoyer à l’agent d’utilisateur cible une demande INVITE contenant un champ d’en-tête Replaces. Le client d’agent d’utilisateur (UAC, User Agent Client) place l’identifiant d’appel, les informations de to-tag, et de from-tag pour le dialogue cible dans un seul champ d’en-tête Replaces et envoie le nouvel INVITE à la cible. Si l’agent d’utilisateur souhaite seulement remplacer un dialogue précoce (comme dans l’exemple Call Pickup du paragraphe 7.1) l’UAC PEUT aussi inclure le paramètre "early-only" dans le champ d’en-tête Replaces. Un UAC NE DOIT PAS envoyer un INVITE avec un champ d’en-tête Replaces qui tente de remplacer un dialogue précoce qui n’était pas généré par la cible de l’INVITE avec un champ d’en-tête Replaces.

Noter que l’utilisation de ce mécanisme ne donne pas de moyen de faire correspondre plusieurs dialogues, ni ne fournit de moyen de faire correspondre un appel entier, une transaction entière, ou de suivre une chaîne de logique de fourchement de mandataires. Par exemple, si Alice remplace Cathy dans un dialogue précoce par Bob, mais si Bob ne répond pas, la demande de remplacement d’Alice ne va pas correspondre aux autres dialogues sur lesquels l’UA de Bob se redirige, ni aux autres branches auxquelles son mandataire retransmet. Bien que la présente spécification prenne des précautions raisonnables pour empêcher un comportement inattendu en face de fourchement, les mises en œuvre DEVRAIENT seulement adresser les demandes de remplacement (c’est-à-dire, régler l’URI de demande de la demande de remplacement) à l’URI de contact SIP de la cible.

Les serveurs mandataires n’exigent pas de nouveau comportement pour prendre en charge la présente extension. Ils passent simplement le champ d’en-tête Replaces de façon transparente comme décrit dans la spécification SIP.

Noter qu’il est possible qu’un mandataire (en particulier lors d’un fourchement sur la base d’une logique de couche application, comme d’un affichage de l’appelant ou un acheminement en fonction de l’heure) transmette une demande INVITE contenant un champ d’en-tête Replaces à un ensemble de contacts complètement orthogonal autre que la demande d’origine qu’il était destiné à remplacer. Dans ce cas, la demande INVITE avec le champ d’en-tête Replaces va échouer.

Le champ d’en-tête Replaces indique qu’un seul dialogue identifié par le champ d’en-tête est à fermer et à remplacer logiquement par l’INVITE entrant dans lequel il est contenu. C’est seulement un en-tête de demande, qui n’est défini que pour les demandes INVITE. Le champ d’en-tête Replaces PEUT être chiffré au titre d’un chiffrement de bout en bout. Une seule valeur de champ d’en-tête Replaces peut être présente dans une demande SIP.

Le présent document ajoute l’entrée suivante au Tableau 2 de la [RFC3261]. Des ajouts à ce tableau sont aussi fournis pour les méthodes d’extension définies au moment de la publication du présent document. Ces ajouts sont fournis pour le confort de la lecture et ne présentent aucun caractère normatif. MESSAGE, SUBSCRIBE et NOTIFY, REFER, INFO, UPDATE, PRACK, et PUBLISH sont définis respectivement dans les [RFC3428], [RFC3265], [RFC3515], [RFC2976], [RFC3311], [RFC3262], et [SIMPLE].

Ch. d’en-tête où mandataire ACK BYE CAN INV OPT REG MSG SUB NOT REF INF UPD PRA PUB

La spécification de syntaxe suivante utilise le format Backus-Naur augmenté (ABNF) décrit dans la [RFC2234]. La syntaxe ci-dessous s’appuie sur un certain nombre de productions de SIP [RFC3261].

Un champ d’en-tête Replaces DOIT contenir exactement une to-tag et exactement une from-tag, car elles sont exigées pour une correspondance univoque du dialogue. Pour la compatibilité avec les dialogues initiés par les UA conformes à la [RFC2543], une étiquette de zéro correspond à la fois aux étiquettes de zéro et de nul. Un champ d’en-tête Replaces PEUT contenir le fanion early-flag.

La présente spécification définit une nouvelle étiquette d’option d’en-tête Require/Supported "replaces". Les UA qui prennent en charge l’en-tête Replaces DOIVENT inclure l’étiquette d’option "replaces" dans un champ d’en-tête Supported. Les UA qui veulent une notification explicite d’échec si Replaces n’est pas pris en charge PEUVENT inclure l’option "replaces" dans un champ d’en-tête Require.

Les exemples non normatifs qui suivent ne sont pas destinés à énumérer toutes les possibilités d’usage de cette extension, mais plutôt de fournir des exemples ou des idées. Pour plus d’exemples, voir les exemples de service SIP dans la [RFC4317]. Les en-têtes Via et Max-Forwards sont omis des exemples dans un souci de clarté et de brièveté.

Dans cet exemple, Bob vient d’arriver dans le laboratoire et ne s’y est pas encore enregistré. Il entend sonner le téléphone de son bureau. Il se connecte rapidement à l’UA logiciel sur un ordinateur voisin. Entre autres choses, l’UA logiciel a accès à l’état de dialogue de son téléphone de bureau. Lorsque il remarque que son téléphone sonne, il lui offre le choix de prendre l’appel. L’UA logiciel envoie un INVITE avec Replaces à Alice. Lorsque l’UA d’Alice reçoit ce nouvel INVITE, il annule (CANCEL) l’INVITE d’origine et connecte Alice à Bob.

L’extension spécifiée dans le présent document change significativement la sécurité relative des appareils SIP. Actuellement dans SIP, même si un espion apprend l’identifiant d’appel, les en-têtes To et From d’un dialogue, il ne peut pas modifier facilement ou détruire ce dialogue si l’authentification par résumé ou l’intégrité de message de bout en bout sont utilisées.

Cette extension peut être utilisée pour déconnecter les participants ou remplacer des participants dans une conversation multimédia. À ce titre, les invitations avec l’en-tête Replaces DOIVENT seulement être acceptée si l’homologue qui demande le remplacement a été correctement authentifié en utilisant un mécanisme SIP standard (Digest ou S/MIME), et autorisé à demander un remlacement du dialogue cible. Toutes les mises en œuvre de SIP sont déjà obligées de prendre en charge l’authentification par résumé. De plus, les mises en œuvre qui prennent en charge l’en-tête Replaces DEVRAIENT aussi mettre en œuvre le mécanisme Referred-By.

Comment un agent d’utilisateur détermine quelles demandes sont légitimement autorisées à faire des remplacements de dialogue n’est pas trivial et dépend d’une quantété considérable de configuration de politique locale. En général, il y a quatre cas où une autorisation de remplacement est raisonnable ou garantie.

1. Remplacement fait par une partie considérée comme équivalente à la partie remplacée.

2. Remplacement fait au nom de la partie remplacée (peut-être de façon transitive).

En commençant par le n° 1 par exemple, si un dirigeant et un assistant reçoivent tous deux des demandes pour une adresse d’enregistrement partagée, si ils sont configurés pour cela, devraient l’un et l’autre être capables de remplacer les dialogues de l’autre pour l’identité partagée. Tous deux pourraient même partager le même matériel de chiffrement (Digest ou S/MIME), ou l’un pourrait détenir un document d’autorisation signé par l’autre exprimant cette relation. De même, dans un environnement de centre d’appel, chaque agent du centre d’appel pourrait posséder des accrédeiifs auxquels les superviseurs ont aussi accès.

Le cas d’utilisation le plus commun de remplacement est à la demande du participant remplacé (qui ne veut plus être impliqué). C’est le cas dans de nombreux dispositifs, comme pour achever un transfert de participant et convertir un appel à trois en appel en point à point. De tels remplacements sont normalement déclanchés par une demande REFER [RFC3515] de la part du participant remplacé. Le mécanisme Referred-By [RFC3892] définit un moyen pour identifier le demandeur original apparent et peut pointer sur un corps d’identité SIP authentifié [RFC3893] (une assertion signé fondée sur S/MIME) pour sécuriser cette information.

Dans l’exemple de la section 1, Alice envoie un INVITE avec Replaces à Bob. Alice était un ancien participant à la conversation et avait une précédente relation de dialogue avec Bob. Alice peut utiliser le même Digest ou les mêmes accréditifs S/MIME qu’elle utilisait pour s’authentifier auprès de Bob durant l’appel d’origine pour prouver qu’elle était un participant antérieur. Noter que cette justification pour les remplacements d’appels est plus dangereuse que les autres, et dans la plupart des cas, c’est une autre façon d’autoriser que le participant remplaçant est disponible. Les mises en œuvre NE DEVRAIENT PAS s’appuyer sur cette méthode pour un mécanisme d’autorisation.

Le dernier scénario est le plus facile à sécuriser mais celui qui a le moins de chances d’être utile en pratique. Il est peu probable qu’un hôte arbitraire soit au courant d’une relation d’autorisation particulière entre la partie remplacée et le remplaçant. Cependant, ce cas d’utilisation peut être utile dans certains environnements. Comme cette utilisation ne dégrade pas effectivement la sécurité de la solution, elle est quand même permise.

Certains mécanismes pour obtenir les informations de dialogue nécessaires pour l’en-tête Replaces (Call-ID, to-tag, et from-tag) incluent des URI sur une page de la Toile, un abonnement à un paquetage d’événements approprié, et des notifications après une demande REFER. Comme la manipulation de ces informations de dialogue pourraient faire que les agents d’utilisateur remplacent le mauvais dialogue, l’utilisation de la protection de l’intégrité du message pour ces informations est fortement RECOMMANDÉE. L’utilisation des mécanismes de sécurité de bout en bout pour chiffrer ces informations est aussi RECOMMANDÉE.

La présente extension a été conçue pour tirer parti des futurs schémas de signature ou d’autorisation définis dans des extensions en cours de normalisation. En général, les dispositifs de commande d’appel bénéficient considérablement d’un tel travail.

Merci à Robert Sparks, Alan Johnston, Dan Petrie, Ben Campbell, et aux nombreux autres membres du groupe de travail SIP pour leur soutien continuel à la cause de la commande d’appel répartie dans SIP.

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

[RFC3851] B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version 3.1", juillet 2004. (Remplacée par RFC5751)

[RFC3892] R. Sparks, "Mécanisme Referred-by du protocole d'initialisation de session (SIP)", septembre 2004.

[RFC3893] J. Peterson, "Format de corps d'identité authentifiée (AIB) du protocole d'initialisation de session (SIP)", septembre 2004.

[CCMP] Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Non publiée, mars 2003.

[RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP : protocole d'initialisation de session", mars 1999. (Obsolète, voir RFC3261, RFC3262, RFC3263, RFC3264, RFC3265) (P.S.)

[RFC2976] S. Donovan, "Méthode INFO pour SIP", octobre 2000. (P.S., Remplacée par la RFC6086)

[RFC3311] J. Rosenberg, "Méthode UPDATE du protocole d'initialisation de session (SIP) ", octobre 2002.

[RFC3515] R. Sparks, "Méthode Refer du protocole d'initialisation de session (SIP)", avril 2003.

[RFC3725] J. Rosenberg et autres, "Bonne pratiques actuelles pour la commande d'appel de tiers (3pcc) dans le protocole d'initialisation de session (SIP)", avril 2004. (BCP0085)

RFC4235] J. Rosenberg et autres, "Paquetage d'événement de dialogue initié par INVITE pour le protocole d'initialisation de session (SIP)", novembre 2005. (P.S.)

[RFC4317] A. Johnston, R. Sparks, "Exemples d'offres et de réponses du protocole de description de session (SDP)", décembre 2005. (Information)

[RFC5589] R. Sparks, A. Johnston, éd., D. Petrie, "Contrôle du transfert d'appel dans le protocole d'initialisation de session (SIP)", juin 2009. (BCP0149)

[SIMPLE] Campbell, B., "SIMPLE Presence Publication Mechanism", Non publiée, février 2003.

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.

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.

Groupe de travail Réseau	R. Mahy, Cisco Systems, Inc.
Request for Comments : 3891	B. Biggs, R. Dean
Catégorie : En cours de normalisation	septembre 2004
Traduction Claude Brière de L’Isle

Rohan Mahy	Billy Biggs	Rick Dean
Cisco Systems, Inc.	mél : bbiggs@dumbterm.net	mél : rfc@fdd.com
5617 Scotts Valley Dr
Scotts Valley, CA 95066
USA
mél : rohan@cisco.com