Subject: Reigistry for tv:URI's

From: "Deventer, M.O. \(Oskar\) van" <[email-masked]>
Date: Mon, 2 Oct 2006 14:03:40 +0200

All,

In the tv:URI discussions on this mailing list, the creation of a
registry was gently suggested by several people. I am now starting to
believe this is the only way to really cut down ambiguity. So I would
like to focus the discussion on the creation of such a registry.

This also means that I am withdrawing my suggestions to modify the
tv:URI syntax, or making links between tv:URI's and the "official"
webpage of a TV channel. So for the scope of the registry discussion,
we'll be talking about tv:URI's that refer purely to TV channels and
that are pure DNS-style identifiers, as described in RFC2838

I think the following questions are relevant:
1) Do we need a registry and why?
2) How should such a registry be organized?
3) What type of information should be registered?
4) How are registrations created, read, updated, and deleted (CRUD)?
5) What is the relationship with existing registries?
     -... in particular with the DNS registry.

Here are my provisional answers for your review.

Ad 1) Yes, we do need a registry. This is the only way to really cut
down ambiguity in referring to TV channels.

Ad 2) The responsibility of the registry would reside with ICANN. ICANN
would delegate the technical work to a third party. An example of such a
delegation is User ENUM, for which ICANN has delegated the e164.arpa
root to RIPE.

Ad 3) The registry will contain a list of unique tv:URI's, to each entry
information is associated on the TV broadcast that it identifies, like
broadcaster, language(s), geographic reach and other. The registry will
serve two purposes.
-Identification: learning which TV broadcast is identified by a specific
tv:URI.
-Search: finding the tv:URI of a specific TV broadcast.

Ad 4) Any person or organization can "nominate" a TV broadcast for
registration. This person or organization should provide evidence that
the TV broadcast exists and that it has not been previously registered.
The registry will subsequently assign a tv:URI to the broadcast
following the RFC2838 guidelines.

Ad 5) The relationship with the DNS registry will be as described in
RFC2838. That is, DNS-style domain name syntax is used to identify a
broadcast. Further then this syntactic relation we do not foresee any
relation with the DNS. Note that this implies - as already stated in
RFC2838 - that it is not the intention that tv:URI's are resolved
through the DNS.

Please let me know your reactions on these thoughts.

Best regards,

Oskar van Deventer & Iko Keesmaat

--------------------------------
dr.ir. M. Oskar van Deventer
TNO Information and Communication Technology
P.O. box 5050
2600 GB  Delft
Netherlands
+31 651 914 918
[email-masked]
--------------------------------
Connecting to a TNO colleague? Call +31 15 285 75 75

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Oct 2006 16:13:58 +0200

Dear Mr. Deventer,

I read your message and while I haven't thought much about the problem
space, I do know that there is a tremendous amount of information in
national databases already.  For instance, you can access engineering
data such as frequency reach via the FCC CDBS database.  Similar
information seems to be available via OFCOM in the UK, and I presume it
will be available in many other countries.  Is this something you will
take advantage of?

Eliot

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 2 Oct 2006 16:03:25 -0400

Some questions ...

On 10/2/06, Deventer, M.O. (Oskar) van <[email-masked]> wrote:
> relation with the DNS.

So would there be any relationship between, say, "tv:nbc.com" and
General Electric (the current owner, per the DNS)?  If yes, do you
intend to reuse the association already maintained by the DNS/ICANN,
or do you intend to create a new registry to make this association?
If not, don't you think General Electric might express concern about
not owning the set of tv URIs using the nbc.com name?

You also mentioned that anybody would be able to register a tv URI.
Again, don't you think GE (or Disney or ...) would balk at that?

> Note that this implies - as already stated in

It sounds like you're leaving the door open to resolvable URIs which
is good, but what would you recommend for those that want them?

And a meta question; would this discussion not be more appropriate for
the URI list ([email-masked])?

Cheers,

Mark.

---

From: "Keesmaat, N.W. \(Iko\)" <[email-masked]>
Date: Tue, 3 Oct 2006 13:06:22 +0200

Mark,

I tried looking up the owner of nbc.com (using various web-based whois
service), but I could not find details. The website www.nbc.com points
at the NBC TV channel/broadcast.  I suspect that GE owns NBC?

In our view the tv:URI should identify a TV broadcast. 

