Is the goal to make RTCweb as complex as possible to meet an irrelevant use case, while ensuring we bring various regulatory agencies into our pants?

Last I looked, RTCweb is about the Web.  Why try to bring legacy telco/ecrit requirements into an application that 99.8% of the time has no interaction with classic emergency services? If someone will build a "telephony terminal," they are already into regulation land, and will build this descendant of Zaphod Beeblebrox appropriately. I agree that there is no reason to make it harder for someone to build a regulated device with RTCweb protocols. However, I also do not see any reason to postpone RTCweb by 3-5 more years as we try to second guess regulatory requirements. Worse yet, we would be asking for regulators to insert themselves into the protocol development process. That is all we need - the next thing they will do is require voting by governments on protocol components! Might as well move the work to the ITU-T so we do not distract people working on the Internet from getting useful work done here in the IETF.

On Feb 1, 2013, at 7:54 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> While we didn't go into it in any depth in the document, there does seem to be a distinction between scenarios in which the application developer has little control over the endpoint (e.g. bring your own device), versus scenarios in which the application developer has some say or influence on what the capabilities of the endpoints are.
> 
> In the former case, the application may have to function even in a browser environment where WebRTC is not available, whereas in the latter case, the application developer can ensure that a set of required capabilities are available.  The "telephony terminal" case seems more in the latter category than the former. 
> 
> For example, a vendor developing a "telephony terminal" could choose the browser they wanted to embed in the device, and might even have access to the browser source code, so as to be able to add codecs and other capabilities.   In that case, the performance and extensibility of the code base will be an important consideration, since that will determine how much work will be involved to add capabilities and what the options are for accomplishing this (e.g. native code required vs. Javascript). 
> 
> Date: Sat, 2 Feb 2013 01:13:52 +0100
> From: gunnar.hellstrom@omnitor.se
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Playing regulator
> 
> It is easy to imagine applications of WebRTC where the users will not have any expectation that they could use it for emergency services. 
> E.g. a web page only providing access to a specific company's customer service.
> So, each application does not need to provide this access.
> 
> However, the platform has apparent ambitions to be possible to use for telephony like applications, with an opportunity to call by address or number,
> E.g  
> 4.3.1. Telephony terminal 
> 
> In at least that case, there will be an expectation from users, and a requirement from regulators in many countries to be able to provide emergency service access.
> 
> So, the topic belongs here in some way.
> 
> I withdrew it from the total conversation addition, because it is a general function. I hope it will be possible to find a suitable place and general wording for it, and there indicate that it is valid for all media, including audio, video and real-time text.
> 
> Gunnar
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
> +46708204288
> On 2013-02-02 00:28, Bernard Aboba wrote:
> With regulations in flux, it is not easy to predict the extent of the obligation, beyond what exists for an "interconnected VoIP" service today.  For example, we have a text to 911 proceeding ongoing as well as quite a few others. In order to examine what the Issues might be, Martin and I put together the following document:
> http://tools.ietf.org/html/draft-aboba-rtcweb-ecrit
> 
> Comments welcome.
> 
> 
> On Feb 1, 2013, at 14:44, "Dale R. Worley" <worley@ariadne.com> wrote:
> 
> 
> Can you explain this?  I suspect that you have a specific meaning, but
> as I read it, it sounds like "I see no objection if WebRTC does not
> interwork with emergency services."  If WebRTC does not interwork with
> emergency services, the regulators will crush it.
> 
> Dale
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> _______________________________________________
> rtcweb mailing list
> 
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> _______________________________________________ rtcweb mailing list rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb