Mon blog

Ce court RFC documente les types « MIME » (RFC 2045) à utiliser pour le format de fichiers multimédia Ogg, changeant sérieusement les anciens types du RFC 3534.

Dans un monde du multimédia dominé par des formats fermés comme WMF ou partiellement ouverts comme Flash (sans compter les innombrables et futiles brevets sur ces formats), Ogg, format maintenu par la fondation Xiph et décrit dans le RFC 3533, reste le principal format ouvert. Comme beaucoup de formats multimédia (par exemple AVI), Ogg ne permet que de créer des containers, des ensembles de flux de données, dont chacun a son propre format. Ainsi, un film stocké dans un container Ogg contiendra en général deux flux, un vidéo (typiquement au format Theora) pour l'image et un audio (typiquement au format Vorbis) pour le son. D'autres containers Ogg peuvent contenir plus de deux flux de données temporelles.

Cette façon de stocker les données complique un peu la définition d'un type de données pour étiqueter les containers Ogg, lorsqu'ils sont distribués par courrier électronique ou bien envoyés via le protocole HTTP. Le RFC originel, le RFC 3534, définissait un type unique, application/ogg. Le problème était qu'un container Ogg ne contenant que du son au format Vorbis se trouvait étiqueté avec le type très général application/ alors que le type audio/ aurait certainement mieux convenu. Notre RFC introduit donc deux nouveaux sous-types de video/ et audio/, soit video/ogg et audio/ogg, et redéfinit le type application/ogg.

La section 2 du RFC rappelle les changements depuis le RFC 3534, la principale étant ces deux nouveaux types.

La section 4 décrit les problèmes de compatibilité qui pourraient surgir avec les anciennes applications. Elle pose le principe que du contenu purement audio devrait être marqué avec le nouveau type audio/ogg (même chose pour la vidéo), réservant l'usage de application/ogg aux contenus plus complexes (par exemple dans le secteur scientifique, où ils sont plus fréquents que dans le monde du multimédia). Pour ces contenus, notre RFC impose l'extension Ogg Skeleton pour identifier les différents flux contenus. Elle décrit aussi l'utilisation du paramètre codecs qui permet de préciser le format des flux inclus, et donc le codec à utiliser. Ainsi, un flux Speex dans un fichier Ogg pourra être identifié par audio/ogg; codecs=speex. La section 5 du RFC précise davantage les relations entre les trois types désormais normalisés, du plus général, application/ogg au plus spécifique, audio/ogg.

La section 10 contient la « paperasse » nécessaire à l'enregistrement des trois types dans le registre IANA des types. La section 10.1 enregistre application/ogg, recommandant l'extension de fichier .ogx (.ogg étant souvent utilisé uniquement pour l'audio).

10.2 définit video/ogg (extension .ogv) et 10.3 audio/ogg, qui garde l'extension « historique » .ogg.

Ogg dispose d'une mise en œuvre de référence, sous une licence libre, la libogg (section 8 du RFC, sur l'interopérabilité).

Notons enfin une section 7 du RFC consacrée à la sécurité et qui donne quelques avertissements utiles : si Ogg en lui-même n'est qu'un format et ne pose pas de problème de sécurité en soi, certains contenus d'un fichier Ogg peuvent être exécutables et poser alors de redoutables problèmes de sécurité comme l'ont montré les nombreuses alertes de sécurité qui concernaient Flash. Ces contenus ne devraient pas être exécutés sans une validation (par exemple une signature électronique, service non fourni actuellement par Ogg lui-même mais qui peut être utilisé sur les flux transportés dans un container).

D'autre part, les contenus multimédia sont souvent de grande taille et des attaques par déni de service indirect sont toujours possibles, par exemple en envoyant une image qui, après décompression, sera ridiculement grande, ou un flux audio avec un rythme d'échantillonage impossible à suivre. Les programmes qui lisent les fichiers multimédia doivent donc être prudents.