Picon
Picon
Favicon

Reigistry for tv:URI's

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.
(Continue reading)

Eliot Lear | 2 Oct 16:13
Picon
Favicon

Re: Reigistry for tv:URI's

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

Deventer, M.O. (Oskar) van wrote:
> 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?
(Continue reading)

Mark Baker | 2 Oct 22:03
Picon
Favicon
Gravatar

Re: Reigistry for tv:URI's

Some questions ...

On 10/2/06, Deventer, M.O. (Oskar) van <oskar.vandeventer <at> tno.nl> wrote:
> 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.

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
> RFC2838 - that it is not the intention that tv:URI's are resolved
> through the DNS.

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 (uri <at> w3.org)?

Cheers,

(Continue reading)

Picon
Picon
Favicon

RE: Reigistry for tv:URI's


Dear Eliot,

> FCC CDBS database ...
> ... available via OFCOM ...
> Is this something you will take advantage of?
What we would like to have is a registry that associates identifying
information with tv:URIs. As such, information from the databases that
you mentioned could be useful:
1) When registring a TV broadcast, there should be proof that the TV
broadcast exists. Info in the FCC database could serve as such a proof. 
2) Moreover, the tv:URI registration could include a reference to that
info in the FCC (or OFCOM) databases.

Note that we also want to include TV broadcasts that are not associated
to terrestrial frequencies, e.g. cable TV, satellite TV and IPTV.

Oskar

-----Original Message-----
From: Eliot Lear [mailto:lear <at> cisco.com] 
Sent: maandag 2 oktober 2006 16:14
To: Deventer, M.O. (Oskar) van
Cc: discuss <at> apps.ietf.org; Keesmaat, N.W. (Iko); Zigmond, Dan
Subject: Re: Reigistry for tv:URI's

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
(Continue reading)

John C Klensin | 3 Oct 12:59

Re: Reigistry for tv:URI's


--On Monday, 02 October, 2006 14:03 +0200 "Deventer, M.O.
\\(Oskar\\) van" <oskar.vandeventer <at> tno.nl> wrote:

> 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.
>...

> 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.

Just so you have your facts straight on starting, ICANN
(actually the IANA) made that delegation when instructed to by
the IAB, which  has management control of the ARPA TLD.  ICANN
was not involved in the choice of where it was delegated.

ICANN does occasionally create and registries on its own.  If
you want such a registry, you should be discussing it with
ICANN, not here.   But e164.arpa is not an example of an
ICANN-created or managed registry.

> Ad 3) The registry will contain a list of unique tv:URI's, to
>...
(Continue reading)

Picon
Picon
Favicon

RE: Reigistry for tv:URI's

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
(Continue reading)

Lisa Dusseault | 3 Oct 18:13
Favicon

Re: Reigistry for tv:URI's

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

On Oct 3, 2006, at 4:06 AM, Keesmaat, N.W. (Iko) wrote:

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.


Picon
Picon
Favicon

RE: Reigistry for tv:URI's

John,

> Just so you have your facts straight
> ... ICANN ... IANA ... IAB ... e164.arpa
Thank you for these facts.

What I want to achieve is that the new registry will be accredited. Like
e164.arpa is the "golden tree" of user ENUM, the registry should become
the "golden registry" for tv:URIs. Do you have a suggestion how we could
achieve this?

> large volume of information, with additions being 
> made on a very frequent basis
What is the reason of your worry? Verisign handled about 5000 new .com
registrations yesterday. In contrast, how many new television broadcasts
have been introduced in the USA yesterday? And how many stations have
changed call sign yesterday? One perhaps? Or were there no changes at
all yesterday?

> If a station changes ownership but not call
> signs, do URIs remain stable?  
> ...mechanisms to keep the registry up to date? ...
> If programming belongs to a producer, how is that
> reflected in the system?
> stable enough to be useful?
> ...how would you propose to enforce that?
These are all valid questions, which we will work out in more detail in
an internet draft.
-As tv:URIs identify television broadcasts, a change of ownership is
irrelevant to the tv:URI. If there is anyone who wants to have the
ownership info changed in the registration record, then he can request
that and the registry will make the change.
-The whole idea of "nomination" is that if nobody asks for changes, no
changes are made. If I were a service provider of advanced television
presence and messaging services, I would regularly check if there are
new TV channels that my customers are watching, and make an effort to
keep the registry up to date, at least for the TV channels in my area.

> why a "guess the URI" mechanism with central, 
> infrastructure, administration makes sense.  
At the discuss <at> apps.ietf.org mailing list some consensus seemed to arise
that without a central registry it would not be possible to have an
effective use of tv:URIs. The initial RFC (RFC2838) indeed proposed a
"guess the URI" mechanism, but enough examples have been given
illustrating that this would always lead to ambiguity. The proposal of
having a central registry is not to go into a "guess the URI" mode, but
to have a database for looking up the "proper" tv:URI. Of course once
such a central database (a.k.a. registry) exists, search machines may be
employed for finding a particular tv:URI. The use of the tv:URI,
however, should not be dependent on the use of search machines. It is
highly preferable that it be possible for humans to type in a television
broadcast identifier (after having searched the tv:URI in the registry,
or by reading it from advertisements or otherwise).

