Re: [rtcweb] Is there room for a compromise? what about no MTI?

[Dave Crocker <[e-mail]>]

On 12/22/2013 2:28 PM, Eric Rescorla wrote:
> In that case, it might be
> reasonable to simply not offer video at all on such devices.  In such
> a case, would it really make sense to call such devices non-compliant
> for not implementing an MTI video codec that they wouldn't negotiate
> in any case?


The complement to the implication of your above is whether it makes 
sense to specify a large "complete" system that you know will not be 
implemented in some cases?

I didn't say that a profiling approach was "wrong".  I said it is more 
complex and therefore riskier.  Profiling is an example of a big-system 
approach to specification.  It usually requires more time, less group 
process discipline, and more difficult adoption and interoperability 
patterns.

Why not simplify things considerably, by distinguishing between the core 
that everyone really /does/ have to implement, for whatever level of 
interoperability is required for everyone?  Then specify whatever 
/additional/ functional suites are needed for specific, tailored 
applications, such as the one you cite?

Again, if I'm understanding the basics here, we have two approaches that 
are logically equivalent, but differ in complexity for some cases.

That is:

1.  Profiling approach

     Read and understand --

     a. MTI:  Control base, component 1, component 2, component 3,
              component 4, component 5, component 6...

     b. Ignore component 2, component4, component 5


2. Incremental approach

    Read and understand --

    a. MTI:  Control base
    b. MTI:  Component 1, Component 3, component 6

Remember that the question of complexity for humans is not an arithmetic 
functions.  More components to process means exponential increases in 
complexity.  Hence, the second is easier to work with, for large numbers 
of average implementers around the world.

d/

ps. As an example of the challenges with negation, note that Justin's 
and your messages did not properly handle the Reply-to field of the 
messages I sent.  Instead, your email client sent the mail to the From: 
address and ignored Reply-to:, although Reply-to: is supposed to 
override From:.  This is a mechanism that has been in our email 
standards for more than 35 years and folks still get it wrong! 
Reply-to: is an exceptional (override) mechanism and indeed, 
implementers often get those wrong. Profiling is a form of exceptional 
specification style.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net