RFC3840 Capacités d’agent d’utilisateur dans SIP Rosenberg & autres

Groupe de travail Réseau

J. Rosenberg, dynamicsoft

Request for Comments : 3840

H. Schulzrinne, Columbia University

Catégorie : En cours de normalisation

P. Kyzivat, Cisco Systems

Traduction Claude Brière de L’Isle

août 2004



Indication des capacités d’agent d’utilisateur 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 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 "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.


Notice de Copyright

Copyright (C) The Internet Society (2004).


Résumé

La présente spécification définit des mécanismes par lesquels un agent d’utilisateur du protocole d’initialisation de session (SIP, Session Initiation Protocol) peut faire connaître ses capacités et caractéristiques aux autres agents d’utilisateur et au registraire pou son domaine. Ces informations sont convoyées comme des paramètres du champ d’en-tête Contact.


Table des Matières

1. Introduction 2

2. Terminologie 2

3. Définitions 2

4. Usage du cadre de négociation de contenu 3

5. Capacités de calcul 4

6. Expression des capacités dans un enregistrement 6

7. Indication des réglages de caractéristiques dans les URI de cible distante 7

8. Traitement de OPTIONS 8

9. Champ d’en-tête Contact 8

10. Définitions d’étiquette de caractéristique de support 9

10.1 Audio 9

10.2 Application 9

10.3 Data 10

10.4 Control 10

10.5 Video 10

10.6 Text 10

10.7 Automata 11

10.8 Class 11

10.9 Duplex 11

10.10 Mobility 12

10.11 Description 12

10.12 Event Packages 12

10.13 Priority 13

10.14. Methods 13

10.15 Extensions 13

10.16 Schemes 14

10.17 Actor 14

10.18 Is Focus 14

11. Considérations pour la sécurité 15

11.1 Considérations sur les étiquettes de caractéristique de support 15

11.2 Considérations sur les enregistrements 15

11.3 Considérations sur les réponses à OPTIONS 15

11.4 Considérations sur les messages d’initiation de dialogue 15

12. Considérations relatives à l’IANA 16

12.1 Arborescence d’enregistrement d’étiquette de caractéristique de support SIP 16

12.2 Étiquettes de caractéristique de support 16

12.3 Étiquette d’option SIP 17

13. Remerciements 17

14. Références 17

14.1 Références normatives 17

14.2. Références pour information 18

Appendice A. Vue d’ensemble de la RFC2533 18

Adresse des auteurs 20

Déclaration complète de droits de reproduction 20


1. Introduction


Les agents d’utilisateur du protocole d’initialisation de session (SIP) [RFC3261] diffèrent largement par leurs capacités et par les types d’appareils qu’ils représentent. Souvent, il est important pour un autre élément SIP d’apprendre les capacités et caractéristiques d’un agent d’utilisateur (UA, User Agent) SIP. Certaines des applications de ces informations incluent :

o Un agent d’utilisateur, une application sur un PC, communique avec un autre qui est incorporé dans un appareil aux fonctions limitées. Le PC aimerait être capable de "grisailler" les composants de l’interface d’utilisateur qui représentent des caractéristiques ou capacités non prises en charge par son homologue. Pour faire cela, ils ont besoin d’un moyen pour échanger des informations de capacité au sein d’un dialogue.

o Un usager a deux appareils à sa disposition. L’un est un visiophone, et l’autre , un téléphone sans fil uniquement vocal. Un appelant veut interagir avec l’ usager en utilisant la vidéo. À ce titre, ils aimeraient que leur appel soit de préférence acheminé sur celui qui prend en charge la vidéo. Pour faire cela, la demande INVITE peut contenir des paramètres qui expriment une préférence pour l’acheminement vers un appareil ayant les capacités spécifiées [RFC3841].

o Une application réseau aimerait envoyer de façon asynchrone des informations à un agent d’utilisateur dans une demande MESSAGE [RFC3428]. Cependant, avant de l’envoyer, elle aimerait savoir si l’UA a les capacités nécessaires pour recevoir le message. Pour faire cela, ils devraient idéalement interroger une base de données d’utilisateurs gérée par le domaine qui détient des telles informations. Le remplissage d’une telle base de données exigerait qu’un UA apporte ses capacités au titre de son enregistrement. Donc, il y a un besoin de transporter les capacités dans les demandes REGISTER.


SIP prend dans une certaine mesure en charge l’expression des capacités. Les champs d’en-tête Allow, Accept, Accept-Language, et Supported portent certaines informations sur les capacités d’un agent d’utilisateur. Cependant, ces champs d’en-tête ne portent qu’une petite partie des informations nécessaires. Ils ne fournissent pas un cadre général pour l’expression des capacités. De plus, ils ne spécifient qu’indirectement les capacités ; les champs d’en-tête indiquent réellement les capacités de l’UA qui s’appliquent à cette demande. SIP n’a pas non plus la capacité de porter les caractéristiques, c’est-à-dire, les informations qui décrivent un UA.


Il en résulte que la présente spécification fournit un cadre plus général pour l’indication des capacités et caractéristiques dans SIP. Les informations de capacités et caractéristiques sur un UA sont portées comme des paramètres du champ d’en-tête Contact. Ces paramètres peuvent être utilisés au sein des demandes et réponses REGISTER, des réponses OPTIONS, et des demandes et réponses qui créent des dialogues (comme INVITE).


2. Terminologie


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


3. Définitions


Caractéristique : Comme défini dans la [RFC2703], un élément d’information sur les propriétés de traitement du support d’un composant du système de passation de message ou d’une ressource de données. Par exemple, les méthodes SIP acceptées par un UA représentent une caractéristique.


Étiquette de caractéristique : Comme défini dans la [RFC2703], une étiquette de caractéristique est un nom qui identifie une caractéristique. Un exemple est "sip.methods".


Caractéristique du support : Comme défini dans la [RFC2703], une caractéristique du support est une information qui indique des facilités supposées disponibles pour que le contenu du message soit rendu ou présenté correctement. Les caractéristiques du support ne sont pas destinées à inclure des informations qui affectent la transmission du message.

Dans le contexte de la présente spécification, une caractéristique du support est une information qui indique les facilités pour le traitement des demandes SIP, plutôt que le contenu spécifique. Dans ce sens, c’est utilisé comme synonyme de caractéristique.


Collection de caractéristiques : Comme défini dans la [RFC2533], une collection de caractéristiques est une collection de différentes caractéristiques du support et des valeurs associées. Cela pourrait être vu comme la description d’un rendu spécifique d’une certaine instance d’un document ou ressource par un receveur particulier.


Ensemble de caractéristiques : Comme défini dans la [RFC2703], un ensemble de caractéristiques est des informations sur un envoyeur, un receveur, ou autre participant à un transfert de message qui décrit l’ensemble des caractéristiques qu’il peut traiter. Lorsque une "caractéristique" décrit un seul attribut identifié d’une ressource, un "ensemble de caractéristiques" décrit un ensemble complet des attributs possibles.


Paramètres de caractéristique : Ensemble de paramètres de champ d’en-tête SIP qui peuvent apparaître dans le champ d’en-tête Contact. Les paramètres de caractéristique représentent un codage d’un ensemble de caractéristiques. Chaque ensemble de paramètres de caractéristique se transpose en un prédicat d’ensemble de caractéristiques.


Capacité : Comme défini dans la [RFC2703], une capacité est un attribut d’un envoyeur ou receveur (souvent du receveur) qui indique une capacité à générer ou traiter un type particulier de contenu du message. Une capacité est distincte d’une caractéristique en ce que la capacité peut être utilisée ou non dans tout appel, tandis qu’une caractéristique est une propriété non négociable d’un UA. SIP lui-même va souvent négocier si des capacités sont utilisées ou non dans un appel.


Caractéristique : Une caractéristique est comme une capacité, mais décrit un aspect d’un UA qui n’est pas négociable. Par exemple, qu’un UA soit ou non un téléphone mobile est une caractéristique, pas une capacité. La sémantique de cette spécification ne différencie pas la capacité de la caractéristique, mais la distinction est utile pour les besoins d’illustration. Bien sûr, dans le texte qui suit, quand on dit "capacité", cela se réfère aussi bien aux capacités qu’aux caractéristiques, sauf mention explicite contraire.


Filtre : Une seule expression dans un prédicat d’ensemble de caractéristiques.


