Content reference identifier: Difference between revisions

Revision as of 04:09, 28 August 2013

Revision as of 01:40, 22 October 2013

Line 23:

crid://authority/data

The ''authority'' field represents the entity that created the CRID and its format is that of a DNS name. The ''data'' field represents a string of characters that will unambiguously identify the content within the authority scope (it is a string of characters assigned by the authority itself).

As an example, let's assume that [[BBC]] wanted to make a CRID for (all the programs of) the Olympics in China. It may have looked something like this

Line 31:

crid://bbc.co.uk/olympics/2008/final/shotput/women

Currently,{{When?|date=January 2013}} four types of CRIDs are playing a major role in some [[Unidirectional networks|unidirectional]] [[Televisiontelevision network|television networks]]s: programme CRID, series CRID, group CRID, and recommendation CRID. One of the most important applications of CRIDs is the so-called series link recording function (SL) of modern digital video recorders ([[Digital_video_recorderDigital video recorder|DVR]], [[Personal_video_recorderPersonal video recorder|PVR]]).

In turn, a locator is a string of characters that contains all the necessary information for a receiver to find and acquire a given content, whether it is received through a transport stream, located in local storage, downloaded as a file from an Internet server, or through a streaming service. For example, a DVB locator will include all the necessary parameters to identify a specific content within a transport stream: network, transport stream, service, table and/or event identifiers.

Line 52:

'''The RAR table'''

The RAR table is one or many data structures that provide the receiver, for each authority that submits CRIDs, information on the corresponding resolution service provider. Among other things, it also informs about which mechanism is used to provide information to resolve the CRIDs from each authority. That is, one or many RAR records must exist for each authority that indicate the receiver where it has to go to resolve the CRIDs of that particular authority.

For example, in the record of the figure (expressed by means of a XML structure, according to the XML Schema defined in the TV-Anytime) there is an authority called “tve.es”, whose resolution service provider is the entity “rtve.es”, available on the URL <nowiki>"http://tva.rtve.es/locres/tve"</nowiki>, which means there is resolution information in that URL.

[[File:RAR record example.png|center|RAR table in XML format]]

These RAR records will have reached the receiver in an indefinite form, unimportant for the TV-Anytime specification, which will depend on the specific transport mechanism of the network to which the receiver is connected. Each family of standards that regulates distribution networks (DVB, ATSC, ISDB, IPTV...) will have previously defined such procedure, which will be used by devices certified according to those standards.

Line 64 ⟶ 62:

'''The ContentReferencingTable table'''

The second structure involved in the ___location resolution process is a proper resolution table which, given a content’s CRID, returns one or several locators that enable the receiver to access an instance of that content, or one or many CRIDs that allow it to move forward in the resolution process.

The figure shows an example of this second structure, an XML document according to the specifications of the XML Schema defined in TV-Anytime. In it, several sections are included (<Result> elements) that structure the information that describes each resolution case.

[[File:ContentReferencingTable.png|center|an example of a ContentReferencingTable]]

The first one declares how a CRID (crid://tv.com/Friends/all), which corresponds to a group content that encompasses several episodes (two) of the “Friends” series is resolved. The result of the resolution process provides two new CRIDs each of them corresponding to one of the two episodes.

Line 84 ⟶ 80:

This procedure depends mainly on the receiver’s connectivity. It is possible to make a basic distinction between unidirectional networks, where the receiver can only receive information through the broadcast channel, and bidirectional networks, where there is also a return channel through which the receiver can communicate with the outside (typically an Internet access).

For receivers connected only to a broadcast channel, it is clear that the resolution information must come directly from that channel, or be available somehow in an existing local storage system. After selecting a CRID, the first thing the receiver needs to do is check the information about where to find the resolution table. For this, it must find a RAR record associated with the authority of the selected CRID.

Once a RAR record corresponding to that authority is found, the receiver will know, by referring to the URL field, where to access (or, in this case, where to listen) to obtain the resolution information.

The information that will receive through that access point will consist of a message for each of the consulted CRIDs (for example, a <Result> element in the ContentReferencingTable).

== In web casting ==

To make the CRID even more globally available the [[IETF]] will publish a request for comments specifying the use of the CRID over the web. This will allow consumer devices to hook up to content provider servers, much like current browsers look up webservers, requesting content by CRID.

In May 2005, an Informational RFC, [http://tools.ietf.org/html/rfc4078 No 4078], was published as the start of this work.