Spécifications du type de support et procédures d'enregistrement

Transcription

1 RFC 4288 page Freed & Klensin Grupe de travail Réseau N. Freed, Sun Micrsystems Request fr Cmments : 4288 J. Klensin BCP n 13 décembre 2005 RFC rendue bslète : 2048 Catégrie : Bnnes pratiques actuelles Traductin Claude Brière de L'Isle Spécificatins du type de supprt et prcédures d'enregistrement Statut du présent mémire Le présent dcument spécifie les bnnes pratiques actuelles de l'internet pur la cmmunauté de l'internet, et appelle à des discussins et suggestins pur sn améliratin. La distributin du présent mémire n'est sumise à aucune restrictin. Ntice de cpyright Cpyright (C) The Internet Sciety (2005). Résumé Le présent dcument définit les prcédures pur la spécificatin et l'enregistrement des types de supprts à utiliser dans MIME et les autres prtcles de l'internet. Table des matières 1. Intrductin Cnventins utilisées dans le présent dcument Préliminaires de l'enregistrement de type de supprt Arbres d'enregistrement et nms de sus-type Arbrescence standard Arbre de fabricant Arbre persnnel u factice Arbre particulier x Arbres d'enregistrement supplémentaires Exigences pur l'enregistrement Exigences fnctinnelles Exigences de dénminatin Exigences de paramètres Exigences de cannisatin et de frmat Recmmandatins d'interpérabilité Exigences de sécurité Exigences spécifiques des types de supprts XML Exigences de cdage Nn exigences d'usage et de mise en œuvre Exigences de publicatin Infrmatins supplémentaires Prcédure d'enregistrement Révisin cmmunautaire préliminaire Apprbatin de l'iesg Enregistrement de l'iana Réviseurs de types de supprts Cmmentaires sur les enregistrements de types de supprts Lcalisatin de la liste des types de supprts enregistrés Prcédures de l'iana pur l'enregistrement des types de supprts Prcédures de mdificatin Gabarit d'enregistrement Cnsidératins pur la sécurité Cnsidératins relatives à l'iana Remerciements Références Références nrmatives Références pur infrmatin...13 Appendice A. Types de supprt anciens...13 Appendice B. Changements depuis la RFC

2 RFC 4288 page Freed & Klensin 1. Intrductin Les prtcles récents de l'internet nt été cnçus avec sin pur être facilement extensibles dans certain dmaines. En particulier, de nmbreux prtcles, y cmpris MIME [RFC2045], snt capables de prter des cntenus arbitraires étiquetés. Un mécanisme est nécessaire pur étiqueter un tel cntenu et un prcessus d'enregistrement est nécessaire pur ces étiquettes, pur s'assurer que l'ensemble de telles valeurs est dévelppé de façn rdnnée, bien spécifiée, et publique. Le présent dcument définit les prcédures de spécificatin et d'enregistrement des types de supprts qui utilisent l'autrité d'allcatin des numérs de l'internet (IANA, Internet Assigned Numbers Authrity) cmme registraire central. Nte histrique Le prcessus d'enregistrement du type de supprt a été initialement défini pur enregistrer les types de supprts à utiliser dans le cntexte de l'envirnnement de la messagerie Internet asynchrne. Dans cet envirnnement de messagerie, il est besin de limiter le nmbre de types de supprts pssibles, pur augmenter la prbabilité de l'interpérabilité lrsque les capacités du système de messagerie distant ne snt pas cnnues. Cmme les types de supprts snt utilisés dans de nuveaux envirnnements dans lesquels la prlifératin des types de supprts n'est pas un bstacle à l'interpérabilité, la prcédure d'rigine s'est révélée excessivement restrictive et devait être généralisée. Cela a été initialement fait dans la [RFC2048], mais la prcédure qui y est définie faisait partie de l'ensemble des dcuments MIME. La prcédure de spécificatin et d'enregistrement des types de supprt est maintenant placée dans ce dcument distinct, pur rendre clair qu'elle est indépendante de MIME. Il peut être suhaitable de restreindre l'utilisatin des types de supprts à des envirnnements spécifiques u d'interdire leur utilisatin dans d'autres envirnnements. La présente révisin essaye pur la première fis d'incrprer de telles restrictins des enregistrements de types de supprts dans un système. Vir au paragraphe 4.9 le dévelppement de cette questin. 1.1 Cnventins utilisées dans le présent dcument Les mts clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF"snt à interpréter cmme décrit dans la [RFC2119]. La présente spécificatin utilise la ntatin de frme Backus-Naur augmentée (ABNF) [RFC4234], y cmpris les règles centrales définies dans l'appendice A du présent dcument. 2. Préliminaires de l'enregistrement de type de supprt L'enregistrement d'un u de nuveaux types de supprts cmmence par la cnstructin d'une prpsitin d'enregistrement. L'enregistrement peut survenir au sein de plusieurs arbres d'enregistrement différents qui nt des exigences différentes, cmme n l'expliquera plus lin. En général, une nuvelle prpsitin d'enregistrement est diffusée et revue de la façn apprpriée à l'arbrescence impliquée. Le type de supprt est alrs enregistré si la prpsitin est acceptable. Les sectins qui suivent décrivent les exigences et prcédures utilisées pur chacun des différents arbres d'enregistrement. 3. Arbres d'enregistrement et nms de sus-type Afin d'augmenter l'efficacité et la suplesse du prcessus d'enregistrement, différentes structures de nms de sus-types peuvent être enregistrées pur s'accmmder des exigences naturelles différentes pur, par exemple, un sus-type qui va être recmmandé pur une large prise en charge et mise en œuvre par la cmmunauté de l'internet, u un sus-type qui est utilisé pur déplacer les fichiers assciés à des lgiciels prpriétaires. Les paragraphes suivants définissent des "arbres" d'enregistrement qui snt distingués par l'utilisatin de nms à facettes, par exemple, des nms de la frme "arbre.susarbre...sus-type". Nter que certains types de supprts définis avant le présent dcument ne se cnfrment pas aux cnventins de dénminatin décrites ci-dessus. Vir à l'appendice A pur des précisins. 3.1 Arbrescence standard L'arbrescence standard est destinée aux types d'intérêt général pur la cmmunauté de l'internet. Les enregistrements dans l'arbrescence standard DOIVENT être appruvés par l'iesg et DOIVENT crrespndre à une publicatin frmelle par un rganisme de nrmalisatin recnnu. Dans le cas d'enregistrement pur l'ietf elle-même, la prpsitin d'enregistrement