Filtre simple : Expression dans un prédicat d’ensemble de caractéristiques qui est une comparaison (égalité ou inégalité) d’une étiquette de caractéristique avec une valeur de caractéristique.


Disjonction : Opération OU booléenne sur un certain nombre de termes.

Conjonction : Opération ET booléenne sur un certain nombre de termes.

Prédicat : Expression booléenne.


Prédicat d’ensemble de caractéristiques : D’après la [RFC2533], un prédicat d’ensemble de caractéristiques est une fonction d’une valeur arbitraire de collection de caractéristiques qui retourne un résultat booléen. Un résultat VRAI signifie que la collection de caractéristiques correspondante appartient à un certain ensemble de capacités de traitement de caractéristique du support définies par ce prédicat.


Prédicat de contact : C’est le prédicat d’ensemble de caractéristiques associé à un URI enregistré dans le champ d’en-tête Contact d’une demande REGISTER. Le prédicat de contact est déduit des paramètres de caractéristiques dans le champ d’en-tête Contact.


4. Usage du cadre de négociation de contenu


La présente spécification fait un large usage de la terminologie et des concepts du travail de négociation de contenu effectué au sein de l’IETF, et documenté dans plusieurs RFC. Celles qui sont pertinentes pour la présente spécification sont la [RFC2506], qui donne un cadre pour l’enregistrement des étiquettes de caractéristique du support, la [RFC2533], qui présente une syntaxe et un algorithme de correspondance pour les ensembles de caractéristique du support, la [RFC2738] qui fait une mise à niveau mineure de la RFC2533, et la [RFC2703] qui fournit un cadre général pour la négociation de contenu.


Au cas où le lecteur n’aurait pas le temps de lire ces spécifications, l’Appendice A donne une brève vue générale des concepts et de la terminologie de ces documents qui sont critiques pour la compréhension de la présente spécification.


Comme le travail de négociation de contenu était principalement destiné à s’appliquer aux documents ou autres ressources avec un ensemble de rendus possibles, la façon dont il est utilisé pour modéliser les agents d’utilisateur SIP n’est pas immédiatement apparente. Un ensemble de caractéristiques est composé d’un ensemble de collections de caractéristiques, dont chacune représente un rendu spécifique pris en charge par l’entité décrite par l’ensemble de caractéristiques. Dans le contexte d’un agent d’utilisateur SIP, une collection de caractéristiques représente une modalité instantanée. C’est-à-dire que si on regarde le démarrage du traitement d’un UA SIP et qu’on en prend une photographie, la collection de caractéristiques décrit ce qui se fait à l’instant de cette photographie.


Ce modèle est important, car il donne des lignes directrices sur la façon de déterminer si quelque chose est une valeur pour une étiquette de caractéristique particulière, ou une étiquette de caractéristique par elle-même. Si deux propriétés peuvent être affichées simultanément par un UA de sorte que toutes deux soient présentes dans une modalité instantanée, elles doivent être représentées par des étiquettes de caractéristique du support différentes. Par exemple, un UA peut être capable de prendre en charge un certain nombre de types de supports - audio, vidéo, et contrôle. Chacun d’eux devrait-il avoir une valeur différente pour une seule étiquette de caractéristique de "types de support", ou chacun d’eux devrait-il avoir une étiquette de caractéristique booléenne différente ? Le modèle donne la réponse. Comme, à tout moment dans le temps, un UA peut traiter à la fois de l’audio et de la vidéo, ils doivent avoir des étiquettes de caractéristique du support séparées. Cependant, les méthodes SIP prises en charge par un UA peuvent chacune être représentée comme des valeurs différentes pour la même étiquette de caractéristique du support (l’étiquette "sip.methods") parce que fondamentalement, un UA traite une seule demande à la fois. Il peut être multi-tâches, de sorte qu’il paraît ne pas l’être, mais au niveau purement fonctionnel, c’est vrai.


Il y a clairement une faiblesse dans ce modèle, mais il sert utilement de ligne directrice pour l’application des concepts de la [RFC2533] au problème posé.


5. Capacités de calcul


Pour construire un ensemble de paramètres de champ d’en-tête Contact qui indique les capacités, un UA construit un prédicat de caractéristiques pour ce contact. Ce processus est décrit dans les termes de la syntaxe et construction de la [RFC2533] (et sa mise à jour mineure, la [RFC2738]) suivie par une conversion à la syntaxe utilisée dans la présente spécification. Cependant, cela représente un flux de traitement logique. Il n’est pas exigé qu’une mise en œuvre utilise en fait la syntaxe de la [RFC2533] comme étape intermédiaire.


Un UA PEUT utiliser toutes les étiquettes de caractéristique qui sont enregistrées par l’IANA dans l’arborescence SIP (établie au paragraphe 12.1) de l’IETF, ou les arborescences globales [RFC2506] ; le présent document en enregistre plusieurs dans l’arborescence SIP. Les étiquettes de caractéristique exposées dans la présente spécification sont mentionnées comme étiquettes de base. Tandis que les autres étiquettes peuvent être utilisées, afin de les identifier comme paramètres de caractéristiques (par opposition aux paramètres pour une autre extension SIP) elles sont codées avec un signe "+" en tête dans le champ d’en-tête Contact. Il est aussi permis d’utiliser l’arbre des URI de la [RFC2506] pour exprimer des étiquettes de caractéristique spécifiques du fabricant. Les étiquettes de caractéristiques dans toutes les autres arborescences créées auprès de l’IANA PEUVENT aussi être utilisées.

Lorsqu’il utilise l’étiquette de caractéristique "sip.methods", un UA NE DOIT PAS inclure de valeurs qui correspondent aux méthodes non normalisées dans les RFC en cours de normalisation de l’IETF. Lorsque il utilise l’étiquette de caractéristique "sip.events", un UA NE DOIT PAS inclure de valeurs qui correspondent à des paquetages d’événements non normalisés dans les RFC en cours de normalisation de l’IETF. Lorsque il utilise l’étiquette de caractéristique "sip.schemes", un UA NE DOIT PAS inclure de valeurs qui correspondent à des schémas non normalisés dans les RFC en cours de normalisation de l’IETF. Lorsque il utilise l’étiquette de caractéristique "sip.extensions", un UA NE DOIT PAS inclure de valeurs qui correspondent à des étiquettes d’option non normalisées dans les RFC en cours de normalisation de l’IETF.

Noter que l’étiquette de caractéristique "sip.schemes" n’indique pas le schéma de l’URI enregistré. Il indique plutôt les schémas auxquels un UA est capable d’envoyer des demandes, si un tel URI devait être reçu dans une page de la Toile ou le champ d’en-tête Contact d’une réponse de redirection.

Il est RECOMMANDÉ qu’un UA fournisse des informations complètes dans son prédicat de contact. C’est-à-dire qu’il DEVRAIT fournir des informations sur autant d’étiquettes de caractéristique que possible. Les mécanismes de la présente spécification fonctionnent mieux quand les agents d’utilisateur enregistrent des ensembles de caractéristiques complets. De plus, lorsque un UA enregistre des valeurs pour une étiquette de caractéristique particulière, il DOIT faire la liste de toutes les valeurs qu’il accepte. Par exemple, lorsque il inclut l’étiquette de caractéristique "sip.methods", un UA DOIT faire la liste de toutes les méthodes qu’il prend en charge.


Le prédicat contact construit par un UA DOIT être une conjonction de termes. Chaque terme est soit une disjonction de filtres simples (ou négation de filtres simples) soit un seul filtre simple ou négation d’un seul filtre. Dans le cas d’une disjonction, chaque filtre de la disjonction DOIT indiquer des valeurs de caractéristiques pour la même étiquette de caractéristique (c’est-à-dire que la disjonction représente un ensemble de valeurs pour une étiquette de caractéristique particulière) tandis que chaque élément de la conjonction DOIT être pour une étiquette de caractéristique différente. Chaque filtre simple peut être une égalité, ou dans le cas d’étiquettes de caractéristique numérique, une inégalité ou une gamme. Si une chaîne (comme défini dans la [RFC2533]) est utilisée comme valeur d’un filtre simple, cette valeur NE DOIT PAS inclure le caractère "<" ou ">", le filtre simple NE DOIT PAS être une négation, et il DOIT être le seul filtre simple pour cette étiquette de caractéristique particulière. Ce prédicat contact est alors converti en une liste de paramètres de caractéristiques, suivant la procédure décrite ci-dessous.


