RE: DNS and some of my ideas

I think I need to clarify a couple of my ideas and make a few points.

By channel number I mean the channel slot on the client device not channel
frequency.  Channel numbers are unique, it's the content of a channel number
which may be localised.  Channels and channel numbers should be
deterministic within locale and are required in parallel to any name based
scheme.

Channel Numbers are essential for channel browsing using channel +/-
functionality and for short-cut channel choice.

Consider an consumer scenario for choosing a Channel by:
- number, consumer enters: "001" (Can use IR-remote, keyboard not
compulsory, quite elegant).
	- name, consumer enters: "1.bbc.co.uk" (keyboard compulsory and
would be unworkable in practice).

If tv:<channel number> is excluded some alternative for channel +/- is
required.  This would still require some form of localised channel mapping,
so I don't see the benefit of excluding channel numbers.
e.g.
	tv:+
	tv:-

I agree that some form of DNS is required for name directed channel choice
for broadcasts.  However I think content will also increasingly be provided
on demand, rather than via broadcast.  I also think that this content will
be provided by third parties in addition to the basic service provider (i.e.
a local cable company) and it's somewhat disingenuous to assume otherwise.

It is for this reason that content directed URL's are required and why I
specifically used the .FILM & .SHOW tld's.  A pleasant side effect of this
approach is that it also neatly avoids the namespace clashes caused by
promotional WWW sites.

NB: The views and opinions expresses in this message may or may not reflect
the views of my employer

Martin Spamer
Senior Software Engineer
Kingston Vision LTD
Phone +44 (0) 1482 602 892
Fax +44 (0) 01482 602 899
E-Mail martin_spamer@kingston-comms.co.uk
<mailto:martin_spamer@kingston-comms.co.uk> 
http://www.kingston-vision.co.uk/ <http://www.kingston-vision.co.uk/> 

	-----Original Message-----
	From:	Martin Spamer [SMTP:martin_spamer@kingston-comms.co.uk]
	Sent:	Monday, October 11, 1999 1:07 PM
	To:	www-tv@w3c.org
	Subject:	DNS and some of my ideas


	Overall I prefer the DNS style scheme.  However I believe that a tv:
scheme
	should be as inclusive as possible and therefore should also support
both
	the channel number and encompass the ITU callsign style scheme. I
believe
	this would allow this scheme to be used on both closed and open
networks.

	e.g.
		tv:<channel no>
	or	tv:<broadcaster>
	or	tv:<network>
	or	tv:<callsign>		or	tv:<callsign>.itu
or
	tv:<callsign>.itu.org

	i.e.
		tv:999
	or	tv:bbc.co.uk	
	or	tv:one.bbc.co.uk	or	tv:1.bbc.co.uk
	or	tv:kqed				or	tv:kqed.itu
	or	tv:kqed.itu.org

	I also feel consideration needs to be given to content centric URL's
	particularly for On-Demand content such as VOD.  I believe a key
issue is
	should this be tied into the service provider or the content,
consistency
	probably means being tied in to a DNS for the service provider.
Flexibility
	& extensibility probably requires allowing for both, with some
additional
	'virtual' domain extensions for content.  If we use a content
centric scheme
	we should also include language/country versions to be addressed.

	Below are a few ideas on how this would be achieved using the
following
	notation:
	<description>	description of element.
	{option}			an optional item.
	<one>|<other>	select either or other.

	e.g.
		tv:<service name>/<content name>/{<season|series>/}<episode>
	or	tv:<title>.<programme|show>.film{.<country>}
	or	tv:<episode name> | <episode
	number>.<programme|show>.show{.<country>}

	i.e.
		tv:vod.net/south park/the movie/
		tv:vod.net/south park/103/
		tv:vod.net/south park/volcano/

	or	tv:the-movie.southpark.film		default
language/country
	version of original content. 
		tv:the-movie.southpark.film.jp	Japanese language version.
		tv:the-movie.southpark.film.de	German language version.

	or	tv:103.southpark.show
		tv:volcano.southpark.show

	I also have a question for those with a better understanding signal
encoding
	than I have:

	Q) Do we need to consider the format of the content streams, so for
example,
	if my consuming device takes a mpeg encoded PAL content stream, It
would
	only be valid to connect to PAL sources. Therefore should the prefix
be
	content format specific:
	e.g.
	MPEG:	
	PAL:
	NTSC:
	SECAM:
	i.e.
	MPEG:the-movie.southpark.film
	PAL:one.bbc.co.uk
		NTSC:abc.com
	SECAM:abc.net.au

	Or do we assume the server know the content format or that client
device can
	translate?

	NB: The views and opinions expresses in this message may or may not
reflect
	the views of my employer

	Martin Spamer
	Senior Software Engineer
	Kingston Vision LTD
	Phone +44 (0) 1482 602 892
	Fax +44 (0) 01482 602 899
	E-Mail martin_spamer@kingston-comms.co.uk
	<mailto:martin_spamer@kingston-comms.co.uk> 
	http://www.kingston-vision.co.uk/
<http://www.kingston-vision.co.uk/>

Received on Monday, 11 October 1999 13:50:10 UTC