> via ITU, probably the Radio Sector
ITU-R is about frequencies and call signs of terrestrial radio/TV
broadcasts (i.e. making use of through-the-air radio waves). It is not
about cable TV, nor satellite TV, nor IPTV, nor webTV. tv:URIs are about
television broadcasts, independent of the transmission technologies
used, see RFC2838.

> trademark and control issues
One of the tasks of the tv:URI registry is to handle trademark issues.
This is exactly the same as with DNS registry's. 

Oskar van Deventer & Iko Keesmaat 

-----Original Message-----
From: John C Klensin [mailto:john-ietf <at> jck.com] 
Sent: dinsdag 3 oktober 2006 12:59
To: Deventer, M.O. (Oskar) van; discuss <at> apps.ietf.org
Cc: Keesmaat, N.W. (Iko); Zigmond, Dan
Subject: Re: Reigistry for tv:URI's

--On Monday, 02 October, 2006 14:03 +0200 "Deventer, M.O.
\\(Oskar\\) van" <oskar.vandeventer <at> tno.nl> wrote:

> 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.
>...

> 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.

Just so you have your facts straight on starting, ICANN
(actually the IANA) made that delegation when instructed to by
the IAB, which  has management control of the ARPA TLD.  ICANN
was not involved in the choice of where it was delegated.

ICANN does occasionally create and registries on its own.  If
you want such a registry, you should be discussing it with
ICANN, not here.   But e164.arpa is not an example of an
ICANN-created or managed registry.

> Ad 3) The registry will contain a list of unique tv:URI's, to
>...

> 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.

I think you are going to have tremendous difficulty keeping such
a registry active and useful.  I see at least two important
problems in that regard.  

First, a per-broadcast registry could, in principle, contain a
large volume of information, with additions being made on a very
frequent basis.  Using it as an example, additions to e164.arpa
occur on a frequency of weeks or months and we know that there
can be a maximum of only a few hundred entries, ever.  If you
are really talking about registering broadcasts, that may
entries could accumulate in much less than an hour.  Even if you
intend to register broadcasters or stations, the number is huge.

These broadcasters, call signs, and hence, usually, station
names and station-related URLs are subject to a significant
number of governmental regulations, as well as ownership issues
for both stations (broadcasters) and broadcasts that differ from
country to country.  If a station changes ownership but not call
signs, do URIs remain stable?  If a station retains management
and programming but changes call signs, do URI's remain stable?
If a station reorganizes its web presence, what are the
incentives and mechanisms to keep the registry up to date?  If
programming belongs to, and is made available from, a producer
or network, rather than linked to a station, how is that
reflected in the system?  And so on.  In addition, given any of
the above changes, how would you expect to keep a URI that is
nominated/registered by the public (someone with no affiliation
to the broadcaster or content producer) stable enough to be
useful?  Does the registrant take on any formal obligation to
manage the link and keep it up to date and how would you propose
to enforce that?

Two constructive observations and suggestions: 

(1) What has been missing from your discussions so far is why a
"guess the URI" mechanism with central, infrastructure,
administration makes sense.  When I think of all the different
ways I might want to find a broadcaster or broadcast, I start
thinking about directories and search engines.  But, if those
are the entry points, the form of the URI they uncover is
largely irrelevant.   And, if directories or search engines or
databases of some sort are the answer, then you are discussing a
business opportunity, not something that is appropriately or
usefully within IETF's domain.

(2) If there is a need for the infrastructure to support a URI
with more or less elaborate structure and semantics, it may
actually be useful discussion to initiate via ITU, probably the
Radio Sector rather than the Telecommunications Standards one.
They have the necessary connections with the call-sign machinery
and regulators to have a serious discussion about what would be
necessary to create a stable identifier and to persuade the
relevant actors to pay attention.

Going down that path would also eliminate the trademark and
control issues pointed out by others.

    john

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

John C Klensin | 4 Oct 14:10

RE: Reigistry for tv:URI's


--On Wednesday, October 04, 2006 13:47 +0200 "Deventer, M.O. 
\\(Oskar\\) van" <oskar.vandeventer <at> tno.nl> wrote:

>...
> What I want to achieve is that the new registry will be
> accredited. Like e164.arpa is the "golden tree" of user ENUM,
> the registry should become the "golden registry" for tv:URIs.
> Do you have a suggestion how we could achieve this?