Le prédicat contact est une conjonction de termes. Chaque terme indique les contraintes sur une seule étiquette de caractéristique, et chaque terme est représenté par un paramètre de caractéristique distinct qui sera présent dans le champ d’en-tête Contact. La syntaxe de ce paramètre dépend de l’étiquette de caractéristique. Chaque barre oblique dans l’étiquette de caractéristique est convertie en un guillemet simple, et chaque caractère deux-points est converti en un point d’exclamation. Pour l’étiquette de base – c’est-à-dire, les étiquettes de caractéristique documentées dans la présente spécification (sip.audio, sip.automata, sip.class, sip.duplex, sip.data, sip.control, sip.mobility, sip.description, sip.events, sip.priority, sip.methods, sip.extensions, sip.schemes, sip.application, sip.video, language, type, sip.isfocus, sip.actor et sip.text) le "sip." en tête, s’il est présent, est supprimé. Pour les étiquettes de caractéristique qui ne sont pas dans cette liste, le "sip." en tête NE DOIT PAS être supprimé s’il est présent, et bien sûr, un signe plus ("+") DOIT être ajouté comme premier caractère du paramètre de champ d’en-tête Contact. Le résultat est le nom du paramètre de caractéristique. Par suite de ces règles, les étiquettes de base apparaissent "nues" dans le champ d’en-tête Contact – elles n’ont ni un "+" ni un préfixe "sip.". Toutes les autres étiquettes vont toujours avoir un "+" en tête lorsqu’elles sont présentes dans le champ d’en-tête Contact, et vont de plus avoir un "sip." si l’étiquette est dans l’arborescence SIP.


La valeur du paramètre de caractéristique dépend du terme de la conjonction. Si le terme est une expression booléenne avec une valeur de vrai, c’est-à-dire, (sip.audio=VRAI), le paramètre contact n’a pas de valeur. Si le terme de la conjonction est une disjonction, la valeur du paramètre contact est une chaîne guillemetée. La chaîne guillemetée est une liste de chaînes séparées par des virgules, chacune déduite d’un des termes de la disjonction. Si le terme de la conjonction est une négation, la valeur du paramètre contact est une chaîne guillemetée. La chaîne guillemetée commence par un point d’exclamation (!), et le reste est construit à partir de l’expression niée.


L’opération restante est de calculer une chaîne à partir d’un filtre de primitive. Si le filtre est un filtre simple qui effectue une comparaison numérique, la chaîne commence par un dièse (#), suivi par le comparateur dans le filtre (=, >=, ou <=), suivi par la valeur provenant du filtre. Si la valeur qui vient du filtre est exprimée en forme rationnelle (X / Y), X et Y sont alors divisés, donnant un nombre décimal, et ce nombre décimal est ajouté à la chaîne.


La [RFC2533] utilise une notation fractionnaire pour décrire les nombres rationnels. La présente spécification utilise une forme décimale. Le texte ci-dessus fait une simple conversion entre les deux représentations. En pratique, cette conversion n’est pas nécessaire car les nombres sont les mêmes dans les deux cas. Cependant, elle est décrite au cas où les mises en œuvre souhaiteraient coller directement les prédicats générés par les règles de ce paragraphe dans une mise en œuvre de la RFC2533.


Si le filtre est une gamme (foo=X..Y), la chaîne est égale à X:Y, où X et Y ont été convertis de nombres fractionnels (A / B) en leur équivalent décimal.


Si le filtre est une égalité sur un jeton ou un booléen, ce jeton ou cette valeur booléenne ("VRAI" ou "FAUX") est ajoutée à la chaîne.


Si le filtre est une égalité sur une chaîne guillemetée, le résultat est un moins que (<), suivi par la chaîne guillemetée, suivie par un supérieur à (>).


Par exemple, ce prédicat de caractéristique :


(& (sip.mobility=fixed)

(| (! (sip.events=presence)) (sip.events=message-summary))

(| (language=en) (language=de))

(sip.description="PC")

(sip.newparam=TRUE)

(rangeparam=-4..5125/1000))


serait converti en les paramètres de caractéristiques suivants :


mobility="fixed";events="!presence,message-summary";language="en,de";description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"


Ces étiquettes de caractéristique apparaîtraient alors au titre du champ d’en-tête Contact :


Contact: <sip:user@pc.example.com>;mobility="fixed";events="!presence,message-summary";language="en,de"; description="<PC>";+sip.newparam;+rangeparam="#-4:+5.125"


On remarque comment le "sip." en tête a été supprimé des étiquettes de caractéristique sip.mobility, sip.events et sip.description avant de les coder dans le champ d’en-tête Contact. C’est parce que ces étiquettes de caractéristique font partie des étiquettes de base énumérées plus haut. C’est pour cette raison que ces étiquettes de caractéristique n’ont pas non plus été codées avec un "+" en tête. Cependant, l’étiquette de caractéristique sip.newparam était codée avec les deux "+" et son "sip." en tête, et le paramètre de gamme rangeparam a été aussi codé avec un "+" en tête. C’est parce que aucune de ces étiquettes de caractéristique n’est définie dans la présente spécification. À ce titre, le "sip." en tête n’est pas supprimé, et un "+" est ajouté.


6. Expression des capacités dans un enregistrement


Lorsque un UA s’enregistre, il peut choisir d’indiquer un ensemble de caractéristiques associé à un contact enregistré. Qu’un UA le fasse ou non dépend de ce que représente l’URI enregistré. Si l’URI enregistré représente une instance d’UA (le cas courant des enregistrements) un UA conforme à la présente spécification DEVRAIT indiquer un ensemble de caractéristiques en utilisant les mécanismes décrits ici. Si, cependant, l’URI enregistré représente une adresse d’enregistrement, ou quelque autre ressource qui n’est pas représentable par un seul ensemble de caractéristiques, il NE DEVRAIT PAS inclure un ensemble de caractéristiques. Par exemple, si un usager souhaite transmettre des appels provenant de sip:user1@example.com à sip:user2@example.org, il pourrait générer un enregistrement qui ressemblerait en partie à :


REGISTER sip:example.com SIP/2.0

To: sip:user1@example.com

Contact: sip:user2@example.org


Dans ce cas, le contact enregistré n’identifie pas un UA, mais plutôt une autre adresse d’enregistrement (AOR, address-of-record). Dans ce cas, le contact enregistré n’indiquerait pas un ensemble de caractéristiques.


Cependant, dans certains cas, un UA peut souhaiter exprimer des paramètres de caractéristiques pour une adresse d’enregistrement. Un exemple en est une AOR qui représente une multiplicité d’appareils dans un réseau domestique, et qui achemine à un serveur mandataire dans la maison de l’usager. Comme tous les appareils de la maison sont à usage personnel, l’AOR elle-même peut être décrite avec le paramètre de caractéristique ;class="personal". Un enregistrement qui transmet des appels à cet AOR domestique pourrait utiliser ce paramètre de caractéristique. En règle générale, un paramètre de caractéristique peut seulement être associé à une adresse d’enregistrement si tous les appareils liés à cette adresse d’enregistrement partagent le même ensemble exact de valeurs pour ce paramètre de caractéristique.


De même, dans certains cas, un UA peut présenter une caractéristique ou une autre, mais la caractéristique n’est pas connue à l’avance. Par exemple, un UA pourrait représenter un appareil qui est un téléphone avec un répondeur intégré. La façon idéale de traiter de tels appareils est de les modéliser comme si ils étaient en fait un mandataire devant deux appareils - un téléphone (qui n’est jamais un répondeur) et un répondeur (qui n’est jamais un téléphone). L’enregistrement de cet appareil serait construit comme si c’était une AOR, selon les procédures ci-dessus. Généralement, cela signifie que, sauf si les caractéristiques sont identiques entre les appareils logiques, cette caractéristique ne sera présente dans aucun enregistrement généré par l’appareil réel.


Le reste de cette section suppose qu’un UA voudrait associer un ensemble de caractéristiques à un contact qui s’enregistre. Cet ensemble de caractéristiques est construit et converti en une série de paramètres de champ d’en-tête Contact, comme décrit à la Section 5, et ces paramètres de caractéristiques sont ajoutés à la valeur du champ d’en-tête Contact contenant l’URI auquel les paramètres s’appliquent. Les champs d’en-tête Allow, Accept, Accept-Language et Allow-Events [RFC3265] sont permis dans les demandes REGISTER, et indiquent aussi les capacités. Cependant, leur sémantique dans REGISTER est différente, indiquant les capacités utilisées par le registraire pour générer la réponse. À ce titre, elles ne sont pas un substitut ou une solution de remplacement pour les paramètres de caractéristiques Contact, qui indiquent les capacités de l’UA d’une façon générale.


La demande REGISTER PEUT contenir un champ d’en-tête Require avec la valeur "pref" si le client veut être sûr que le registraire comprend les extensions définies dans la présente spécification. Cela signifie que le registraire va mémoriser les paramètres de caractéristiques, et les rendre disponibles aux éléments qui accèdent au service de localisation au sein du domaine. En l’absence du champ d’en-tête Require, un registraire qui ne comprend pas cette extension va simplement ignorer les paramètres du champ d’en-tête Contact.


Si un UA s’enregistre pour plusieurs adresses d’enregistrement séparées, et si les contacts enregistrés pour chacune ont des capacités différentes, l’UA DOIT utiliser des URI différents dans chaque enregistrement. Cela permet à l’UA de déterminer de façon univoque l’ensemble de caractéristiques associé à l’URI de demande d’une demande entrante.


Par exemple, un serveur de messagerie vocale qui est un UA prenant en charge les types de support audio et vidéo et n’est pas mobile construirait un prédicat de caractéristique comme ceci :


(& (sip.audio=TRUE)

(sip.video=TRUE)

(sip.actor=msg-taker)

(sip.automata=TRUE)

(sip.mobility=fixed)

(| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS)

(sip.methods=ACK) (sip.methods=CANCEL)))


