headers
Keesmaat, N.W. (Iko | 4 Oct 12:37
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)

Permalink | Reply |
headers
Clive D.W. Feather | 5 Oct 10:27

Re: Reigistry for tv:URI's

Keesmaat, N.W. (Iko) said:
> 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

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:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:    +44 870 051 9937
(Continue reading)

Permalink | Reply |
headers
Keesmaat, N.W. (Iko | 9 Oct 13:24
Picon
Picon
Favicon

RE: Reigistry for tv:URI's

Clive,

> > need the following tv:URIs:
> > 
> > * eastern.nbc.com
> > * central.nbc.com
> > * mountain.nbc.com
> > * pacific.nbc.com
> 
> 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?

You have a good point here.
(Continue reading)

Permalink | Reply |
headers
Deventer, M.O. (Oskar) van | 4 Jul 11:35
Picon
Picon
Favicon

ETSI TISPAN interest in tv:URI

All,

The issue of identification of television channels has been discussed in
the ETSI TISPAN 14bis meeting of last week. The application of this
identification is IPTV Presence: a presentity can publish which TV
channel he is watching. The fact that ETSI TISPAN has requirements
related to the identification of TV channels (e.g. tv:URI) is reflected
in the recent update of our internet draft
http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-01.txt.

TISPAN WG1 (services) and WG2 (architecture) have defined the following
requirements, relevant to our IETF APPS mailing list discussions on the
tv:URI last October.

========== Start of TISPAN requirements ==========

WI01044 (Draft TS 181 016):
"Users' presence information may be related to, e.g., their connection
status, location information, channel currently accessed or acceptable
communication means. Presence information on channel currently accessed
may be used by another user to instruct his set-top box with a single
click to switch to the identified channel, or to instruct his set-top
box to keep following identified channel changes. There may be
significant delays in this following, depending on the update speed of
the presence service.
Any published presence information should only be disseminated other
users that are authorised to receiving this presence information
according to the presentity policies
Users can also define a set of access rules to control access to their
presence information.
(Continue reading)

Permalink | Reply |
headers
Deventer, M.O. (Oskar) van | 1 Nov 10:36
Picon
Picon
Favicon

RE: ETSI TISPAN interest in tv:URI

All,

The issue of identification of television channels for IPTV Presence has
been discssed at the ETSI TISPAN 14ter and 15 Plenary meetings. This has
lead to the start of a new Work Item in Working Group WG4. 

The new Work Item WI 4014 is titled "Guidelines on TV URI use for the
identification of television channels", see
http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=27318.

The subject of IPTV Presence itself ("my buddies being able to see which
TV channel I am watching") will be documented in the protocol document
TS 183 063 "IMS-based IPTV stage 3 specification", see
http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=26367

TISPAN WG4 (identifiers) has allocated a session in next TISPAN meeting
dedicated to "Guidelines on TV URI use for the identification of
television channels"". The meeting details are as follows, see
http://webapp.etsi.org/MeetingCalendar/MeetingDetails.asp?mid=11493.

Meeting: TISPAN4-TISPAN WG4 Ad Hoc 
Location: ETSI Headquarters, Sophia Antipolis
Dates: 26-30 November 2007

With this email, I would like to invite interested parties to
participate and/or contribute to this ETSI TISPAN WG4 work.

Best regards,

Oskar
(Continue reading)

Permalink | Reply |
headers
Keith Moore | 4 Oct 23:59
Picon

Re: Reigistry for tv:URI's

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

Permalink | Reply |
headers
Keesmaat, N.W. (Iko | 5 Oct 09:36
Picon
Picon
Favicon

RE: Reigistry for tv:URI's

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.

===============================
Iko Keesmaat
TNO Information and Communication Technology
E-mail: iko.keesmaat <at> tno.nl

-----Original Message-----
From: Keith Moore [mailto:moore <at> cs.utk.edu] 
Sent: donderdag 5 oktober 2006 0:00
To: Keesmaat, N.W. (Iko)
(Continue reading)

Permalink | Reply |
headers
Keith Moore | 5 Oct 09:45
Picon

Re: Reigistry for tv:URI's

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

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.

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

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

Keith
Permalink | Reply |
headers
Keesmaat, N.W. (Iko | 5 Oct 10:11
Picon
Picon
Favicon

RE: Reigistry for tv:URI's

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

> 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.
Exactly. The keywords here are: 'real time', and 'broadcast', i.e.
multiple viewers.

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

Iko.

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

Permalink | Reply |
headers
Keith Moore | 5 Oct 15:18
Picon

Re: Reigistry for tv:URI's

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

concur.

Keith
Permalink | Reply |
headers
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)

Permalink | Reply |
headers
Deventer, M.O. (Oskar) van | 4 Oct 13:47
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
(Continue reading)

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

Permalink | Reply |

Gmane