Next message: Tom Worthington: "RFC: Internet-TV Convergence at Communications Research Forum, 26 Sep"
Date: Tue, 14 Aug 2001 17:40:25 -0500 (CDT)
Message-Id: <200108142240.RAA15747@isis.visi.com>
From: "Craig A. Finseth" <fin@finseth.com>
To: rh@matriplex.com
Cc: martin_spamer@kingston-comms.co.uk
Cc: www-tv@w3.org
Subject: Re: OT : Proposed DTV channel changing packet
> I am about to submit an Internet-Draft for a DTV channel changing packet
> and protocol to the IETF, and thought you might have an interest in this
> matter. The IETF is closed for submissions until the 14th while they have
> their meeting, but I would be glad to have your comments or suggestions
> before submitting the first draft.
>
> You can get a copy of the draft at:
> http://www.matriplex.com/docs/draft-hodges-dtv-chanchange-00.txt
Some quick comments on this proposal:
- There are 16 bits of bandwidth in units of 1000 bps. The total that
can be expressed is thus around 64 Mbps. Given Gigabit Ethernet, it
seems silly to propose a new protocol that can't support existing
networks.
Suggestion: make each 32 bits (in units of 1000 bps). This gives
speeds up to at least 4 terabits.
- Channel should be specified as tv:<name> URIs (so don't worry about
having a fixed, 100-byte packet size). The interface between URIs
and channel numbers is handled by the guide client.
- You should be able to specify the client's time zone (e.g., for
sorting out east and west coast feeds).
- In the US. you will need to be able to specify the client's location
(either in the request or by reference to a database) to determine
which local channels should be delivered. (This requirement is
mandated by legislation.)
- There should be a protocol switch byte and one address.
- There should be a way of adding optional data (e.g., descriptors)
for future needs.
Craig