Re: DNS and some of my ideas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 01:06 PM 10/11/99 +0100, Martin Spamer wrote:
>
>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 think the group is moving away from the above multiple syntaxes as 
confusing and ambiguous, in favor of the DNS-based naming only.

Use of ITU callsigns is fine, although FYI, they might do something 
more like:

	tv://kqed.transmitters.itu.int

in case ITU wants to do something else with the namespace besides 
transmitter callsigns.

>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

The above overloads the tv: namespace (see above), and binds a 
program to a service (see earlier email why this is bad).  Both of 
these are undesirable features of TV URI schemes in my opinion.

>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

No.  MPEG is both a content encoding and a transport name (where's 
that Glossary when you need it ;-)  The others are electrical formats 
that identify final transmitter emissions.  A content author using 
URI's is unlikely to know how the program or service is being finally 
delivered to a user when thinking up URI's.

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

Most of us believe that the schemes we are pondering now must be 
transport independent.  There may be a use for transport-dependent 
schemes (dvb: or dsmccc:, for example), but they would not be folded 
into these schemes.  Thus, the transport encoding needs to be left 
out.

	Mike

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBOAH5tyl9dIG/haQGEQI3cgCfSPsKzVqWuJKlEe+/U0sqd0nDNW0AnR2l
9V/mJjb5wh8Wu0WmcAHk+CBo
=tklv
-----END PGP SIGNATURE-----

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122

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