RFC 4078

The TV-Anytime Content Reference Identifier (CRID)

📅 published May 2005, from ietf

RFC 4078: The TV-Anytime Content Reference Identifier (CRID) 📺✨

Okay bestie, this one is a whole vibe 💖. It's RFC 4078, titled "The TV-Anytime Content Reference Identifier (CRID)", and it came out in May 2005 as part of the Network Working Group stream. It was written by four authors: N. Earnshaw (BBC Research and Development), S. Aoki (TokyoFM Broadcasting), A. Ashley (NDS Limited), and W. Kameyama (GITS, Waseda University) 🌸. Its category is Informational 🦋, which means it's just sharing info with the internet and isn't a standard. The title block doesn't list anything it obsoletes or updates.

Status of This Memo 📝

This memo just gives info to the Internet community. It does not specify an Internet standard of any kind 🙅‍♀️. And the distribution of this memo is unlimited, so share it with everyone 🫶.

It's Copyright (C) The Internet Society (2005). Protect that legacy 💅.

Abstract 🎀

So the URL scheme CRID: was created to let you reference current or future scheduled publications of broadcast media content. This works across TV distribution platforms and the Internet 📡.

The main reason it exists is as an embedded link inside scheduled programme description metadata. The home user or their agent can use it to connect a programme selection to the matching programme location info, so it can be acquired automatically later 🧚.

This document copies the TV-Anytime CRID definition from the TV-Anytime content referencing specification. It's published as an RFC so people can access it easily and so it can be registered with the Internet Assigned Numbers Authority (IANA) 🌈.

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 🌟

Okay so there are SO many more broadcast TV and radio services for people at home now 📺🎶. You've got the traditional stuff like Digital Terrestrial, Satellite, and Cable, and then high-speed internet brings even MORE info and entertainment, with audio-visual programmes sent straight to your home over the Internet 🚀.

Alongside all that, home devices have gotten way more complex, and they let the user work in a "search-select-acquire" paradigm 🔍. In this model, the user or their user agent looks at descriptive info about audio-visual programmes, picks one, and then acquires it to watch later 🍿. Home appliances also come with local storage now, so they can automatically capture programmes by recording off-air or downloading 💾.

The 'CRID:' Uniform Resource Locator is basically the bridge 🌉. It connects programme-related descriptive metadata with the matching programme location data, which might be published over a different distribution network or at a different time 💜.

Programme location data gives the home user agent what it needs to get the programme when it's published 🎯. For TV distribution, these locators have the broadcast timing and tuning info, so the appliance can record the programme while it's airing live 📼. For Internet delivery, the locators need to be in the form used by streaming protocols or file exchange protocols, with the time (or time window) of availability included ⏰.

Because a content publisher might release the same audio-video material on a bunch of platforms, or repeat it over a period of time, the CRID can group all those publications together and link them to one description 🧩. There can also be other meaningful connections between programme publications that aren't otherwise related, and those can be grouped under a higher-level CRID 🪆. That higher-level CRID gets its own descriptive metadata. Honestly, deciding what to group is subjective, and that's part of the CRID authoring process. It's not standardised 🤷‍♀️.

The CRID resolution process, which lets the user agent finally acquire the audio-visual programme material, can be timely 💫. Resolution updates can come in dynamically from the service provider. This matches common business practice of moving the time of content availability close to the original published time, so a live, managed, reactive broadcast service works smoothly 🎬.

2. Ancestry 👑

The 'CRID:' Uniform Resource Locator scheme comes from the TV-Anytime forum Content Reference Identifier 🎀. It's the result of the consensus that forum members reached between March 2000 and June 2002 🤝. The TV-Anytime CRID and its supporting data are specified in the TV-Anytime Phase 1 Content Referencing Specification [TVA-CR] 📚.

3. Notation Used in This Document ✏️

The notation in this document looks like this:

<first>/<second>

The component names go in angle brackets, and anything outside the angle brackets is a literal separator 💅.

4. The CRID URL Scheme 🔗

The CRID URL looks like this:

crid://<DNS name>/<data>

Here, <DNS name> is a registered Internet domain name. It has to take the form of the 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 🧁. It has to mean something to the authority given by the authority field. That part of the field is case insensitive 🙈. It is recommended that all characters that aren't in the range allowed in a URI get encoded into UTF-8 and included in the URI as a sequence of escaped octets. An escaped octet is a character triplet: the percent character %, followed by the two hexadecimal digits that represent the octet code 🦋.

Altogether, the CRID is URI compliant as specified in [RFC3986] ✨. And as per [RFC3986], the crid:// part of the syntax is case insensitive 💖.

5. Examples of CRID Syntax 🌸

Here are some examples of a valid CRID 🧚:

crid://example.com/foobar

This CRID was created by the "example.com" authority, with a data part of foobar 🍓.

crid://example.co.jp/%E3%82%A8%E3%82%A4%E3%82%AC

This CRID was created by the "example.co.jp" authority, with a data part of "E", "I", and "GA" (meaning "movie") 🎞️. Those are written as KATAKANA LETTERS (Japanese characters) in UTF-8 encoding, with each one preceded by "%" 🇯🇵. It's giving multilingual main character energy 🔥.

