RE: ULE encryption Support.

["Allison, Art" <AAllison@nab.org>]

As to backwards compatibility, no mater how it is defined, the initial
products will not process and use newly defined data. So, even if the
original product can process the larger header, it can do nothing with data
with a new meaning defined after the product is built: 
With a bit = 0 it is the 'Rev0' standard device Gen0.
With a bit = 1 a Gen0 device cannot process the <new> data, but can process
all Rev0 data.
With a series of bits, a Gen0 device cannot process the <new> data, but can
process all Rev0 data.
At each header instance a different type can be signaled. 

Bits are bucks for broadcasters, and each one has a fixed pipe size, so we
must resist sending any more than absolutely needed.  I can make a case for
NO expansion bit, as the new service can be defined when the application is
defined and new devices can process it -- but 1 bit per header is ok. 

Please help me see what I must be missing that justifies use of more bits...
Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418


-----Original Message-----
From: Alain RITOUX [mailto:alain.ritoux@6wind.com]
Sent: Monday, March 01, 2004 12:08 PM
To: ip-dvb@erg.abdn.ac.uk
Subject: Re: ULE encryption Support.




Allison, Art wrote:

> So, if we should not encrypt at this layer [agree with Alain] and we
should
> not put additional error correction at this layer.. it seems we no longer
> have a reason to add more than a just-in-case escape bit just in case a
> yet-to-be-invented function is needed someday.  

Not totally agree. This "reserve" may have no usage now, but the
mechanism is not that heavy, and once it is done, it will allow
introduciton of "possible" ext headers in a backward-compatible
way, which seems to me worth the price.

Cheers
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com