Groupe de travail Réseau	D. Zigmond, WebTV Networks, Inc.
Request for Comments : 2838	M. Vickers, Liberate Technologies, Inc.
Catégorie : Information	mai 2000
Traduction Claude Brière de L'Isle

Identifiants de ressource uniformes pour les diffusions télévisuelles

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright 
Copyright (C) The Internet Society (2000). Tous droits réservés.

 	1.	Introduction

Les navigateurs de la Toile mondiale commencent à apparaître sur divers appareils électroniques grand public, comme des appareils de télévision et des boîtiers de médiation de télévision, qui sont capables de recevoir des programmes de télévision à partir de diffusion terrestre, par satellite, ou par câble. Dans ce contexte il y a un besoin de référence à la diffusion télévisuelle en utilisant le format d'URI décrit dans la [RFC2396]. Le présent document décrit un schéma d'URI largement mis en œuvre pour se référer à de telles diffusions.

 	2.	URI de télévision

La structure de base d'un URI de télévision est :

tv:<broadcast>

où "broadcast" est une description de la source des données. La description prend la forme d'un identifiant de style DNS pour un diffuseur ou réseau de télévision particulier. Par exemple :

tv:wqed.org	la station WQED
tv:nbc.com	le réseau NBC

 	3.1	Forme de schéma seul
La forme la plus simple du schéma d'URI "tv:" est utilisée pour se référer au canal "courant" ou "par défaut" :

tv:

Cet URI se réfère à toute diffusion télévisuelle qui est actuellement reçue par l'appareil. Il est souvent utilisé combiné avec le contenu HTML qui est en fait diffusé avec l'audio et la vidéo, où la signification de "diffusion actuelle" est sans ambiguïté (parce que c'est la diffusion sur laquelle le contenu qui contient l'URI a été reçu). C'est en fait l'usage de plus courant du schéma "tv:" aujourd'hui, et il est explicitement référencé par la publication récente de la spécification du forum d'amélioration de la télévision évoluée (Advanced Television Enhancement Forum) [ATVEF 1.1].

 	3.2	Identifiants de style DNS
Les diffusions télévisuelles ont traditionnellement été identifiées de diverses façons. Tous les diffuseurs de télévision terrestre ont reçu des signaux d'appel (comme "KDKA" ou "WQED") pour identifier leur signal. Ils sont généralement alloués par des autorités nationales (comme la Commission fédérale des communications aux États-Unis d'Amérique) et sont uniques au monde. L'espace de noms mondial est géré par l'Union Internationale des Télécommunications qui en alloue des portions aux pays membres (voir [UIT RR]).

De nombreux réseaux de télévision modernes ne sont pas diffusés sur les ondes, mais sont disponibles seulement par un abonnement au câble ou par satellite. Les identifiants de ces réseaux (comme les "CNN" et "HBO" familiers) ne sont pas régulés pour le moment. Dans certains pays, même les diffuseurs hertziens utilisent ces sortes d'identifiants, plutôt que les signaux d'appel.

Malheureusement, ces deux espaces de noms se chevauchent, la plupart des identifiants de réseau étant aussi des signaux d'appel valides. De plus, les identifiants de réseau ne sont pas uniques au monde, et il existe de nombreux cas de collisions de noms. (Par exemple, la "Australian Broadcast Corporation" et la "American Broadcasting Company" s'identifient comme "ABC".) Afin d'assurer l'unicité, le schéma "tv:" utilise des identifiants de style DNS pour tous les flux de diffusion. Parce que cela s'appuie sur le système existant d'enregistrement des noms d'hôte pour le DNS, toutes les collisions de noms peuvent être résolues par les processus existants de résolution de conflit du DNS.

Dans la forme la plus simple, les noms de domaines eux-mêmes sont utilisés conne identifiants de diffusion. Par exemple :

tv:abc.com : American Broadcast Company
tv:abc.co.au : Australian Broadcast Corporation

Dans certains cas, les réseaux ont plusieurs flux de diffusion qui doivent être distingués. Cela est aussi traité dans le style du DNS :

tv:east.hbo.com : HBO East
tv:west.hbo.com : HBO West

Il est important de noter que ces identifiants de style DNS n'ont pas besoin de correspondre à des noms d'hôte réels ; ils ne devraient pas être résolus en adresses IP qui utilisent le DNS. Donc, en utilisant les termes définis dans la RFC 2396, le schéma "tv:" est un identifiant de ressource universel et non un localisateur de ressource universel.

