- From: Craig A. Finseth <fin@finseth.com>
- Date: Tue, 14 Aug 2001 17:40:25 -0500 (CDT)
- To: rh@matriplex.com
- Cc: martin_spamer@kingston-comms.co.uk
- Cc: www-tv@w3.org
> 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
Received on Tuesday, 14 August 2001 18:40:33 UTC