Internet DRAFT - draft-msparks-template-star
draft-msparks-template-star
Internet Engineering Task Force M. Sparks
Internet-Draft BBC Research and Development
Intended status: Experimental June 28, 2012
Expires: December 30, 2012
Service synchronisation for Television And Related devices -- STAR
draft-msparks-template-star-00
Abstract
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.
Status of this Memo
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 30, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Sparks Expires December 30, 2012 [Page 1]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Notational Conventions and Generic Grammar . . . . . . . . 7
2. STAR System Overview . . . . . . . . . . . . . . . . . . . . . 8
2.1. The Broadcast System . . . . . . . . . . . . . . . . . . . 9
2.2. The Broadcast Bridge and Broadcast System . . . . . . . . 9
2.3. Broadcast Bridge Time Services and STAR Client . . . . . . 10
2.4. Broadcast Bridge Programme Services and STAR Client . . . 11
2.5. STAR Additional Services Server . . . . . . . . . . . . . 12
2.5.1. Playout Scripts . . . . . . . . . . . . . . . . . . . 14
2.5.2. Additional data sources . . . . . . . . . . . . . . . 14
2.6. Full Glass System View . . . . . . . . . . . . . . . . . . 14
3. STAR Time Synchronisation . . . . . . . . . . . . . . . . . . 15
3.1. Broad View of Time synchronisation over TCP . . . . . . . 16
3.2. Network Delta Corrected Time Synchonisation over TCP . . . 17
4. STAR Broadcast Bridge Programme Services over TCP . . . . . . 19
4.1. command: time . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2. Response format . . . . . . . . . . . . . . . . . . . 20
4.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. command: echotime . . . . . . . . . . . . . . . . . . . . 21
4.2.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 21
4.2.2. Response format . . . . . . . . . . . . . . . . . . . 21
4.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. command: summary . . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2. Response format . . . . . . . . . . . . . . . . . . . 22
4.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. command: services . . . . . . . . . . . . . . . . . . . . 23
4.4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 23
4.4.2. Response format . . . . . . . . . . . . . . . . . . . 23
Sparks Expires December 30, 2012 [Page 2]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
4.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. command: channels . . . . . . . . . . . . . . . . . . . . 23
4.5.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 24
4.5.2. Response format . . . . . . . . . . . . . . . . . . . 24
4.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 24
4.6. command: channel . . . . . . . . . . . . . . . . . . . . . 24
4.6.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 24
4.6.2. Response format . . . . . . . . . . . . . . . . . . . 24
4.6.3. Example . . . . . . . . . . . . . . . . . . . . . . . 25
4.7. command: service . . . . . . . . . . . . . . . . . . . . . 26
4.7.1. Arguments . . . . . . . . . . . . . . . . . . . . . . 26
4.7.2. Response format . . . . . . . . . . . . . . . . . . . 26
4.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 26
5. STAR Broadcast Bridge Programme Services over HTTP . . . . . . 27
5.1. Mapping to HTTP from the TCP Service . . . . . . . . . . . 27
5.2. Example Mappings . . . . . . . . . . . . . . . . . . . . . 27
5.2.1. command: time . . . . . . . . . . . . . . . . . . . . 27
5.2.2. command: echotime . . . . . . . . . . . . . . . . . . 28
5.2.3. command: summary . . . . . . . . . . . . . . . . . . . 28
5.2.4. command: services . . . . . . . . . . . . . . . . . . 28
5.2.5. command: channels . . . . . . . . . . . . . . . . . . 28
5.2.6. command: channel . . . . . . . . . . . . . . . . . . 28
5.2.7. command: service . . . . . . . . . . . . . . . . . . 28
6. STAR Additional Services Server . . . . . . . . . . . . . . . 28
7. STAR Playout Scripts . . . . . . . . . . . . . . . . . . . . . 29
7.1. MIME type . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. File Format . . . . . . . . . . . . . . . . . . . . . . . 29
7.3. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 29
7.4. Event types . . . . . . . . . . . . . . . . . . . . . . . 29
7.4.1. Datatype Tags . . . . . . . . . . . . . . . . . . . . 29
7.4.2. Encoding Tags . . . . . . . . . . . . . . . . . . . . 30
7.5. Event data encoding . . . . . . . . . . . . . . . . . . . 30
7.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Future Expansion . . . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10.1. Personal Information - Abuse of Server Logs . . . . . . . 32
10.2. Data encoding and decoding . . . . . . . . . . . . . . . . 32
10.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
Sparks Expires December 30, 2012 [Page 3]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
1. Introduction
The original specification of xml2rfc format is in RFC 2629
[RFC2629].
1.1. Purpose
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.
Sparks Expires December 30, 2012 [Page 4]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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.
1.2. Requirements Language
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."
1.3. Terminology
This specification uses a number of terms to refer to the roles
played by participants in, and objects of, a STAR system.
Sparks Expires December 30, 2012 [Page 5]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
broadcast
An audio/visual transmission over radio or similar system
that also includes a time and data signal - such as digital
broadcasting or analogue broadcast with a teletext, etc. data
channel.
digital broadcast
A broadcast using a digital broadcast standard such as
Digital Video Broadcasting (DVB), or Advanced Television
Systems Committee (ATSC). Digital broadcasts typically
contain audio, video, subtitles, applications, and metadata
regarding the broadcasts - in terms of content and transport.
broadcast receiver
A standard receiver for a given broadcast system.
broadcast time
The time specified in a broadcast signal, as recieved by a
broadcast reciever.
broadcast bridge
A broadcast receiver that stores metadata from a given
broadcast service. It acts as a server on the network
available to be queried by a client. (ie it bridges the push
of broadcast and the pull from a network client)
play out script
Data file that is used to schedule playback of events
relative to given times based on event type
content server
A server that a client can retrieve play out scripts from as
well as additional content.
client
A network connected device capable of playing out 1 or more
form of synchronised content. Performs synchronisation with
the broadcast bridge, retrieves content from the content
server for play out.
client clock
The actual system clock of the client device. Assumed to be
poor quality and unchangeable.
application clock
A corrected software clock based synchronisation with the
broadcast bridge. Does not have a defined accuracy level.
Sparks Expires December 30, 2012 [Page 6]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
broadcast time server port
A TCP socket listening on the broadcast bridge for a client
to connect to. Provides a basic "NOW" time service for
client application clocks to synchronised against.
Connection is closed by the server.
echo broadcast time server port
A TCP socket listening on the broadcast bridge for a client
to connect to. Provides a basic "NOW" time service for
client application clocks to synchronised against. Does this
after receiving data from the client. All data sent by the
client is echoed back to the client. Connection is closed by
the server.
repeating echo broadcast time server port
A TCP socket listening on the broadcast bridge for a client
to connect to. Provides a basic "NOW" time service for
client application clocks to synchronised against. Does this
after receiving data from the client. All data sent by the
client is echoed back to the client. Connection is closed by
the client.
1.4. Notational Conventions and Generic Grammar
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.
Sparks Expires December 30, 2012 [Page 7]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
2. STAR System Overview
+------------------------------------------------------------+
| |
| 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 | | <-----> | |
| +-----+ +-----+ +-----------------------------------+ |
| |
+------------------------------------------------------------+
Figure 1: Top level
STAR consists of 4 main subsystems:
o A broadcast system, including a broadcast system and a broadcast
client
o A broadcast bridge
o A STAR client
o A STAR additional services server
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:
o Broadcast within the broadcast system
o The broadcast bridge's reception and analysis of the broadcast
o Time synchronisation between the STAR client and the broadcast
bridge
Sparks Expires December 30, 2012 [Page 8]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o Programme information services provided by the broadcast bridge to
the STAR client
o Synchronised data services from the STAR additional services
server provided to the STAR client. These fall into two
categories:
* Play out scripts
* Additional data sources
The rest of this section follows the communication in the system.
2.1. The Broadcast System
The broadcast system is a digital television service. Such broadcast
systems have the following core characteristics:
o An audio and video (maybe) service per channel
o A time service giving the current time. For example the time and
date (TDT) table in DVB suffices here. TDT data is typically
broadcast once per second, and represents the time "now".
o A programme service describing what programme is on "now". In DVB
the event information table information contains a "now and next"
service. The now and next service data is sent regularly, but is
additionally updated when the broadcast programme changes.
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.
2.2. The Broadcast Bridge and Broadcast System
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
Sparks Expires December 30, 2012 [Page 9]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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.
2.3. Broadcast Bridge Time Services and STAR Client
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 |
| |
+------------------------------------------------------------+
Figure 2: Time Synchronisation, Relevant subsystems
This has the following characteristics:
Sparks Expires December 30, 2012 [Page 10]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o The client can request the current time from the broadcast bridge.
o The client can request the current time from the broadcast bridge
with a payload which the broadcast bridge includes in its
response.
o The time services are available over both TCP and HTTP
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:
o A tool - dvbdate - exists that provides a means of configuring an
NTP server, which can then be used for synchronising time over
UDP.
o Restricted clients - such as browsers or plugins - were considered
desirable.
o UDP is not available to browser based components
o TCP is commonly available from browser plugins
o HTTP is natively available to browser based clients
Thus UDP has not been viewed as appropriate.
2.4. Broadcast Bridge Programme Services and STAR Client
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:
o The programme services must include the actual start time of a
programme as broadcast.
Sparks Expires December 30, 2012 [Page 11]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o This may be queried over TCP or HTTP, for the same reasons as the
time services.
The broadcast bridge also provides facilities for:
o Identifying what channels the bridge covers, by name and service
id
o Summary information across all channels
o Detailed information on the channel's current state, based on
channel or serviceid
+------------------------------------------------------------+
| . +--------+ |
| . RF . . IP . | | |
| . | | <-----> PROG | |
| | <----> | | SYNC | |
| | S | | B | | | |
| | y | | r | |--------+ |
| | s | | i | . . |
| | t | | d | . . |
| | e | | g | . | |
| | m | | e | . | | |
| +-----+ +-----+ +-----------------------------------+ |
| RF IP STAR CLIENT |
| |
+------------------------------------------------------------+
Figure 3: Programme Services interaction
2.5. STAR Additional Services Server
The STAR additional services server provides 2 core services:
o Play out scripts, which describe what events to play out when
o Data storage for data to playback from playout scripts.
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.
Sparks Expires December 30, 2012 [Page 12]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
. - --------------------------------------+
|
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 |
| |
+-----------------------------------------------+
Figure 4: Playout subsystems' interactions
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:
o To repeatedly poll the server with a "what do I do now message".
For services with low levels of service, this may be appropriate,
but for nationwide services, this is not a scalable approach, and
was discounted on that basis.
o To open a connection to the server, and wait for event data to be
sent over the connection. Whilst this limits connection set up
and tear down, this could for popular events require a server
handle millions of connections held open for long periods of time
and data delivered instantaneously to all the clients
concurrently. This was not deemed scalable.
Sparks Expires December 30, 2012 [Page 13]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o The client opens an XMPP connection, and receiving data over that
connection from an XMPP group. This is a promising approach, but
raises the implementation bar to that of implementing an XMPP
client. It also requires the client to remain connected.
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.
2.5.1. Playout Scripts
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:
o Plain text
o Base 64 encoded data.
o URLs
2.5.2. Additional data sources
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.
2.6. Full Glass System View
Figure 5 shows all the subsystems and their interactions.
Sparks Expires December 30, 2012 [Page 14]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
+------------------------------------------------------------+
| |
| 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 |
| |
+------------------------------------------------------------+
Figure 5: Glass view
3. STAR Time Synchronisation
Clock synchronisation is a complex topic, and this specification
takes a necessarily simplistic view for the following reasons:
o Expected clients include javascript within a browser. This means
sync will happen over HTTP. The many layers involved limit the
effectiveness of aiming for extremely tight sync.
o STAR time synchronisation is therefore primarily concerned with
synchronising browser events, and simplicity aids implementation.
o For some applications, accuracy of within a second or so is
acceptable. For others, accuracy down to 40ms is desirable.
Going beyond this would appear to require a UDP based service.
Sparks Expires December 30, 2012 [Page 15]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
+------------------------------------------------------------+
| . |
| . RF . . IP . |
| . | | | . |
| | <----> | . |
| | S | | B | | |
| | y | | r | |--------+ |
| | s | | i | | | |
| | t | | d <-----> TIME | . |
| | e | | g | | SYNC | . | |
| | m | | e | | | | | |
| +-----+ +-----+ +-----------------------------------+ |
| RF IP STAR CLIENT |
| |
+------------------------------------------------------------+
Figure 6: Time Synchronisation, Relevant subsystems
Application clock synchronisation occurs as follows:
o The client synchronises an application clock against a broad view
of time with the broadcast bridge.
o The client may attempt to calculate the error incurred by the
network traversal - the network delta. The approach taken is
deliberately simple at the possible expense of accuracy.
3.1. Broad View of Time synchronisation over TCP
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.
Sparks Expires December 30, 2012 [Page 16]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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.
3.2. Network Delta Corrected Time Synchonisation over TCP
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.
Sparks Expires December 30, 2012 [Page 17]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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()
Sparks Expires December 30, 2012 [Page 18]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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.
4. STAR Broadcast Bridge Programme Services over TCP
+------------------------------------------------------------+
| |
. .
. . +---------- - .
| . . | | |
| . . . <-----> PROG | |
| | <----> | | SYNC | |
| | S | | B | | | |
| | y | | r | |--------+ |
| | s | | i | | . |
| | t | | d | . |
| | e | | g | . |
| | m | | e | |
| +-----+ +-----+ STAR CLIENT |
| RF IP |
| |
+------------------------------------------------------------+
Figure 7: Programme Time Synchronisation, Relevant subsystems
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:
Sparks Expires December 30, 2012 [Page 19]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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:
o time
o echotime
o summary
Commands the broadcast bridge SHOULD implement:
o services
o channels
o channel
o service
Note: The server is expected to lower case all commands and arguments
on the way into the server.
4.1. command: time
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.
4.1.1. Arguments
None
4.1.2. Response format
The response is a JSON object with 3 name value pairs:
o time - Number of seconds since the Unix Epoch. The timezone is
defined to be UTC.
o elemental - 9 element array representation of the same time,
consisting of:
Sparks Expires December 30, 2012 [Page 20]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
* year - integer representing the full year
* month - integer in range 1..12
* day of month - integer day of the month
* hour - integer
* minute - integer
* seconds - integer
* weekday - integer in range 0..6, where monday is 0.
* day of year - counting from 1
* daylight savings flag
+ 0 means no daylight savings adjustment has taken place
+ 1 means time is adjusted for daylight savings
o textual - Again, the same time as a human readable time/date.
This should be treated as human readable and machine opaque.
4.1.3. Example
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}
4.2. command: echotime
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.
4.2.1. Arguments
TIMESTAMP - as defined above
4.2.2. Response format
The response is a JSON object with 4 name value pairs:
o time - Number of seconds since the Unix Epoch. The timezone is
defined to be UTC.
Sparks Expires December 30, 2012 [Page 21]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o elemental - 9 element array representation of time as defined
before in section 4.1.2
o textual - Same time as a human readable time/date. As in 4.1.2
this is defined as machine opaque and human readable.
o echo - Contains whatever the client sent as TIMESTAMP
4.2.3. Example
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}
4.3. command: summary
Provides a quick lookup mechanism of channel name, programme and
start time.
4.3.1. Arguments
None
4.3.2. Response format
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:
o channelname - which may be either:
* the human readable name of the channel from the broadcasting
system
* The symbolic service id for the channel on this broadcast
system.
o A value is an array consisting of 2 values
* First value is TIMESTAMP when programme started
* Second value is Programme name
This format means that the summary contains duplication of
information. The reason for this is to enable clients to be simpler
to implement.
Sparks Expires December 30, 2012 [Page 22]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
4.3.3. Example
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"]}
4.4. command: services
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.
4.4.1. Arguments
None
4.4.2. Response format
The response is a JSON object which is an array of integers, each one
representing the service ids which may be queried.
4.4.3. Example
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]
4.5. command: channels
This command returns the list of channels available on the bridge.
This uses the names of the channels as used by the broadcast system.
Sparks Expires December 30, 2012 [Page 23]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
4.5.1. Arguments
None
4.5.2. Response format
The response is a JSON object which is an array of strings, where
each string is a channel name available on the bridge.
4.5.3. Example
SEND: channels
RECV: OK CHANNELS ["bbc one", "bbc two", "cbeebies",
"cbbc channel", "bbc radio 1", "bbc radio 2",
"bbc radio 3", "bbc radio 4"]
4.6. command: channel
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.
4.6.1. Arguments
*OCTET - String that represents a channel name
4.6.2. Response format
Contains a JSON object with 2 name value pairs:
o channel - value is a string with the channel name
o info - value is another JSON object with 3 name value pairs:
* changed - value is a floating point value which is the number
of seconds since the Unix Epoch. Represents when the now and
next information changed.
* NOW - now/next JSON object (see below) where the "when" value
is "NOW"
* NEXT - now/next JSON object (see below) where the "when" value
is "NEXT"
A now/next JSON object is a JSON object with 8 name value pairs:
Sparks Expires December 30, 2012 [Page 24]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o name - string with the name of the programme the now/next object
refers to
o description - a string containing a human readable description of
the programme.
o startdate - an array of integers, representing [year, month, day]
o starttime - an array of integers, representing [hours, minutes,
seconds]
o duration - an array of integers, representing [hours, minutes,
seconds]
o when - a string which is either "NOW" or "NEXT"
o service - an integer which is the broadcast service id
o transportstream - an integer which is the broadcast service id
4.6.3. Example
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,
Sparks Expires December 30, 2012 [Page 25]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
"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]"
}
}
}
4.7. command: service
This command returns all the information the broadcast bridge has on
a particular channel, identified by broadcast system service id at
that instant.
4.7.1. Arguments
*OCTET - String that represents a service number
4.7.2. Response format
The response format is the same as the command "channel"
4.7.3. Example
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]"},
Sparks Expires December 30, 2012 [Page 26]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
"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]"}
},
}
5. STAR Broadcast Bridge Programme Services over HTTP
5.1. Mapping to HTTP from the TCP Service
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.
5.2. Example Mappings
5.2.1. command: time
http://example.com/bridge?command=time
Sparks Expires December 30, 2012 [Page 27]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
5.2.2. command: echotime
http://example.com/bridge?command=echotime&args=1278346870.0
5.2.3. command: summary
http://example.com/bridge?command=summary
5.2.4. command: services
http://example.com/bridge?command=services
5.2.5. command: channels
http://example.com/bridge?command=channels
5.2.6. command: channel
http://example.com/bridge?command=channel&args=bbc%20one
5.2.7. command: service
http://example.com/bridge?command=service&args=4287
6. STAR Additional Services Server
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:
o A broadcaster publishes a schedule online with programme names,
times and a unique id.
o Using the broadcast bridge, the STAR client identifies the current
programme, allowing the identification of the unique id.
o The STAR client can then request from a web service the specific
play out script for that programme.
There are clearly other feasible approaches, and STAR is not
prescriptive about any particular approach.
That play out script MAY be delivered over HTTP.
Sparks Expires December 30, 2012 [Page 28]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
7. STAR Playout Scripts
7.1. MIME type
The MIME type of play out script is application/json.
7.2. File Format
The STAR play out script
o is a UTF8 encoded
o contains a JSON encoded object.
The JSON object:
o is an array of events
Each event is an array consisting of 3 values:
o The first value is a float representing a timestamp - see 7.3
o The second is an event type - see 7.4
o The third is event data - see 7.5
7.3. Timestamps
Timestamps are defined to be relative to time zero of the programme
as defined above.
7.4. Event types
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.
7.4.1. Datatype Tags
A base type may be:
o a standard MIME Type
Sparks Expires December 30, 2012 [Page 29]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o An application's custom type. As defined above an application's
custom type is defined in terms of DOMAINNAME followed by a "/"
followed by any text. It is up to the entity that owns the domain
DOMAINNAME to publish and manage that namespace.
7.4.2. Encoding Tags
The encoding tag defines how to interpret the encoding of the event
data:
o "INLINE" - means to treat the event data as raw data of the type
given (eg textual)
o "BASE64" - means that the event data inline is the data of the
given datatype, but is base64 encoded. (This allows for example a
small audio/wav file to be represented inline. This is expected
to be a rare necessity but potentially useful)
o "URL" - means to treat the event data as an URL to download and
interpret at the given time.
Given the encoding tag is optional, if the encoding tag is not
supplied, then the following rules are used to determine the
encoding:
o If the datatype tag is the MIME type "text/plain" then the
encoding tag is inline
o Otherwise the encoding tag is assumed to be URL (This allows for
example a small audio/wav file to be represented inline. This is
expected to be a rare necessity but potentially useful)
7.5. Event data encoding
The actual event data interpretation is just a string.
If the data encoding is an URL:
o Then the STAR client accesses the resource indicated by the URL
and uses that resource as the event data.
If the data encoding is BASE64:
o Then the STAR client decodes the BASE64 encoded data, and uses
that as the event data
Otherwise the data encoding is INLINE:
Sparks Expires December 30, 2012 [Page 30]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
o This means the STAR client just treats the raw data as the event
data.
The data is then interpreted according to local rules for the given
MIME type.
7.6. Example
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.
8. Future Expansion
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.
9. IANA Considerations
This memo includes no request to IANA.
Sparks Expires December 30, 2012 [Page 31]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
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.
10. Security 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.
10.1. Personal Information - Abuse of Server Logs
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.
10.2. Data encoding and decoding
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.
Sparks Expires December 30, 2012 [Page 32]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
10.3. Denial of Service
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.
11. Acknowledgements
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.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[RFC2629] Rose, M., "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.
Appendix A. Additional Stuff
This becomes an Appendix.
Sparks Expires December 30, 2012 [Page 33]
Internet-Draft STAR: IP & Broadcast Synchronisation June 2012
Author's Address
Michael Sparks
BBC Research and Development
BBC R & D North Lab
Dock House
MediaCityUK
Salford, M50 2LH
UK
Phone: +44 303 040 9510
Email: michael.sparks@bbc.co.uk
Sparks Expires December 30, 2012 [Page 34]
