Re: [rtcweb] WebRTC endpoint categories

[Sergio Garcia Murillo <[e-mail]>]

On 11/12/2014 0:00, Ron wrote:
> [Changing the subject of this thread as requested earlier]
>
> On Wed, Dec 10, 2014 at 01:50:50PM -0800, David Singer wrote:
>> I don’t think we need to change definitions. In some specs, there is
>> an explicit “if the device supports the audio media type, it must…”
>> and I took it as implicit that that was the case for the codecs for a
>> given media type here. Users would not expect a device that states it
>> doesn’t do audio to interop on audio.  But if a device claims to be a
>> general-purpose device that supports audio and video in webRTC, I
>> think we’d all like it if it actually interoperated, right? Isn’t that
>> the main thrust of looking for MTI codecs?
> I'm afraid I'm missing the crux of the distinction you see if you think
> we're not just agreeing with each other now :)
>
> A device is a WebRTC endpoint (browser or not) if it implements the
> mandatory requirements of the WebRTC protocol (which includes MTI
> codecs).
>
> Anything which doesn't do that, but can otherwise do some subset of
> WebRTC to operate with WebRTC endpoints, in some unspecified here way,
> is in the WebRTC-compatible class of devices.  Whatever we end up
> calling those, if the definition remains the same, they can do anything
> they please, however they please, which obviously video and audio is a
> subset of.  I don't see how we could sensibly say they must not do
> either of those things at all, when the definition says they are not
> constrained by, or defined in, or implementations of, this spec.
>
> There's no confusion about the expectations for interop though, because
> they are "non-WebRTC" devices, so nothing at all can be expected except
> what the device itself says it is actually capable of.  They might
> implement some melange of various standards or they might be an entirely
> proprietary thing.  The IETF isn't really concerned with marketing
> appellations, these classes are just language to use in the spec itself
> when we need to say something referring to these categories of things.
>
> A device which doesn't implement the WebRTC protocol, doesn't implement
> the WebRTC protocol.  It doesn't really matter what its reasons for that
> might be, or what other things it does implement.  Does it?
>
> If I implement a protocol that shares the same first 8 octets with an
> IPv4 header, that doesn't mean I have implemented RFC 791.
>
>

+1 It is quite difficult to not agree with anything that Ron says.. :)

Also, I hear some people complaining about the definition of a WebRTC 
compatible endpoint, but it would be good if those people expose what 
are the changes that they want to introduce:
  -Remove webrtc compatible endpoints mentions from spec
  -Change definition of a webrtc compatible endpoint
  -Mandate webrtc compatible enpoints to implement both MTI video codecs

Best regards
Sergio