Cela serait converti en paramètres de caractéristiques et inclus dans la demande REGISTER :


REGISTER sip:example.com SIP/2.0

From: sip:user@example.com;tag=asd98

To: sip:user@example.com

Call-ID: hh89as0d-asd88jkk@host.example.com

CSeq: 9987 REGISTERMax-Forwards: 70

Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8

Contact: <sip:user@host.example.com>;audio;video;actor="msg-taker";automata;mobility="fixed"

;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"

Content-Length: 0

Noter qu’un serveur de messagerie vocale est habituellement un automate et un preneur de message.


Lorsque un UAC rafraîchit son enregistrement, il DOIT inclure ses paramètres de caractéristiques dans ce rafraîchissement si il souhaite qu’ils restent actifs. De plus, lorsque un registraire retourne une réponse 200 OK à une demande REGISTER, chaque valeur de champ d’en-tête Contact DOIT inclure tous les paramètres de caractéristiques associés à cet URI.


7. Indication des réglages de caractéristiques dans les URI de cible distante


Les demandes et réponses de rafraîchissement de cible sont utilisées pour établir et modifier l’URI de la cible distante dans un dialogue. L’URI de la cible distante est porté dans le champ d’en-tête Contact. Un UAC ou UAS PEUT ajouter des paramètres de caractéristiques à la valeur du champ d’en-tête Contact dans des demandes et réponses de rafraîchissement de cible afin d’indiquer les capacités de l’UA. Pour ce faire, il construit un ensemble de paramètres de caractéristiques conformément à la Section 5. Ceux-ci sont alors ajoutés aux paramètres du champ d’en-tête Contact dans la demande ou la réponse.


Les paramètres de caractéristiques peuvent être inclus dans les demandes initiales et les demandes de mi-dialogue, et PEUVENT changer à mi-dialogue pour signaler un changement des capacités de l’UA.


Il y a un chevauchement du mécanisme de capacités de l’appelant avec les champs d’en-tête Allow, Accept, Accept-Language, et Allow-Events [RFC3265], qui peuvent aussi être utilisés dans les demandes de rafraîchissement de cible. Précisément, le champ d’en-tête Allow et l’étiquette de caractéristique "sip.methods" indiquent les mêmes informations. Le champ d’en-tête Accept et l’étiquette de caractéristique "type" indiquent les mêmes informations. Le champ d’en-tête Accept-Language et l’étiquette de caractéristique "language" indiquent les mêmes informations. Le champ d’en-tête Allow-Events et l’étiquette de caractéristique "sip.events" indiquent les mêmes informations. Il est possible que d’autres champs d’en-tête et étiquettes de caractéristique définis à l’avenir se recoupent aussi. Lorsque il existe une étiquette de caractéristique qui décrit une capacité qui peut aussi être représentée par un champ d’en-tête SIP, un UA DOIT utiliser le champ d’en-tête pour décrire la capacité. Un UA qui reçoit un message contenant à la fois le champ d’en-tête et l’étiquette de caractéristique DOIT utiliser le champ d’en-tête, et non l’étiquette de caractéristique.


8. Traitement de OPTIONS


Lorsque un UAS conforme à la présente spécification reçoit une demande OPTIONS, il PEUT ajouter des paramètres de caractéristiques au champ d’en-tête Contact dans la réponse OPTIONS afin d’indiquer les capacités de l’UA. Pour ce faire, il construit un ensemble de paramètres de caractéristiques conformément à la Section 5. Celui-ci est ensuite ajouté comme paramètres de champ d’en-tête Contact dans la réponse OPTIONS. Bien sûr, si les paramètres de caractéristiques étaient inclus dans l’enregistrement généré par cet UA, ces mêmes paramètres DEVRAIENT être utilisés dans la réponse OPTIONS.


Les lignes directrices de la Section 7 concernant le chevauchement des diverses étiquettes de caractéristique de capacités d’appelant avec les champs d’en-tête SIP s’appliquent aussi à la génération des réponses OPTIONS. En particulier, elles s’appliquent lorsque un champ d’en-tête Contact décrit l’UA qui a généré la réponse OPTIONS. Lorsque un champ d’en-tête Contact dans la réponse OPTIONS identifie un UA différent, il n’y a pas de chevauchement.


9. Champ d’en-tête Contact


La présente spécification étend le champ d’en-tête Contact. En particulier, elle permet aux paramètres du champ d’en-tête Contact d’inclure des paramètres de caractéristique (feature-param). "feature-param” est un paramètre de caractéristique qui décrit une caractéristique de l’UA associé à l’URI dans le champ d’en-tête Contact. Les paramètres de caractéristique sont identifiables parce qu’ils appartiennent à l’ensemble bien connu des étiquettes de caractéristique de base, ou qu’ils commencent par un signe plus.


feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list / string-value ) RDQUOT]

enc-feature-tag = base-tags / other-tags

base-tags = "audio" / "automata" / "class" / "duplex" / "data" / "control" / "mobility" / "description" / "events" / "priority" / "methods" / "schemes" / "application" / "video" / "language" / "type" / "isfocus" / "actor" / "text" / "extensions"

other-tags = "+" ftag-name

ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / "." / "-" / "%" )

tag-value-list = tag-value *("," tag-value)

tag-value = ["!"] (token-nobang / boolean / numeric)

token-nobang = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" )

boolean = "VRAI" / "FAUX"

numeric = "#" numeric-relation number

numeric-relation = ">=" / "<=" / "=" / (number ":")

number = [ "+" / "-" ] 1*CHIFFRE ["." 0*CHIFFRE]

string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">"

qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII


Noter que la liste tag-value-list utilise une vraie virgule au lieu de la construction COMMA parce qu’elle apparaît au sein d’une chaîne guillemetée où le renvoi à la ligne ne peut avoir lieu.


La production pour qdtext se trouve dans la [RFC3261].


Il y a des contraintes supplémentaires à l’usage de “feature-param” qui ne peuvent pas être représentées dans un BNF. Il DOIT n’y avoir qu’une seule instance de toute étiquette de caractéristique dans feature-param. Tout nombre présent dans un paramètre de caractéristique DOIT être représentable en utilisant un double ANSI C.


La production suivante met à jour celui de la [RFC3261] pour contact-params :


contact-params = c-p-q / c-p-expires / feature-param / contact-extension


10. Définitions d’étiquette de caractéristique de support