6. Usage 🎬

6.1. Normative Specification 📜

The Uniform Resource Locator scheme 'CRID:' identifies the URL as the TV-Anytime Content Reference Identifier, and it 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, which is described in the informative overview Systems Description Specification [TVA-Sys] 🗺️. The normative Content Referencing Specification [TVA-CR] also has all the details on the contents and format of the associated content referencing tables. Those tables resolve the TV-Anytime CRID into further CRID instances or transport system-dependent locations 🧩.

6.2. Role of Domain Name System (DNS) Namespace 🌐

Using a registered Internet Domain doesn't mean the DNS resolving service has to be used to resolve a CRID URL 🙅‍♀️. The resolution info is fully specified in [TVA-CR], so it doesn't need the DNS resolution service at all. This matters a LOT because one key application area is broadcast television and radio distribution services that aren't Internet based 📡.

In business scenarios that use Internet connectivity to reach the home, the DNS portion of the CRID can resolve the Internet location of the service provider 🏠. The service provider then gives location resolution info in the 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 does the resolving, then the resolution provider needs some info from the authority so it can tie the CRID to its resolution. Examples of relationships between CRID authors and resolution info suppliers are given in [TVA-Sys] 💼.

As described in [TVA-CR], there will most likely be more than one CRID that resolves, 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 scheduled content are likely to resolve to more than one location 🔁. That's because television and radio programmes often get published again and again within broadcast schedules, across different broadcast services, or over different distribution platforms during an extended period of time 📆.

The TV-Anytime specification [TVA-Met] specifies the format and contents of the programme-related descriptive metadata. That metadata is designed to convey the TV-Anytime CRID for the purpose outlined here 💜. It also covers other data that supports publishing and using programme material 📦.

7. IANA Considerations 🦋

7.1. General ✨

okay so the crid: URI scheme is reserved 💖 It says the URI is about the TV-Anytime CRID, and it has to be used the way the TV-Anytime Content Referencing Specification [TVA-CR] describes 🎀

Whoever is listed in the 'authority' field is the CRID author, and that author is the one responsible for deciding what each CRID value is 🫶

The assignment policy belongs to that same CRID author. And bestie, there's going to be a bunch of different policies, possibly changing over time, because every organisation talks to its own audience 🌈 These policies might cover things like:

  • when different locations count as showing the same programme material (subjective equivalence) 🎬
  • grouping several CRIDs under another CRID so they can be described and resolved together 🧚
  • cross-referencing CRIDs between authorities 🔗
  • how long a CRID lives, and whether it can be reused 🍓

Some of these policies might come out of business deals, local operational agreements, or national governments 💅

7.2. Registration Template in Accordance with [RFC2717] 🦋

URL scheme name: crid

URL scheme syntax: See Section 4

Character encoding considerations: TV-Anytime doesn't decide which character encoding each implementation uses 🤷‍♀️ But if you want things to work across the Internet, it is recommended that any character that isn't allowed in a URI gets encoded in UTF-8 and put into the URI as escaped octets. An escaped octet is a triplet: the percent character % followed by the two hexadecimal digits for that octet 😭 Some examples: the character A stays as A, LATIN CAPITAL LETTER A WITH GRAVE becomes %C3%80, and KATAKANA LETTER A becomes %E3%82%A2 ✨

Intended Use: See Section 6

Application and protocols which use this scheme: See Section 6

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 🔥

okay bestie, this part is serious, so listen up 🙈

The CRID URL here is just a referencing mechanism 🧚 Its values hold the authoring 'Authority' name, which is a DNS namespace identifier, plus a data portion that tells it apart from other CRIDs from the same authority. There should be no reason to hide these values, and they carry no commercial sensitivity 💜

When the binding is carried inside a bigger data set that might be worth real money, or where the link between a CRID and its accompanying data is critical, the security and integrity of that binding is up to the people building the wider system to judge and protect. One way to protect metadata is in [TVA-Prt], but nobody is forced to use it 🙅‍♀️ Also, there might be other system-wide security functions already in place, or those extra precautions might not seem necessary at all.

Changing CRID values during transmission or distribution over public or open networks only causes nuisance or denial-of-service effects, unless the change makes alternative location resolution data or programme metadata get referenced instead 😭 Again, that's a system-level data integrity problem, not something specific to the CRID itself.

Impersonating a CRID authority is when someone writes CRIDs using an authority portion they don't have permission to use from the registered DNS name holder. That counts as misusing the DNS name holder's identity, and it should be handled through normal business practice 💀

9. Acknowledgements 🫶

The authors want to thank the members of the TV-Anytime forum for supporting them and for all their work developing the TV-Anytime CRID 🌈✨

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.

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

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 doesn't take a side on whether any Intellectual Property Rights or other rights claimed for the technology in this document are valid or in scope, or on whether licenses for them are available 🤷‍♀️ It also doesn't say it has checked for any such rights itself. Info on how RFC documents handle rights is in BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, or the outcome of an attempt to get a general license or permission for implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗

The IETF invites anyone to point out any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 💖✨

📦 where this page comes from