No.   e164.arpa depends on two things that may seem invisible. 
One is management of the registry (to the extent needed) by IAB, 
not IANA or some other structure.  IANA has no, or substantially 
no, experience managing registries of this type.  The second is 
that RIPE-NCC is authorized to charge cost-recovery fees if 
needed to support the registry... and the registry is, as I 
mentioned, small and of low volatility.

>> large volume of information, with additions being
>> made on a very frequent basis

> What is the reason of your worry? Verisign handled about 5000
> new .com registrations yesterday. In contrast, how many new
> television broadcasts have been introduced in the USA
> yesterday? And how many stations have changed call sign
> yesterday? One perhaps? Or were there no changes at all
> yesterday?

Verisign maintains a very large and expensive infrastructure to 
add that many registrations.  They have an elaborate system of 
registrars for dealing with end users, most of which charge fees 
or are otherwise in business to make a profit.  When there are 
conflicts about names, there are ICANN-imposed policies about 
mechanisms for resolving them.    I don't see any of that in 
your proposal.    And, if a URI is to potentially point to a 
particular broadcast and not to "a series" (whatever that means 
when one gets down to precise definitions) then the answer to 
"how many" is in the thousands or more.

>> If a station changes ownership but not call
>> signs, do URIs remain stable?
>> ...mechanisms to keep the registry up to date? ...
>> If programming belongs to a producer, how is that
>> reflected in the system?
>> stable enough to be useful?
>> ...how would you propose to enforce that?
> These are all valid questions, which we will work out in more
> detail in an internet draft.
> -As tv:URIs identify television broadcasts, a change of
> ownership is irrelevant to the tv:URI. If there is anyone who
> wants to have the ownership info changed in the registration
> record, then he can request that and the registry will make
> the change.

But, if a change of ownership leads to a change of domain name 
(which it often does), then, unless the URIs are not dependent 
on those domain names, they immediately become invalid or, 
worse, subject to errors as domain names are transferred or 
otherwise reused.

> -The whole idea of "nomination" is that if nobody asks for
> changes, no changes are made. If I were a service provider of
> advanced television presence and messaging services, I would
> regularly check if there are new TV channels that my customers
> are watching, and make an effort to keep the registry up to
> date, at least for the TV channels in my area.

Then perhaps one wants to create a URN tree of service providers 
and let them take care of the broadcast URI records.

>> why a "guess the URI" mechanism with central,
>> infrastructure, administration makes sense.

> At the discuss <at> apps.ietf.org mailing list some consensus
> seemed to arise that without a central registry it would not
> be possible to have an effective use of tv:URIs. The initial
> RFC (RFC2838) indeed proposed a "guess the URI" mechanism, but
> enough examples have been given illustrating that this would
> always lead to ambiguity. The proposal of having a central
> registry is not to go into a "guess the URI" mode, but to have
> a database for looking up the "proper" tv:URI. Of course once
> such a central database (a.k.a. registry) exists, search
> machines may be employed for finding a particular tv:URI. The
> use of the tv:URI, however, should not be dependent on the use
> of search machines. It is highly preferable that it be
> possible for humans to type in a television broadcast
> identifier (after having searched the tv:URI in the registry,
> or by reading it from advertisements or otherwise).

I am not convinced, but will wait to see a _very_ specific 
proposal.

>> via ITU, probably the Radio Sector

> ITU-R is about frequencies and call signs of terrestrial
> radio/TV broadcasts (i.e. making use of through-the-air radio
> waves). It is not about cable TV, nor satellite TV, nor IPTV,
> nor webTV. tv:URIs are about television broadcasts,
> independent of the transmission technologies used, see RFC2838.

Yes, but you are moving into a newer space.  Or consider ITU-T, 
since a few of their SGs seem to be willing to claim authority 
over anything transmitted electronically.

>> trademark and control issues
> One of the tasks of the tv:URI registry is to handle trademark
> issues. This is exactly the same as with DNS registry's.

Actually, DNS registries, especially the generic ones, have 
elaborate rules to avoid getting embroiled in those 
controversies.  See above, or have a look at ICANN's web site 
and their discussions about "dispute resolution".

      john

Picon
Picon
Favicon

RE: Reigistry for tv:URI's

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: iko.keesmaat <at> tno.nl

-----Original Message-----
From: mbaker <at> gmail.com [mailto:mbaker <at> gmail.com] On Behalf Of Mark Baker
Sent: maandag 2 oktober 2006 22:03
To: Deventer, M.O. (Oskar) van
Cc: discuss <at> apps.ietf.org; Keesmaat, N.W. (Iko); Zigmond, Dan
Subject: Re: Reigistry for tv:URI's

Some questions ...

On 10/2/06, Deventer, M.O. (Oskar) van <oskar.vandeventer <at> tno.nl> wrote:
> 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.

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
> RFC2838 - that it is not the intention that tv:URI's are resolved
> through the DNS.

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 (uri <at> w3.org)?

Cheers,

Mark.

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


Gmane