3 RFC 4288 page Freed & Klensin DOIT être publiée cmme RFC. Les RFC d'enregistrement dans l'arbrescence standard peuvent être des RFC autnmes "d'enregistrement seul", u elles peuvent être incrprées dans des spécificatins plus générales de tutes srtes. Les types de supprts dans l'arbrescence standard snt nrmalement ntés par des nms qui ne snt pas explicitement à facettes, c'est-à-dire, qu'ils ne cntiennent pas de caractères pint ("."). Le "pssesseur" d'un enregistrement de type de supprt dans l'arbrescence standard est suppsé être l'rganisme de nrmalisatin lui-même. La mdificatin u l'altératin de la spécificatin exige le même niveau de traitement (par exemple, en curs de nrmalisatin) que celui exigé pur l'enregistrement initial. 3.2 Arbre de fabricant L'arbre de fabricant est utilisé pur les types de supprts assciés à des prduits dispnibles sur le marché. "Fabricant" u "prducteur" snt des termes cmpris cmme équivalents et de sens très large dans ce cntexte. Un enregistrement peut être placé dans l'arbre de fabricant par quicnque a besin d'échanger des fichiers assciés à un prduit particulier. Cependant, l'enregistrement appartient frmellement au fabricant u à l'rganisatin qui prduit le lgiciel u frmat de fichier qui est enregistré. Les changements à la spécificatin sernt effectués à leur demande, cmme expliqué dans les paragraphes suivants. Les enregistrements dans l'arbre de fabricant sernt distingués par la facette de tête "vnd.". Elle peut être suivie, à la discrétin de l'enregistreur, par un nm de sus-type de supprt à partir d'un prducteur bien cnnu (par exemple, "vnd.mudpie") u par une désignatin appruvée par l'iana- du nm du prducteur qui est suivi par une désignatin de type de supprt u de prduit (par exemple, vnd.bigcmpany.funnypictures). Bien que la publicatin et la révisin des types de supprts à enregistrer dans l'arbre de fabricant ne sient pas exigées, l'utilisatin de la liste de diffusin ietf-types@iana.rg pur la révisin est frtement encuragée pur amélirer la qualité de ces spécificatins. Les enregistrements dans l'arbre de fabricant peuvent être sumis directement à l'iana. 3.3 Arbre persnnel u factice Les enregistrements pur les types de supprts de créatin expérimentale u au titre de prduits qui ne snt pas distribués cmmercialement peuvent être enregistrés dans l'arbre persnnel u factice. Les enregistrements snt distingués par la facette de tête "prs.". Le prpriétaire des enregistrements "persnnels" et des spécificatins assciées est la persnne u entité qui fait l'enregistrement, u à qui la respnsabilité a été transférée cmme décrit ci-dessus. Bien que la cmmunicatin au public et la révisin des types de supprts à enregistrer dans l'arbre persnnel ne sit pas exigée, l'utilisatin de listes de types ietf pur la révisin est frtement cnseillée pur amélirer la qualité de ces spécificatins. Les enregistrements dans l'arbre persnnel snt sumis directement à l'iana. 3.4 Arbre particulier x. Pur des raisns pratiques et de symétrie avec ce schéma d'enregistrement, les nms de sus-types avec "x." cmme première facette peuvent être utilisés pur les mêmes besins que pur les nms qui cmmencent en "x-". Ces types snt nn enregistrés, expérimentaux, et pur une utilisatin exclusive avec l'accrd actif des parties qui les échangent. Cependant, avec les prcédures d'enregistrement simplifiées décrites ci-dessus pur les arbres de fabricant et persnnel, il sera rarement, sinn jamais, nécessaire d'utiliser les types expérimentaux nn enregistrés. Dnc, l'utilisatin des frmes "x-" et "x." est décnseillée. Les types dans cette arbrescence NE DOIVENT PAS être enregistrés. 3.5 Arbres d'enregistrement supplémentaires De temps en temps, et en fnctin des besins de la cmmunauté, l'iana peut, seln l'avis et avec le cnsentement de

4 RFC 4288 page Freed & Klensin l'iesg, créer de nuvelles arbrescences d'enregistrement de niveau supérieur. Il est explicitement suppsé que ces arbrescences peuvent être créées pur l'enregistrement et la gestin externes par des rganismes permanents bien cnnus; par exemple, des sciétés scientifiques peuvent enregistrer des types de supprts spécifiques des sciences qu'elles cuvrent. En général, la qualité de révisin des spécificatins pur un de ces arbres d'enregistrement supplémentaires est suppsée être équivalente à celle des enregistrements de l'arbrescence standard. L'établissement de ces nuvelles arbrescences sera annncée par la publicatin d'une RFC appruvée par l'iesg. 4. Exigences pur l'enregistrement Les prpsitins d'enregistrement de types de supprts snt tutes suppsées êtres cnfrmes aux diverses exigences expsées dans les paragraphes qui suivent. Nter que des exigences spécifiques varient parfis seln les arbrescences d'enregistrement, là encre, précisées dans les paragraphes qui suivent. 4.1 Exigences fnctinnelles Les types de supprts DOIVENT fnctinner cmme un frmat de supprt réel. L'enregistrement de chses qui seraient plutôt un cdage de transfert, cmme un jeu de caractères, u cmme une cllectin d'entités distinctes d'un autre type, n'est pas permis. Par exemple, bien qu'il existe des applicatins pur décder le cdage de transfert en base64 [RFC2045], le base64 ne peut pas être enregistré cmme type de supprt. Cette exigence s'applique sans cnsidératin de l'arbrescence d'enregistrement impliquée. 4.2 Exigences de dénminatin Tus les types de supprts enregistrés DOIVENT avir des types et nms de sus-types allués. La cmbinaisn de ces nms sert à identifier de façn univque le type de supprt, et le frmat du nm de sus-type identifie l'arbrescence d'enregistrement. Les nms de type et de sus-types snt tus deux insensibles à la casse. Les nms de types et de sus-types cmmençant par "X-" snt réservé pur les utilisatins expérimentales et NE DOIVENT PAS être enregistrés. Cette restrictin est parallèle à la restrictin sur l'arbrescence x., cmme expsé au paragraphe 3.4. Les nms de types et de sus-types DOIVENT se cnfrmer à l'abnf suivant : nm-de-type = nm-enregistré nm-de-sus-type = nm-enregistré nm-enregistré = 1*127reg-name-chars reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_" Nter que cette syntaxe est un peu plus restrictive que celle permise par l'abnf de la [RFC2045]. Cnfrmément aux règles spécifiées dans la [RFC3023], les sus-types de supprts qui ne représentent pas des entités XML NE DOIVENT PAS recevir un nm se terminant par le suffixe "+xml". De façn plus générale, les cnstructins "+suffixe" devraient être utilisées avec prudence, sachant la pssibilité de cnflits avec des définitins de suffixes futures. Bien qu'il sit pssible que sient allués des nms supplémentaires à un type de supprt dnné, l'utilisatin de nms différents pur identifier le même type de supprt est décnseillée. Cette exigence s'applique sans cnsidératin de l'arbrescence d'enregistrement impliquée. Le chix d'un nm de type de niveau supérieur DOIT tenir cmpte de la nature du type de supprt impliqué. De nuveaux sus-types de types de niveau supérieur DOIVENT se cnfrmer aux restrictins du type de niveau supérieur, s'il en est. Les paragraphes suivants décrivent chaque ensemble initial des types de niveau supérieur et les restrictins qui leur snt assciées. De plus, divers prtcles, y cmpris, mais sans s'y limiter, MIME, PEUVENT impser des restrictins supplémentaires aux types de supprts qu'ils peuvent transprter. (Vir dans la [RFC2046] des infrmatins supplémentaires sur les restrictins impsées par MIME.)

