Network Working Group I. Keesmaat Internet Draft O. van Deventer Expires: December 2007 TNO June 20, 2007 Registry for tv:URIs draft-keesmaat-tvreg-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 20, 2007. Comments are solicited and should be addressed to the Application Area's mailing list at discuss@apps.ietf.org and/or the author(s). Abstract The tv:URI is an existing Uniform Resource Identifier (URI) scheme to refer to television broadcasts. These include all types of analog and digital television broadcasts, like terrestrial TV broadcasts, satellite TV broadcasts, cable TV broadcast, IP television and web TV. Keesmaat Expires December 20, 2007 [Page 1] Internet-Draft Registry for tv:URIs June 2007 This document defines a registry for tv:URIs. A registry is needed to solve the ambiguity about tv:URIs in two directions: for each (registered) tv:URI it identifies uniquely and unambiguously the television broadcast it refers to, and vice versa it provides a single tv:URI for each (registered) television broadcast. Table of Contents 1. Introduction...................................................3 1.1. Use cases for television broadcast identifiers............3 1.1.1. Clickable link to a television broadcast.............4 1.1.2. Presence: see what your buddies are watching.........4 1.1.3. Scheduling of tv broadcast in relation to personal calendars...................................................5 2. Need for a registry for tv:URIs................................5 2.1. Ambiguity problems of tv:URIs.............................5 2.2. Solutions to reduce ambiguity.............................6 2.2.1. Stricter rules for the definition of tv:URIs.........6 2.2.2. Association of tv:URIs with websites.................7 2.2.3. Creation of a registry for tv:URIs...................7 3. Organization of the registry for tv:URIs.......................8 4. Structure of the tv:URI registry...............................8 5. Processes to handle tv:URI registrations.......................9 5.1. Creation of tv:URI registrations..........................9 5.2. Reading of tv:URI registrations...........................9 5.3. Updates of tv:URI registrations..........................10 5.4. Deletion of tv:URI registrations.........................10 6. Rules for the registration of a new tv:URI....................10 7. Procedures for dispute resolution of claiming a tv:URI........11 8. Relation with existing registries.............................11 8.1. Relation with the Domain Name System.....................11 8.2. Relation with the ShowView/VideoPlus+ system.............11 9. Security Considerations.......................................12 10. IANA Considerations..........................................12 11. Acknowledgments..............................................12 12. References...................................................12 Author's Addresses...............................................13 Intellectual Property Statement..................................13 Disclaimer of Validity...........................................13 Copyright Statement..............................................14 Acknowledgment...................................................14 Keesmaat Expires December 20, 2007 [Page 2] Internet-Draft Registry for tv:URIs June 2007 1. Introduction World-Wide Web browsers, Electronic Program Guide applications, Instant-Messaging clients and Presence functionality are starting to appear on a variety of consumer electronic devices, such as television sets, television set-top boxes and mobile devices capable of receiving television broadcasts. In this respect television broadcasts refers to all forms of analog and digital television broadcasts, such as terrestrial TV broadcasts, satellite TV broadcasts, cable TV broadcasts, IP television and web TV. In the wake of these new types of TV applications a need arises to be able to communicate to others about television broadcasts and as a consequence to be able to have a means of unambiguously referring to such television broadcasts. In [RFC2838] the syntax and semantics of tv:URIs is defined. A tv:URI consists of an identifier part in the form of a domain name, and it identifies a television broadcast. It is, however, not intended for tv:URIs to be resolvable by the internet Domain Name System [RFC1034]. Examples given in [RFC2838] are: o tv:wqed.org the WQED station o tv:nbc.com the NBC network o tv:abc.com the American Broadcast Company o tv:abc.co.au the Australian Broadcast Corporation o tv:east.hbo.com HBO East o tv:west.hbo.com HBO West 1.1. Use cases for television broadcast identifiers In general there is a need for identifiers referring to TV broadcasts in all situations where communication (via some type of messages or textual content) is taking place and in this communication the sender wants to refer the receiver to a particular TV broadcast. The following diagram illustrates this. Keesmaat Expires December 20, 2007 [Page 3] Internet-Draft Registry for tv:URIs June 2007 +---------------------->--------------------+ | Message containing: | ^ TV broadcast identifier | | ^ : V +----------------+ : : +----------------+ | Communication | : : | Communication | | Sender | (1) (2) | Receiver | | | : : | | | +------------+ | : : | +------------+ | | |TV broadcast|...../ \....>|TV broadcast| | +-+------------+-+ +-+------------+-+ Figure 1: Communication entities referring to TV broadcasts Note that in general there will be a mapping - by the sender - from a particular TV broadcast to the TV broadcast identifier used in the message (marked by (1) in the diagram) and a mapping - by the receiver - from the received TV broadcast identifier to the correct TV broadcast (marked by (2) in the diagram). Examples of such communication use cases are given in the next sections. 1.1.1. Clickable link to a television broadcast One application is clickable links to television broadcasts. Web pages, instant messages and emails may contain such links. If you clicked on such a link on a sufficiently equipped and configured device, you would view the identified television broadcast. This application may be used to send and receive television watching tips. Note that clicking on a tv:URI might also result in a pull-down menu with various options what to do. 1.1.2. Presence: see what your buddies are watching Another application is presence. By using the television broadcast identification in presence applications, you can see what programs your buddies are watching. With a single click (see previous example) you can follow the channel switching of a specific buddy. Currently the issue of presence in relation to IPTV has gained considerable attention in standardization bodies such as ETSI. For instance: Keesmaat Expires December 20, 2007 [Page 4] Internet-Draft Registry for tv:URIs June 2007 o ETSI TISPAN work item 1044, Section 6.2.1.1 states: "It must be possible to define presence information related to the IPTV experience, e.g. channel currently accessed.". o ETSI TISPAN work item 2048, Section 9.2, titled "Presence attributes for IPTV", states: "The following specific IPTV attributes may also be supported: channel currently accessed, ...". 1.1.3. Scheduling of tv broadcast in relation to personal calendars It is possible to combine tv:URIs with iCalendar applications. In that way people can integrate what shows they want to watch with their personal calendars. 2. Need for a registry for tv:URIs There does not (yet) exist a registry for tv:URIs. This means that the allocation of a tv:URI is essentially a mechanism of "guess the URI" in case of finding the appropriate tv:URI for a given television broadcast and a "guess the television broadcast" for a given tv:URI. 2.1. Ambiguity problems of tv:URIs Two types of ambiguities can occur in the use of tv:URIs: 1. Finding ambiguity There may be multiple tv:URIs referring to one and the same television broadcast. For example, one person might choose tv:abc.co.au for the Australian Broadcast Corporation (as has been suggested in [RFC2838]). Another person might choose to use tv:abc.net.au to refer to the same television broadcast ('because' http://abc.net.au point to the website of this broadcast). Note that this relates to mapping (1) in Figure 1. 2. Identification ambiguity A single tv:URI might refer to two different television broadcasts. This is the original reason given in [RFC2838] for choosing a domain name structure for tv:URIs. The illustrative example here is "abc", which could refer to the American Broadcast Company or Australian Broadcast Corporation. Note that this relates to mapping (2) in Figure 1. Keesmaat Expires December 20, 2007 [Page 5] Internet-Draft Registry for tv:URIs June 2007 In both cases, the ambiguity would lead to some difficulties when using tv:URIs, but the second type of ambiguity would cause the most problems. In case of finding ambiguity, someone wanting to get at the television broadcast pointed at (supposedly) by a tv:URI might be referred to a television broadcast unknown to his application/device. After having identified the proper broadcast, he can configure this in his application/device for future use. In case of identification ambiguity, someone wanting to get at the television broadcast pointed at by a tv:URI will have a choice of broadcasts. Since one source of the same tv:URI might point at a different broadcast as another source, he can never configure his application/device to always point at the right television broadcast. 2.2. Solutions to reduce ambiguity Ambiguity (especially identification ambiguity) can be reduced (but maybe not resolved) in different ways. 2.2.1. Stricter rules for the definition of tv:URIs One approach to reduce the ambiguity problem would be to provide stricter rules for the definition of tv:URIs. Basically [RFC2838] already provided some of such rules to reduce ambiguity. o Television-broadcast name collisions over multiple countries are solved by adding DNS-style top-level domains. For example tv:abc.com versus tv:abc.co.au. o Ambiguity over time-zone dependent transmissions are resolved with a time-zone indication. Example: tv:east.hbo.com versus tv:west.hob.com. Additional rules could be formulated to reduce ambiguity even more. For example: o Rules for numbers in the name of a television broadcast. Example: bbcone versus bbc1. o Rules for stations with multiple television broadcasts. Example: family.hbo.com versus hbofamily.com o Rules for (European) public broadcast stations that share one or multiple television broadcast channels. Example: nederland1.nl versus avro.nl. Keesmaat Expires December 20, 2007 [Page 6] Internet-Draft Registry for tv:URIs June 2007 Each new rule would reduce ambiguity a bit more, but it would not prevent ambiguity altogether. 2.2.2. Association of tv:URIs with websites Another approach to reduce the ambiguity problem would be to associate tv:URI's with web pages. If http://example.com is the official web page of the Example.com television broadcast station, then tv:example.com would be the tv:URI of that television broadcast. Just replace "http://" by "tv:". This approach has several problems. o Not every television broadcast has its own website. In case of local television station, there may not be an "official" website at all. There are also cases, where multiple television broadcasts share a single website, for example in time-zone dependent broadcasts. o Some television broadcasts have multiple websites. There may for example be different websites for different languages. Also, web pages often redirect to other web pages. o Web pages change regularly. Television stations may e.g. decide to replace a convoluted subdomain web page naming structure by better looking second-level domain names. Also ownership changes regularly leading to changes in the naming of websites. o Web page syntax includes paths (starting with '/') whereas the tv:URI only uses clean DNS-style identifiers in its syntax. An example is the website of the Dutch National Geographic Channel, which has as its 'official' website http://www.nationalgeographic.nl/channel. So associating tv:URIs to web pages would change the syntax of tv:URIs. Hence, this approach would require a change in tv:URI syntax while at the same time not be able to solve every ambiguity. 2.2.3. Creation of a registry for tv:URIs The only solution to 100% eliminate all ambiguity in the use of tv:URI's is the creation of a registry. This registry would make sure that any television broadcast can be registered and that: 1. a registered television broadcast is uniquely identified by a tv:URI. Keesmaat Expires December 20, 2007 [Page 7] Internet-Draft Registry for tv:URIs June 2007 2. a registered tv:URI uniquely identifies a television broadcast. 3. Organization of the registry for tv:URIs The registry shall be the responsibility of a single organization. It is possible that part of the effort in maintaining the registry is delegated to other (e.g. local) organizations. In this respect a division in terms of registry and registrars similar to that for domain names might be advisable in order to be able to handle the often localized nature of television broadcasts. 4. Structure of the tv:URI registry The tv:URI registry is a single list of registrations where each registration consist of: o a television broadcast identifier, and o an identification record. The television broadcast identifier will be a tv:URI following the syntax described in [RFC2838]. It is this tv:URI that the registration is registering. No two registrations shall have identical tv:URIs. As tv:URIs are case-insensitive two tv:URIs are considered identical if they are the same modulo case-change. The identification record associated with a particular tv:URI contains the following fields: o The name of the television broadcast. o (Optionally) The name of company or person that is the holder/owner of the television broadcast. o (Optionally) The "official" website(s) of the television broadcast. o (Optionally) The language(s) of the television broadcast. o (Optionally) The nationality(ies) of the television broadcast. o (Optionally) The reach of the television broadcast, geographic or otherwise. o (Optionally) Other useful identifying information. Keesmaat Expires December 20, 2007 [Page 8] Internet-Draft Registry for tv:URIs June 2007 5. Processes to handle tv:URI registrations This section describes the processes to create, read, update and delete ("CRUD") tv:URI registrations. A process of "nomination" is used for creation, updating and deletion of tv:URI registrations. A registration does not have a registrant in the traditional sense of [RFC3375], but it has a "nominator". This nominator can be a natural person, but it can also be on behalf of an organization. The reason to use a process of nomination by any person or organization instead of direct registration by the owner of the television broadcast is to be independent of this owner for the creation of new innovative television-based services as described in Section 1.1. . The owner of the television broadcast does have a say in the registration, however. This is explained in Section 7. . 5.1. Creation of tv:URI registrations When it is noticed that a new television broadcast has come into existence, then it can be nominated for assignment of a tv:URI. The nominator has to provide evidence that the television broadcast actually exists and that it has not been registered yet. The nominator has to motivate the proposed new tv:URI for the television broadcast. Moreover, the nominator has to provide sufficient amounts of identifying information on the television broadcast for inclusion in the registry. Once a television broadcast has been nominated for inclusion, the registry will check whether the proposed registration would satisfy the rules for the registration of tv:URIs. These rules are given in Section 6. of this document. If the proposed registration satisfies the rules, then the registration is created. 5.2. Reading of tv:URI registrations The tv:URI registry will be a public registry. The list of tv:URIs and associated identification records, as described in Section 4. , will be published on a public website. That website may have search functionality to find tv:URIs based on identifying information and vice versa. Keesmaat Expires December 20, 2007 [Page 9] Internet-Draft Registry for tv:URIs June 2007 5.3. Updates of tv:URI registrations Identifying information of a television broadcast may change over time. For instance, the television broadcast may have changed website or its geographic reach may have changed. Again, a nominator may indicate that the identifying information associated with a particular television broadcast needs to be changed. Again, the registry will check whether the proposed update would satisfy the rules given in Section 6. of this document. If the proposed update satisfies the rules, then the registration is updated. 5.4. Deletion of tv:URI registrations Television broadcasts may cease to exist, e.g. due to bankruptcy of its owner. Again, a nominator may nominate the tv:URI for deletion. And again the registry will make the check and consequently delete the tv:URI registration. 6. Rules for the registration of a new tv:URI A new tv:URI shall satisfy the following rules in order to be suitable for registration in the tv:URI registry 1. A tv:URI should identify a television broadcast, i.e. - it should be television. That is, the content has combined audio and video components. This would include world-wide, national and local television stations, but it would exclude radio broadcast and silent webcam transmissions. - it should be broadcast. That is, the content can be received by multiple television watchers in real-time. This includes all types of analog and digital television broadcasts, like terrestrial broadcasts, satellite broadcasts, cable broadcast, IP television and web TV. A broadcast does not to be available 24 hours per day, 7 days in a week, to be allowed for registration. It would exclude recorded video content and video phone communication. Keesmaat Expires December 20, 2007 [Page 10] Internet-Draft Registry for tv:URIs June 2007 2. The new registration should not duplicate an existing registration, i.e. it should not refer to the same television broadcast as one that has already been registered. Time-zone dependent television broadcasts are considered different broadcasts in this document (as in [RFC2838]). For instance tv:west.hbo.com versus tv:east.hbo.com. 3. The registration should not violate any trademark law. Such a violation could occur if the owner of a DNS domain name objects to reusing that domain name for a tv:URI registration. 7. Procedures for dispute resolution of claiming a tv:URI Disputes may occur on conflicting registrations for tv:URI's, in the sense that two nominees may want to use the same tv:URI for different television broadcasts (similar to the conflicts about domain names). In such cases, the registry will consult the owner of the television broadcast and ask for advice. If the owner of the broadcast has a clear preference, then the registry will follow this preference. If the owner cannot be reached, or the owner has no opinion, then the registry will make a decision itself. If the dispute is about the ownership of a domain name, which is used in a tv:URI, then the DNS system (whois database) is used for guidance. Ultimately, suspected trademark violations may be challenged in court. 8. Relation with existing registries 8.1. Relation with the Domain Name System The tv:URI has no direct relationship with the internet Domain Name System. tv:URIs are not resolvable by the domain name system, 8.2. Relation with the ShowView/VideoPlus+ system ShowView/VideoPlus+ is a proprietary system that identifies television broadcasts for the purpose of programming video recorders [ShwVw]. Showview/VideoPlus+ is mainly used in Europe and showview numbers are only nationally significant. The registration of a tv:URI may contain references to ShowView/VideoPlus+ numbers in the identification record. Showview/VideoPlus+ numbers shall not be incorporated in a tv:URI itself. Keesmaat Expires December 20, 2007 [Page 11] Internet-Draft Registry for tv:URIs June 2007 9. Security Considerations As any person or organization can nominate a television broadcast for inclusion in, update of, or deletion from the tv:URI registry, there are no specific security considerations in the nomination process. The registry itself and the website showing the registrations should be protected again unauthorized modifications. The only authorized modifications are those authorized by the registry itself. 10. IANA Considerations This document does not have IANA considerations. Note that the tv:URI scheme itself needs to be registered by IANA, but that this document is concerned about registration of tv:URI values, not about the registration of the tv:URI scheme itself. 11. Acknowledgments The authors thank the following persons for critical comments and useful remarks: Dan Zigmond, Keith Moore, Tim Bray, Lisa Dusseault, Cullen Jennings, Eliot Lear, Mark Baker and John Klensin. 12. References 12.1. Normative references [RFC2838] D. Zigmond and M. Vickers, "Uniform Resource Identifiers for Television Broadcasts", RFC 2838, May 2000. 12.2. Informative references [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987. [RFC3375] S. Hollenbeck, "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002. [ShwVw] ShowView/VideoPlus+, www.showview.com. Keesmaat Expires December 20, 2007 [Page 12] Internet-Draft Registry for tv:URIs June 2007 Author's Addresses Iko Keesmaat TNO P.O. Box 5050, 2600 GB Delft, Netherlands Phone: +31 6 519 161 91 Email: iko.keesmaat@tno.nl Oskar van Deventer TNO P.O. Box 5050, 2600 GB Delft, Netherlands Phone: +31 651 914 918 Email: oskar.vandeventer@tno.nl Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND Keesmaat Expires December 20, 2007 [Page 13] Internet-Draft Registry for tv:URIs June 2007 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Keesmaat Expires December 20, 2007 [Page 14]