Looking at the TV broadcast known in the USA as NBC (via the website
http://www.nbc.com), then we can see that it has four different
schedules: E (Eastern), C (Central), M (Mountain), and P (Pacific).
These four TV broadcasts can be seen as four different ones, so we may
need the following tv:URIs:

* eastern.nbc.com
* central.nbc.com
* mountain.nbc.com
* pacific.nbc.com

On the other hand according to the website of the company 'owning' NBC,
NBC Universal, there are 10 TV stations transmitting NBC: WNBC (NBC4 New
York), KNBC (NBC4 Los Angeles), WMAQ (NBC5 Chicago), etc. So we may also
need the following tv:URIs:

* wnbc.nbc.com
* knbc.nbc.com
* wmaq.nbc.com
etc.

The tv:URI registry that we need here will contain the list of available
tv:URIs, i.e. eastern.nbc.com, wnbc.nbc.com, etc. and to each tv:URI in
the list information is associated identifying the TV broadcast. 

For instance:

tv:eastern.nbc.com => "The eastern schedule of the NBC TV broadcast in
the USA, website reference http://www.nbc.com"
tv:wnbc.nbc.com => "The TV broadcast transmitted by the TV station WNBC
(NBC4 New York) of NBC Universal, website reference
http://www.nbcuni.com/About_NBC_Universal/Company_Overview/overview02.sh
tml"

Regarding the involvement of the company NBC or the company GE in the
tv:URIs mentioned above:
* if they get involved in specifying the information associated to the
tv:URIs mentioned, they are very welcome. 
* if they do not want to get involved in specifying the information
associated to the tv:URIs mentioned, fine as well.
They do not have to get involved, but they are sure welcome.

The main relation with the DNS domain name nbc.com is by 'human'
association. Someone wanting to have information about
tv:eastern.nbc.com, might have a look at a website http://www.nbc.com as
mentioned in the tv:URI registry. Looking up the domain nbc.com (via
whois) would perhaps be less successful for explaining what
tv:eastern.nbc.com points at.

So actually there is in our view no hard relationship between tv:URIs
and domain names.

About the resolvability of tv:URIs we have a future hope that they might
become resolvable by automatic means. But in the mean time we are quite
happy at getting the list of available tv:URIs and some identifying
information. At configuration of a TV application, the tv:URI can then
be configured by human intervention after a lookup in the tv:URI
registry. Note that a similar situation already exists in Europe in case
of the use of Showview (see http://www.showview.com): each buyer of a
video/hard disk recorder with Showview needs to configure the mapping of
Showview channels onto actual TV channels.

Making the resovability dependent on the DNS system is not our intention
as this would *force* each tv:URI resolving to be dependent on the
cooperation of the domain name owner of the (super)domain in the tv:URI.

Iko Keesmaat (and Oskar van Deventer).

===============================
Iko Keesmaat
TNO Information and Communication Technology
The Netherlands
E-mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: maandag 2 oktober 2006 22:03
To: Deventer, M.O. (Oskar) van
Cc: [email-masked]; Keesmaat, N.W. (Iko); Zigmond, Dan
Subject: Re: Reigistry for tv:URI's

Some questions ...

Cheers,

Mark.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 3 Oct 2006 09:13:37 -0700

Resolvability might be a local matter in the meantime.  A device  
could have a configuration list of available channels containing  
their tv:URIs and their frequencies or other information on how to  
access.   Then when that device receives a tv: URI it is perfectly  
capable of turning on the right channel.  To schedule recordings or  
publicize showings, this could all be quite useful.

Lisa

---

From: "Keesmaat, N.W. \(Iko\)" <[email-masked]>
Date: Wed, 4 Oct 2006 12:37:22 +0200

Mark,

* eastern.nbc.com
* central.nbc.com
* mountain.nbc.com
* pacific.nbc.com

* wnbc.nbc.com
* knbc.nbc.com
* wmaq.nbc.com
etc.

For instance:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Baker
Sent: maandag 2 oktober 2006 22:03
To: Deventer, M.O. (Oskar) van
Cc: [email-masked]; Keesmaat, N.W. (Iko); Zigmond, Dan
Subject: Re: Reigistry for tv:URI's

Some questions ...

Cheers,

Mark.

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Oct 2006 17:59:34 -0400

> In our view the tv:URI should identify a TV broadcast. 

I am not sure that this is a good thing.  What is important about 
distinguishing tv: from other URIs?  Is it that the signal is encoded 
using NTSC or PAL?  Or will MPEG do?  Is it that the signal is 
transmitted using radio frequency electromagnetic radiation through the 
air?  Or is it okay if the signal is transmitted over cable?  What about 
satellite? Does it matter how it's modulated?

IMO, one of the goals of the tv: URI should be to permit convergence so 
that different sources of video programming can be viewed by the same 
computer program (or set-top box, whatever) while at the same time 
presenting the viewer with a reasonably clean user interface for 
selecting between different sources, and probably allowing those program 
sources to be linked to from other sources - say from a web page or 
email reader.  That doesn't inherently mean that tv: URI should be 
usable by any kind of video programming source, but it probably does 
mean that there should be _some_ level of naming which can be used by 
any kind of video programming source.

 From my point-of-view, whether tv: is the higher-level name that maps 
to one or more lower-level services, or whether tv: is a specific 
lower-level service and there's a higher-level name (say a URN) to 
describe the video programming source, is almost arbitrary - as long as 
the relationship between the two levels of naming is clear.  Though it 
seems that there is already some investment in the tv: URL prefix along 
the former lines.

Keith

---

From: "Keesmaat, N.W. \(Iko\)" <[email-masked]>
Date: Thu, 5 Oct 2006 09:36:06 +0200

Keith,

I do not understand what you driving at here. In RFC2838 the tv:URI was
explicitly defined as an identifier of television broadcasts.

Are we having a misunderstanding about what a TV broadcast is? 

What we are needing is a way to identify what people would call *the* TV
broadcast, i.e. if you have a device that can display NBC as received
over the air and NBC as received over the cable and they are displaying
the same television content at the same time, then that is what we would
like to refer to.

Whether or not you need NTSC decoding software/hardware to view the one
and PAL decoding software/hardware to view the other is not important.
That is lower level information that may be locally configured.

Does this make sense to you?

Iko.

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: donderdag 5 oktober 2006 0:00
To: Keesmaat, N.W. (Iko)
Cc: [email-masked]
Subject: Re: Reigistry for tv:URI's

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 05 Oct 2006 03:45:24 -0400

> Are we having a misunderstanding about what a TV broadcast is? 

perhaps.  that's why I was asking the questions I asked.  I don't 
understand where you want to draw the line between a "TV broadcast" and 
some other source of video programming. for example, we have "Internet 
radio" stations now, why not Internet TV stations?

offhand I think the difference between what I would call a "TV 
broadcast" and some other video program source is that a "TV broadcast" 
is immediate - that is, there are some set of viewers watching "in real 
time" (although of course it might also be possible to watch portions of 
it later) and the programming can therefore be chosen to fit the time at 
which it is broadcast.

> the same television content at the same time, then that is what we would

that's fine.  I just don't think that the notion of TV broadcasts 
covered by tv: URLs should exclude internet-only broadcasters.

Keith

---

From: "Keesmaat, N.W. \(Iko\)" <[email-masked]>
Date: Thu, 5 Oct 2006 10:11:51 +0200

> radio" stations now, why not Internet TV stations?
We do not want to exclude Internet TV stations, but we do not need a new
identifier to point at recorded video clips (such as Youtube.com).

> it later) and the programming can therefore be chosen to fit 
Exactly. The keywords here are: 'real time', and 'broadcast', i.e.
multiple viewers.