5 RFC 4288 page Freed & Klensin Types de supprt "text" Le type de supprt "text" est destiné à l'envi de matériel principalement de frme textuelle. Un paramètre "charset" (jeu de caractères) PEUT être utilisé pur indiquer le jeu de caractères du crps du texte pur les sus-types "text", ntamment ceux qui incluent le sus-type "text/plain" (texte en clair), qui est un sus-type générique pur le texte en clair défini dans la [RFC2046]. Si il est défini, un paramètre "charset" de texte DOIT être utilisé pur spécifier un nm de jeu de caractères défini cnfrmément aux prcédures établies dans la [RFC2978]. Le texte en clair ne furnit ni ne permet pas les cmmandes de frmatage, les spécificatins d'attributs de plice, les instructins de traitement, les directives d'interprétatin, u le marquage du cntenu. Le texte en clair est vu simplement cmme une séquence linéaire de caractères, éventuellement interrmpue par des sauts de ligne u des sauts de page. Le texte en clair PEUT permettre l'empilage de plusieurs caractères à la même psitin dans le texte. Le texte en clair dans les écritures cmme l'arabe et l'hébreu peut aussi inclure des facilités qui permettent un mélange arbitraire de segments de texte avec des directins d'écriture ppsées. Au delà du texte en clair, il y a de nmbreux frmats pur représenter ce qui peut être appelé du "texte enrichi". Une caractéristique intéressante de nmbre de ces représentatins est qu'elles snt dans une certaine mesure lisibles même sans le lgiciel qui les interprète. Il est utile de les distinguer, au plus haut niveau, de dnnées illisibles cmme les images, l'audi, u le texte représenté sus une frme nn lisible. En l'absence d'un lgiciel d'interprétatin apprprié, il est raisnnable de présenter les sus-types de "text" à l'utilisateur, alrs qu'il n'est pas raisnnable de le faire avec la plupart des dnnées nn textuelles. De telles dnnées textuelles frmatées devraient être représentées en utilisant des sus-types de "text" Types de supprt Image Les type de supprt de "image" indiquent que le cntenu spécifie une u plusieurs images distinctes qui exigent un matériel apprprié pur les afficher. Le sus-type désigne le frmat spécifique de l'image Types de supprt Audi Un type de supprt "audi" indique que le cntenu cntient des dnnées audi Types de supprt Vidé Un type de supprt de "vidé" indique que le cntenu spécifie une image qui varie dans le temps, éventuellement avec des culeurs et du sn crdnné. Le terme "vidé" est utilisé dans sn sens le plus générique, plutôt qu'en référence à une technlgie u frmat particulier, et n'est pas destiné à exclure de sus-types tels que des dessins animés à cdage cmpact. Nter que bien qu'en général le présent dcument décnseille frtement le mélange de plusieurs supprts dans un même crps, il est recnnu que beaucup de frmats dits de vidé cmprtent une représentatin d'audi synchrnisé et/u de texte, et ceci est explicitement permis pur les sus-types de "vidé" Types de supprt Applicatin Le type de supprt "applicatin" est à utiliser pur des dnnées discrètes qui ne rentrent dans aucun des types de supprts, et en particulier pur des dnnées à traiter par un type de prgramme d'applicatin. Ce snt des infrmatins qui divent être traitées par une applicatin avant qu'elles ne sient visibles u utilisables par un usager. Les utilisatins prévues pur le type de supprt "applicatin" incluent, mais sans s'y limiter, les transferts de fichiers, les spreadsheets, les présentatins, les dnnées de prgrammatin, et les langages pur le matériel "actif" (de calcul). (Ces dernier, en particulier, peuvent pser des prblèmes de sécurité qui divent être cmpris par les mises en œuvre, et snt examinés en détails dans l'expsé sur le type de supprt "applicatin/ PstScript" dans la [RFC2046].) Par exemple, un prgrammeur de réunin purrait définir une représentatin standard d'infrmatins sur les dates de réunin prpsées. Un agent d'utilisateur intelligent utilisera ces infrmatins pur cnduire un dialgue avec l'utilisateur, et purra alrs envyer du matériel supplémentaire sur la base de ce dialgue. Plus généralement, il y a eu plusieurs langages "actifs" dévelppés dans lesquels des prgrammes dans un langage spécialisé cnvenable snt transprtés jusqu'à une lcalisatin distante et lancés autmatiquement dans l'envirnnement du receveur. De telles applicatins peuvent être définies cmme sus-types du type de supprt "applicatin". Le sus-type "applicatin" va suvent être sit le nm, sit inclure une partie du nm de l'applicatin pur laquelle les dnnées snt destinées. Cela ne signifie cependant pas que tut nm de prgramme d'applicatin puisse être librement utilisé cmme sus-type de "applicatin".

