4. Exigences d'enregistrement (Registration Requirements)
Tous les enregistrements de types de médias doivent se conformer aux diverses exigences énoncées dans les sections suivantes. Notez que les spécificités des exigences varient parfois en fonction de l'arbre d'enregistrement, comme détaillé dans les sections suivantes.
4.1 Exigence de fonctionnalité
Les types de médias doivent fonctionner comme des formats de médias réels. L'enregistrement de choses qui sont mieux considérées comme un encodage de transfert, comme un jeu de caractères, ou comme une collection d'entités séparées d'un autre type, n'est pas autorisé. Par exemple, bien que des applications existent pour décoder l'encodage de transfert base64 [RFC2045], base64 ne peut pas être enregistré comme type de média.
Cette exigence s'applique quel que soit l'arbre d'enregistrement concerné.
4.2 Exigences de dénomination
Tous les types de médias enregistrés doivent se voir attribuer un type de niveau supérieur et des noms de sous-types. La combinaison de ces noms sert à identifier de manière unique le type de média, et la facette du nom de sous-type (ou son absence) identifie l'arbre d'enregistrement. Les noms de type de niveau supérieur et de sous-type sont insensibles à la casse.
Les noms de types et de sous-types doivent se conformer à l'ABNF suivant :
type-name = restricted-name
subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Les caractères avant le premier point
; spécifient toujours un nom de facette
restricted-name-chars =/ "+" ; Les caractères après le dernier plus
; spécifient toujours un suffixe de syntaxe structurée
4.2.1 Types de médias texte
Le type de niveau supérieur « text » est destiné à l'envoi de matériel principalement textuel.
De nombreux sous-types de text, notamment le sous-type « text/plain », qui est un sous-type générique pour le texte brut défini dans [RFC2046], définissent un paramètre « charset ». Si un paramètre « charset » est défini pour un sous-type particulier de text, il doit être utilisé pour spécifier un nom de jeu de caractères défini conformément aux procédures établies dans [RFC2978].
4.2.2 Types de médias image
Un type de niveau supérieur « image » indique que le contenu spécifie une ou plusieurs images individuelles. Le sous-type nomme le format d'image spécifique.
4.2.3 Types de médias audio
Un type de niveau supérieur « audio » indique que le contenu contient des données audio. Le sous-type nomme le format audio spécifique.
4.2.4 Types de médias vidéo
Un type de niveau supérieur « video » indique que le contenu spécifie une image à variation temporelle, éventuellement avec couleur et son coordonné. Le terme « video » est utilisé dans son sens le plus générique, plutôt qu'en référence à une technologie ou un format particulier.
4.2.5 Types de médias application
Le type de niveau supérieur « application » doit être utilisé pour les données discrètes qui ne correspondent à aucun des autres noms de types, et en particulier pour les données devant être traitées par un type de programme d'application.
4.2.6 Types de médias multipart et message
Multipart et message sont des types composites ; c'est-à-dire qu'ils fournissent un moyen d'encapsuler zéro ou plusieurs objets, chacun étant un type de média distinct.
Tous les sous-types de multipart et message doivent se conformer aux règles de syntaxe et autres exigences spécifiées dans [RFC2046] et modifiées par la section 3.5 de [RFC6532].
4.2.7 Types de niveau supérieur supplémentaires
Dans certains cas, un nouveau type de média peut ne pas « correspondre » à l'un des noms de types de niveau supérieur actuellement définis. De tels cas devraient être assez rares. Cependant, si un tel cas se présente, un nouveau nom de type peut être défini pour l'accommoder. La définition d'un nouveau nom de type de niveau supérieur doit être effectuée via une RFC Standards Track ; aucun autre mécanisme ne peut être utilisé pour définir des noms de types supplémentaires.
4.2.8 Suffixes de noms de syntaxe structurée
Les types de médias qui utilisent une syntaxe structurée nommée devraient utiliser le « +suffixe » enregistré approprié pour cette syntaxe structurée lorsqu'ils sont enregistrés. De même, les types de médias ne doivent pas recevoir de noms incorporant des suffixes pour des syntaxes structurées qu'ils n'emploient pas réellement.
4.2.9 Alias obsolètes
Dans certains cas, un seul type de média peut avoir été largement déployé avant l'enregistrement sous plusieurs noms. Dans de tels cas, un nom préféré doit être choisi pour le type de média, et les applications doivent l'utiliser pour être conformes à l'enregistrement du type.
4.3 Exigences relatives aux paramètres
Les types de médias peuvent choisir d'utiliser un ou plusieurs paramètres de type de média, ou certains paramètres peuvent être automatiquement mis à disposition du type de média en vertu d'être un sous-type d'un type de contenu qui définit un ensemble de paramètres applicables à l'un de ses sous-types.
Les noms de paramètres ont la syntaxe des noms et valeurs de types de médias :
parameter-name = restricted-name
Les noms de paramètres sont insensibles à la casse et aucune signification n'est attachée à l'ordre dans lequel ils apparaissent. C'est une erreur qu'un paramètre spécifique soit spécifié plus d'une fois.
4.4 Exigences de canonisation et de format
Tous les types de médias enregistrés doivent employer un seul format d'encodage canonique.
4.5 Recommandations d'échange
Les types de médias devraient inclure des recommandations sur la meilleure façon d'accomplir l'échange entre systèmes hétérogènes.
4.6 Exigences de sécurité
Une analyse des problèmes de sécurité doit être effectuée pour tous les enregistrements. Tous les enregistrements de types de médias doivent inclure une section « Considérations de sécurité » détaillant les implications de sécurité du type de média.
4.7 Exigences spécifiques aux types de médias XML
Les types de médias qui utilisent XML doivent se conformer aux exigences spécifiées dans [RFC7303].
4.8 Exigences d'encodage
Les enregistrements de types de médias doivent spécifier clairement comment le type doit être encodé pour une utilisation avec divers protocoles de transport.
4.9 Non-exigences d'utilisation et d'implémentation
L'enregistrement d'un type de média n'implique aucune approbation d'une implémentation particulière.
4.10 Exigences de publication
Les enregistrements d'arbres de standards pour les types de médias largement déployés devraient être publiés en tant que RFC.
4.11 Exigences relatives aux identificateurs de fragment
Les types de médias qui utilisent des identificateurs de fragment doivent documenter quelle syntaxe d'identificateur de fragment est prise en charge.
4.12 Informations supplémentaires
Le modèle d'enregistrement de type de média comprend un certain nombre de champs d'informations supplémentaires.