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

[Dave Crocker <[e-mail]>]

On 12/21/2013 9:28 PM, Justin Uberti wrote:
> I hope that it will be even simpler than that; merely a statement
> indicating that devices that can't send or receive a given media type
> need not concern themselves with the MTI codecs of that type.
>
> On Fri, Dec 20, 2013 at 1:36 PM, Dave Crocker <[e-mail]> wrote:
>     On 12/20/2013 1:32 PM, Justin Uberti wrote:
>         I do think we should have an affordance for audio-only devices that
>         don't need to concern themselves with video codecs, but that
>         seems like
>         a spec wording issue, and not a reason to throw out the idea of MTI.
>
>     What you are implying is multiple usage profiles, or configurations,
>     with specifics sets of MTIs for each.
>
>     Ideally, these should be built on top of each other, starting with a
>     core, minimal capability and then adding capabilities on top.
>
>     Pessimally, these would be non-overlapping configurations.


Except that the reality of what you describe isn't nearly as simple as 
it sounds.

You are proposing there be statements about what "mandatory to 
implement" features are not mandatory to implement.

What you describe is typically called a "profile".  Whatever its length, 
a profile defines a subset of some larger specification, and says what 
parts of the specification apply, and what parts don't.

The problem with writing a larger and more complicated specification, 
and then going back and writing a profile which says what parts of the 
specification are or are not in force, is that it's complex and 
confusing, when applied in large-scale.

Adoption of anything for the Internet is an ultimate example of 
"large-scale".  The issue isn't what you or I might find comfortable, 
but what works well across the very, very wide range of readers, 
developers and operators across the global Internet.

Historically, the approach that has worked far better for the Internet 
is to specify a small, tight, core that everyone MUST -- absolutely 
must, no exceptions -- implement, and then build upon that.  Add modules 
incrementally or in combination.

(Humans are better at processing conjunction than negation.  Profiling 
is a negation mechanism.  Incremental features is, of course, conjunction.)

If I am understanding the nature of what is being proposed with respect 
to codecs, it translates into:

      1.  Define a core rtcweb control mechanism that does not specify 
any MTI codecs.  Everyone must implement this core.  No exceptions.  By 
itself, this mechanism will not be usable, since /some/ codecs are 
needed.  But at least the control mechanism would be standardized.

      2.  Define suites of codecs -- possibly independent or overlapping 
suites -- for use by different rtcweb communities.

      3.  The hope is that some of these suites will come to dominate 
the industry.

The above merely tries to summarize what some others have been saying or 
implying.

The one point of concern is that #3 does not require open standards for 
the codecs.  It can; but it doesn't have to.

That is, the community process of adopting particular codecs might turn 
out to be dominated by entirely proprietary components.  So that while 
the control mechanism is an open public standard, the operational system 
is not.

When the Internet was first going into the mass-market, some products 
were labeled "based on Internet standards".  "Based on" was a 
code-phrase that meant that proprietary components were part of the 
product and rendered it non-interoperable with products from other vendors.

That's the risk of the no-MTI codec approach.

d/




-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net