summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4078.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4078.txt')
-rw-r--r--doc/rfc/rfc4078.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc4078.txt b/doc/rfc/rfc4078.txt
new file mode 100644
index 0000000..86951db
--- /dev/null
+++ b/doc/rfc/rfc4078.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group N. Earnshaw
+Request for Comments: 4078 BBC Research and Development
+Category: Informational S. Aoki
+ TokyoFM Broadcasting
+ A. Ashley
+ NDS Limited
+ W. Kameyama
+ GITS, Waseda University
+ May 2005
+
+
+ The TV-Anytime Content Reference Identifier (CRID)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ The Uniform Resource Locator (URL) scheme "CRID:" has been devised to
+ allow references to current or future scheduled publications of
+ broadcast media content over television distribution platforms and
+ the Internet.
+
+ The initial intended application is as an embedded link within
+ scheduled programme description metadata that can be used by the home
+ user or agent to associate a programme selection with the
+ corresponding programme location information for subsequent automatic
+ acquisition.
+
+ This document reproduces the TV-Anytime CRID definition found in the
+ TV-Anytime content referencing specification, and is published as an
+ RFC for ease of access and registration with the Internet Assigned
+ Numbers Authority (IANA).
+
+
+
+
+
+
+
+
+
+
+
+Earnshaw, et al. Informational [Page 1]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Ancestry ........................................................3
+ 3. Notation Used in This Document ..................................3
+ 4. The CRID URL Scheme .............................................3
+ 5. Examples of CRID Syntax .........................................4
+ 6. Usage ...........................................................4
+ 6.1. Normative Specification ....................................4
+ 6.2. Role of Domain Name System (DNS) Namespace .................5
+ 6.3. CRID Resolving .............................................5
+ 6.4. CRID Related Metadata ......................................5
+ 7. IANA Considerations .............................................6
+ 7.1. General ....................................................6
+ 7.2. Registration Template in Accordance with RFC 2717 ..........6
+ 8. Security Considerations .........................................7
+ 9. Acknowledgements ................................................7
+ 10. References .....................................................8
+ 10.1. Normative References .....................................8
+ 10.2. Informative References ...................................8
+
+1. Introduction
+
+ In recent years there has been an expansion in the number of
+ broadcast television and radio services available to the home. In
+ addition to the broadcast services delivered over traditional
+ distribution channels such as Digital Terrestrial, Satellite and
+ Cable, the advent of high-speed Internet connection will give rise to
+ even more information and entertainment services, providing audio-
+ visual programme material sourced directly to the home over the
+ Internet.
+
+ Alongside this expansion there has also been increased growth in
+ complexity of devices available to the home user, which will allow
+ the user to operate in a 'search-select-acquire' paradigm. In this
+ model, the user or user agent uses descriptive information about
+ audio visual programmes as a basis for selecting the programme for
+ subsequent acquisition and viewing. Increasingly, home appliances
+ are being furnished with local storage, enabling the automatic
+ capture of programme material through off-air recording or
+ downloading by a home appliance.
+
+ The 'CRID:' Uniform Resource Locator is designed to be the bridge
+ between programme-related descriptive metadata and corresponding
+ programme location data that may be published over a different
+ distribution network or at a different time.
+
+
+
+
+
+Earnshaw, et al. Informational [Page 2]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+ Programme location data provides the home user agent with the
+ information required to acquire the programme at the time of
+ publication. In the case of the television distribution model, these
+ locators provide programme broadcast timing and tuning information so
+ that the user appliance can record the programme when it is broadcast
+ in real time. In the case of Internet delivery, the locators have to
+ be of the form associated with streaming protocols or file exchange
+ protocols with the time (or time window) of availability indicated.
+
+ Because a content publisher may release audio-video material in the
+ same form on a number of platforms or repeatedly over some time
+ interval, the CRID can be used to aggregate these different
+ publications and associate them with a single description.
+ Furthermore, there may be other meaningful semantic associations
+ between otherwise unrelated programme publications with assigned CRID
+ that can be further aggregated under a higher-level CRID. This
+ higher-level CRID can be described through its own descriptive
+ metadata. The subjective nature of these aggregation decisions is
+ part of the CRID authoring process and is not standardised.
+
+ The CRID resolution process ultimately enabling the user agent to
+ acquire audio-visual programme material may be a timely process, with
+ resolution updates delivered dynamically from the service provider.
+ This is to reflect common business practice of adjusting the time of
+ content availability close to the original published time to
+ accommodate a live, managed, reactive broadcast service.
+
+2. Ancestry
+
+ The Uniform Resource Locator scheme 'CRID:' is taken from the
+ TV-Anytime forum Content Reference Identifier and is a result of the
+ consensus reached by members of this forum between March 2000 and
+ June 2002. The TV-Anytime CRID and associated supporting data is
+ specified in the TV-Anytime Phase 1 Content Referencing Specification
+ [TVA-CR].
+
+3. Notation Used in This Document
+
+ The notation used in this document takes the form
+
+ <first>/<second>
+
+ in which the component names are in angle brackets and any characters
+ outside angle brackets are literal separators.
+
+
+
+
+
+
+
+Earnshaw, et al. Informational [Page 3]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+4. The CRID URL Scheme
+
+ The CRID URL takes the form
+
+ crid://<DNS name>/<data>
+
+ in which <DNS name> is a registered Internet domain name that takes
+ the form of domain name described in Section 3 of [RFC1034] and
+ Section 2.1 of [RFC1123].
+
+ <data> is a free format string that is URI [RFC3986] compliant, and
+ that is meaningful to the authority given by the authority field.
+ The portion of the field is case insensitive. It is recommended that
+ all characters not within the range of characters allowed in a URI
+ must be encoded into UTF-8 and included in the URI as a sequence of
+ escaped octets. An escaped octet is encoded as a character triplet,
+ consisting of the percent character, "%", followed by the two
+ hexadecimal digits representing the octet code.
+
+ In its entirety, the CRID is URI compliant as specified in [RFC3986].
+ As per [RFC3986], the crid:// part of the syntax is case insensitive.
+
+5. Examples of CRID Syntax
+
+ The following are examples of a valid CRID:
+
+ crid://example.com/foobar
+
+ The above CRID was created by "example.com" authority, with data part
+ of foobar:
+
+ crid://example.co.jp/%E3%82%A8%E3%82%A4%E3%82%AC
+
+ The above CRID was created by "example.co.jp" authority, with a data
+ part of "E", "I", and "GA" (meaning "movie"), represented as KATAKANA
+ LETTERS (Japanese characters) in UTF-8 encoding preceded by "%".
+
+6. Usage
+
+6.1. Normative Specification
+
+ The Uniform Resource Locator scheme 'CRID:' identifies the URL as the
+ TV-Anytime Content Reference Identifier and conforms to the TV-
+ Anytime Content Referencing Specification [TVA-CR]. The TV-Anytime
+ CRID is a key component in the TV-Anytime forum specification series
+ as described in the informative overview Systems Description
+ Specification [TVA-Sys]. The normative Content Referencing
+ Specification [TVA-CR] also includes the details of the contents and
+
+
+
+Earnshaw, et al. Informational [Page 4]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+ format of the associated content referencing tables that resolve the
+ TV-Anytime CRID into further CRID instances or transport system-
+ dependent locations.
+
+6.2. Role of Domain Name System (DNS) Namespace
+
+ Note that the use of the registered Internet Domain does not mean
+ that the DNS resolving service is to be employed for the resolution
+ of CRID URL. Indeed the resolution information is fully specified in
+ [TVA-CR] and does not require the use of the DNS resolution service.
+ This is especially important as one key application area is broadcast
+ television and radio distribution services that are not Internet
+ based.
+
+ In business scenarios that exploit Internet connectivity to the home,
+ the DNS portion of the CRID can be used to resolve the Internet
+ location of the service provider, who in turn will provide location
+ resolution information in a form described in [TVA-CR].
+
+6.3. CRID Resolving
+
+ As addressed in [TVA-CR], the CRID is ultimately resolved either
+ directly by the CRID authority or by another party. If another party
+ is providing resolution, the ability to resolve the CRID requires the
+ flow of some information from the authority to the resolution
+ provider, in order to tie the CRID to its resolution. Examples of
+ relationships between CRID authors and the suppliers of resolution
+ information are given in [TVA-Sys].
+
+ As described in [TVA-CR], there will in all likelihood be more than
+ one CRID that can resolve directly or indirectly to a given single
+ locator at a given time.
+
+ Also shown in [TVA-CR], CRIDs that resolve directly to the location
+ of the scheduled content are likely to resolve to more than one
+ location, as television and radio programmes are often published
+ repeatedly within broadcast schedules or across different broadcast
+ services or distribution platforms over an extended period of time.
+
+6.4. CRID Related Metadata
+
+ TV-Anytime specification [TVA-Met] specifies the format and contents
+ of the programme-related descriptive metadata designed to convey the
+ TV-Anytime CRID for the purpose outlined here, as well as that of
+ other data supporting the publication and usage of programme
+ material.
+
+
+
+
+
+Earnshaw, et al. Informational [Page 5]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+7. IANA Considerations
+
+7.1. General
+
+ The 'crid:' URI scheme is reserved to designate that the URI relates
+ to the TV-Anytime CRID and is to be used in accordance with the
+ TV-Anytime Content Referencing Specification [TVA-CR].
+
+ The designation of the value of each CRID is the responsibility of
+ the CRID author, as identified through the 'authority' field.
+
+ The policy of assignment of CRID values lies with the CRID author
+ associated with the authority field. It is likely that there will be
+ a number of diverse (and possibly changing) authoring policies as
+ required by various organisations as they address their respective
+ audiences. These individual policies will address resolution target
+ resource designation issues such as the subjective equivalence of
+ programme material available from different locations, the grouping
+ of CRIDs under another CRID for collective description and resolution
+ purposes, the cross referencing of CRID between authorities, CRID
+ lifetime, and CRID reuse.
+
+ It is likely that some authoring policies may be set through
+ collaborative business arrangements, localised operational
+ agreements, or national governmental bodies.
+
+7.2. Registration Template in Accordance with [RFC2717]
+
+ URL scheme name: crid
+
+ URL scheme syntax: See Section 4
+
+ Character encoding considerations: TV-Anytime does not specify the
+ character encoding scheme to be adopted by each implementation.
+ However, in the case where Internet interoperability is desired, it
+ is recommended that all characters not within the range of characters
+ allowed in a URI must be encoded into UTF-8 and included in the URI
+ as a sequence of escaped octets. An escaped octet is encoded as a
+ character triplet, consisting of the percent character, "%", followed
+ by the two hexadecimal digits representing the octet code. For
+ example, the character A would be represented as "A", the character
+ LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80",
+ and the character KATAKANA LETTER A would be represented as
+ "%E3%82%A2".
+
+ Intended Use: See Section 6
+
+ Application and protocols which use this scheme: See Section 6
+
+
+
+Earnshaw, et al. Informational [Page 6]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+ Interoperability considerations: None (Section 4 contains the first
+ version of the CRID URL definition)
+
+ Security considerations: See Section 8
+
+ Relevant publications: See [TVA-CR], [TVA-Met], [TVA-Sys], [TVA-Prt]
+
+ Contact: Wataru KAMEYAMA, Vice Chairman and Secretary of the TV-
+ Anytime Forum, wataru@waseda.jp
+
+ Author/Change controller: IESG
+
+8. Security Considerations
+
+ The CRID URL described here provides a referencing mechanism. The
+ values of the URL contain the authoring 'Authority' name as a DNS
+ namespace identifier and a data portion to distinguish it from other
+ CRIDs from the same authority. There should be no reason to prevent
+ disclosure of the values within the CRID and no commercial
+ sensitivity associated with these values.
+
+ When the binding conveyed as part of a larger data set which may have
+ commercial value or critical binding between a CRID and the
+ accompanying data, the security and integrity of the binding is a
+ matter for the wider system implementers to judge and protect
+ accordingly. One such method for protecting metadata can be found in
+ [TVA-Prt], though it is not mandated that users adopt this. In any
+ case, there may be other, wider system security functions in place or
+ such precautions may not be seen as necessary.
+
+ Tampering with values of CRIDs during transmission or distribution
+ over public or open networks has only nuisance or denial-of-service
+ effects unless it causes alternative location resolution data or
+ programme metadata to be referenced. Again, this can be dealt with
+ as a system delivery of data integrity issue not specific to the
+ CRID.
+
+ Impersonating a CRID authority by authoring CRID with an authority
+ portion for which the bogus author does not have permission from the
+ registered DNS name holder would be a misuse of the DNS name holder's
+ identity and should be dealt with through normal business practice.
+
+9. Acknowledgements
+
+ The authors would like to acknowledge the support of the members of
+ the TV-Anytime forum and their work in the development of the TV-
+ Anytime CRID.
+
+
+
+
+Earnshaw, et al. Informational [Page 7]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+10. References
+
+10.1. Normative References
+
+ [TVA-CR] European Telecommunications Standards Institute, "ETSI TS
+ 102 822-4 v1.1.2 ; Broadcast and On-line Services: Search,
+ select and rightful use of content on personal storage
+ systems ("TV-Anytime Phase 1"); Part 4: Content
+ referencing", October 2004.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ RFC 1034, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", RFC 1123, October 1989.
+
+ [RFC2717] Petke, R. and I. King, "Registration Procedures for URL
+ Scheme Names", RFC 2717, November 1999.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+10.2. Informative References
+
+ [TVA-Sys] European Telecommunications Standards Institute, "ETSI TS
+ 102 822-2 v1.2.1 ; Broadcast and On-line Services: Search,
+ select and rightful use of content on personal storage
+ systems ("TV-Anytime Phase 1"). Part 2 System
+ Description", September 2004.
+
+ [TVA-Met] European Telecommunications Standards Institute, "ETSI TS
+ 102 822-3-1 v1.2.1 ; Broadcast and On-line Services:
+ Search, select and rightful use of content on personal
+ storage systems ("TV-Anytime Phase 1"). Part 3 Metadata.
+ Sub-part 1: Metadata Schemas", September 2004.
+
+ [TVA-Prt] European Telecommunications Standards Institute, "ETSI TS
+ 102 822-7 v1.1.1 ; Broadcast and On-line Services: Search,
+ select and rightful use of content on personal storage
+ systems ("TV-Anytime Phase 1"). Part 7 Bi-directional
+ Metadata Delivery Protection", October 2003.
+
+
+
+
+
+
+
+
+
+Earnshaw, et al. Informational [Page 8]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+Authors' Addresses
+
+ Nigel Earnshaw
+ BBC Research and Development
+ Kingswood Warren
+ Tadworth, Surrey KT20 6NP
+ United Kingdom
+
+ Phone: +44 1737 839618
+ EMail: nigel.earnshaw@rd.bbc.co.uk
+
+
+ Shigeru Aoki
+ TokyoFM Broadcasting
+ 1-7 Kojimachi
+ Chiyoda-ku, TOKYO 102-8080
+ JAPAN
+
+ Phone: +81 3 3221 0244
+ EMail: shig@center.jfn.co.jp
+
+
+ Alex Ashley
+ NDS Limited
+ One London Road
+ Staines, Middlesex TW18 4EX
+ United Kingdom
+
+ Phone: +44 208 4768270
+ EMail: aashley@ndsuk.com
+
+
+ Wataru Kameyama
+ GITS, Waseda University
+ 1011 Okuboyama, Nishi-tomida
+ Honjo-shi, SAITAMA 367-0035
+ JAPAN
+
+ Phone: +81 495 24 6052
+ EMail: wataru@waseda.jp
+
+
+
+
+
+
+
+
+
+
+
+Earnshaw, et al. Informational [Page 9]
+
+RFC 4078 TV-Anytime CRID May 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ 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.
+
+ 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 AND 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.
+
+Intellectual Property
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Earnshaw, et al. Informational [Page 10]
+