Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec)

[Gaelle Martin-Cocher <[e-mail]>]

Inline with [gmc]

-----Original Message-----
From: rtcweb [mailto:[e-mail]] On Behalf Of Harald Alvestrand
Sent: Wednesday, December 10, 2014 1:09 PM
To: [e-mail]
Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec)

Den 10. des. 2014 18:59, skrev Gaelle Martin-Cocher:
> The main problem is with what the terminology covers and its 
> inconsistent usage.
> 
>  
> 
> The WebRTC gateway in
> https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt is 
> defined as a WebRTC-compatible endpoint with some requirements being 
> applied to it.
> 
> I am not sure how the last sentence in the WebRTC-compatible endpoint 
> definition  "It is not constrained by this specification."  applies to 
> the gateway.

Renaming the term is certainly possible.

And this thread has certainly made the point that the -gateways draft needs to be informative, not standards-track.

[gmc] what does it change to be on the informative or standard track? VP8 is on the informative track too, right? Though VP8 or gateway would be "well defined". I don't see why it should not be the same for legitimate other WebRTC-to-be-renamed endpoints, that makes them easier to market. 

>  
> 
> If a mobile app is centered around text or text and audio, it should 
> not be relegated in the WebRTC-compatible endpoint category and should 
> be able to benefit from the WebRTC non browser/endpoint terminology .
> 
>  
> 
> If a WebRTC-compatible endpoint supports everything but a subset of 
> functions (e.g. does not support bundle)  there could be requirements 
> applied to it; in IETF or in other standardization groups that are 
> referring to the IETF terminology.


I see absolutely no reason to go down this path.
If you want a standard that specifies conformance to a spec that is part of the WebRTC spec, you are of course free to try to do so.

But I see no reason to join in on that journey.

[GMC] conformance is only one reason.
  
Let's take 3 sensor based hardware devices that do not need one feature (say audio for simplicity) and are used in home automation. Both indicate they are WebRTC-compatible devices on their packaging.  
Though they are different, one would have all the other WebRTC features including all security mechanisms, the second would have less security mechanisms, and the third, well, hard to say what it does. 
Tthe first device should benefit of the WebRTC enpoint terminology (as audio is not needed for that device), the second from the WebRTC-compatible terminology, the third maybe should not have any WebRTC related label.

How do a user know which one to pick and if each of them will work with my WebRTC mobile home automation apps with full protection or not if they are all called a WebRTC-compatible endpoint?

Basically that WebRTC-compatible label becomes irrelevant, though one product offers all of what is needed and not the other ones. 
How is it clear to the user that the Mobile home automation WebRTC endpoint is not the failing point when trying to interact with the second or third device?

Gaëlle




_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb