Re: DNS and some of my ideas

From: Michael A. Dolan (
Date: Mon, Oct 11 1999

Message-Id: <>
Date: Mon, 11 Oct 1999 07:52:40 -0700
From: "Michael A. Dolan" <>
Subject: Re: DNS and some of my ideas

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: 
>should be as inclusive as possible and therefore should also support 
>the channel number and encompass the ITU callsign style scheme. I 
>this would allow this scheme to be used on both closed and open 
>	tv:<channel no>
>or	tv:<broadcaster>
>or	tv:<network>
>or	tv:<callsign>		or	tv:<callsign>.itu		or
>	tv:999
>or	or
>or	tv:kqed				or	tv:kqed.itu

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:


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, 
>probably means being tied in to a DNS for the service provider.  
>& extensibility probably requires allowing for both, with some 
>'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 
><description>	description of element.
>{option}			an optional item.
><one>|<other>	select either or other.
>	tv:<service name>/<content name>/{<season|series>/}<episode>
>or	tv:<title>.<programme|show>.film{.<country>}
>or	tv:<episode name> | <episode
> park/the movie/
> park/103/
> park/volcano/
>or		default language/country
>version of original content. 
>	Japanese language version.
>	German language version.

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 
>than I have:
>Q) Do we need to consider the format of the content streams, so for 
>if my consuming device takes a mpeg encoded PAL content stream, It 
>only be valid to connect to PAL sources. Therefore should the prefix 
>content format specific:

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

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 


Version: PGP for Personal Privacy 5.0
Charset: noconv


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