Re: [rtcweb] RTCWEB and emergency services

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 27 September 2011 18:57 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C2621F8D22 for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 11:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.722
X-Spam-Level:
X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zddxn0Fnj55t for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 11:57:11 -0700 (PDT)
Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by ietfa.amsl.com (Postfix) with ESMTP id F2B3C21F8C8E for <rtcweb@ietf.org>; Tue, 27 Sep 2011 11:57:10 -0700 (PDT)
Received: from BLU152-W39 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 11:59:56 -0700
Message-ID: <BLU152-W39115E9C2A50B4A634789093F00@phx.gbl>
Content-Type: multipart/alternative; boundary="_f4437325-14ed-4b27-a145-b79a3fcd84a3_"
X-Originating-IP: [98.203.198.61]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <ted.ietf@gmail.com>
Date: Tue, 27 Sep 2011 11:59:55 -0700
Importance: Normal
In-Reply-To: <CA+9kkMA5zZe7D+2F_MmfJgkJCS9CRpDMN3zn=uTjMina-pGaAw@mail.gmail.com>
References: <BLU152-W318BAE2CE0C609B1BB45CD93F30@phx.gbl>, <CA+9kkMA5zZe7D+2F_MmfJgkJCS9CRpDMN3zn=uTjMina-pGaAw@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Sep 2011 18:59:56.0462 (UTC) FILETIME=[A5CB5CE0:01CC7D47]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWEB and emergency services
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2011 18:57:12 -0000




It should therefore be understood that the burden for implementation of emergency services falls principally upon the operator of the service, and that the role of the RTCWEB implementer is to deliver basic capabilities and to enable an operator to add to this functionality, rather than providing for every possible need natively ("I want a pony").   



Ted Hardie said:

"Do I understand you correctly to be saying "The emergency service must stand up an RTCWEB server which provides downloadable javascript applications, rather than presuming that other javascript applications provide this functionality."? "

[BA] I'm saying that the provider of the RTCWEB service is ultimately responsible for satisfying the regulatory requirements, which may vary by the location and functionality of the service.    If they utilize Javascript libraries, they need to make sure that those libraries can provide the required functionality.  For example, there are various location libraries that support the W3C Location APIs as well as potentially other Location APIs.  However, in general those libraries and underlying services were built to provide "Location Based Services" and not a "Location Information Service" in the sense that the term is used in IETF, NENA and other emergency services specifications.   However, there may be other libraries that *are* built to support emergency services (e.g. a library that supports HELD).    Also, there may be APIs available (such as the WebAPI proposed by Mozilla, see http://hacks.mozilla.org/2011/08/introducing-webapi/) that can enable an HTML5 application to access the underlying telephony capabilities of the device on which the browser runs (e.g. a mobile handset that is capable of making emergency calls with location).   The service provider needs to understand their responsibilities and utilize the right APIs and libraries to satisfy them.  

---------------------------------------

While in the long-term it may be possible to close the gaps,  in the short term the gaps may be addressed via Javascript libraries implementing elements of the ECRIT 
architecture such as HELD, or even LoST.    



Ted Hardie also said:

"It doesn't make sense to use LoST alone in the case you've described, at least if I understood you.  LoST takes a desired service and a location as inputs and discovers the service provider associated with that location.  If we're presuming that someone starts at a particular server, LoST must run prior to reaching that server.  So you'd need some sort of libraries provided prior to that server being reached to run LoST.  If you start from a known server that provides javascript libraries for discovering location (by pulling from DHCP or HELD, for example) and running LoST, you could then get to the Emergency Service Provider's RTCWEB server, but it would be pretty fragile."

[BA] Richard Barnes has been developing an ECRIT client that runs in the browser, so I suspect he will have some observations on how LoST functionality could be provided.  My main point was that just because something is a requirement in ECRIT PhoneBCP doesn't necessarily imply that it needs to be provided natively in the browser.  Before making that determination we need to understand if the functionality could be viably provided another way -- such as in Javascript, via a plugin, or maybe even via server-side functionality.