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]