Subject: RE: Update of RFC 2838, tv: URI

From: "Deventer, M.O. \(Oskar\) van" <[email-masked]>
Date: Wed, 23 Aug 2006 15:03:21 +0200

All,

I think Dan is absolutely right that there will always remain
ambiguities, as long as there is no central registry for the
identification of TV channels. I do not think anyone is proposing to
create such a registry, am I right? So, our task is to provide
guidelines to make the identification as unambiguous as possible, and
guidelines how to handle possible ambiguities (aliases/synonyms).

Let's take a look at the HBO channels for example. I checked their
website. They have lots of channels, each with its own website.

-hbo.com/hbo2

-hbo.com/hbosignature

-hbofamily.com

-hbo.com/comedyplex

-hbo.com/zone

-hbolatino.com

-etcetera.

What would be proper RFC 2838 identification(s) for these TV channels?
Would it help if we provide (lots of) additional examples that help
people deduce/derive these tv: URI's? Would it help when we suggest to
people how they could use the website name as inspiration to
deduce/derive the tv: URI?

I think that we should also provide guidelines on handling
synonyms/aliases. Let's take the HBO Family channel as example. Viable
RFC 2838 identifications for this TV channel would be e.g.

-tv:hbofamily.com

-tv:hbofamily.hbo.com

-tv:familiy.hbo.com

If my application knows only the first two and your application knows
only the latter two, there can still be interoperability. I my presence
application publishes "Oskar is now watching tv:hbofamily.com AKA
tv:hbofamily.hbo.com", then your application recognizes the second
synonym and makes the match. So you see that I am watching the HBO
Family channel. And if you click on the channel identification, your TV
may automatically zap to the that channel, if that is what your
application is programmed to do.

Do you think that such guidelines on tv: URI derivation/deduction and
synonym/alias handling would be useful?

Best regards,

Oskar

________________________________

From: Dan Zigmond [mailto:[email-masked]] 
Sent: dinsdag 22 augustus 2006 18:40
To: Keith Moore; Deventer, M.O. (Oskar) van
Cc: [email-masked]; Keesmaat, N.W. (Iko)
Subject: Re: Update of RFC 2838, tv: URI

I think I agree with Keith here. But first, I would like to emphasize
that there is no essentially "European" issue with RFC 2838. Rather, the
issue is that one cannot unambiguously deduce the correct tv: URL for a
given broadcaster without additional information. 

But this is a very loose sort of ambiguity, and it exists everywhere on
the Internet. You cannot deduce my email address unless I tell you;
based on my name and employer, it could easily be [email-masked],
for example, or [email-masked], or any of a very large number of
plausible things. The basic standards simply allow me to pick one, but
do not mandate which one I choose or how I tell you my choice.
Similarly, you can't deduce an HTTP URI from a  domain name either.
Google is free to support, say, http://www.google.com,
http://google.com, or http://foo.google.com (or any combination). Unless
someone tells your which one is in use, you can't accurately guess. The
situation with tv: is the same. 

Second, I don't see how supporting path components like
tv:bbc.co.uk/bbcone would solve the basic problem. You would still have
many potential ambiguities. As Oskar notes, there can be multiple web
sites for a given broadcast. But how do you know that the various sites
refer to the same underlying TV signal? You could use HTTP to detect
redirects (assuming all devices supporting tv: also support HTTP, which
is doubtful), but this can't be guaranteed to be a reliable indicator.
Perhaps the two different sites don't redirect, or use slightly
different content for some reason. Perhaps for a week, both
http://bbc.co.uk/bbcone and hhtp://bbc.co.uk/bbctwo redirect to the same
"Under Construction" page. Should the corresponding tv: URIs be treated
as equivalent during that week? And as Keith notes, web sites changes
fairly frequently, while new TV broadcasts are introduced very rarely
these days. 

In some cases, the opposite problem will exist, too. In the US, for
example, both HBO East and HBO West share the same web pages, because
they are the "same" channel, but with the West version delayed three
hours. Yet my TV receives both, and I need to be clear about which one
to tune to if I want to watch a given program since at any given moment
they are almost guaranteed to show distinct content. 

In summary, I agree that a problem exists with RFC 2838: there is no
universal way for everyone to agree on which tv: URIs refer to which TV
broadcasts. But I don't think the proposed change solves this problem.
The only solution I can think of is a central registry to which
broadcasters would be encouraged to submit unique tv: identifiers for
their broadcasts. 

     Dan

On 8/22/06, Keith Moore <[email-masked]> wrote: 

	>> broadcasters have not rushed to establish identifiers based
on this
	>> scheme
	> This is the good thing about the RFC 2838 tv: URI. It allows
me to
	> create internet-based services that point to TV channels
without being 
	> dependent on the collaboration of broadcasters. Many use cases
(see
	> previous posts in this thread) would not need such
collaboration, but
	> only an unambiguous identification of TV channels.
	
	I'm not sure it's entirely a good thing to have a scheme that
encourages
	creation of identifiers for broadcasters without their
participation.
	If nothing else, it seems like it would be difficult to keep the
	URI-to-broadcaster mappings up to date (say when they change
their 
	domain names, or call letters - maybe because a station is sold
to a new
	owner or wishes to change its target market) without the
cooperation of
	the broadcasters.
	
	I like the idea of using domain names in tv: URIs, but
broadcasters 
	should be allowed/encouraged to use DNS to associate information
about
	their channels with the TV URI.  I dislike the idea of using web
page
	addresses as tv: URIs for reasons mentioned earlier, but also
because
	web page addresses (including both the domain and a path) change
more
	frequently than domain names, as web sites get reorganized.
	
	Keith

-- 

------------------------ 
[email-masked]

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Aug 2006 09:49:25 -0400

> create such a registry, am I right? 

I don't think anyone has figured out how to solve the problem without 
creating a registry.  So yes, I'm inclined to think that if tv: is to be 
viable, there needs to be a registry.

Or maybe there should be two registries - a "video broadcast channel" 
registry and a "video content stream" registry.

The video broadcast channel registry would try to define a hierarchy for 
uniquely naming all ways of broadcasting video (terrestrial radio, 
satellite, IPv4 multicast, etc.).  The idea would be to make it obvious, 
for a particular kind of broadcast channel, where it fits in the hierarchy.

The "video content stream" registry populated by content channel sources 
would consist of a list of domain names that were owned by those 
sources.  There would then be a well-defined way for those domain owners 
to publish the mappings from those content streams to broadcast 
channels.  This mapping should allow a single content stream to be 
associated with multiple content channels; it should also allow the 
content stream to be associated with a content channel only at certain 
times.  This registry would serve two purposes - it would allow content 
streams to advertise information about their content and link it to tv: 
URLs; it would also serve to collect a list of all video content 
channels so that comprehensive information about such channels could be 
compiled without scanning every node in the DNS.

Keith