6 RFC 4288 page Freed & Klensin Types de supprt multipartie et message Multipartie et message snt des types cmpsites, c'est à dire qu'ils furnissent un myen d'encapsuler zér, un u plusieurs bjets, étiqueté chacun avec sn prpre type de supprt. Tus les sus-types de multipartie et de message DOIVENT se cnfrmer aux règles de syntaxe et autres exigences spécifiées dans la [RFC2046] Types de niveau supérieur supplémentaires Dans certains cas, un nuveau type de supprt peut ne pas "tenir" dans un type de cntenu de niveau supérieur actuellement défini. On pense que de tels cas snt assez rares. Cependant, si un tel cas se présente, un nuveau type de niveau supérieur peut être défini pur le traiter. Une telle définitin DOIT être faite par une RFC sumise à nrmalisatin ; aucun autre mécanisme ne peut être utilisé pur définir des types de cntenu de niveau supérieur supplémentaires. 4.3 Exigences de paramètres Les types de supprts PEUVENT chisir d'utiliser un u plusieurs paramètres de type de supprt, u certains paramètres peuvent être autmatiquement dispnibles pur le type de supprt par le fait qu'ils snt un sus-type d'un type de cntenu qui définit un ensemble de paramètres applicables à tus ses sus-types. Dans l'un et l'autre cas, les nms, valeurs, et significatin de tus les paramètres DOIVENT être cmplètement spécifiés lrsque un type de supprt est enregistré dans l'arbrescence standard, et DEVRAIT être spécifié aussi cmplètement que pssible lrsque les types de supprts snt enregistrés dans les arbrescences de fabricant u persnnelle. Les nms de paramètres nt cmme nms et valeurs de type de supprt la syntaxe suivante : nm-de-paramètre = nm-enregistré Nter que cette syntaxe est un peu plus restrictive que ce qui est permis par l'abnf de la [RFC2045] amendée par la [RFC2231]. Il n'y a pas de syntaxe définie pur les valeurs de paramètres. Les enregistrements DOIVENT dnc spécifier la syntaxe de valeur de paramètre. De plus, certains transprts impsent des restrictins à la syntaxe de valeur de paramètre, et il faut dnc faire attentin à limiter l'usage de syntaxes ptentiellement prblématiques ; par exemple, les paramètres avec de pures valeurs binaires, bien que permis dans certains prtcles, devraient prbablement être évités. De nuveaux paramètres NE DEVRAIT PAS être définis cmme un myen d'intrduire de nuvelles fnctinnalités dans des types enregistrés dans l'arbrescence standard, bien que de nuveaux paramètres PUISSENT être ajutés pur prter des infrmatins supplémentaires qui ne changent pas par ailleurs la fnctinnalité existante. Un exemple en serait un paramètre "révisin" pur indiquer un niveau de révisin d'une spécificatin externe cmme JPEG. Un cmprtement similaire est cnseillé pur les types de supprts enregistrés dans les arbrescences de fabricant u persnnelle mais n'est pas exigé. 4.4 Exigences de cannisatin et de frmat Tus les types de supprts enregistrés DOIVENT emplyer un seul frmat de dnnées cannisées, sans cnsidératin de l'arbrescence d'enregistrement. Une spécificatin précise et librement dispnible du frmat de chaque type de supprt DOIT exister pur tus types enregistrés dans l'arbrescence standard et DOIT au minimum être référencée par la prpsitin d'enregistrement du type de supprt, si elle n'y est pas en fait incluse elle même. Les spécificatins des particularités de frmat et de traitement peuvent u nn être librement dispnibles pur les types de supprts enregistrés dans l'arbrescence des fabricants, et il est explicitement permis à de telles prpsitins d'enregistrement de limiter leur spécificatin aux lgiciels et versins qui prduisent u traitent de tels types de supprts. Les références aux spécificatins de frmat, u leur inclusin dans les prpsitins d'enregistrement est cnseillée mais nn exigée.

7 RFC 4288 page Freed & Klensin L'enregistrement des spécificatins de frmat est encre exigé pur l'arbrescence persnnelle, mais elles peuvent sit être publiées cmme RFC sit dépsées par ailleurs auprès de l'iana. Les spécificatins dépsées divent satisfaire aux mêmes critères que celles dnt il est exigé qu'elles enregistrent un accès TCP bien cnnu, en particulier, elles n'nt pas besin d'être rendues publiques. Certains types de supprts impliquent l'utilisatin de technlgie brevetées. L'enregistrement de types de supprts impliquant des technlgie brevetées est spécifiquement permis. Cependant, les restrictins avancées dans la [RFC2026] sur l'utilisatin de technlgies brevetées dans les prtcles en curs de nrmalisatin de l'ietf divent être respectées lrsque la spécificatin d'un type de supprt fait partie d'un prtcle en curs de nrmalisatin. De plus, d'autres rganismes de nrmalisatin qui utilisent l'arbrescence standard peuvent avir leurs prpres règles en ce qui cncerne les drits de prpriété intellectuelle qui divent être bservés dans leurs enregistrements. 4.5 Recmmandatins d'interpérabilité Les types de supprts DEVRAIENT interpérer à travers autant de systèmes et applicatins que pssible. Cependant, certains types de supprts vnt inévitablement avir des prblèmes d'interpératin à travers des plates-frmes différentes. Les prblèmes avec des versins différentes, l'rdre des ctets, et les spécificités du traitement des passerelles peuvent, et vnt, survenir. L'interpérabilité universelle des types de supprts n'est pas exigée, mais les prblèmes d'interpérabilité cnnus DEVRAIENT être identifiés chaque fis que pssible. La publicatin d'un type de supprt ne requiert pas une revue exhaustive de sn interpérabilité, et la sectin de cnsidératins d'interpérabilité est l'bjet d'une évaluatin permanente. Ces recmmandatins s'appliquent sans cnsidératin de l'arbrescence d'enregistrement impliqué. 4.6 Exigences de sécurité Une analyse des questins de sécurité DOIT être effectuée pur tus les types enregistrés dans l'arbrescence standard. Une analyse similaire est cnseillée, mais nn exigée pur les types de supprts enregistrés dans les arbrescences de fabricant u persnnelle. Cependant, sans cnsidératin de la nature de l'analyse de sécurité qui a été u nn faite, tutes les descriptins de questins de sécurité DOIVENT être aussi précises que pssible sans cnsidératin de l'arbrescence d'enregistrement. En particulier, la déclaratin qu'il "n'y a pas de prblème de sécurité asscié à ce type" NE DOIT PAS être cnfndue avec "les prblèmes de sécurité assciés à ce type n'nt pas été vérifiés". Il n'est abslument pas exigé que les types de supprts enregistrés dans une des arbrescences sient sécurisés u abslument sans risque. Néanmins, tus les risques cnnus pur la sécurité DOIVENT être identifiés dans l'enregistrement d'un type de supprt, là encre, sans cnsidératin de l'arbrescence d'enregistrement. La sectin des cnsidératins pur la sécurité de tut enregistrement est sumise à une évaluatin permanente et à mdificatin, et en particulier PEUT être étendue par l'utilisatin des mécanismes de "cmmentaires sur les types de supprts" décrits à la Sectin 6 ci-dessus. Certaines des questins qui devraient être regardées dans une analyse de sécurité d'un type de supprt snt : Les types de supprts cmplexes peuvent inclure des dispsitins qui dnnent des directives qui instituent des actins sur les fichiers u autres ressurces d'un receveur. Dans de nmbreux cas, des dispsitins snt prises pur que le générateur spécifie des actins arbitraires sans restrictin qui peuvent avir des effets dévastateurs. Vir un exemple de telles directives dans l'enregistrement du type de supprt applicatin/pstscript dans la [RFC2046] et de la façn dnt il devrait être décrit dans un enregistrement de type de supprt. Tus les enregistrements DOIVENT déclarer si ils emplient u nn un tel "cntenu actif", et si ils le fnt, ils DOIVENT déclarer quelles mesures snt prises pur prtéger les utilisateurs du type de supprt cntre les dmmages éventuels. Les types de supprts cmplexes peuvent inclure des dispsitins pur dnner des directives qui instituent des actins qui, bien que nn directement dmmageables pur le receveur, peuvent résulter en la divulgatin d'infrmatins qui vnt faciliter une attaque ultérieure u viler d'une certaine manière la cnfidentialité du receveur. Là encre, l'enregistrement du type de supprt applicatin/pstscript illustre cmment peuvent être traitées de telles directives. Un type de supprt qui emplie la cmpressin peut furnir une pprtunité d'envi d'une petite quantité de dnnées

