| Internet Engineering Task Force | M. Sparks |
| Internet-Draft | BBC Research and Development |
| Intended status: Experimental Protocol | June 2012 |
| Expires: December 01, 2012 |
Service synchronisation for Television And Related devices -- STAR
draft-msparks-template-star-00
Service synchronisation for Television And Related devices (STAR) is a suite of application level protocols to enable network connected devices to correlate events on a broadcast system with events outside that broadcast system. It is a generic suite of protocols, that enables playback of content retrieved from over a network such that it is synchronised to a broadcast source. It also enables correlation of non-broadcast events (such as conversations) to broadcast events.
Key features of STAR include: 1) The broadcast system does not require modification 2) It is designed to work with restricted clients limited to stream connections - such as web browsers 3) It is content agnostic.
This specification describes the research implementation as it stands today, and is published as a starting point for further discussion.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 01, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The original specification of xml2rfc format is in RFC 2629 [RFC2629].
Broadcast is a well understood single to many push medium, with modern television broadcast systems being digital broadcast systems. In the USA, the system is ATSC, in Europe DVB is common, with DVB-T, DVB-C and DVB-S widely deployed.
Whilst such digital systems have variations, they fundamentally form a lossy data channel from a broadcaster to an audience at a fixed bit rate. This is generally then received by a display which is a shared resource, broadly controlled by the occupants of a single room. Thus what is displayed or played back on the shared display must be of interest to all users of that device (or well known arguments ensue).
Digital broadcasts carry a variety of non audio/video data including subtitles, audio description (also called narrative subtitles for the blind), interactive applications, as well as information bundles similar to web pages. Each addition to the broadcast uses up the scarce resource. More data can be squeezed in at the expense (primarily) of picture quality. Each change presents diminishing returns for the broadcaster, despite benefits to the audience, due to the nature of broadcast being a single shared push channel. Furthermore, in order to "fake" a pull approach for data, information on a data channel - such as electronic programme guide (EPG) information - is has to be repeatedly pushed in order to allow clients timely access to data. This data carousel (as it is termed) squeezes the transmission channel even further.
Unlike broadcast clients, network clients control their local communications channel, leading to clients pulling services from servers. Being pull based, they are by their nature elective and therefore extremely good for personalised experiences. They can tend to suffer efficiency concerns for very large concurrent audiences, in particular servicing large audiences efficiently without content injection concerns is still hard.
Work has previously been done have investigating how to marry the broadcast and IP world. However in many cases they have sought to change the inherent nature of either broadcast from it's shared receiver audio or video nature, or to change network delivery to take control away from the receiver. That is to try and change the network delivery from a pull medium to a push medium.
Service Synchronisation for Television and Related Devices (STAR) is predicated on the principle of using the broadcast data channel for push aspects of a service in a form useful for the majority of an audience, and using pull-based network delivery for personalisation.
These personalisations need to be synchronised relative to the programme being broadcast, and presented to the user at appropriate times. To do this we expose key information about the broadcast data channel over the network, along with defining a means of synchronising with the broadcast data channel, and also a standard play out data format which can be used by a generic client to play out content synchronised to the broadcast.
STAR is also assumes that whilst custom clients are possible, clients are most likely to be implemented in restriction environments such as browsers or virtual machines residing in browsers. In practical terms this means that whilst it could operate on top of many transports, it is designed to primarily operate on top of either TCP or HTTP.
Thus STAR comprises a small suite of application level protocols that seeks to work with each medium appropriately, forming initial research results in this area. This specification describes the research implementation as it stands today, and is published as a starting point for further discussion.
In particular while each protocol could be specified separately, but describing them together retains important context.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."
This specification uses a number of terms to refer to the roles played by participants in, and objects of, a STAR system.
STAR uses the same notational conventions and generic grammar as HTTP/1.1 as defined in RFC 2616. For the purposes of this document:
NUMBER = 1*DIGIT
TIMESTAMP = NUMBER "." NUMBER
COMMAND = 1*ALPHA
ARGUMENT = *OCTET
STATUS = "OK" | "ERROR"
COMMANDTAG = 1*ALPHA
JSONRESPONSE = 1*OCTET
JSONRESPONSE is required to be a valid JSON object. JSON is defined in RFC 4627.
+------------------------------------------------------------+
| |
| RF IP |
| +-----+ +-----+ +-----------------------------------+ |
| | B <----> | | | |
| | r | | B | | STAR ADDITIONAL SERVICES SERVER | |
| | o | | r | | ^ ^ | |
| | a | | i | +----|----------------------|-------+ |
| | d | | d | | | |
| | c | | g | +----|----------------------|-------+ |
| | a | | e <-----> V V | |
| | s | | | | STAR CLIENT | |
| | t | | <-----> | |
| +-----+ +-----+ +-----------------------------------+ |
| |
+------------------------------------------------------------+
STAR consists of 4 main subsystems:
The STAR client protocol is specifically designed to allow clients to be implemented inside a web browser or similarly restricted environment (eg flash or java plugins). Tighter synchronisation accuracy could be achieved by mandating a less restricted environment, but to do so would restrict STAR's applicability & implementability needlessly.
Communications in a STAR system includes:
The rest of this section follows the communication in the system.
The broadcast system is a digital television service. Such broadcast systems have the following core characteristics:
Some analogue television services also contain this information, but for the purposes of discussion this document assumes a digital television service.
This protocol assumes that the existing broadcast service and broadcast client (eg a TV) are left unmodified. If a service on a non-broadcast client is being played out simultaneously with the broadcast service, then this service needs to be synchronised to the time as received by a broadcast receiver.
The broadcast bridge bridges the "push" of the broadcast world, and the "pull" of the IP based world. In particular, it is a server that contains a broadcast client receiver, and makes available a time service to synchronise against, and now/next programme services over IP for network based clients.
The broadcast bridge uses the time signal to synchronise a local server clock. In particular a DVB based broadcast bridge can retrieve TDT packets, and use their regularity to set a local clock time and rate of advance.
The broadcast bridge also receives the now and next data services, and keeps track of what programmes are being broadcast. This information is then made available over IP. Additionally, the broadcast time at which the now and next information changes is monitored. For the purposes of STAR, this change time is denoted to be "time zero" for the given programme.
It is worth noting that whether this is actually time zero depends upon the configuration of the broadcast service. Furthermore the accuracy of time zero also depends upon the configuration of the broadcast service.
It is also possible for the broadcast service to include a special marker including the time the programme actually started via the related content table.
Additionally, there may be other means to determine the start of the programme. The broadcast bridge is responsible for obtaining this time, and making this available to clients.
The broadcast bridge makes available a time service for the STAR client to synchronise against.
+------------------------------------------------------------+
| . |
| . RF . . IP . |
| . | | | . |
| | <----> | . |
| | S | | B | | |
| | y | | r | |--------+ |
| | s | | i | | | |
| | t | | d <-----> TIME | . |
| | e | | g | | SYNC | . | |
| | m | | e | | | | | |
| +-----+ +-----+ +-----------------------------------+ |
| RF IP STAR CLIENT |
| |
+------------------------------------------------------------+
This has the following characteristics:
The current time service can be used to derive a broad view of time - that is the current time as seen by a broadcast receiver. This can be accurate within a delta proportional to the network round trip time.
The echoing time service can be used to calculate an approximation of the network round trip time. This may be useful in circumstances where the network round trip time is likely to be too large relative to the additional service intended to be synchronised against the broadcast service.
The reason for using TCP and HTTP and not UDP are as follows:
Thus UDP has not been viewed as appropriate.
IP based programme services available are provided by the broadcast bridge to enable a client to determine which programme is currently being broadcast. This can be correlated with other IP based services to locate appropriate data on for playback synchronous to the broadcast service.
Prerequisites for this to work:
The broadcast bridge also provides facilities for:
+------------------------------------------------------------+
| . +--------+ |
| . RF . . IP . | | |
| . | | <-----> PROG | |
| | <----> | | SYNC | |
| | S | | B | | | |
| | y | | r | |--------+ |
| | s | | i | . . |
| | t | | d | . . |
| | e | | g | . | |
| | m | | e | . | | |
| +-----+ +-----+ +-----------------------------------+ |
| RF IP STAR CLIENT |
| |
+------------------------------------------------------------+
The STAR additional services server provides 2 core services:
Play out scripts are not required to be limited to playback of data from the data storage. In all cases it is expected that these scripts and data are to be retrieved over HTTP.
. - --------------------------------------+
|
STAR ADDITIONAL SERVICES SERVER |
+-----------------------------------+ |
| | | | |
. | Play out | Additional | |
| Scripts | data sources | |
| ^ | ^ | |
-------|-----------|-------+ |
| | |
.---------|-----------V-------+ |
| V | Output Dev 1 | |
| |--------------| |
| | Output Dev 2 | |
| Play out |--------------| |
--+ | Output Dev 3 | |
| Core |--------------| |
| | ... | |
. | |--------------| |
| | | Output Dev N | |
. +-----------------------------------+ |
. STAR CLIENT |
| |
+-----------------------------------------------+
A client may have many output means, which can be considered to include text, links, audio, video, and event send messages to a serial port for controlling (for example) arduino based devices, synchronous to the broadcast.
Three possible alternatives to a play out script delivered over HTTP are as follows:
In all 3 cases, unlike the downloaded file approach, these approaches preclude pre-caching data for playback. For this reason, a play out file was considered more appropriate.
Playout scripts are files consisting of a list of events. This file is UTF8 encoded, and contains a JSON object. Events denote times into the programme, the type of the event, and an opaque data blob relating to the event. The interpretation of the blob depends on the type. 3 types are considered critical:
Due to the fact that additional data sources may be linked to by an URL may be audio, video, text, web pages, and more. If the client does not understand how to interpret the URL, it should pass the interpretation over to a web browser.
Figure 6 shows all the subsystems and their interactions.
+------------------------------------------------------------+
| |
| RF IP STAR ADDITIONAL SERVICES SERVER |
| +-----+ +-----+ +-----------------------------------+ |
| | B <----> B | | | | | |
| | r | | r | | Content | Play out | Additional | |
| | o | | o | | Server | Scripts | data sources | |
| | a | | a | | ^ | ^ | ^ | |
| | d | | d | +-----|---------|-----------|-------+ |
| | c | | c | | | | |
| | a | | a | +-----|---------|-----------V-------+ |
| | s | | s | | V | V | Output Dev 1 | |
| | t | | t <-----> PROG | |--------------| |
| | | | | | SYNC | | Output Dev 2 | |
| | S | | B | | | Play out |--------------| |
| | y | | r | |--------+ | Output Dev 3 | |
| | s | | i | | | Core |--------------| |
| | t | | d <-----> TIME | | ... | |
| | e | | g | | SYNC | |--------------| |
| | m | | e | | | | Output Dev N | |
| +-----+ +-----+ +-----------------------------------+ |
| STAR CLIENT |
| |
+------------------------------------------------------------+
Clock synchronisation is a complex topic, and this specification takes a necessarily simplistic view for the following reasons:
+------------------------------------------------------------+
| . |
| . RF . . IP . |
| . | | | . |
| | <----> | . |
| | S | | B | | |
| | y | | r | |--------+ |
| | s | | i | | | |
| | t | | d <-----> TIME | . |
| | e | | g | | SYNC | . | |
| | m | | e | | | | | |
| +-----+ +-----+ +-----------------------------------+ |
| RF IP STAR CLIENT |
| |
+------------------------------------------------------------+
Application clock synchronisation occurs as follows:
The client connects to the broadcast time server port on the broadcast bridge. The client does not send any data. The server's response is a sequence of octets, that are terminated by the server closing the connection.
The sequence of octets sent forms a TIMESTAMP as defined above. That time-stamp is a string representation of a floating point value. That float represents the number of seconds since the beginning of the Unix epoch - ie the number of seconds since 00:00:00 UTC on 1 January 1970.
The time obtained is a broadcast time as defined above. This defines the broadcast view of time (BVT) according to a broadcast receiver at a given instant. These are received by the client at a given local clock (LC) times from the client clock.
In order to gain a broad view of time, the client needs to get two such timestamps - BVT1 and BVT2. These correspond to local clock times LC1 and LC2. The further these sets of timestamps, the better.
Using these times, the client can define a local application clock using BVT1, BVT2, LC1, and LC2. For brevity this is defined here in python:
class BroadViewClock(object):
def __init__(self, BVT1, BVT2, LC1, LC2):
"Configure application clock"
remote_elapsed = BVT2 - BVT1
local_elapsed = LC2 - LC1
self.ratio = remote_elapsed / local_elapsed
self.remote_baseline = BVT1
self.local_baseline = LC1
def sleep(self, time_in_remote_seconds):
"Sleep for a period time counted in broadcast seconds"
sleeptime = time_in_remote_seconds / self.ratio
time.sleep(sleeptime)
def time(self):
"Return the current time according to broadcast"
now = time.time()
local_elapsed = now - self.local_baseline
remote_elapsed = local_elapsed * self.ratio
remote_now = self.remote_baseline + remote_elapsed
return remote_now
ApplicationClock = BroadViewClock(BVT1, BVT2, LC1, LC2)
The accuracy of this broad view of time application clock depends on the network latency between the client and the broadcast bridge. For some applications, this delay will be acceptable. For many applications it will be desirable to attempt to eliminate the network delta.
The client initialises a client application clock which is a BroadViewClock as defined in 2.1 above. The client connects to the echo broadcast time server port on the broadcast bridge.
Upon connecting the client sends time request of the following form:
TIMEREQUEST = TIMESTAMP CRLF
That is it send an octet stream which is a string representation of a float, representing a timestamp of the number of seconds since the start of the unix epoch, followed by a CRLF sequence.
The server response is as follows:
BLOBRESPONSE = 1*OCTET
ECHOTIME = BLOBRESPONSE " " TIMESTAMP
The server then terminates the connection. BLOBRESPONSE as defined here is whatever data the client sends the server. Whilst the client MUST send data in the form defined as TIMEREQUEST, the server must be lenient and respond with whatever was sent as blob response.
Using the BroadViewClock, the client can build on BroadViewClock to create a new application clock which removes the network delta as follows:
class NetworkCorrectedBroadcastClock(object):
def __init__(self, application_clock, network_delta):
self.application_clock = application_clock
self.network_delta = network_delta
def sleep(self, delay):
self.application_clock.sleep(delay)
def time(self):
self.application_clock.time() + self.network_delta
BVT1, BVT2, LC1, LC2 -- Obtained as before
CoarseApplicationClock = BroadViewClock(BVT1, BVT2, LC1, LC2)
TOLERANCE = 0.01 # 10ms
WITHIN_TOLERANCE = False
while not WITHIN_TOLERANCE:
sendtime = CoarseApplicationClock.time()
sendtime_for_network = str(float(sendtime))
# sendtime_for_network and BLOBRESPONSE should be identical
BLOBRESPONSE, TIMESTAMP = EchoTimeRequest(sendtime_for_network,
server=broadcastbridge,
port=echo_time_port)
# Assuming network delays are constant within a certain delta,
# the following two values should be identical or close to
# identical
remote_now = float(TIMESTAMP)
now = CoarseApplicationClock.time()
if abs(remote_now - now) < TOLERANCE:
WITHIN_TOLERANCE = True
# Assume network is symmetrical
network_delta = (remote_now - sendtime)/2
BetterApplicationClock = NetworkCorrectedBroadcastClock(
CoarseApplicationClock,
network_delta)
At this point the client then has a network corrected local clock locked to the same clock as broadcast, within a reasonable tolerance.
+------------------------------------------------------------+
| |
. .
. . +---------- - .
| . . | | |
| . . . <-----> PROG | |
| | <----> | | SYNC | |
| | S | | B | | | |
| | y | | r | |--------+ |
| | s | | i | | . |
| | t | | d | . |
| | e | | g | . |
| | m | | e | |
| +-----+ +-----+ STAR CLIENT |
| RF IP |
| |
+------------------------------------------------------------+
Programme Services are provided on a request/response basis.
The client connects to the broadcast bridge programme port and sends a REQUEST matching the following:
REQUEST = COMMAND " " ARGUMENT CRLF
Note that the command is terminated by a blank line.
The server sends a RESPONSE as follows:
RESPONSE = STATUS " " COMMANDTAG " " JSONRESPONSE
The response is terminated by closing the connection.
If the status is ERROR, the client should handle the error gracefully. COMMANDTAG is always relative to the command the client sent to the server.
Commands the broadcast bridge MUST implement:
Commands the broadcast bridge SHOULD implement:
Note: The server is expected to lower case all commands and arguments on the way into the server.
This provides an alternative interface to the timing subsystem, and can be used in much the same way. It has a higher parsing overhead, and hence speed penalty.
None
The response is a JSON object with 3 name value pairs:
SEND: time
RECV: OK TIME {"elemental": [2010, 7, 5, 17, 21, 10, 0, 186, 1],
"textual": "Mon Jul 5 17:21:10 2010", "time": 1278346870.0}
This provides an alternative interface to the timing subsystem, and can be used in much the same way. It has a higher parsing overhead, and hence speed penalty.
TIMESTAMP - as defined above
The response is a JSON object with 4 name value pairs:
SEND: echotime 1278346870.0
RECV: OK TIME {"echo": "1278346870.0", "elemental": [2010, 7, 5,
17, 21, 15, 0, 186, 1], "textual": "Mon Jul 5 17:21:15 2010",
"time": 1278346875.0}
Provides a quick lookup mechanism of channel name, programme and start time.
None
The response is a JSON object with as many name value pairs as channels the broadcast bridge can receive. Each pair has the same format:
This format means that the summary contains duplication of information. The reason for this is to enable clients to be simpler to implement.
SEND: summary
RECV: OK SUMMARY {"bbc one": [1278346448.0, "The Weakest Link"],
"bbc two": [1278346554.0, "Escape to the Country"],
"cbeebies": [1278346632.0, "ZingZillas"],
"cbbc channel": [1278346613.0, "ROY"],
"bbc radio 1": [1278342000.0, "Scott Mills"],
"bbc radio 2": [1278345900.0, "Simon Mayo"],
"bbc radio 3": [1278345610.0, "In Tune"],
"bbc radio 4": [1278345610.0, "PM"],
"4168": [1278346448.0, "The Weakest Link"],
"4287": [1278346554.0, "Escape to the Country"],
"4672": [1278346632.0, "ZingZillas"],
"4608": [1278346613.0, "ROY"],
"6720": [1278342000.0, "Scott Mills"],
"6784": [1278345900.0, "Simon Mayo"],
"6848": [1278345610.0, "In Tune"],
"6912": [1278345610.0, "PM"]}
This command returns the list of services available on the bridge. The reason for this is to accommodate automated lookups based upon service ids used in the broadcast system rather than based on channel name.
None
The response is a JSON object which is an array of integers, each one representing the service ids which may be queried.
SEND: services
RECV: OK SERVICES [4288, 4544, 6016, 5952, 6784, 4168, 5760,
6720, 5888, 4352, 4416, 6848, 5632, 4608, 4672, 7168, 4736,
5824, 6912, 5696, 4287]
This command returns the list of channels available on the bridge. This uses the names of the channels as used by the broadcast system.
None
The response is a JSON object which is an array of strings, where each string is a channel name available on the bridge.
SEND: channels
RECV: OK CHANNELS ["bbc one", "bbc two", "cbeebies",
"cbbc channel", "bbc radio 1", "bbc radio 2",
"bbc radio 3", "bbc radio 4"]
This command returns all the information the broadcast bridge has on a particular channel at that instant. This provides a bridged version of the current "now and next" information for the channel. In particular, the dates and time information are provided "as is" from the broadcast system.
*OCTET - String that represents a channel name
Contains a JSON object with 2 name value pairs:
A now/next JSON object is a JSON object with 8 name value pairs:
SEND: channel bbc one
RECV: OK CHANNEL {
"channel": "bbc one",
"info":
{"NEXT":
{"startdate": [2010, 7, 5],
"name": "BBC News at Six",
"service": 4168,
"when": "NEXT",
"duration": [0, 30, 0],
"starttime": [17, 0, 0],
"transportstream": 4168,
"description": "The latest national and international
news stories from the BBC News team,
followed by weather. [S]"
},
"changed": 1278346448.0,
"NOW": {"startdate": [2010, 7, 5],
"name": "The Weakest Link",
"service": 4168,
"when": "NOW",
"duration": [0, 45, 0],
"starttime": [16, 15, 0],
"transportstream": 4168,
"description": "Anne Robinson presents the quick-
fire general knowledge quiz in which
contestants must decide at the end
of each round which of their number
should be eliminated. [S]"
}
}
}
This command returns all the information the broadcast bridge has on a particular channel, identified by broadcast system service id at that instant.
*OCTET - String that represents a service number
The response format is the same as the command "channel"
SEND: service 4287
RECV: OK CHANNEL {
"info": {
"channel": "bbc two"
"NEXT": {
"startdate": [2010, 7, 5], "
"name": "Eggheads",
"service": 4287,
"when": "NEXT",
"duration": [0, 30, 0],
"starttime": [17, 0, 0],
"transportstream": 4168,
"description": "General knowledge quiz in which
teams from all over the UK battle to beat the
Eggheads, some of the country's top quiz
champions. Also in HD. [S]"},
"changed": 1278346554.0,
"NOW": {
"startdate": [2010, 7, 5],
"name": "Escape to the Country",
"service": 4287,
"when": "NOW", "duration": [0, 45, 0],
"starttime": [16, 15, 0],
"transportstream": 4168,
"description": "New Forest: Series in which
prospective buyers are helped to find their dream
home in the country. Jules Hudson helps a couple
with a budget of 650,000 pounds find a house in
the New Forest. [S]"}
},
}
This provides a basic web based API to access the same commands as the TCP command format.
The broadcast bridge presents itself on the following form of URL:
http://example.com/bridge?command=<CMD>
http://example.com/bridge?command=<CMDA>&args=<ARG>
The response type for URLs of the format above is application/json, and the format/structure matches the TCP version precisely.
CMD is any command from the TCP version which does not take any arguments.
CMDA is any command from the TCP version which takes at least one argument. The argument it takes is passed through in args.
http://example.com/bridge?command=time
http://example.com/bridge?command=echotime&args=1278346870.0
http://example.com/bridge?command=summary
http://example.com/bridge?command=services
http://example.com/bridge?command=channels
http://example.com/bridge?command=channel&args=bbc%20one
http://example.com/bridge?command=service&args=4287
After synchronising a clock, and after retrieving programme start times, the STAR client (which may be a javascript based client inside a web page) can then choose to retrieve a play out script from the STAR additional services server. How this happens precisely is left as an exercise to an implementer.
One approach that is feasible is as follows:
There are clearly other feasible approaches, and STAR is not prescriptive about any particular approach.
That play out script MAY be delivered over HTTP.
The MIME type of play out script is application/json.
The STAR play out script
The JSON object:
Each event is an array consisting of 3 values:
Timestamps are defined to be relative to time zero of the programme as defined above.
Event type is defined as follows
EVENT TYPE = *ENCODINGTAG DATATYPETAG
ENCODINGTAG = ( "INLINE" | "BASE64"|"URL") ";"
DATATYPETAG = MIMETYPE | CUSTOMTYPE
CUSTOMTYPE = DOMAIN "/" *OCTECT
ie An optional (encoding tag and semicolon) preceding a base type.
A base type may be:
The encoding tag defines how to interpret the encoding of the event data:
Given the encoding tag is optional, if the encoding tag is not supplied, then the following rules are used to determine the encoding:
The actual event data interpretation is just a string.
If the data encoding is an URL:
If the data encoding is BASE64:
Otherwise the data encoding is INLINE:
The data is then interpreted according to local rules for the given MIME type.
Given the following (tidied) example:
[[0, "text/plain", "Programme Start"],
[0.5, "audio/wav", "http://www.example.com/example.wav"],
[1.0, "BASE64;image/vnd.microsoft.icon", 'AAABAAIAEBAAAAAAABo...'],
[1.5, "URL;example.com/game", "http://www.example.com/games/gam"],
[2.0, "example.com/serial", "http://www.example.com/ardunio/robo"],
...
]
Time 0 is interpreted as as text/plain - which may be displayed on a screen, or spoken.
Time 0.5 is interpreted as an URL to download and then treat as an audio/wav file.
Time 1.0 is interpreted an inline embedded ".ico" file, which is base 64 encoded in the data field.
Time 1.5 is interpreted as an URL to download and then treat according to the rules defined by the entity owning "example.com" as the datatype "example.com/game".
Time 2.0 is interpreted as an URL to download and then treat according to the rules defined by the entity owning "example.com" as the datatype "example.com/serial". For example, this could mean to take whatever data is sent back and to send that to the serial port, controlling an arduino controlled robot.
Future expansion of datatype tags is provided through the standard IANA MIME types, and also by the custom datatype tag formats which may be managed by the owner of a domain name.
This memo includes no request to IANA.
This document describes an experimental protocol. It re-uses the existing IANA namespace for defining datatype tags, and additionally defines a mechanism for users of the protocol to define their own namespace for defining datatype tags, and maintaining this within their organisation.
As a result this protocol has no IANA considerations.
All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide.
This section is meant to inform application developers, information providers, and users of the security limitations in STAR as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.
It is not warranted to be exhaustive.
The server enables the maintainer of the broadcast bridge to identify what programmes particular IPs are using. If the maintainer of the broadcast bridge or additional services server store cookies, then they are potentially able to identify particular individuals.
Since the event file format is defined to automatically download URLS in the file, if the client does this at the same time as the moment in the programme occurs, then the maintainer of the broadcast bridge is able to track which users are watching how much of what programme through the broadcast bridge log data.
The client is not required to download the URLs at that instant, and may download the content beforehand, which mitigates this risk.
JSON format data is directly interpretable in a number of languages, including actionscript, javascript, and python. If the creator of the client fails to use a parser, this opens the client up to well known attacks.
Similarly, assuming BASE64 encoded data is BASE64 encoded without any conversion errors would open up the client to well known attacks.
It is possible for a badly crafted file to cause a denial of service attack on the additional services store. For example, if all the timestamps were "0", this would mean "interpret all these events as being at time 0". This could cause a very large number of concurrent requests against the additional services store, albeit by accident. Hijacking of a site and replacement of the play out script with a malicious play out script could result in a similar effect.
This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822.
Also, this specification is inspired by HTTP to be content agnostic and extensible, and additionally by the semantic web approach of allowing namespaces interpretation to be owned by a group.
The time synchronisation approach is based very loosely on a simplification of the core ideas of a number of time synchronisation protocols.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2629] | Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. |
| [RFC3552] | Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. |
This becomes an Appendix.