> covered by tv: URLs should exclude internet-only broadcasters.
It shouldn't.

Iko.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 5 Oct 2006 09:27:23 +0100

> need the following tv:URIs:

Except, as I understand it, they only have two or three, depending on how
you look at it - schedules. Thus to take a single programme, "Deal Or No
Deal Episode #209", this shows at:

    Eastern:  21:00 (01:00 UTC)
    Central:  20:00 (01:00 UTC)
    Mountain: 20:00 (02:00 UTC)
    Pacific:  21:00 (04:00 UTC)

So there are two "wall time" schedules (E/P and C/M) but three broadcasting
schedules (E/C, M, and P).

So how should we handle that? Are we interested in actual UTC broadcast
time or in local clock broadcast time?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: Keith Moore <[email-masked]>
Date: Thu, 05 Oct 2006 09:18:29 -0400

> identifier to point at recorded video clips (such as Youtube.com).

concur.

Keith

---

From: "Keesmaat, N.W. \(Iko\)" <[email-masked]>
Date: Mon, 9 Oct 2006 13:24:41 +0200

Clive,

> time or in local clock broadcast time?

You have a good point here.

I would consider any tv broadcast that is not showing the same program
at the same UTC time as different, because communication in the form:
"watch tv:yyy now!" would then become less useful.

So this argument would distinguish Eastern from Mountain and Pacific (at
NBC).

Remains the distinction between Eastern and Central. These two
broadcasts show (most likely) the same program at the same UTC time.

However, I still feel that they can be considered different (and thus
warrant different tv:URIs). A communication in the form: "watch the
upcoming program at tv:yyy at 20:00" would for instance be the wrong
communication if the tv:URIs of both tv broadcast are the same.

Ultimately it would be less of a problem of the same tv broadcast has
multiple tv:URIs pointing at it. But the reverse: a single tv:URI
pointing to multiple tv broadcast *is* a major problem.

So, for the moment I think it would be best to have both
tv:eastern.nbc.com and tv:central.nbc.com. And as argued above also
tv:mountain.nbc.com and tv:pacific.nbc.com.

Iko.