La présente spécification définit un ensemble initial d’étiquettes de caractéristique du support à utiliser avec la présente spécification. Cette section sert d’enregistrement auprès de l’IANA pour ces étiquettes de caractéristique, qui est fait dans l’arborescence SIP d’étiquette de caractéristique du support. De nouvelles étiquettes de caractéristique du support seront enregistrées dans l’arborescence de l’IETF ou les arborescences globales sur la base du processus défini pour l’enregistrement des étiquettes de caractéristique [RFC2506], ou dans l’arborescence SIP sur la base du processus défini au paragraphe 12.1.


Toutes les étiquettes de caractéristique enregistrées PEUVENT être utilisées avec la présente spécification. Cependant, plusieurs de celles qui existent paraissent particulièrement applicables. Cela inclut l’étiquette de caractéristique de langage [RFC2987], qui peut être utilisée pour spécifier le langage de la personne ou de l’automate représenté par l’UA, et l’étiquette de caractéristique de type [RFC2913], qui peut être utilisée pour spécifier les types MIME qu’un UA SIP peut recevoir dans un message SIP. Les étiquettes de caractéristique audio, vidéo, application, data, et control dans l’arborescence SIP (dont chacune indique un type de support, et sont définies dans la [RFC2327]) sont différentes. Elles n’indiquent pas les types MIME de niveau supérieur qui peuvent être reçus dans les demandes SIP. Elles indiquent plutôt les types de support qui peuvent être utilisés dans les flux de supports, et par suite, correspondent aux types définis dans la [RFC2327].


Si un nouveau type de support SDP devait être défini, comme "message", un nouvel enregistrement d’étiquette de caractéristique DEVRAIT être créé pour lui dans l’arborescence SIP. Le nom de l’étiquette de caractéristique DOIT être égal à "sip." enchaîné avec le nom du type de support, sauf au cas peu probable de collision de dénomination entre le nouveau type de support et un enregistrement existant d’étiquette de caractéristique. Il en résulte que les mises en œuvre peuvent en toute sécurité construire les préférences de l’appelant et les capacités de l’appelant pour le nouveau type de support avant qu’il soit enregistré, tant qu’il n’y a pas de conflit de dénomination.


Si une nouvelle étiquette de caractéristique du support est enregistrées avec l’intention d’utiliser cette étiquette avec la présente spécification, l’enregistrement est fait pour la forme non codée de l’étiquette (voir la Section 5). En d’autres termes, si une nouvelle étiquette de caractéristique "foo" est enregistrée dans l’arborescence de l’IETF, l’enregistrement de l’IANA serait pour l’étiquette "foo" et non "+foo". De même, si une nouvelle étiquette de caractéristique "sip.gruu" est enregistrée dans l’arborescence SIP, l’enregistrement de l’IANA serait pour l’étiquette "sip.gruu" et non "+sip.gruu" ou "gruu". À ce titre, tous les enregistrements dans l’arborescence SIP auront le préfixe "sip.".


Les étiquettes de caractéristique dans cette section sont toutes enregistrées dans l’arborescence d’étiquette de caractéristique du support SIP créée par le paragraphe 12.1.


10.1 Audio

Nom d’étiquette de caractéristique de support : sip.audio

Identifiant ASN.1 : 1.3.6.1.8.4.1

Résumé des caractéristique du support indiquées par cette étiquette : Cette étiquette de caractéristique indique que l’appareil prend en charge l’audio comme type de support de flux.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil tel qu’un téléphone ou PDA.

Exemples d’utilisation normale : acheminement d’un appel à un téléphone qui peut prendre en charge l’audio.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.2 Application

Nom d’étiquette de caractéristique de support : sip.application

Identifiant ASN.1 : 1.3.6.1.8.4.2

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique que l’appareil prend en charge des applications comme un type de support de flux. Cette étiquette de caractéristique existe principalement par souci de complétude. Comme de très nombreux types MIME sont en dessous de l’application, indiquer la capacité à prendre en charge des applications apporte peu d’informations utiles.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen.

L’étiquette de caractéristique est destinée principalement à être utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications, pour décrire les capacités d’un appareil, tel qu’un téléphone ou PDA.

Exemples d’utilisation normale : acheminer un appel à un téléphone qui peut prendre en charge une application de contrôle du support.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.3 Data

Nom d’étiquette de caractéristique de support : sip.data

Identifiant ASN.1 : 1.3.6.1.8.4.3

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique que l’appareil prend en charge data comme type de support de flux.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, tel qu’un téléphone ou PDA.

Exemples d’utilisation normale : acheminer un appel à un téléphone qui peut prendre en charge une application de flux de données.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.4 Control

Nom d’étiquette de caractéristique de support : sip.control

Identifiant ASN.1 : 1.3.6.1.8.4.4

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique que l’appareil prend en charge control comme type de support de flux.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, tel qu’un téléphone ou PDA.

Exemples d’utilisation normale : acheminer un appel à un téléphone qui peut prendre en charge une application de contrôle plancher.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.5 Video

Nom d’étiquette de caractéristique de support : sip.video

Identifiant ASN.1 : 1.3.6.1.8.4.5

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique que l’appareil prend en charge la vidéo comme type de support de flux.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : acheminer un appel à un téléphone qui peut prendre en charge une application de vidéo.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.6 Text

Nom d’étiquette de caractéristique de support : sip.text

Identifiant ASN.1 : 1.3.6.1.8.4.6

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique que l’appareil prend en charge text comme type de support de flux.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : acheminer un appel à un téléphone qui peut prendre en charge une application de texte.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.7 Automata

Nom d’étiquette de caractéristique de support : sip.automata

Identifiant ASN.1 : 1.3.6.1.8.4.7

Résumé des caractéristique du support indiquées par cette étiquette : l’étiquette de caractéristique sip.automata est une valeur booléenne qui indique si l’UA représente un automate (comme un serveur de messagerie vocale, un serveur de conférence, un IVR, ou un appareil enregistreur) ou une personne.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen. VRAI indique que l’UA représente un automate.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : refuser de communiquer avec un automate quand on sait que les services automatiques sont inacceptables.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.8 Class

Nom d’étiquette de caractéristique de support : sip.class

Identifiant ASN.1 : 1.3.6.1.8.4.8

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique le réglage, professionnel ou personnel, dans lequel l’appareil de communications est utilisé.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs normales incluent :

professionnel : l’appareil est utilisé pour des communications professionnelles.

personnel : l’appareil est utilisé pour des communications personnelles.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications, pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir entre un téléphone professionnel et un téléphone domestique.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.9 Duplex

Nom d’étiquette de caractéristique de support : sip.duplex

Identifiant ASN.1 : 1.3.6.1.8.4.9

Résumé des caractéristique du support indiquées par cette étiquette : l’étiquette de caractéristique du support sip.duplex indique si un appareil de communications peut simultanément envoyer et recevoir un support ("full"), alterner entre envoyer et recevoir ("half"), peut seulement recevoir ("receive-only") ou seulement envoyer ("send-only").

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs normales incluent :

full : l’appareil peut simultanément envoyer et recevoir sur le support.

half : l’appareil peut alterner entre envoyer et recevoir sur le support.

receive-only : l’appareil peut seulement recevoir sur le support.

send-only : l’appareil peut seulement envoyer sur le support.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir de communiquer avec un serveur de diffusion, par opposition à un téléphone normal, lorsque on fait un appel pour écouter une annonce.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.10 Mobility

Nom d’étiquette de caractéristique de support : sip.mobility

Identifiant ASN.1 : 1.3.6.1.8.4.10

Résumé des caractéristique du support indiquées par cette étiquette : l’étiquette de caractéristique sip.mobility indique si l’appareil est fixe (ce qui signifie qu’il est associé à un point de contact fixe avec le réseau) ou mobile (signifiant qu’il n’est pas associé à un point de contact fixe). Noter que les téléphones sans cordon sont fixes, non mobiles, sur la base de cette définition.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs normales incluent :

fixe : l’appareil est stationnaire.

mobile : l’appareil peut se déplacer avec l’usager.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir de communiquer avec un téléphone sans fil au lieu d’un téléphone fixe.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.11 Description

Nom d’étiquette de caractéristique de support : sip.description

Identifiant ASN.1 : 1.3.6.1.8.4.11

Résumé des caractéristique du support indiquées par cette étiquette : l’étiquette de caractéristique sip.description fournit une description textuelle de l’appareil.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : chaîne avec une relation d’égalité.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : indiquer qu’un appareil est d’un certain type et modèle.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.12 Event Packages

