Re: [rtcweb] confirming sense of the room: mti codec

[Ron <[e-mail]>]

On Wed, Dec 10, 2014 at 12:17:36PM +0100, Eric Rescorla wrote:
> On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <[e-mail]>
> wrote:
> 
> > My bad.
> >
> > New question:  How can an endpoint that implements video but none of the
> > MTI codecs be construed as "WebRTC Compatible"?
> >
> 
> Well, this seems like a generic complaint about the term "compatible",
> since such
> endpoints are explicitly not required to meet any requirements:
> 
>      A WebRTC-compatible endpoint is an endpoint that is able to
>       successfully communicate with a WebRTC endpoint, but may fail to
>       meet some requirements of a WebRTC endpoint.  This may limit where
>       in the network such an endpoint can be attached, or may limit the
>       security guarantees that it offers to others.  It is not
>       constrained by this specification; when it is mentioned at all, it
>       is to note the implications on WebRTC-compatible endpoints of the
>       requirements placed on WebRTC endpoints.
> 
> 
> So, perhaps we need a new term, but this doesn't seem like an issue limited to
> video codecs

Yes, I thought the definition was already very clear; but given that even
with Adam's clarification, people in this group (who you might reasonably
expect to have read these documents) appear to be confused, are already
transmuting the defined term WebRTC-compatible to "WebRTC Compatible" or
even "WebRTC compliant", and are foreshadowing their fear that some
implementers might abuse this to deliberately mislead the market (for
whatever that is worth); then maybe renaming this term is useful.

Maybe s/WebRTC-compatible endpoint/non-WebRTC endpoint/ ?

That would be consistent with "It is not constrained by this specification",
would still include my WebRTC controlled coffee maker, and might better
avoid any sort of "Vista Capable" vs "Vista Ready" word games.

  Ron