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

[Eric Rescorla <[e-mail]>]

On Sun, Dec 22, 2013 at 2:20 PM, Dave Crocker <[e-mail]> wrote:
> 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.

I don't think that's what Justin is suggesting.

Rather, I think he's suggesting is that if you don't do video, for
instance, you need not do the video MTI codec.

To take a simple example, a number of phones do not have front-facing
cameras and also have processors that are incapable of doing an
adequate video call (especially if we select a codec for which they
don't have adequate hardware support). 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?

This seems like an orthogonal question to whether devices that do
video MUST do a given video codec.

-Ekr