- From: Craig A. Finseth <fin@finseth.com>
- Date: Wed, 30 Dec 1998 14:44:22 -0600 (CST)
- To: www-tv@w3.org
WWW-TV URI/URL/URN Issues
Comparing Applications to Requirements
1998-12-30
Given that the list of applications has appeared to stabilize, Phil
Hoschka has requested that I compare that list to the list of
requirements developed by Werner ten Kate.
For your convenience, this posting will be followed by a re-posting of
the applications list document.
The relevant portions of the requirements document are in the next
section.
Depending upon the feedback from this document, the next step would be
to take the (adjusted by feedback) results of this document and modify
the requirements document.
Please send general comments on this document to the www-tv@w3.org
mailing list. Specific comments can be sent directly to me at
craig@finseth.com.
- Craig A. Finseth
------------------------------------------------------------
This section presents the relevant portions of the Internet-Draft
draft-tenkate-tvweb-uri-reqs-00.txt by ten Kate, Thomas, and Finseth.
NOTE: I have taken the liberty of modifying the item numbering on the
requirments document to facilitate the comparision. The modificiation
consists of replacing the "o" bullet points with sequntial numbers.
Sections 3 and 5 are included for completeness: the actual
requirements are listed only in section 4.
3. TV Broadcast
Definition: In this document TV Broadcast is used as the generic term
to refer to currently existing TV systems, their transport protocols,
and their typical operation of content provision and distribution.
TV Broadcast includes systems like DVB, ATSC, DSS, NTSC, and PAL.
The TV Broadcast 'network layer' is typically non-IP based.
4. Requirements on TV Broadcast URI schemes
4.1 The URI scheme should comply with RFC 2396.
4.2 It must be possible for the resource identified by a URI to
be a channel/service (i.e. a concatenation of programs), an
entire program/event, or just a single component of a program/event.
Fragments within a component are outside the current scope of
requirements.
4.3 Given a URI, it must be possible for a receiver to actually
locate the resource, or conclude that it is not reachable.
4.4 Given a URI, it must be possible for a receiver to determine
the time period(s) within which the resource can be retrieved
from the (also resolved) location.
4.5 A URI should be invariant with respect to the normal range of
transport stream transformations, both in referencing the time
and the location of the resource in that transport stream.
4.6 The URI scheme should support the spectrum of transport protocols
applied and standardized in TV Broadcast systems. This includes
both audio/video and data broadcast protocols.
4.7 A URI must be meaningful when interpreted from any of the
following locations relative to the resource being referenced:
4.7.1 From the same TV Broadcast network
4.7.2 From another TV Broadcast network
4.7.3 From an arbitrary location in the Internet
[Note: this means that the system can detect it concerns a URI
pointing to a TV Broadcast network.]
4.8 A URI should be resolvable under any of the following network
access conditions:
4.8.1 TV Broadcast, same or another network
4.8.2 Internet
4.8.3 In Home/local storage
4.8.4 Other (future) networks
The actual resource's retrieved content data may differ in terms
of content encoding, content quality, performance, and edit version.
[Note the difference with the previous requirement, particularly
the use of 'must' and 'should'.]
4.9 The URI scheme must be compatible with solutions already adopted
in standardisation bodies such as ATSC, DVB, and DAVIC.
4.10 The URI scheme should interoperate with the Internet access schemes,
in particular http.
[Note: the scheme, not per se the access protocol it calls; it means
that hierarchies in the URI scheme should map as much as possible.
This should assist seamless transitions when the client decides
to use another access protocol (and network).]
4.11 Ideally, the URI should support referencing various instantiations
of the same content (encoding, quality/compression ratio,
versions/edits).
4.12 The URI scheme should support relative referencing such that
a TV-program with all its associated resources can be referenced
against a common base, which is the TV Broadcast URI of that
aggregate.
5. Exceptions in TV Broadcast URIs
TV Broadcast differs from the conventional Internet in several ways.
The TV Broadcast URI scheme is affected by that in the following aspects:
o The host is not necessarily a server identifyable through an
IP-address. For instance, the 'host' is a transport stream.
o The resource access and retrieval scheme is not necessarily
IP-stack based.
o The resource's availability implicitly depends on, or at least
relates to, a transmission schedule.
------------------------------------------------------------
Comparison: Applications to Requirements
This section presents each point in the applications list document and
identifies which of the requirements it relates to.
As a reminder, this list is the result of a "brainstorming" session
and the list has not undergone any sort of review.
1. Be able to refer to the audio/video image.
The requirements document does not cover this case.
2. Be able to include queries into the receiver in a
technology-independent manner.
The requirements document does not really cover this case,
although 4.1 may serve this purpose
3. Provide for technology-specific tuning.
There is a problem in that this application does not meet
the requirements of a UR*: the same string (e.g., reference
to NTSC channel 7) points to different content depending
upon the physical place that it is referenced from.
That said, 4.2 refers to naming channels and 4.6 covers
different technologies.
4. Provide for network-specific tuning, such as:
4.2 covers naming channels
4.5 covers naming the same channel throughout transformation
4.7.* cover naming the same channel from anywhere (although
we have to be careful of the HBO problem)
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming the same channel throughout transformation
5. Be able to uniquely address authored...content.
4.2 covers naming content (we'll assume that it was intended to
cover data content)
4.5 covers naming the same content throughout transformation
4.6 covers naming the same content throughout transformation
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming the same content throughout transformation
6. Be able to name discrete data content...being broadcast by a
network, and *not* available via the Internet...
4.2 covers naming content (we'll assume that it was intended to
cover data content)
4.5 covers naming the same content throughout transformation
4.6 covers naming the same content throughout transformation
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming the same content throughout transformation
7. Be able to name standard web content...
4.1 covers use of a resonable UR* format
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast
4.8.2 covers resolving it from the Internet
4.8.3 and .4 apply to the extent that the devices have
access to the Internet
4.10 is a clear statement of this intent
8. Be able to reference an application...
4.2 covers naming content (we'll assume that it was intended to
cover applications)
4.5 covers naming the same content throughout transformation
4.6 covers naming the same content throughout transformation
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming the same content throughout transformation
4.12 states that we want to support this feature that is
commonly used by applications
9. Be the target of a trigger...
4.2 covers naming content (we'll assume that it was intended to
cover applications)
4.5 covers naming the same content throughout transformation
4.6 covers naming the same content throughout transformation
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming the same content throughout transformation
10. It is the year 2002....Fox wishes to put a hyperlink to the
broadcast on its web site...
4.1 covers use of a resonable UR* format
4.2 covers naming the broadcast
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
11. In the same situation as (10) above, the broadcast is
data-enhanced...
4.1 covers use of a resonable UR* format
4.2 covers naming the broadcast (we'll assume that it was
intended to cover applications/data)
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
12. In the same broadcast situation as (10) and (11) above, Fox wants
to put hyperlinks....in other Fox channels
4.2 covers naming the broadcast (we'll assume that it was
intended to cover applications/data)
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere; 4.7.2
is particularly important
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
13. Paramount Productions wants to put on its web site a generic
hyperlink to Star Trek episodes and/or movies....
4.1 covers use of a resonable UR* format
4.2 could cover it: it is by no means clear from the wording
that the intention was to be able to name arbitrary
collections of material
given that 4.2 does apply:
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
14. In the same situation as in (13) above... mini-EPG show only the
current and upcoming episodes of this series.
4.1 covers use of a resonable UR* format
4.2 could cover it: it is by no means clear from the wording
that the intention was to be able to name arbitrary
collections of material
given that 4.2 does apply:
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
15. In the same situation as in (14) above...mini-EPG showing the
current and upcoming showings of this specific episode.
4.1 covers use of a resonable UR* format
4.2 could cover it: it is by no means clear from the wording
that the intention was to be able to name arbitrary
collections of material
given that 4.2 does apply:
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
16. A local broadcast station...wants to put a hyperlink on its web
site...this week's episode.
4.1 covers use of a resonable UR* format
4.2 covers this material
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
Recall that even within a local area, the same broadcast may
be available by means of over-the-air, cable (lots of
different ways), satellite, etc.
17. ...Fox, wants to put on its website a generic invitation to watch
a particlular one of its channels...
4.1 covers use of a resonable UR* format
4.2 covers naming channels
4.5 covers naming the same channel throughout transformation
4.7.* cover naming the same channel from anywhere (although
we have to be careful of the HBO problem)
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming the same channel throughout transformation
18. A local affiliate of the network mentioned in (17) above wants to
...web site...to tune to a particular one of its channels.
4.1 covers use of a resonable UR* format
4.2 covers naming channels
4.5 covers naming the same channel throughout transformation
4.7.* cover naming the same channel from anywhere (although
we have to be careful of the HBO problem)
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming the same channel throughout transformation
Recall that even within a local area, the same broadcast may
be available by means of over-the-air, cable (lots of
different ways), satellite, etc.
19. ...parent corporation wants its multiple channels to be able to
advertise each other...
4.2 covers naming the channel
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere; 4.7.2
is particularly important
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
20. In the same situation as in (19) above, suppose a single
application can operate with the data of any of multiple different
data services broadcast on different channels...
4.2 covers naming the broadcast (we'll assume that it was
intended to cover applications/data)
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere; 4.7.2
is particularly important
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
21. The NFL...distributes e-mail...containing a UR*...Some of the
e-mail is sent via the Internet and some...via an "e-mail" channel...
4.1 covers use of a resonable UR* format
4.2 covers this material
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere; 4.7.2
is particularly important
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
22. Some global brand...place a URI...in to be broadcast with the
program and displayed as a pop-up, linking to one or more of:
a) a web-cast infomercial on their site
b) Informercial broadcast separately, for example the previous night,
and locally stored on the receiver's memory.
c) Infomercial broadcast on a separate advertising channel
d) infomercial available on a VOD (or NVOD) channel
4.2 covers naming the material (we'll assume that it was
intended to cover applications/data)
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere; 4.7.2
is particularly important
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
23. A sponsor wishes to identify data describing their logo (perhaps
animated) for inclusion in the program guide.
4.2 covers naming the material (we'll assume that it was
intended to cover applications/data)
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere; 4.7.2
is particularly important
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
24. A content creator...assemble and test a commercial...when... the
distribution format(s) is(are) not known.
4.2 covers naming the material (we'll assume that it was
intended to cover applications/data)
4.5 covers naming it from anywhere
4.6 covers naming it from using different protocols
4.7.* cover naming the same content from anywhere
4.8.1 covers resolving it from a broadcast; other 4.8.* points
apply to the extent that the devices have access
to the broadcast
4.11 covers naming different versions
25. ...the naming mechanism must...be globally unique.
The requirements document does not cover this case, although
4.9 could be stretched to cover other existing organizations
such as used by the Internet DNS.
26. ...a receiver can obtain the same material from two
different sources...the UR* must not force solutions in this area...
The requirements document does not cover this case, although
4.5, 4.6 and 4.11 could be put together and stretched out
of shape to attempt to deal with it.
27. ...The UR* mechanism should allow receivers that have such
"pre-cached" material to make use of it... from the _same_ reference...
4.5 covers normal transformations (if you assume that pre-caching
is normal)
4.11 covers naming different versions
28. The UR* mechanism should facilitate the recording...
4.5 covers normal transformations (and we all should assume
that recording/playback is normal!)
4.6 record/playback is certainly part of the normal spectrum
4.7.1 and .2 cover cross-stream references
4.8.3 covers home storage
4.11 covers variations of content (tape may be at a lower
resolution than the orginial broadcast)
29. Given (28) the source space of UR*s should be large enough that
UR*s need not be reused...
The requirements document does not cover this case, although
the points from (28) could be stretched to apply.
In summary, UR*s reference things transmitted down the broadcast
stream(s). The things that they can reference are one or more
instances of:
a) the tuner output
Not covered by requirements
b) a transmission multiplex
Not explicitly covered by requirements; could be inferred from 4.2
c) a (virtual) channel
in 4.2
d) an event
in 4.2
e) an application
Not explicitly covered by requirements; could be inferred from 4.2
d) data used by an application
Not explicitly covered by requirements; could be inferred from 4.2
------------------------------------------------------------
Comparison: Requirements to Applications
This section presents each point in the requirements list and
identifies which of the applications it relates to.
4.1 The URI scheme should comply with RFC 2396.
The applications document does not address this area
explicitly. However, (2), (10), (11), (13), (14), (15), (16),
(17), (18), and (21) all imply Internet interaction and
with such interaction is an assumed duty to comply with
RFC 2396.
4.2 It must be possible for the resource identified by a URI to
be a channel/service (i.e. a concatenation of programs), an
entire program/event, or just a single component of a program/event.
Fragments within a component are outside the current scope of
requirements.
(3), (4), (10), (12), (17), (18), (19), (21), and (28) call
for URIs that designate channels or broadcasts.
(16) calls for URIs that designate events.
(5), (6), (8), (9), (11), (20), (22), (23), (24), call (27)
for URIs that designate data and/or applications.
4.3 Given a URI, it must be possible for a receiver to actually
locate the resource, or conclude that it is not reachable.
None of the applications was defined in such a way as to
prescribe an implementation mechansim.
Note that in one sense this requirement is one that is not met
by the "traditional" Internet UR* schemes such as http: and
ftp:. Those all rely on other resources such as the DNS, IP
routing, ARP, TCP encapsulation, etc. in order to actually
locate the target of the UR*.
However, it is reasonable for a URI scheme to specify
how it interoperates with other resources to achieve the
desired effect.
4.4 Given a URI, it must be possible for a receiver to determine
the time period(s) within which the resource can be retrieved
from the (also resolved) location.
None of the applications was defined in such a way as to
prescribe an implementation mechansim.
(5), (6), (8), (9), (10), (11), (12), (13), (14), (15),
(16), (19), (20), (21), (22), (23), (24), (26), (27),
and (28) all refer to the ability to name resources that
are not continuous in time (e.g., events, collections of
events, data, applications): this might be what the
requirement intended.
4.5 A URI should be invariant with respect to the normal range of
transport stream transformations, both in referencing the time
and the location of the resource in that transport stream.
(4), (5), (6), (8), (9), (10), (11), (12), (13), (14), (15),
(16), (17), (18), (19), (20), (21), (22), (23), (24), (26),
(27), and (28) all call for this capability.
4.6 The URI scheme should support the spectrum of transport protocols
applied and standardized in TV Broadcast systems. This includes
both audio/video and data broadcast protocols.
(4), (5), (6), (8), (9), (10), (11), (12), (13), (14), (15),
(16), (17), (18), (19), (20), (21), (22), (23), (24), (26),
(27), and (28) all call for this capability.
(3) might be in the list if it was in fact a UR* scheme.
4.7 A URI must be meaningful when interpreted from any of the
following locations relative to the resource being referenced:
4.7.1 From the same TV Broadcast network
4.7.2 From another TV Broadcast network
4.7.3 From an arbitrary location in the Internet
[Note: this means that the system can detect it concerns a URI
pointing to a TV Broadcast network.]
(4), (5), (6), (8), (9), (10), (11), (12), (13), (14), (15),
(16), (17), (18), (19), (20), (21), (22), (23), (24), (26),
(27), and (28) all call for this collection of capabilitites.
4.8 A URI should be resolvable under any of the following network
access conditions:
4.8.1 TV Broadcast, same or another network
4.8.2 Internet
4.8.3 In Home/local storage
4.8.4 Other (future) networks
The actual resource's retrieved content data may differ in terms
of content encoding, content quality, performance, and edit version.
[Note the difference with the previous requirement, particularly
the use of 'must' and 'should'.]
(4), (5), (6), (8), (9), (10), (11), (12), (13), (14), (15),
(16), (17), (18), (19), (20), (21), (22), (23), (24), (26),
(27), and (28) all call for this collection of capabilitites.
For all, the assumption is that the devices implied uner 4.8.2
and 4.8.3 have access to a TV broadcast data stream.
For (10), (11), (12), (13), (14), (15), (16), (17), (18), and
(21), they assume some sort of Internet access as implied under
4.8.2.
For (28), it assumes some form of local storage under 4.8.3.
The presumed requirement under 4.8.4 is that the scheme will
be defined in such a way that future devices can also take
advantage of it.
4.9 The URI scheme must be compatible with solutions already adopted
in standardisation bodies such as ATSC, DVB, and DAVIC.
The solutions adopted by DVB and DAVIC (ATSC has not adopted
one in this area) are all technology specific.
The applications document does not have any examples supporting
this requirement. (10), (11), (12), (17), (24), (26), and
(27) all clearly assume a decoupling between the UR* scheme
and the transport technology. Although the exact wording does
not permit a conclusive determination, it is likely that the
authors of many of the other points would have included a
decoupling requirement if they had thought of it.
4.10 The URI scheme should interoperate with the Internet access schemes,
in particular http.
[Note: the scheme, not per se the access protocol it calls; it means
that hierarchies in the URI scheme should map as much as possible.
This should assist seamless transitions when the client decides
to use another access protocol (and network).]
(7) covers this.
4.11 Ideally, the URI should support referencing various instantiations
of the same content (encoding, quality/compression ratio,
versions/edits).
(4), (5), (6), (10), (11), (12), (13), (14), (15), (16), (17),
(18), (19), (21), (22) (maybe), (23), (24), (26), and (27)
all rely on this to some extent. (26) speaks to it directly.
4.12 The URI scheme should support relative referencing such that
a TV-program with all its associated resources can be referenced
against a common base, which is the TV Broadcast URI of that
aggregate.
None of the applications was defined in such a way as to
bring out this level of detail. (24), (25), and (28) may
be taken to imply this need.
Received on Wednesday, 30 December 1998 15:44:25 UTC