Groupe de travail Réseau	S. Futemma, Sony
Request for Comments : 5372	E. Itakura, Sony
Catégorie : Sur la voie de la normalisation	A. Leung, Sony
Traduction Claude Brière de L'Isle	octobre 2008

Format de charge utile pour vidéo JPEG 2000  : extensions pour mise à l'échelle et récupération d’en-tête principal

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
Le présent mémoire décrit des extensions d’usage de l’en-tête de charge utile dans le "format de charge utile RTP pour les flux de vidéo JPEG 2000" comme spécifié dans la RFC 5371, pour une meilleure prise en charge des caractéristiques de JPEG 2000 comme l’adaptabilité et la récupération d’en-tête principal.

Le présent mémoire doit être accompagné d’une mise en œuvre complète du "format de charge utile RTP pour les flux de vidéo JPEG 2000". Ce document est une description complète de l’en-tête de charge utile et de la signalisation  ; le présent document décrit seulement le traitement supplémentaire de l’en-tête de charge utile. Il y a un type de support supplémentaire et un marqueur de signalisation du protocole de description de session (SDP, Session Description Protocol) pour les mises en œuvre de ce document.
Table des matières
1. Introduction	2
1.1 Description des mécanismes	2
1.2 Motivations du codage de champ de priorité	2
1.3 Conventions utilisées dans ce document	3
2. Traitement amélioré du format de charge utile	3
2.1 Marqueurs de traitement amélioré	3
3. Tableau de transposition de priorité	4
3.1 Ordre fondé sur le numéro de paquet	4
3.2 Ordre fondé sur la progression	4
3.3 Ordre fondé sur la couche	5
3.4 Ordre fondé sur la résolution	6
3.5 Ordre fondé sur le composant	6
4. Schéma de compensation d’en-tête principal JPEG 2000	6
4.1 Traitement par l’envoyeur	7
4.2 Traitement par le receveur	7
5. Enregistrement du type de support	7
6. Paramètres SDP	8
6.1 Transposition des paramètres facultatifs en SDP	8
6.2 Utilisation avec le modèle SDP d’offre/réponse	8
7. Considérations relatives à l’IANA	10
8. Considérations sur la sécurité	10
9. Contrôle d’encombrement	10
10. Références normatives	10
Appendice A. Exemples détaillés d’en-têtes	10
A.1 Échantillon 1 : Image progressive avec un seul pavé, 3500 octets (c'est-à-dire, concis)	11
A.2 Échantillon 2 : Image avec 4 pavés	12
A.3 Échantillon 3 : empaquetage de plusieurs pavés dans une seule charge utile, en-tête fragmenté. pas de compensation d’en-tête, image progressive	13
A.4 Échantillon 4  : Image entrelacée, un seul pavé	14
Adresse des auteurs	16
Déclaration complète de droits de reproduction	16
 	1.	Introduction

Ce document est une extension du "format de charge utile RTP pour les flux vidéo JPEG 2000" [RFC5371]. Ce sont des mécanismes supplémentaires qui peuvent être utilisés avec certaines parties de l'en-tête de la [RFC5371] pour prendre en charge des caractéristiques de JPEG 2000 telles que l’adaptabilité et une méthode de compensation de l’en-tête principal. Ces mécanismes sont décrits en détail dans le document.

Ces extensions à la [RFC5371] sont facultatives  ; on peut les utiliser pour faire un meilleur usage des caractéristiques de JPEG 2000. Ces extensions ne sont pas exigées pour une mise en œuvre de la [RFC5371].

 	1.1	Description des mécanismes
 	1.1.1	Compensation d’en-tête principal
L’en-tête d’image JPEG 2000 contient des informations de décodage essentielles pour le décodeur. Si un décodeur JPEG 2000 reçoit des données d’image JPEG 2000 sans en-tête d’image JPEG 2000, il ne pourra pas décoder correctement les données d’image JPEG 2000. Les codeurs de vidéo JPEG 2000 changent très rarement les paramètres de codage entre les trames successives. Donc, la possibilité que le décodeur décode successivement les nouvelles données d’image JPEG 2000 en utilisant un en-tête d’image JPEG 2000 antérieur est très forte dans cette situation.

Le schéma de compensation d’en-tête principal utilisé dans ce document exploite le fait que les images successives de vidéo JPEG 2000 changent rarement les paramètres de codage. Cela exige que les receveurs sauvegardent les en-têtes d’image JPEG 2000 passées pour les utiliser en cas d’en-têtes d’image JPEG 2000 manquantes à l’avenir. La signalisation de changements de l’en-tête d’image JPEG 2000 est faite par l’en-tête de charge utile. Quand la valeur de mh_id de l’en-tête de charge utile change, les receveurs devraient sauvegarder le nouvel en-tête JPEG 2000 pour l’utiliser pour une récupération d’en-tête principal.

 	1.1.2	Tableau de priorité
Les flux de codes JPEG 2000 ont de riches fonctionnalités incorporées de sorte que les décodeurs peuvent facilement traiter la livraison adaptable ou la transmission progressive. La transmission progressive permet que les images soient reconstruites avec une précision de pixel ou une résolution spatiale accrues. Cette caractéristique permet la reconstruction des images avec différentes résolutions et précisions de pixels, pour différents appareils cibles. Une seule source d’image peut fournir un flux de codes qui est facilement traité pour de plus petits appareils d’affichage d’image.

Les paquets JPEG 2000 contiennent toutes les données d’image compressées provenant d’une couche, composant, niveau de résolution, et/ou district spécifique. L’ordre dans lequel ces paquets JPEG 2000 se trouvent dans le flux de codes est appelé l’ordre de progression. L’ordre des paquets JPEG 2000 peut progresser le long de quatre axes : couche, composant, résolution, et district (ou position).

Fournir un champ de priorité pour indiquer l’importance des données contenues dans un paquet RTP donné peut aider à utiliser les fonctions de progression et d’adaptabilité de JPEG 2000.

 	1.2	Motivations du codage de champ de priorité
Le schéma de codage JPEG 2000 permet de réordonner le flux de codes de nombreuses façons. Même quand le schéma de codage est déterminé et arrangé par le codeur, un décodeur peut quand même réarranger le flux de codes en vol pour s’adapter aux paramètres de décodage comme de réarranger de la résolution progressive à la qualité progressive.

En utilisant le codage de champ de priorité, le décodeur obtient des informations sur le flux de codes sans accéder au flux de codes complet et expose les caractéristiques de JPEG 2000 à un niveau supérieur.

Les auteurs ont trouvé les scénarios qui suivent pour utiliser ce champ. Le champ de priorité permet que plus d’informations sur l’image soient envoyées sans ajouter de signalisation entre l’envoyeur et les receveurs pour développer les capacités de JPEG 2000.

 	1.2.1	Scénario de juste assez de résolution
Ce scénario est quand l’accès rapide à la scène est plus important qu’une meilleure qualité d’image. En utilisant le champ de priorité, le receveur peut décoder pour son propre niveau de qualité. Si l'envoyeur ne peut pas déterminer la résolution du receveur, celui-ci peut choisir quelles parties du flux de codes sont à décoder ou charger en utilisant le champ de priorité.

 	1.2.2	Scénario de clients multiples et une seule source
Dans un environnement de diffusion groupée, il y a des clients avec une meilleure capacité visuelle que d’autres (c'est-à-dire, conférence TV contre mobile). Les clients respectifs peuvent utiliser le champ de priorité pour déterminer quels paquets sont vitaux pour leur propre présentation visuelle. L’envoyeur a seulement à travailler sur le champ de priorité pour  servir de façon optimale tous les clients tout en gérant seulement un flux visuel.

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

 	2.	Traitement amélioré du format de charge utile
 	2.1	Marqueurs de traitement amélioré
Cette section du document décrit les usage supplémentaires des valeurs des champs mh_id et priorité et l’interprétation qui diffère de la [RFC5371]. Les mises en œuvre de ce document devraient suivre d’abord la [RFC5371] puis ajouter le traitement d’en-tête supplémentaire comme décrit dans le présent document. Les mises en œuvre qui suivent le présent document sont supposées interopérer avec les mises en œuvre de [RFC5371] et du présent document.

Le format d’en-tête de charge utile RTP pour le flux vidéo JPEG 2000 est le suivant :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T|     Priorité  |        Numéro de pavé         |
+---+---+-----+-+---------------+---------------+---------------+
|  Réservé      |        Décalage de fragment                   |
+---------------+---------------+---------------+---------------+

Figure 1 : Format  d’en-tête de charge utile RTP pour JPEG 2000

mh_id (Identifiant d’en-tête principal) : 3 bits.Valeur de l’identifiant d’en-tête principal. C’est utilisé pour la récupération d’en-tête principal JPEG 2000. La valeur initiale de mh_id DOIT être 1 au début de la session. La même valeur de mh_id est utilisée tant que les paramètres de codage décrits dans l’en-tête principal restent inchangés entre les trames. La valeur de mh_id DOIT être incrémentée de 1 chaque fois qu’un nouvel en-tête principal est transmis. Une fois que la valeur de mh_id devient supérieure à 7, elle DEVRAIT revenir à 1. Quand mh_id est 0, il a une utilisation particulière pour le receveur. Cette utilisation particulière est décrite au paragraphe 4.2 de ce document. Les envoyeurs devraient suivre le paragraphe 4.1 de ce document pour la bonne allocation et le bon usage du mh_id.

Priorité : 8 bits. Le champ de priorité indique l’importance du paquet JPEG 2000 inclus dans la charge utile. Normalement, une valeur de priorité supérieure est établie dans les paquets contenant les sous bandes JPEG 2000 inférieures.

Valeurs de priorité particulières :
0 : est réservé pour les charges utiles qui contiennent un en-tête (principal ou en-tête de partie de pavé). Elles sont considérées comme les plus importantes.
1 à 255 : l’importance de ces valeurs diminue comme les valeurs croissent (c'est-à-dire, 1 est plus important que 2, etc.).  L’application des valeurs de priorité devrait être corrélée directement à l’importance du flux de codes JPEG 2000.

Plus faible est la valeur de priorité, plus l’importance est grande. Une valeur de priorité de 0 de la plus haute importance et 255 est la moindre importance. On définit la valeur de priorité 0 comme une valeur de priorité spéciale pour les en-têtes (en-tête principal ou en-tête de partie de pavé). Si des en-têtes (en-tête principal ou en-tête de partie de pavé) sont mis en paquet dans la charge utile RTP, l'envoyeur DOIT régler la valeur de priorité à 0.

L’allocation des valeurs est décrite à la Section 3.

 	3.	Tableau de transposition de priorité

Pour l’ordre de progression, la valeur de priorité pour chaque paquet JPEG 2000 est donnée par le tableau de transposition de priorité.

Le présent document spécifie plusieurs tableaux de transposition de priorité couramment utilisés, des tableaux de transposition de priorité pré-définis : fondés sur le numéro de paquet (par défaut), fondés dur la progression, fondés sur la couche, fondés sur la résolution, et fondés sur le composant.

La prise en charge de la transposition de priorité de numéro de paquet est EXIGÉE pour les clients qui mettent en œuvre la présente spécification. Les autres tableaux de transposition de priorité (fondés sur la progression, la couche, la résolution, et le composant) sont FACULTATIFS pour les mises en œuvre de cette spécification.

Les règles que toutes les mises en œuvre de cette spécification DOIVENT suivre dans tous les modes de priorité sont :

o	Quand il y a un en-tête dans le paquet avec un paquet JPEG 2000, l'envoyeur DOIT régler la valeur du paquet de charge utile de priorité à 0.

o	Quand il y a plusieurs paquets JPEG 2000 dans le même paquet de charge utile RTP, l'envoyeur DOIT régler la valeur de priorité du paquet de charge utile au plus bas paquet JPEG 2000 (c'est-à-dire, si des paquets JPEG 2000 avec une priorité de 5, 6, 7 sont empaquetés dans une seule charge utile, la valeur de priorité va être 5).

 	3.1	Ordre fondé sur le numéro de paquet
L’ordre fondé sur le numéro de paquet alloue la valeur de priorité de paquet de charge utile à partir de la "valeur de paquet JPEG 2000" (note : les flux de codes JPEG 2000 sont mémorisé dans des unités de paquets et chaque paquet a une valeur).  Cette méthode est la méthode par défaut pour allouer la valeur de priorité. Toutes les mises en œuvre de cette spécification DOIVENT prendre en charge cette méthode.

Si la valeur de paquet de flux de codes JPEG 2000 est supérieure à 255, l'envoyeur DOIT  régler la valeur de priorité de charge utile à 255.

 	3.2	Ordre fondé sur la progression
L’envoyeur va allouer la valeur de priorité de paquet de charge utile fondée seulement sur l’ordre de couche, de résolution, et de composant du flux de codes.

L’ordre fondé sur la progression peut allouer les différentes valeurs de priorité dans la même couche ou niveau de résolution, ce qu’il ne peut pas faire dans l’ordre fondé sur la couche or l’ordre fondé sur la résolution.

À la différence de l’ordre fondé sur le numéro de paquet, l’ordre fondé sur la progression n’alloue pas de valeur dans le niveau de position, ce qui économise les valeurs de priorité. La valeur de priorité dans le niveau de position n’est pas si important parce qu’un receveur pourrait reconnaître la position en vérifiant le champ Numéro de pavé. Donc, l’ordre fondé sur la progression serait utile.

L’algorithme général est que l’ordre se fonde sur le triplet <couche, résolution, composant> et la priorité minimum est 1. Donc, si le flux de codes est construit de L couches (les valeurs de couche vont de 0 à L-1) R résolutions (les valeurs de résolution vont de 0 à R-1) et C composants (les valeurs de composants vont de 0 à C-1) alors pour un triplet <lval, rval, cval>, la valeur de priorité du flux de codes dans l’ordre LRCP est calculée par :

priorité = 1 + cval + (C * rval) + (C * R * lval)

La valeur de priorité du flux de codes dans l’ordre RLCP est calculée par :

priorité = 1 + cval + (C * lval) + (C * L * rval)

La valeur de priorité du flux de codes en ordre RPCL est calculée par :

priorité = 1 + lval + (L * cval) + (L * C * rval)

La valeur de priorité d’un flux de codes en ordre PCRL est calculée par :

priorité = 1 + lval + (L * rval) + (L * R * cval)

La valeur de priorité d’un flux de codes en ordre CPRL est calculée par :

priorité = 1 + lval + (L * rval) + (L * R * cval)

Par exemple :

Si le flux de codes est ordonné en LRCP (couche, résolution, composant, position) avec 1 couche (L=1), 2 résolutions (R=2), 3 composants (C=3), et 2 positions, la valeur de priorité devrait être (1 + cval + 3*rval + 6*lval). Un exemple aurait alors le numérotage de paquets suivant :

Tous les paquets dans :
couche.........0
résolution....0
composant.....0
position......0 ou 1
alors la valeur de priorité de paquet : 1

Tous les paquets dans :
couche........0
résolution....0
composant.....1
position......0 ou 1
alors la valeur de priorité de paquet : 2

Tous les paquets dans :
couche.........0
resolution....0
composant.....2
position......0 ou 1
alors la valeur de priorité de paquet : 3

Tous les paquets dans :
couche.........0
resolution....1
composant.....0
position......0 ou 1
alors la valeur de priorité de paquet : 4

Tous les paquets dans :
couche.........0
resolution....1
composant.....1
position......0 ou 1
alors la valeur de priorité de paquet : 5

 	3.3	Ordre fondé sur la couche
Le tableau de transposition de priorité fondé sur la couche simplifie la transposition par défaut à juste confronter les paquets JPEG 2000 provenant de la même couche.

Par exemple :

Tous les paquets dans la couche 0 : valeur de priorité de paquet : 1
Tous les paquets dans la couche 1 : valeur de priorité de paquet : 2
Tous les paquets dans la couche 2 : valeur de priorité de paquet : 3
      ...
Tous les paquets dans la couche n : valeur de priorité de paquet : n+1
Tous les paquets dans la couche 255 : valeur de priorité de paquet : 255

 	3.4	Ordre fondé sur la résolution
Le tableau de transposition de priorité fondé sur la résolution est similaire à l’ordre fondé sur la couche mais pour les paquets JPEG 2000 de même résolution.

Par exemple :

Tous les paquets dans la résolution 0 : valeur de priorité de paquet : 1
Tous les paquets dans la résolution 1 : valeur de priorité de paquet : 2
Tous les paquets dans la résolution 2 : valeur de priorité de paquet : 3
      ...
Tous les paquets dans la résolution n : valeur de priorité de paquet : n+1
Tous les paquets dans la résolution 255 : valeur de priorité de paquet : 255

 	3.5	Ordre fondé sur le composant
Le tableau de transposition de priorité fondé sur le composant est de transposer ensemble les composants JPEG 2000 du même composant.

Par exemple :

Tous les paquets dans le composant 0 : valeur de priorité de paquet : 1
Tous les paquets dans le composant 1 : valeur de priorité de paquet : 2
Tous les paquets dans le composant 2 : valeur de priorité de paquet : 3
      ...
Tous les paquets dans le composant n : valeur de priorité de paquet : n+1
Tous les paquets dans le composant 255 : valeur de priorité de paquet : 255

 	4.	Schéma de compensation d’en-tête principal JPEG 2000

Le champ mh_id de l’en-tête de charge utile est utilisé pour indiquer si les paramètres de codage de l’en-tête principal sont les mêmes que les paramètres de codage de la trame précédente. La même valeur est réglée dans le mh_id du paquet RTP dans la même trame. Le mh_id et les paramètres de codage ne sont pas associés les uns les autres 1:1, mais ils sont utilisés pour indiquer si les paramètres de codage de la trame précédente sont ou non les mêmes en cas de perte d’un en-tête.

La valeur du champ mh_id DEVRAIT être sauvegardée des trames précédentes pour être utilisée à récupérer l’en-tête principal de la trame en cours. Si le mh_id de la trame en cours a la même valeur que celle du mh_id de la trame précédente, l’en-tête principal de la trame précédente PEUT être utilisé pour décoder la trame en cours, en cas de perte de l’en-tête de la trame en cours.

L’envoyeur DOIT incrémenter mh_id quand des paramètres de l'en-tête changent et envoyer un nouvel en-tête principal en conséquence.

Le receveur PEUT utiliser le mh_id et PEUT conserver l'en-tête pour une telle compensation.

 	4.1	Traitement par l’envoyeur
L’envoyeur DOIT transmettre les paquets RTP avec la même valeur de mh_id si les paramètres du codeur de la trame en cours sont les mêmes que ceux de la trame précédente. Les paramètres de codage sont le segment de marqueur des informations fixes (marqueur SIZ) et des segments de marqueurs fonctionnels (COD, COC, RGN, QCD, QCC, et POC) spécifié dans JPEG 2000 Partie 1, Annexe A [T.800.1].

Si les paramètres de codage changent, l'envoyeur qui transmet les paquets RTP DOIT incrémenter la valeur de mh_id de un, mais quand la valeur de mh_id devient supérieure à 7, un envoyeur DOIT ramener la valeur de mh_id à 1.

 	4.2	Traitement par le receveur
Quand le receveur reçoit complètement l’en-tête principal, le numéro de séquence RTP, le mh_id, et l’en-tête principal devraient être sauvegardés. Seul le dernier en-tête principal reçu complètement DEVRAIT être sauvegardé. Quand la valeur de mh_id est 0, le receveur NE DEVRAIT PAS sauvegarder l'en-tête.

Quand l’en-tête principal n’est pas reçu, le receveur peut comparer la valeur du mh_id de l’en-tête de charge utile en cours à la précédente valeur de mh_id sauvegardée. Si les valeurs correspondent, le décodage peut être effectué en utilisant l’en-tête principal précédemment sauvegardé.

Si le champ mh_id est réglé à 0, le receveur NE DOIT PAS sauvegarder l’en-tête principal et NE DOIT PAS compenser les en-têtes perdus.

Si la valeur de mh_id change, les receveurs DEVRAIENT sauvegarder l’en-tête en cours et la nouvelle valeur de mh_id. L’ancien en-tête sauvegardé devrait être supprimé de la mémorisation.

Aussi, si le décodeur détecte une incohérence entre l'en-tête et la charge utile, il est recommandé de supprimer le mh_id et l’en-tête principal sauvegardés. Voir plus d’explications à la Section 8.

 	5.	Enregistrement du type de support

Le présent document étend le type de support associé "video/jpeg2000" de la [RFC5371]. Voici les paramètres facultatifs supplémentaires  :

mhc (Main Header Compensation)  : compensation d’en-tête principal. Cette option est utilisée quand un envoyeur et/ou receveur utilise la technique de compensation d’en-tête principal comme spécifié dans le présent document. La valeur acceptable quand on utilise la technique de compensation d’en-tête principal est "1" ; autrement, ce devrait être "0".

Voici une liste d’options à inclure quand l'envoyeur ou receveur utilise l’option de tableau de priorité comme spécifié dans le présent document.

pt (Priority Table)  : tableau de priorité. Cette option est suivie par une liste séparée de virgules des définitions de tableau de priorité pré-définies à utiliser par l’envoyeur ou le receveur.

L’option qui apparaît en premier sur la ligne d’options est la plus importante et les suivantes sont d’importance décroissante.

Valeurs acceptables :
progression : ce tableau suit l’ordre de progression du flux de codes.
couche : ce tableau suit l’ordre de couches du flux de codes.
résolution : ce tableau suit l’ordre de résolution du flux de codes.
composant : ce tableau suit l’ordre de composant du flux de codes.
défaut : ce tableau suit l’ordre de paquets du flux de codes.

 	6.	Paramètres SDP
 	6.1	Transposition des paramètres facultatifs en SDP
Les nouveaux paramètres facultatifs mhc et pt, si ils sont présents, DOIVENT être inclus dans la ligne "a=fmtp" de SDP. Ces paramètres sont exprimés par une chaîne de type support, sous la forme d’une liste de paires paramètre=valeur séparées par des points-virgules.

 	6.2	Utilisation avec le modèle SDP d’offre/réponse
En plus de la section d’offre/réponse SDP de la [RFC5371] :

Quand on offre JPEG 2000 sur RTP en utilisant SDP dans un modèle d’offre/réponse [RFC3264], les règles et limitations suivantes s’appliquent :

o	Tous les paramètres DOIVENT avoir une valeur acceptable pour ce paramètre.

o	Tous les paramètres DOIVENT correspondre aux paramètres de la charge utile.

o	Si le paramètre facultatif "mhc" est utilisé, il DOIT apparaître dans l'offre avec la valeur "1", et si il est accepté, il DEVRAIT apparaître dans la réponse.

o	Si le paramètre facultatif "pt" est utilisé, il DOIT apparaître dans l'offre en contenant une liste complète séparée de virgules indiquant quelles définitions de tableaux de priorité l'envoyeur prend en charge. Si il est accepté, il DEVRAIT apparaître dans la réponse en contenant une seule définition de tableau de priorité choisie dans l’offre.

o	Si le paramètre facultatif "mhc" est utilisé, il DOIT apparaître dans l'offre avec la valeur "1", et si il est accepté, il DOIT  apparaître dans la réponse. Si le paramètre facultatif "pt" est utilisé, il DOIT apparaître dans l'offre en contenant une liste complète séparée de virgules indiquant quelles définitions de tableau de priorité l'envoyeur prend en charge. Si il est accepté, il DOIT apparaître dans la réponse en contenant une seule définition de tableau de priorité choisie dans l’offre.

o	Dans un environnement de diffusion groupée :
*	Les envoyeurs devraient envoyer une option pour une définition de tableau de priorité pour chacun dans le groupe.
*	Même si un seul client dans le groupe ne prend pas en charge les extensions mentionnées dans ce document, les envoyeurs PEUVENT utiliser ces mécanismes. Un receveur qui ne prend pas en charge les mécanismes pourra en toute sécurité ignorer les valeurs de mh_id et de champ de priorité.

 	6.2.1	Exemples
Voici des exemples d’échange d’offre/réponse  :

 	6.2.1.1	Exemple 1
Alice offre la fonction de compensation d’en-tête principal, l’espace de couleurs YCbCr 422, l’entrelacement d’image avec une largeur de 720 pixels et une hauteur de 480 pixels, et plusieurs options de tableau de priorité (défaut, progression, couche, résolution, composant) :

v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2; interlace=1;
pt=default,progression,layer,resolution, composant;
width=720;height=480

Bob accepte la fonction de compensation d’en-tête principal, l’espace de couleurs YCbCr 422, l’entrelacement d’image, le tableau de transposition par défaut, et répond :

v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2;interlace=1;
pt=default;width=720;height=480

 	6.2.1.2	Exemple 2
Alice offre la compensation d’en-tête principal, l’espace de couleurs YCbCr 420, l’image progressive avec une largeur de 320 pixels et une hauteur de 240 pixels, et les options de tableau de priorité suivantes :

v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240

Bob n'accepte pas la fonction de compensation d’en-tête principal mais accepte l’espace de couleurs YCbCr-4:2:0, la transposition de priorité fondée sur la couche, et répond :

v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240

 	6.2.1.3	Exemple 3
Alice offre un horodatage à 27 MHz, la compensation d’en-tête principal, l’espace de couleurs YCbCr 420, l’image progressive avec une largeur de 320 pixels et une hauteur de 240 pixels, et les options de tableau de priorité fondé sur la couche :

v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98 99
a=rtpmap:98 jpeg2000/27000000
a=rtpmap:99 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
a=fmtp:99 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240

Bob peut accepter le type de charge utile avec horodatage à 27 MHz, et n'accepte pas la fonction de compensation d’en-tête principal mais accepte l’espace de couleurs YCbCr-4:2:0, la transposition de priorité fondée sur la couche et répond :

v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/27000000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240

 	7.	Considérations relatives à l’IANA

Ce document étend le type de support associé "video/jpeg2000" de la [RFC5371]. Les paramètres supplémentaires sont spécifiés à la Section 5 de ce document.

 	8.	Considérations sur la sécurité

Voir la Section 6 de la [RFC5371] pour les considérations sur la sécurité concernant ce format RTP. Les questions de sécurité qui concernent les mécanismes d’amélioration présentés dans ce document sont discutées ici.

Le champ mh_id peut identifier un maximum de 7 différents en-têtes principaux. Si une perte de paquets sévère (aléatoire ou introduite intentionnellement par un attaquant) cause la perte de six mises à jour successives de l’en-tête principal, le décodeur va tenter la décompression en utilisant un en-tête principal incorrect. Même si l’en-tête principal incorrect est passé, le décodeur standard JPEG 2000 pourrait détecter l’incohérence du flux de codes et le traiter de façon appropriée. Il est recommandé de supprimer le mh_id et l’en-tête principal sauvegardés si le décodeur détecte une telle incohérence.

 	9.	Contrôle d’encombrement

Se reporter à la Section 7 de la [RFC5371] pour le contrôle d’encombrement concernant ce format RTP.

 	10.	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par RFC8843, 9143)

[RFC5371]	S. Futemma et autres, "Format de charge utile RTP pour flux vidéo JPEG 2000", octobre 2008. (P.S.)

[T.800.1]	Recommandation UIT-T T.800, "Technologie de l’information - Système de codage d’image JPEG 2000 – Partie 1 : Cœur du système de codage", aussi ISO/CEI 15444-1. http://www.itu.int/rec/T-REC-T.800.1  ; décembre 2000.

 	Appendice A.	Exemples détaillés d’en-têtes

Les figures suivantes sont des échantillons d’en-têtes RTP qui montrent les valeurs qui devraient apparaître dans l’en-tête RTP. La priorité de paquet est celle fondée sur le numéro de paquet.

Pour référence, l’en-tête de charge utile est :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T|     Priorité  |         Numéro de pavé        |
+---+---+-----+-+---------------+---------------+---------------+
|  Réservé      |         Décalage de fragment                  |
+---------------+---------------+---------------+---------------+

Figure 2 : En-tête de charge utile JPEG 2000

 	A.1	Échantillon 1 : Image progressive avec un seul pavé, 3500 octets (c'est-à-dire, concis)
Premier paquet : ce paquet va avoir tout l’en-tête principal, 210 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 |  1  |1|       0       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 0000                   ....                     |
+---------------+---------------+---------------+---------------+

Figure 3 : Échantillon d'en-tête 1-1 (premier paquet)

Second paquet : ce paquet va avoir un en-tête de pavé et la première partie de pavé LLband, 1500 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  1  |0|       1       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      210                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 2DB3  0001 FF93   ....                     |
+---------------+---------------+---------------+---------------+

Figure 4 : Échantillon d'en-tête 1-2 (second paquet)

Troisième paquet : ce paquet va avoir la prochaine partie du pavé, pas d’en-tête de pavé, 1500 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  1  |0|       2       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1710                      |
+---------------+---------------+---------------+---------------+
|E841 4526 4556 9850 C2EA              ....                     |
+---------------+---------------+---------------+---------------+

Figure 5 : Échantillon d'en-tête 1-3 (troisième paquet)

Quatrième paquet : dernier paquet pour l’image, 290 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  1  |0|       3       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3210                      |
+---------------+---------------+---------------+---------------+
|A55D 8B73 3B25 25C7 B9EB ....                         2FBE B153|
+---------------+---------------+---------------+---------------+

Figure 6 : Échantillon d'en-tête 1-4 (quatrième paquet)

 	A.2	Échantillon 2 : Image avec 4 pavés
Premier paquet : ce paquet va avoir tout l’en-tête principal, 210 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 |  1  |1|       0       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 0000                   ....                     |
+---------------+---------------+---------------+---------------+

Figure 7 : Échantillon d'en-tête 2-1 (premier paquet)

Second paquet : ce paquet va avoir une première partie de pavé (pavé 0) 1400 octets.
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  1  |0|       1       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      210                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 0578  0001 FF93   ....                     |
+---------------+---------------+---------------+---------------+

Figure 8 : Échantillon d'en-tête 2-2 (second paquet)

Troisième paquet : ce paquet va avoir une seconde partie de pavé (pavé 1) 1423 octets.
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  1  |0|       1       |               1               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1610                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0001 0000 058F 0001 FF93    ....                     |
+---------------+---------------+---------------+---------------+

Figure 9 : Échantillon d'en-tête 2-3 (troisième paquet)

Quatrième paquet : ce paquet va avoir une troisième partie de pavé (pavé 2) 1355 octets.
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  1  |0|       1       |               2               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3033                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0002 0000 054B 0001 FF93    ....                     |
+---------------+---------------+---------------+---------------+

Figure 10 : Échantillon d'en-tête 2-4 (4ième paquet)

Cinquième paquet : ce paquet va avoir une quatrième partie de pavé (pavé 3) 1290 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  1  |0|       1       |               3               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     4388                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0003 0000 050A 0001 FF93    ....                     |
+---------------+---------------+---------------+---------------+

Figure 11 : Échantillon d'en-tête 2-5 (5ième paquet)

 	A.3	Échantillon 3 : empaquetage de plusieurs pavés dans une seule charge utile, en-tête fragmenté. pas de compensation d’en-tête, image progressive
Premier paquet : ce paquet va avoir la première partie de l’en-tête principal, 110 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1 |  0  |1|       0       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 0000 ....                                       |
+---------------+---------------+---------------+---------------+

Figure 12 : Échantillon d'en-tête 3-1 (premier paquet)

Second paquet : ce paquet a la seconde partie de l’en-tête principal, 1400 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 |  0  |1|       0       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      110                      |
+---------------+---------------+---------------+---------------+
|FF64 00FF ....                                                 |
+---------------+---------------+---------------+---------------+

Figure 13 : Échantillon d'en-tête 3-2 (second paquet)

Troisième paquet : ce paquet a deux pavés, le pavé 0 et le pavé 1, 1400 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |1|       1       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1510                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 02BC 0001 FF93 ...                         |
//                                    .                        //
|FF90 000A 0001 0000 02BC 0001 FF93 ...                         |
+---------------+---------------+---------------+---------------+

Figure 14 : Échantillon d'en-tête 3-3 (troisième paquet)

Quatrième paquet : ce paquet a un pavé, le pavé 2, 1395 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |  0  |0|       1       |               2               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     2910                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0002 0000 0573 0001 FF93    ....                     |
+---------------+---------------+---------------+---------------+

Figure 15 : Échantillon d'en-tête 3-4 (4ième paquet)

 	A.4	Échantillon 4  : Image entrelacée, un seul pavé
Le flux de codes de chaque image est ordonné en LRCP (Layer (couche), résolution, composant, position) avec une couche, 3 résolutions, 3 composants et 1 position.

Premier paquet : ce paquet va avoir tout l’en-tête principal pour le champ impair, 210 octets.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 3 |  1  |1|       0       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 0000 ....                                       |
+---------------+---------------+---------------+---------------+

Figure 16 : Échantillon d'en-tête 4-1 (premier paquet)

Second paquet : ce paquet va avoir la première partie du pavé du champ impair où trois paquets jp2 sont inclus, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |  1  |1|       1       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                      210                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 0578  0001 FF93  ....                      |
+---------------+---------------+---------------+---------------+

Figure 17 : Échantillon d'en-tête 4-2 (Second paquet)

Troisième paquet : ce paquet va avoir la seconde partie du pavé du champ impair, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |  1  |1|       4       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1610                      |
+---------------+---------------+---------------+---------------+
|7F04 E708 27D9 D11D 22CB ...                                   |
+---------------+---------------+---------------+---------------+

Figure 18 : Échantillon d'en-tête 4-3 (troisième paquet)

Quatrième paquet : ce paquet va avoir la troisième partie du pavé du champ impair, 1300 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |  1  |1|       7       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3010                      |
+---------------+---------------+---------------+---------------+
|98BD EC9B 2826 DC62 D4AB ...                                   |
+---------------+---------------+---------------+---------------+

Figure 19 : Échantillon d'en-tête 4-4 (4ième paquet)

Cinquième paquet : ce paquet va avoir tout l’en-tête principal pour le champ pair, 210 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 3 |  1  |1|       0       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                       0                       |
+---------------+---------------+---------------+---------------+
|FF4F FF51 002F 0000 ....                                       |
+---------------+---------------+---------------+---------------+

Figure 20 : Échantillon d'en-tête 4-5 (5ième paquet)

Sixième paquet : ce paquet va avoir la première partie du pavé du champ pair, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |  1  |1|       1       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     1610                      |
+---------------+---------------+---------------+---------------+
|FF90 000A 0000 0000 0578  0001 FF93  ....                      |
+---------------+---------------+---------------+---------------+

Figure 21 : Échantillon d'en-tête 4-6 (6ième paquet)

Septième paquet : ce paquet va avoir la seconde partie du pavé du champ pair, 1400 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |  1  |1|       4       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     3010                      |
+---------------+---------------+---------------+---------------+
|626C 42F0 166B 6BD0 F8E1 ...                                   |
+---------------+---------------+---------------+---------------+

Figure 22 : Échantillon d'en-tête 4-7 (7ième paquet)

Huitième paquet : ce paquet va avoir la troisième partie du pavé de champ pair, 1300 octets

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 |  1  |1|       7       |               0               |
+---+---+-----+-+---------------+---------------+---------------+
|       0       |                     4410                      |
+---------------+---------------+---------------+---------------+
|8114 41D5 18AB 4A1B ...                                        |
+---------------+---------------+---------------+---------------+

Figure 23 : Échantillon d'en-tête 4-8 (8ième paquet)

 	Adresse des auteurs

Satoshi Futemma	Eisaburo Itakura	Andrew Leung	
Sony Corporation	Sony Corporation	Sony Corporation	
mél : satosi-f@sm.sony.co.jp	mél : itakura@sm.sony.co.jp	mél : andrew@ualberta.net	

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

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

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.