Afin de prendre en charge ces identifiants dans un URI "tv:", un receveur doit mettre en œuvre un moyen de transposer les identifiants connus en fréquences. La nature de cette transposition et la façon dont elle est utilisée sont actuellement spécifiques du navigateur et de l'appareil et sortent du domaine d'application de ce document. De cette façon, le schéma "tv:" est un peu analogue aux schémas "news:" et "file:" dans la [RFC2396] : il désigne simplement un signal de diffusion de télévision mais suppose que le navigateur local a des moyens pour restituer effectivement ce signal sur l’appareil local. Divers systèmes logiciels fournissent actuellement les transpositions spécifiques de l'appareil pour de tels identifiants en numéros de canaux spécifiques ou directement en fréquences. Ces systèmes peuvent être incorporés dans les appareils de télévision ou les boîtiers de médiation pour faciliter l'interprétation des URI de télévision par l'appareil client.

 	3.3	Formes obsolètes
Les projets antérieurs de la présente spécification permettaient que les diffusions soient identifiées par des numéros de canal, comme "tv:4", et cette forme est actuellement prise en charge par plusieurs plates-formes indépendantes. Les numéros de canaux correspondent généralement à des fréquences de réglage dans les diverses normes nationales de fréquences de diffusion ; par exemple, "tv:4" aux États-Unis va se trouver sur 66 MHz. Cependant, parce que cette transposition de numéro de canal en fréquences varie d'un pays à l'autre, cette forme est particulièrement mal adaptée à l'usage sur l'Internet.

Les projets précédents permettaient aussi que les identifiants de réseau et les signaux d'appel soient utilisés directement comme identifiants de diffusion, comme dans "tv:abc" et "tv:kron". Ces formes ne devraient pas être utilisées à cause des problèmes de collision de noms décrits au paragraphe précédent.

 	4.	BNF pour les URI Television

Voici une spécification formelle pour les nouveaux URI :

tvuri  =          "tv:" [ broadcast ]
broadcast = dns-identifier
dns-identifier = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum

Les définitions de alpha et alphanum sont dans la [RFC 2396]. De plus, la définition de dns-identifier est identique à la définition de hostname dans la RFC 2396, et est insensible à la casse.

 	5.	Remerciements

Beaucoup des idées de ce document viennent de conversations avec Andrew Lochart. D'autre personnes ont fourni des apports précieux dont Matt Trifiro et Eric Del Sesto. Le projet original de ce schéma d'URI a été développé alors que l'auteur était employé par Wink Communications. Les plus récentes suggestions ont été faites par Lee Acton, Jonathan Boltax, Dean Blackketter, Michael Dolan, Iain Hackett, Jim Helman, Sean McDowell, David Mott, Scott Watson, et d'autres dans le groupe de travail ATVEF (que les auteurs co-présidaient) et de Craig Finseth, Gomer Thomas, Harald Alvestrand, et Larry Masinter.

 	6.	Considérations sur la sécurité

Ce nouveau schéma d'URI est soumis aux mêmes implications pour la sécurité que le schéma général d'URI décrit dans la [RFC2396]. Il est possible que le simple acte de voir un signal de diffusion de télévision puisse causer des coûts pour le spectateur dans certaines instances (par exemple, les films et événements "à péage"). Tout logiciel qui utilise ce schéma d'URI pour permettre un réglage automatique d'un appareil client sur un signal particulier de diffusion de télévision devrait alerter les utilisateurs avant d'effectuer des actions qui peuvent impliquer des coûts pour l'utilisateur.

 	7.	Références

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

[ATVEF 1.1]	Advanced Television Enhancement Forum, "Advanced Television Enhancement Forum Specification Version 1.1r26," février 1999. http://www.atvef.com/library/spec1_1a.html 

[UIT RR]	Union Internationale des Télécommunications, "Règlement des radiocommunications," 1998. Voir en particulier l'Article S19, "Identification des stations," et l'Appendice 42, "Tableau d'attribution des séries internationales d'indication d'appel."

 	9.	Adresse des auteurs

Dan Zigmond	Mark Vickers	
WebTV Networks, Inc.	Liberate Technologies	
1065 La Avenida	2 Circle Star Way	
Mountain View, CA 94043	San Carlos, CA  94070	
USA	USA	
mél : djz@corp.webtv.net 	mél : mav@liberate.com 	

 	10.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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 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.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.