Nom d’étiquette de caractéristique de support : sip.events

Identifiant ASN.1 : 1.3.6.1.8.4.12

Résumé des caractéristique du support indiquées par cette étiquette : chaque valeur de l’étiquette de caractéristique sip.events (noter le pluriel) indique un paquetage d’événements SIP [RFC3265] pris en charge par un UA SIP. Les valeurs pour cette étiquette sont égales aux noms de paquetage d’événement qui sont enregistrés par chaque paquetage d’événements.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs sont tirées du registre IANA de l’espace de noms de types d’événement SIP.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir de communiquer avec un serveur qui prend en charge le paquetage d’événement d’attente de message, comme un serveur de messagerie vocale [RFC3842].

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.13 Priority

Nom d’étiquette de caractéristique de support : sip.priority

Identifiant ASN.1 : 1.3.6.1.8.4.13

Résumé des caractéristique du support indiquées par cette étiquette : l’étiquette de caractéristique sip.priority indique les priorités d’appel que l’appareil accepte de traiter. Une valeur de X signifie que l’appareil accepte de prendre des demandes avec la priorité X et supérieure. Cela n’implique pas qu’un téléphone doit rejeter les appels de priorité inférieure. Comme toujours, la décision on de traiter de tels appels est l’affaire de la politique locale.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : un entier. Chaque valeur d’entier correspond à une des valeurs possibles du champ d’en-tête Priority comme spécifié dans SIP [RFC3261]. La transposition est définie comme :

non-urgent : valeur d’entier de 10. L’appareil accepte les appels non urgents.

normal : valeur d’entier de 20. L’appareil accepte les appels normaux.

urgent : valeur d’entier de 30. L’appareil accepte les appels urgents.

extrême urgence : valeur d’entier de 40. L’appareil accepte les appels dans le cas de situation d’extrême urgence.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir de communiquer avec le téléphone cellulaire d’urgence d’un usager.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.14. Methods

Nom d’étiquette de caractéristique de support : sip.methods

Identifiant ASN.1 : 1.3.6.1.8.4.14

Résumé des caractéristique du support indiquées par cette étiquette : chaque valeur de l’étiquette de caractéristique sip.methods (noter le pluriel) indique une méthode SIP prise en charge par cet UA. Dans ce cas, "pris en charge" signifie que l’UA peut recevoir des demandes avec cette méthode. Dans ce sens, il a la même connotation que le champ d’en-tête Allow.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs sont tirées du Tableau des méthodes défini dans le registre IANA des paramètres SIP.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir de communiquer avec une application de présence sur un PC, au lieu de l’application téléphone d’un PC.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.15 Extensions

Nom d’étiquette de caractéristique de support : sip.extensions

Identifiant ASN.1 : 1.3.6.1.8.4.15

Résumé des caractéristique du support indiquées par cette étiquette : chaque valeur de l’étiquette de caractéristique sip.extensions (noter le pluriel) est une extension SIP (dont chacune est définie par une étiquette d’option enregistrée auprès de l’IANA) qui est comprise par l’UA. Compris, dans ce contexte, signifie que l’étiquette d’option sera incluse dans le champ d’en-tête Supported d’une requête.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs sont tirées du Tableau des étiquettes d’option du registre des paramètres SIP de l’IANA.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir de communiquer avec un téléphone qui prend en charge des pré conditions de qualité de service plutôt qu’un qui ne le fait pas.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.16 Schemes

Nom d’étiquette de caractéristique de support : sip.schemes

Identifiant ASN.1 : 1.3.6.1.8.4.16

Résumé des caractéristique du support indiquées par cette étiquette : chaque valeur de l’étiquette de caractéristique du support sip.schemes (noter le pluriel) indique un schéma d’URI [RFC2396] qui est accepté par un UA. Accepté implique, par exemple, que l’UA va savoir comment traiter un URI de ce schéma dans le champ d’en-tête Contact d’une réponse redirect.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs sont tirées du registre de schéma d’URI de l’IANA.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : choisir d’être redirigé sur un numéro de téléphone lorsque l’appelé est occupé, plutôt qu’une page de la Toile.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.17 Actor

Nom d’étiquette de caractéristique de support : sip.actor

Identifiant ASN.1 : 1.3.6.1.8.4.17

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique le type d’entité qui est disponible à cet URI.

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : jeton avec une relation d’égalité. Les valeurs suivantes sont définies :

principal : l’appareil assure la communication avec le principal associé à l’appareil. Ce sera souvent une personne spécifique, mais ce peut être un automate (par exemple, pour appeler un portail vocal).

attendant : l’appareil assure la communication avec un automate ou une personne qui va agir en intermédiaire en contactant le principal associé à l’appareil, ou un substitut de celui-ci.

msg-taker : l’appareil assure la communication avec un automate ou une personne qui va prendre les messages et les livrer au principal.

information : l’appareil assure la communication avec un automate ou une personne qui va fournir des informations sur le principal.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : demander qu’un appel ne soit pas acheminé à une messagerie vocale.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


10.18 Is Focus

Nom d’étiquette de caractéristique de support : sip.isfocus

Identifiant ASN.1 : 1.3.6.1.8.4.18

Résumé des caractéristique du support indiquées par cette étiquette : cette étiquette de caractéristique indique que l’UA est un serveur de conférence, aussi appelé point de convergence (focus) qui va assembler les supports pour tous les appels au même URI [RFC4353].

Valeurs appropriées pour l’usage de cette étiquette de caractéristique : Booléen.

L’étiquette de caractéristique est destinée à être principalement utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : cette étiquette de caractéristique est des plus utiles dans une application de communications pour décrire les capacités d’un appareil, comme un téléphone ou PDA.

Exemples d’utilisation normale : indiquer à un UA que le serveur auquel il s’est connecté est un serveur de conférence.

Normes ou documents en rapport : RFC 3840

Considérations pour la sécurité : les considérations de sécurité pour cette étiquette de caractéristique du support sont exposées au paragraphe 11.1 de la RFC 3840.


11. Considérations pour la sécurité

11.1 Considérations sur les étiquettes de caractéristique de support

La présente Section expose les considérations de sécurité pour les étiquettes de caractéristique du support, sans ce limiter à la présente spécification.


Les étiquettes de caractéristique du support définies à la Section 10 révèlent des informations sensibles sur un usager ou sur l’agent d’utilisateur qu’elles décrivent. Certaines des étiquettes de caractéristique portent des informations sur les capacités de l’agent – par exemple, les types de support qu’il peut accepter, les méthodes SIP qu’il peut prendre en charge, et les extensions SIP qu’il accepte. Ces informations de capacités peuvent être utilisées pour de l’espionnage industriel, par exemple, de sorte que leur protection peut avoir son importance. D’autres attributs, comme la mobilité, la priorité, et les attributs isfocus, révèlent les caractéristiques de l’agent d’utilisateur. Ces attributs sont plus sensibles que les informations de capacité. Ils décrivent la façon dont un agent d’utilisateur est utilisé par un usager, et révèlent donc les informations sur les préférences de l’usager et la façon dont il veut que les appels soient traités. Certaines étiquettes de caractéristique, comme les langages, révèlent des informations sur l’usager lui-même. Il en résulte que les applications qui utilisent ces étiquettes de caractéristique du support DEVRAIENT fournir un moyen pour s’assurer de leur confidentialité.


Les étiquettes de caractéristique du support peuvent être utilisées de façons qui affectent les comportements d’application. Par exemple, l’extension SIP de préférences de l’appelant [RFC3841] permet de prendre des décisions d’acheminement des appels sur la base des valeurs de ces paramètres. Donc, si un attaquant peut modifier les valeurs de ces étiquettes de caractéristique, elle peuvent affecter le comportement des applications. Il en résulte que les applications qui utilisent ces étiquettes de caractéristique du support DEVRAIENT fournir un moyen pour s’assurer de leur intégrité. De même, les étiquettes de caractéristique du support ne devraient être considérées comme valides que lorsque elles viennent de l’usager ou agent d’utilisateur décrit par ces étiquettes de caractéristique. Il s’ensuit que les mécanismes pour convoyer les étiquettes de caractéristique DEVRAIENT fournir un mécanisme pour garantir leur authenticité.