8 RFC 4288 page Freed & Klensin qui, lrsque elles snt reçues et évaluées, se dévelppent énrmément pur cnsmmer tutes les ressurces du receveur. Tus les types de supprts DEVRAIENT déclarer si ils emplient u nn la cmpressin, et s'ils l'emplient, ils devraient expser quelles mesures divent être prises pur éviter de telles attaques. Un type de supprt purrait être ciblé sur des applicatins qui requièrent une srte d'assurance de sécurité mais ne furnissent pas elles-mêmes les mécanismes de sécurité nécessaires. Par exemple, un type de supprt purrait être défini pur la mémrisatin d'infrmatins médicales cnfidentielles qui à sn tur exige un service de cnfidentialité externe, u qui serait cnçu pur une utilisatin exclusive en envirnnement sécurisé. 4.7 Exigences spécifiques des types de supprts XML Un certain nmbre d'exigences supplémentaires snt spécifiques des enregistrements des types de supprts XML. Ces exigences snt spécifiées dans la [RFC3023]. 4.8 Exigences de cdage Certains transprts impsent des restrictins sur le type de dnnées qu'ils peuvent transprter. Par exemple, la messagerie Internet était traditinnellement limitée à du texte US-ASCII à 7 bits. Les schémas de cdage snt suvent utilisés pur cnturner de telles limitatins de transprt. Il est dnc utile de nter au titre de sn enregistrement en quelles srtes de dnnées un type de supprt peut cnsister. Un champ "cnsidératins de cdage" est furni à cet effet. Les valeurs pssibles pur ce champ snt : 7 bits : Le cntenu du type de supprt cnsiste uniquement en texte US-ASCII à 7 bits délimité par des CRLF. 8 bits : Le cntenu du type de supprt cnsiste uniquement en texte à 8 bits délimité par des CRLF. binaire : tramé : Le cntenu cnsiste en séquences d'ctets sans restrictin. Le cntenu cnsiste en une série de trames u de paquets sans tramage interne ni indicateurs d'alignement. Des infrmatins hrs bande supplémentaires snt nécessaires pur interpréter crrectement les dnnées, y cmpris, mais pas nécessairement limité, à la cnnaissance des frntières entre les trames successives et la cnnaissance du mécanisme de transprt. Nter que les types de supprts de cette srte ne peuvent pas être simplement mémrisés dans un fichier u transprtés cmme un simple flux d'ctets ; dnc, de tels types de supprts ne cnviennent pas pur une utilisatin dans de nmbreux prtcles traditinnels. Un transprt cmmunément utilisé avec le cdage tramé est le prtcle de transprt en temps réel (RTP, Real-time Transprt Prtcl). Des règles supplémentaires pur les cdages tramés définis pur le transprt qui utilise RTP snt dnnées dans la [RFC3555]. Des restrictins supplémentaires sur le texte à 7 bits et à 8 bits figurent dans la [RFC2046]. 4.9 Nn exigences d'usage et de mise en œuvre Dans l'envirnnement de messagerie asynchrne, ù les infrmatins sur les capacités de l'agent de messagerie distant snt fréquemment indispnibles à l'envyeur, l'interpérabilité maximum est atteinte en restreignant les types de supprts utilisés à ceux de frmat "cmmun" dnt n s'attend à ce qu'ils sient largement mis en œuvre. Cela a été affirmé dans le passé cmme une raisn de la limitatin du nmbre de types de supprts pssibles, et il en résulte des bstacles et des délais significatifs au prcessus d'enregistrement de ces types de supprts. Cependant, le besin de types de supprts "cmmuns" n'exige pas de limiter l'enregistrement de nuveaux types de supprts. Si un ensemble limité de types de supprts est recmmandé pur une applicatin particulière, cela devrait être affirmé par une déclaratin d'applicabilité distincte, spécifique de l'applicatin et/u de l'envirnnement. Dnc, la prise en charge et la mise en œuvre universelle d'un type de supprt N'EST PAS une exigence d'enregistrement. Cependant, si un type de supprt est explicitement destiné à une utilisatin limitée, cela DOIT être nté dans sn enregistrement. Le champ "Restrictins d'utilisatin" est furni à cette fin.

9 RFC 4288 page Freed & Klensin 4.10 Exigences de publicatin Les prpsitins d'enregistrements de types de supprts dans l'arbrescence standard par l'ietf elle-même DOIVENT être publiées cmme RFC. La publicatin de RFC de prpsitins de types de supprt de fabricants et persnnelles est cnseillée mais pas exigée. Dans tus les cas, l'iana gardera des cpies de tutes les prpsitins de types de supprt et les "publiera" au titre de l'arbrescence d'enregistrement des types de supprts elle-même. Cmme déclaré précédemment, les enregistrements dans l'arbrescence standard pur les types de supprts définis dans les dcuments prduits par d'autres rganismes de nrmalisatin DOIVENT être décrits par une spécificatin de nrme frmelle prduite par cet rganisme. De telles spécificatins DOIVENT cntenir un gabarit d'enregistrement de type de supprt apprprié tiré de la Sectin 10. De plus, les drits de reprductin sur le gabarit d'enregistrement DOIVENT permettre à l'iana de le cpier dans le registre de l'iana. En dehrs des enregistrements de l'ietf dans l'arbrescence standard, l'enregistrement d'un type de dnnées n'implique pas l'endssement, l'apprbatin, u la recmmandatin par l'iana u par l'ietf u même la certificatin que la spécificatin est adéquate. Pur devenir une nrme de l'internet, un prtcle u bjet de dnnées dit passer par le prcessus de nrmalisatin de l'ietf. C'est un prcessus trp difficile et trp lng pur un enregistrement pratique des types de supprts. L'arbrescence standard existe pur les types de supprts qui exigent effectivement une révisin de substance et un prcessus d'apprbatin par un rganisme de nrmalisatin recnnu. Les arbrescences de fabricant et persnnel existent pur les types de supprts qui n'exigent pas un tel prcessus. Il est prévu que les déclaratins d'applicabilité pur des applicatins particulières sient publiées de temps en temps par l'ietf, recmmandant la mise en œuvre et la prise en charge des types de supprts qui se snt révélés être particulièrement utiles dans ces cntextes. Cmme expsé plus haut, l'enregistrement d'un type de niveau supérieur requiert le traitement de prductin d'une nrme dans l'ietf et dnc, la publicatin d'une RFC Infrmatins supplémentaires Diverses srtes d'infrmatins facultatives DEVRAIENT être incluses dans la spécificatin d'un type de supprt si elles snt dispnibles : Les numérs magiques (lngueur, valeurs d'ctet). Les numérs magiques snt des séquences d'ctet qui snt tujurs présentes à un endrit dnné dans le fichier et peuvent dnc être utilisées pur identifier les entités cmme étant d'un type de supprt dnné. La u les extensins de nm de fichier curamment utilisées sur une u plusieurs plates-frmes pur indiquer qu'un certain fichier cntient un type de supprt dnné. Le u les cdes de type de fichier d'os Mac (4 ctets) utilisés pur étiqueter les fichiers qui cntiennent un type de supprt dnné. Les infrmatins sur la façn dnt les identifiants de fragment/ancre [RFC3986] snt cnstruits pur les utiliser en cnjnctin avec ce type de supprt. Dans le cas d'un enregistrement dans l'arbrescence standard, ces infrmatins supplémentaires PEUVENT être furnies dans la spécificatin frmelle du type de supprt. Il est suggéré que cela sit fait en incrprant le frmulaire d'enregistrement IANA de type de supprt dans la spécificatin elle-même. 5. Prcédure d'enregistrement La prcédure d'enregistrement de type de supprt n'est pas un prcessus frmel de nrmalisatin, mais plutôt une prcédure administrative destinée à permettre les cmmentaires et les vérificatins de bnne tenue par la cmmunauté sans intrduire de délais excessifs. Le prcessus nrmal de l'ietf devrait être suivi pur tus les enregistrements de l'ietf dans l'arbrescence standard. L'envi d'un Prjet Internet est la première étape nécessaire, suivie par l'envi à la liste de diffusin ietf-types@iana.rg cmme indiqué plus lin. Les enregistrements dans les arbrescences de fabricant et persnnelle devraient être sumises directement à l'iana, en thérie après les avir envyés pur révisin à la liste ietf-types@iana.rg. Les enregistrements prpsés dans l'arbrescence standard par d'autres rganismes de nrmalisatin devraient être

10 RFC 4288 page Freed & Klensin cmmuniqués à l'iesg (à iesg@ietf.rg) et à la liste des types ietf (à ietf-types@iana.rg). L'envi préalable cmme Prjet Internet n'est pas exigé pur ces enregistrements, mais cela peut être utile pur l'iesg, et est dnc cnseillé. 5.1 Révisin cmmunautaire préliminaire L'avis d'un ptentiel enregistrement de type de supprt dans l'arbrescence standard DOIT être envyé à la liste de diffusin "ietf-types@iana.rg" pur révisin. Cette liste de diffusin a été établie pur les besins de la révisin des prpsitins de types de supprts et d'accès. L'enregistrement dans d'autres arbrescences PEUT être envyé aussi à la liste pur révisin. L'intentin de l'envi public à la liste est de slliciter des cmmentaires et des returs sur le chix des nms de type/sustype, la nn ambiguïté des références par rapprt aux infrmatins de versins et de prfilage externe, et une révisin de tutes cnsidératins d'interpérabilité u de sécurité. Le pstulant peut sumettre un enregistrement révisé u abandnner cmplètement l'enregistrement à tut mment. 5.2 Apprbatin de l'iesg Les types de supprt enregistrés dans l'arbrescence standard DOIVENT être appruvés par l'iesg avant l'enregistrement. 5.3 Enregistrement de l'iana Purvu que le type de supprt satisfasse à tutes les exigences pertinentes et ait btenu tutes les apprbatins nécessaires, l'auteur peut sumettre la demande d'enregistrement à l'iana. Les demandes d'enregistrement peuvent être envyées à iana@iana.rg. Un frmulaire électrnique est aussi dispnible pur les demandes d'enregistrement. L'envi à ietf-types@iana.rg ne cnstitue pas la sumissin de l'enregistrement à l'iana. Lrsque l'enregistrement fait partie d'une demande de publicatin de RFC u d'un enregistrement dans l'arbrescence standard sumise à l'iesg, une crdinatin étrite entre l'iana et l'iesg signifie que l'apprbatin par l'iesg sumet en fait l'enregistrement à l'iana. Il n'y a pas besin d'une autre demande d'enregistrement de tels cas. 5.4 Réviseurs de types de supprts Les enregistrements sumis à l'iana sernt passés au réviseur de types de supprts. Le réviseur de types de supprts, qui est nmmé par les directeurs de zne d'applicatin de l'ietf, va revir l'enregistrement pur s'assurer qu'il satisfait aux exigences établies dans le présent dcument. Les enregistrements qui ne satisfnt pas à ces exigences sernt renvyées pur révisin au sumettant. On peut faire appel des décisins prises par le réviseur de types de supprts devant l'iesg en utilisant la prcédure spécifiée dans la [RFC2026] paragraphe Une fis qu'un enregistrement de type de supprt a passé la révisin, l'iana va enregistrer le type de supprt et rendre l'enregistrement de type de supprt dispnible à la cmmunauté. 6. Cmmentaires sur les enregistrements de types de supprts Les cmmentaires sur les types de supprts enregistrés peuvent être sumis par les membres de la cmmunauté à l'iana. Ces cmmentaires sernt révisés par les réviseurs de types de supprts et ils sernt cmmuniqués au "prpriétaire" du type de supprt si pssible. Ceux qui sumettent des cmmentaires peuvent demander que leur cmmentaire sit jint à l'enregistrement de type de supprt lui-même, et si l'iana l'appruve, le cmmentaire sera rendu accessible cnjintement avec l'enregistrement de type.

11 RFC 4288 page Freed & Klensin 7. Lcalisatin de la liste des types de supprts enregistrés La liste des enregistrements de types de supprts est tenue par l'iana à l'adresse : 8. Prcédures de l'iana pur l'enregistrement des types de supprts L'IANA n'enregistrera les types de supprts dans l'arbrescence standard qu'en répnse à une cmmunicatin de l'iesg déclarant qu'un enregistrement dnné a été appruvé. Les types fabriquant et persnnel sernt enregistrés autmatiquement par l'iana sans aucun prcessus d'apprbatin frmelle pur autant que les cnditins minimales suivantes sient satisfaites : Les types de supprts DOIVENT fnctinner cmme un frmat de supprt réel. En particulier, les jeux de caractères et les cdages de transfert NE DOIVENT PAS être enregistrés cmme types de supprts. Tus les types de supprts DOIVENT avir des types et nms de sus-types frmés crrectement. Tus les nms de type DOIVENT être définis par des RFC en curs de nrmalisatin. Tutes les paires de nm type/sus-type DOIVENT être uniques et DOIVENT cntenir le préfixe d'arbrescence apprprié. Les types enregistrés dans l'arbrescence persnnelle DOIVENT furnir une spécificatin de frmat u un pinteur sur une spécificatin de frmat. Tus les types de supprts DOIVENT avir une sectin raisnnable de cnsidératins pur la sécurité. (Il n'est ni pssible ni nécessaire que l'iana mène une enquête de sécurité cmplète sur les enregistrements de type de supprt. Néanmins, l'iana a autrité pur identifier le matériel évidemment incrrect et le returner au sumettant pur révisin.) Les enregistrements dans l'arbrescence standard DOIVENT satisfaire aux exigences supplémentaires qui nt pur rigine l'ietf elle-même u un autre rganisme de nrmalisatin recnnu cmme tel par l'ietf. 9. Prcédures de mdificatin Une fis qu'un type de supprt a été publié par l'iana, sn prpriétaire peut demander un changement de sa définitin. La descriptins des différentes arbrescences d'enregistrement ci-dessus désigne les "prpriétaires" de chaque type d'enregistrement. La même prcédure qui serait apprpriée pur la demande riginale d'enregistrement est utilisée pur traiter une demande de changement. Les changements devraient n'être demandés que lrsque il y a de sérieuses missins u erreurs dans la spécificatin publiée. Lrsque la révisin est demandée, une demande de changement peut être refusée si elle devrait rendre invalides dans la nuvelle définitin des entités qui étaient valides sus la précédente définitin. Le prpriétaire d'un type de supprt peut passer sa respnsabilité à une autre persnne u agence en infrmant l'iana et la liste des types ietf ; cela peut être fait sans discussin u révisin. L'IESG peut réalluer la respnsabilité d'un type de supprt. Le cas le plus curant en sera pur permettre de faire des changements à des types dnt l'auteur de l'enregistrement est décédé, déplacé u injignable u est autrement incapable de faire des changements qui snt imprtants pur la cmmunauté. Les enregistrements de type de supprt ne peuvent pas être supprimées ; les types de supprts dnt n estime qu'ils ne snt plus apprpriés peuvent être déclarés OBSOLETE par un changement de leur champ "utilisatin prévue" ; de tels types de supprts sernt clairement marqués dans les listes publiées par l'iana. 10. Gabarit d'enregistrement À : ietf-types@iana.rg Objet : Enregistrement du type de supprt XXX/YYY

12 RFC 4288 page Freed & Klensin Nm du Type : Nm du sus-type : Paramètres exigés : Paramètres facultatifs : Cnsidératins de cdage : Cnsidératins de sécurité : Cnsidératins d'interpérabilité : Spécificatin publiée : Applicatins qui utilisent ce type de supprt : Infrmatins supplémentaires : Numérs magiques : Extensins de fichier : Cdes de type de fichier Macintsh : Adresse de la persnne à cntacter pur des infrmatins cmplémentaires : Utilisatin prévue : (UTILISATION COMMUNE, LIMITÉE u OBSOLETE.) Restrictins d'usage : (Tutes restrictins sur l'endrit ù le type de supprt peut être utilisé viennent ici.) Auteur : Cntrôleur des changements : (Tutes les autres infrmatins que l'auteur estime intéressantes peuvent être ajutées en dessus de cette ligne.) On truvera un expsé sur les cdes de type de fichier Macintsh et leur bjet dans [MacOSFileTypes]. On est de plus prié de s'abstenir d'écrire "aucune" u des mentins similaires lrsque aucune extensin de fichier u type de fichier Macintsh n'est spécifié, car "aucune" peut être cnfndu avec une valeur de cde réelle. 11. Cnsidératins pur la sécurité Les exigences de sécurité pur les enregistrements de type de supprt snt expsées au paragraphe Cnsidératins relatives à l'iana L'bjet du présent dcument est de définir les registres de l'iana pur les types de supprt. 13. Remerciements Les auteurs actuels tiennent à recnnaître leurs dettes à l'égard du regretté Dr. Jn Pstel, dnt le mdèle général de prcédures d'enregistrement de l'iana et les cntributins spécifiques nt dnné frme aux prédécesseurs du présent dcument [RFC2048]. Nus espérns que la versin actuelle est de celles qui auraient recueilli snt agrément, mais cmme il est impssible de vérifier cet accrd, nus avns dû à regret retirer sn nm de la liste de c-auteurs. 14. Références 14.1 Références nrmatives [RFC2045] N. Freed et N. Brenstein, "Extensins de messagerie Internet multi-bjets (MIME) Partie 1 : Frmat des crps de message Internet", nvembre (D. S., MàJ par 2184, 2231, 5335.) [RFC2046] N. Freed et N. Brenstein, "Extensins de messagerie Internet multi-bjets (MIME) Partie 2 : Types de supprt", nvembre (D. S., MàJ par 2646, 3798, 5147.) [RFC2119] S. Bradner, "Mts clés à utiliser dans les RFC pur indiquer les niveaux d'exigence", BCP 14, mars [RFC2978] N. Freed et J. Pstel, "Prcédures d'enregistrement des jeux de caractère par l'iana", BCP 19, ctbre 2000.

13 RFC 4288 page Freed & Klensin [RFC3023] M. Murata, S. St.Laurent et D. Khn, "Types de supprt XML", janvier [RFC3555] S. Casner et P. Hschka, "Enregistrement de type MIME pur les types de charge utile RTP", juillet [RFC3986] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressurce unifrme (URI) : Syntaxe générique", STD 66, janvier [RFC4234] D. Crcker et P. Overell, "BNF augmenté pur les spécificatins de syntaxe : ABNF", ctbre (Remplacé par 5234) 14.2 Références pur infrmatin [MacOSFileTypes] Apple Cmputer, Inc., "Mac OS: File Type and Creatr Cdes, and File Frmats", Apple Knwledge Base Article 55381, June 1993, < [RFC2026] S. Bradner, "Le prcessus de nrmalisatin de l'internet -- Révisin 3", (BCP0009) ctbre (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378) [RFC2048] N. Freed, J. Klensin et J. Pstel, "Extensins multi-bjets de la messagerie Internet (MIME) Partie 4 : Prcédures d'enregistrement", BCP 13, nvembre (Rendue bslète par les RFC ) [RFC2231] N. Freed, K. Mre, "Extensins MIME Valeur de paramètre et Mt cdé : jeux de caractères, langages, et cntinuatins", nvembre (P.S.) Appendice A. Types de supprt anciens Un certain nmbre de types de supprts, enregistrés avant 1996, auraient dû, s'il avaient été enregistrés seln les lignes directrices du présent dcument, être placés dans les arbres de fabricant u persnnels. Le réenregistrement de ces types pur refléter les arbrescences apprpriées est cnseillé mais pas exigé. Les principes de prpriété et de cntrôle des mdificatins sulignés dans le présent dcument s'appliquent à ces types cmme si ils avaient été enregistrés dans les arbrescences décrites ci-dessus. Appendice B. Changements depuis la RFC 2048 Les prcédures de spécificatin et d'enregistrement de type de supprt nt été retirées de l'ensemble des dcuments MIME pur être placées dans cette spécificatin distincte. Les diverses URL et adresses dans ce dcument nt été changées de telle srte qu'elles se réfèrent tutes à iana.rg plutôt qu'à isi.edu. De plus, beaucup des URL nt été changées de façn à utiliser HTTP, au lieu de FTP. Une grande partie du dcument a été précisée à la lumière de l'expérience du fnctinnement avec ces prcédures. L'arbrescence IETF nn articulée est maintenant appelée l'arbrescence standard, et les règles d'enregistrement pur cette arbrescence nt été assuplies pur permettre sn utilisatin par d'autres rganisatins de nrmalisatin. Le texte qui décrit la prcédure d'enregistrement de type de supprt a été précisé. Les règles et exigences pur la cnstructin des sectins de cnsidératins pur la sécurité nt été étendues et précisées. La RFC 3023 est maintenant référencée cmme surce des infrmatins supplémentaires cncernant l'enregistrement des types de supprts XML. Plusieurs des références dans ce dcument nt été mises à jur pur se référer aux versins actuelles des spécificatins pertinentes. Une nte a été ajutée pur décnseiller l'allcatin de plusieurs nms à un même type de supprt. Les sectins de cnsidératins pur la sécurité et relatives à l'iana nt été ajutées.

14 RFC 4288 page Freed & Klensin Les questins cncernant les drits de reprductin sur les gabarits d'enregistrement de type de supprt prduits par d'autres rganismes de nrmalisatin nt été traitées en exigeant que l'iana sit autrisée à cpier le gabarit d'enregistrement dans le registre. Les exigences de base de l'enregistrement pur les divers types de niveau supérieur nt été déplacées de la RFC 2046 à ce dcument. Une syntaxe est maintenant spécifiée pur les nms de type de supprt, de sus-type, et de paramètres. Une lngueur maximum de 127 est impsée sur tus les nms de types et de sus-types de supprts. Une nte a été ajutée pur prévenir cntre l'utilisatin excessive des cnstructins "+suffixe" dans les nms de sustypes. Le champ Cnsidératins de cdage a été étendu pur permettre la valeur "tramé". Une référence décrivant les cdes de type Macintsh a été ajutée. La révisin des listes de types ietf d'enregistrement dans l'arbrescence standard est maintenant exigée plutôt que seulement recmmandée. Adresse des auteurs Ned Freed Jhn C. Klensin Sun Micrsystems 1770 Massachusetts Ave, # Centrelake Drive, Suite 410 Cambridge, MA Ontari, CA USA USA mél : klensin+ietf@jck.cm téléphne : mél : ned.freed@mrchek.cm Déclaratin cmplète de cpyright Cpyright (C) The Internet Sciety (2006). Le présent dcument est sumis aux drits, licences et restrictins cntenus dans le BCP 78, et à et sauf pur ce qui est mentinné ci-après, les auteurs cnservent tus leurs drits. Le présent dcument et les infrmatins qui y snt cntenues snt furnies sur une base "EN L ÉTAT" et le cntributeur, l rganisatin qu il u elle représente u qui le/la finance (s il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent tutes garanties, exprimées u implicites, y cmpris mais nn limitées à tute garantie que l utilisatin des infrmatins ci enclses ne vilent aucun drit u aucune garantie implicite de cmmercialisatin u d aptitude à un bjet particulier. Prpriété intellectuelle L IETF ne prend pas psitin sur la validité et la prtée de tut drit de prpriété intellectuelle u autres drits qui purraient être revendiqués au titre de la mise en œuvre u l utilisatin de la technlgie décrite dans le présent dcument u sur la mesure dans laquelle tute licence sur de tels drits purrait être u n être pas dispnible ; pas plus qu elle ne prétend avir accmpli aucun effrt pur identifier de tels drits. Les infrmatins sur les prcédures de l ISOC au sujet des drits dans les dcuments de l ISOC figurent dans les BCP 78 et BCP 79. Des cpies des dépôts d IPR faites au secrétariat de l IETF et tutes assurances de dispnibilité de licences, u le résultat de tentatives faites pur btenir une licence u permissin générale d utilisatin de tels drits de prpriété par ceux qui mettent en œuvre u utilisent la présente spécificatin peuvent être btenues sur répertire en ligne des IPR de l IETF à L IETF invite tute partie intéressée à prter sn attentin sur tus cpyrights, licences u applicatins de licence, u autres drits de prpriété qui purraient cuvrir les technlgies qui peuvent être nécessaires pur mettre en œuvre la présente nrme. Prière d adresser les infrmatins à l IETF à ietf- ipr@ietf.rg.

15 RFC 4288 page Freed & Klensin Remerciement Le financement de la fnctin d éditin des RFC est actuellement furni par l activité de sutien administratif (IASA) de l IETF.