11.2 Considérations sur les enregistrements

Selon les exigences générales du paragraphe 11.1, lorsque des étiquettes de caractéristique du support sont portées dans un enregistrement, l’authenticité, la confidentialité, et l’intégrité doivent être assurées. Pour ce faire, les enregistrements qui contiennent des informations de capacités DEVRAIENT être fournies en adressant l’enregistrement à un URI SIPS (en d’autres termes, l’URI de demande de la demande devrait être sips:example.com lors de la création d’un enregistrement dans le domaine example.com). De plus, le registraire DEVRAIT mettre au défi l’UA en utilisant un résumé sur TLS, pour vérifier son authenticité. La combinaison de TLS et du résumé assure l’intégrité, la confidentialité, et l’authenticité, comme exige.


Il n’est pas nécessaire que le contact dans l’enregistrement contienne lui-même un URI sips, car les étiquettes de caractéristique ne sont pas portées dans les demandes entrantes envoyées à l’UA.


11.3 Considérations sur les réponses à OPTIONS

Lors de l’inclusion d’informations sur les capacités dans une réponse à une demande OPTIONS, un UA DEVRAIT vérifier avec l’usager (à travers une interface d’utilisateur ou par configuration préalable) si les informations de capacités devraient être ou non divulguées au demandeur. Si l’identité du demandeur ne peut pas être vérifiée cryptographiquement (en utilisant le résumé ou les améliorations sur l’identité SIP de la [RFC4474]) l’usager DEVRAIT aussi être alerté sur ce fait, et avoir la possibilité de choisir si de telles informations devraient être divulguées.


Si l’usager souhaite révéler les informations de capacités au demandeur, et souhaite garantir leur confidentialité, mais si la demande n’est pas arrivée avec SIPS, l’UAS DEVRAIT rediriger la demande sur un URI sips. Cela va amener l’UAC à envoyer la demande OPTIONS en utilisant SIPS à la place, et donc, fournir la confidentialité de toute réponse envoyée sur des connexions sûres.


De plus, S/MIME PEUT être utilisé dans la réponse OPTIONS. Dans ce cas, les informations de capacité ne seront contenues que dans le corps S/MIME sécurisé, et non dans les champs d’en-tête de la réponse OPTIONS.


11.4 Considérations sur les messages d’initiation de dialogue

Lorsque un UAS génère une réponse qui va initier un dialogue, et qu’il souhaite inclure des informations de capacités dans le champ d’en-tête Contact, les mêmes considérations que décrites au paragraphe 11.3 s’appliquent.


Lorsque un UAC génère une demande qui va initier un dialogue, il DEVRAIT obtenir la permission de l’usager (soit à travers une interface d’usager, soit par configuration à priori) avant d’inclure des informations de capacités dans le champ d’en-tête Contact de la demande. La confidentialité et l’intégrité des informations DEVRAIENT être assurées en utilisant SIPS. S/MIME PEUT être utilisé.


12. Considérations relatives à l’IANA


Un certain nombre de considérations relatives à l’IANA sont associées à la présente spécification.


12.1 Arborescence d’enregistrement d’étiquette de caractéristique de support SIP

La présente spécification sert à créer une nouvelle arborescence d’enregistrement d’étiquette de caractéristique du support, selon les lignes directrices du paragraphe 3.1.4 de la [RFC2506]. Le nom de cette arborescence est "arborescence d’enregistrement d’étiquette de caractéristique de support SIP", et son préfixe est "sip.". Il est utilisé pour l’enregistrement des étiquettes de caractéristique du support qui sont applicables au protocole d’initialisation de session, et dont la signification n’est définie qu’au sein de cet usage.


L’ajout d’entrées dans ce registre se fait par consensus de l’IETF, comme défini dans la [RFC2434]. Cela exige la publication d’une RFC qui contient l’enregistrement. Les informations requises dans l’enregistrement sont identiques à celles de l’arborescence de l’IETF. À ce titre, les spécifications qui ajoutent des entrées au registre devraient utiliser le gabarit fourni au paragraphe 3.4 de la [RFC2506]. Noter que toutes les étiquettes de caractéristique du support enregistrées dans l’arborescence SIP vont avoir des noms avec un préfixe de "sip.". Aucun "+" n’est utilisé en tête dans l’enregistrement des arborescences d’étiquette de caractéristique du support.


12.2 Étiquettes de caractéristique de support

La présente spécification enregistre un certain nombre de nouvelles étiquettes de caractéristique du support conformément aux procédures de la [RFC2506]. Ces enregistrements sont tous faits dans l’arborescence SIP nouvellement créée pour les étiquettes de caractéristique du support. Ces enregistrements sont :


sip.audio : les informations pour enregistrer l’étiquette sip.audio de caractéristique du support sont contenues au paragraphe 10.1.


sip.application : les informations pour enregistrer l’étiquette sip.application de caractéristique du support sont contenues au paragraphe 10.2.


sip.data : les informations pour enregistrer l’étiquette sip.data de caractéristique du support sont contenues au paragraphe 10.3.


sip.control : les informations pour enregistrer l’étiquette sip.control de caractéristique du support sont contenues au paragraphe 10.4.


sip.video : les informations pour enregistrer l’étiquette sip.video de caractéristique du support sont contenues au paragraphe 10.5.


sip.text : les informations pour enregistrer l’étiquette sip.text de caractéristique du support sont contenues au paragraphe 10.6.


sip.automata : les informations pour enregistrer l’étiquette sip.automata de caractéristique du support sont contenues au paragraphe 10.7.


sip.class : les informations pour enregistrer l’étiquette sip.class de caractéristique du support sont contenues au paragraphe 10.8.


sip.duplex : les informations pour enregistrer l’étiquette sip.duplex de caractéristique du support sont contenues au paragraphe 10.9.


sip.mobility : les informations pour enregistrer l’étiquette sip.mobility de caractéristique du support sont contenues au paragraphe 10.10.


sip.description : les informations pour enregistrer l’étiquette sip.description de caractéristique du support sont contenues au paragraphe 10.11.


sip.events : les informations pour enregistrer l’étiquette sip.events de caractéristique du support sont contenues au paragraphe 10.12.


sip.priority : les informations pour enregistrer l’étiquette sip.priority de caractéristique du support sont contenues au paragraphe 10.13.


sip.methods : les informations pour enregistrer l’étiquette sip.methods de caractéristique du support sont contenues au paragraphe 10.14.


sip.extensions : les informations pour enregistrer l’étiquette sip.extensions de caractéristique du support sont contenues au paragraphe 10.15.


sip.schemes : les informations pour enregistrer l’étiquette sip.schemes de caractéristique du support sont contenues au paragraphe 10.16.


sip.actor : les informations pour enregistrer l’étiquette sip.actor de caractéristique du support sont contenues au paragraphe 10.17.


sip.isfocus : les informations pour enregistrer l’étiquette sip.isfocus de caractéristique du support sont contenues au paragraphe 10.18.


12.3 Étiquette d’option SIP

La présente spécification enregistre une seule étiquette d’option SIP, pref. Les information requises pour cet enregistrement, comme spécifié dans la [RFC3261], sont :


Nom : pref


Description : cette étiquette d’option est utilisée dans un champ d’en-tête Require d’un enregistrement pour s’assurer que le registraire accepte les extensions de préférences de l’appelant .


13. Remerciements


Le jeu initial d’étiquettes de caractéristique du support utilisé par la présente spécification a été influencé par la conception de CMA de Scott Petrack. Jonathan Lennox, Bob Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, et John Hearty ont fourni d’utiles commentaires. Graham Klyne a fourni son assistance sur l’utilisation de la RFC 2533. Merci à Allison Mankin pour ses commentaires et son soutien, et à Ted Hardie pour ses conseils sur l’usage des étiquettes de caractéristique du support.


14. Références

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


[RFC2327] M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998. (Obsolète; voir RFC4566)


[RFC2396] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", août 1998. (Obsolète, voir RFC3986)


[RFC2506] K. Holtman, A. Mutz, T. Hardie, "Procédure d'enregistrement d'étiquette de caractéristique de support", mars 1999. (BCP0031)


[RFC2533] G. Klyne, "Syntaxe de description des ensembles de caractéristiques des supports", mars 1999. (MàJ par RFC2738, RFC2938) (P.S.)


[RFC2738] G. Klyne, "Corrections à "Syntaxe pour décrire les ensembles de caractéristiques de support", décembre 1999. (P.S.)


[RFC2913] G. Klyne, "Types de contenu MIME dans les expressions de caractéristiques de support", septembre 2000. (P.S.)


[RFC2987] P. Hoffman, "Enregistrement des étiquettes de caractéristiques de support de jeu de caractères et de langage", novembre 2000. (P.S.)


[RFC3261] J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC6665) )


[RFC3265] A.B. Roach, "Notification d'événement spécifique du protocole d'initialisation de session (SIP)", juin 2002. (MàJ par RFC6446) (Remplacée par la RFC6665)


14.2. Références pour information

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)


[RFC2703] G. Klyne, "Cadre de négociation de contenu indépendant du protocole", septembre 1999. (Information)


[RFC3428] B. Campbell et autres, "Extension de messagerie instantanée pour le protocole d'initialisation de session (SIP) ", déc. 2002.


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


[RFC3842] R. Mahy, "Paquetage d'événement Résumé de message et Indication de message en attente pour le protocole d'initialisation de session (SIP)", août 2004.


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


[RFC4474] J. Peterson et C. Jennings, "Améliorations de la gestion d'identité authentifiée dans le protocole d'initialisation de session (SIP)", août 2006. (P.S.)


[RFC4515] M. Smith, éd. et T. Howes, "Protocole léger d'accès aux répertoires (LDAP) : Représentation de chaîne des filtres de recherche", juin 2006.


Appendice A. Vue d’ensemble de la RFC2533


La présente Section donne une brève vue d’ensemble de la RFC 2533 et des spécifications qui s’y rapportent et forment le cadre de négociation de contenu. Cette section ne représente pas un comportement normatif. En cas de conflit entre le matériau indicatif présenté ici et le texte normatif de la RFC 2533, la RFC 2533 a la préséance.


Un concept critique du cadre est celui d’ensemble de caractéristiques. Un ensemble de caractéristiques est des informations sur une entité (dans notre cas, un UA) qui décrit un ensemble de caractéristiques qu’il peut traiter. Un ensemble de caractéristiques peut être vu comme une région dans un espace à N dimensions. Chaque dimension de l’espace est une caractéristique du support différente, identifiée par une étiquette de caractéristique du support. Par exemple, une dimension (ou axe) pourrait représenter des langages, une autre pourrait représenter des méthodes, et une autre, des types MIME. Une collection de caractéristiques représente un seul point dans cet espace. Il représente un rendu ou instance particulier d’une entité (dans notre cas, un UA). Par exemple, un "rendu" d’un UA définirait un mode de fonctionnement instantané qu’il peut prendre en charge. Un tel rendu serait de traiter la méthode INVITE, qui porte le type MIME application/sdp, d’envoyer à un UA pour un usager qui parle anglais.


Un ensemble de caractéristiques peut donc être défini comme un ensemble de collections de caractéristiques. En d’autres termes, un ensemble de caractéristiques est aune région d’espaces de caractéristique à N dimensions, cette région étant définie par l’ensemble de points - collections de caractéristiques – qui constitue l’espace. Si une collection de caractéristiques particulière est dans l’espace, cela signifie que le rendu décrit par cette collection de caractéristiques est acceptée par l’appareil avec cet ensemble de caractéristiques.


Comment représente t-on un ensemble de caractéristiques ? Il y a de nombreuses façons de décrire un espace à N dimensions. L’une d’elles est d’identifier les fonctions mathématiques qui identifient ses contours. En clair, ceci est trop complexe pour être utile. La solution de la RFC 2533 est de définir l’espace avec un prédicat d’ensemble de caractéristiques. Un prédicat de caractéristiques définit une relation sur un espace à N dimensions ; son entrée est tout point de cet espace (c’est-à-dire, une collection de caractéristiques) et qui est vrai pour tous les points qui sont dans la région ainsi définie.


La RFC 2533 décrit une syntaxe pour écrire ces fonctions booléennes à N dimensions, empruntées à LDAP [RFC4515]. Elle utilise une syntaxe de style prolog qui s’explique d’elle-même. Cette représentation est appelée un prédicat d’ensemble de caractéristiques. L’unité de base du prédicat est un filtre, qui est une expression booléenne mise entre parenthèses. Un filtre peut être complexe, lorsque il contient des conjonctions et disjonctions d’autres filtres, ou il peut être simple. Un filtre simple est celui qui exprime une opération de comparaison sur une seule étiquette de caractéristique du support.


Par exemple, considérons le prédicat d’ensemble de caractéristiques suivant :


(& (foo=A)

(bar=B)

(| (baz=C) (& (baz=D) (bif=E))))


Cela définit une fonction sur quatre caractéristiques du support - foo, bar, baz, et bif. Tout point de l’espace de caractéristiques avec foo égal à A, bar égal à B, et baz égal soit à C, soit à D, et bif égal à E, est dans l’ensemble de caractéristiques défini par ce prédicat d’ensemble de caractéristiques.


Noter que le prédicat ne dit rien sur le nombre de dimensions de l’espace de caractéristiques. Le prédicat fonctionne sur un espace de caractéristiques de n’importe quel nombre de dimensions, mais seules les dimensions étiquetées foo, bar, baz, et bif importent. Le résultat est que les valeurs des autres caractéristiques du support n’ont pas d’importance. La collection de caractéristiques {foo=A,bar=B,baz=C,bop=F} est dans l’ensemble de caractéristiques décrit par le prédicat, même si l’étiquette de caractéristique du support "bop" n'est pas mentionnée. Les prédicats d’ensemble de caractéristiques sont donc inclusifs par défaut. Une collection de caractéristiques est présente sauf si le prédicat booléen l’élimine. C’était un choix conscient de la RFC 2533.


La RFC 2533 parle aussi de correspondance entre une préférence et un ensemble de capacités. Cela se fait en représentant les deux par un ensemble de caractéristiques. Une préférence est un ensemble de caractéristiques – c’est une spécification d’un certain nombre de collections de caractéristiques, dont chacune satisferait aux exigences de l’envoyeur. Une capacité est aussi un ensemble de caractéristiques – c’est une spécification des collections de caractéristiques que le receveur accepte. Il y a correspondance lorsque les espaces définis par les deux ensembles de caractéristiques se chevauchent. Lorsque il y a chevauchement, il existe au moins une collection de caractéristiques qui existe dans les deux ensembles de caractéristiques, et donc une modalité ou rendu désiré par l’envoyeur qui est pris en charge par le receveur.


Cela nous mène directement à la définition d’une correspondance. Deux ensembles de caractéristiques se correspondent si il existe au moins une collection de caractéristiques présente dans les deux ensembles de caractéristiques.


Calculer une correspondance pour deux prédicats généraux d’ensembles de caractéristiques n’est pas facile. La Section 5 de la RFC 2533 présente un algorithme pour le faire en développant une expression arbitraire en une forme disjonctive normale. Cependant, les prédicats d’ensembles de caractéristiques utilisés par la présente spécification sont soumis à des contraintes. Ils sont toujours en forme conjonctive normale, chaque terme de la conjonction décrivant les valeurs pour les différentes caractéristiques du support. Cela rend facile le calcul d’une correspondance. Elle est calculée indépendamment pour chaque caractéristique du support, et ensuite les ensembles de caractéristiques se chevauchent si les caractéristiques du support spécifiées dans les deux ensembles se recouvrent. Calculer le chevauchement d’une seule caractéristique du support est très direct, et se réduit à calculer si deux ensemble finis se recoupent.


Adresse des auteurs


Jonathan Rosenberg

Henning Schulzrinne

Paul Kyzivat

dynamicsoft

Columbia University

Cisco Systems

600 Lanidex Plaza

M/S 0401

1414 Massachusetts Avenue

Parsippany, NJ 07054

1214 Amsterdam Ave.

BXB500 C2-2

USA

New York, NY 10027

Boxboro, MA 01719

téléphone : +1 973 952-5000

USA

USA

mél : jdrosen@dynamicsoft.com

mél : schulzrinne@cs.columbia.edu

mél : pkyzivat@cisco.com

URI: http://www.jdrosen.net

URI: http://www.cs.columbia.edu/~hgs



Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2004)


Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et 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 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, l’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 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 assuré par la Internet Society.


page - 20 -