Agreed - this is not so much about standards, but developer awareness. If we write any "how to" or similar informational documents, they should probably contain that type of discussion.
There is a browser aspect, however: Right now, users only have a binary choice about location disclosure, even though I suspect many users would be fine with "location disclosure for 911 only", not "disclose my fine-grained location for any purpose you like". On May 27, 2013, at 1:51 PM, Richard Barnes <r...@ipv.sx> wrote: > Even for location delivery, there's not that much to say at the standards > layer. > > For *delivery*, the story is the same as with signaling. Either the RTCWeb > VoIP service can translate the location information to comply with RFC 6442, > or the PSAP can just build a web app that collects it however it likes. > > For *determination*, it's about the browser. You can do browser-based > geolocation today, to "OK" quality. Or the browser could implement the > GEOPRIV protocols to benefit from network-provided location. > > All that's about implementation/deployment though. I don't really see any > new standards there. > > --Richard > > > > On Mon, May 27, 2013 at 12:19 PM, Henning Schulzrinne <h...@cs.columbia.edu> > wrote: > The most difficult part for any emergency calling system is location > delivery. WebRTC probably doesn't have much impact on emergency calls if all > the calls traverse a server of some kind and if the caller location can be > looked up based on caller IP addresses, but once you have the end system > involved in location determination (e.g., for mobile devices or for > DHCP-delivered location), it has to know when a call is an emergency call as > you otherwise end up providing location for every call, which is non-ideal > from a privacy and battery perspective. > > At least in the US, many of the WebRTC services would be considered > "interconnected VoIP", so they are indeed subject to 911 obligations. > > Henning > > On May 26, 2013, at 3:57 PM, Richard Barnes <r...@ipv.sx> wrote: > >> Indeed, there has already been some coordination between the groups, going >> back about a year: >> <http://tools.ietf.org/agenda/84/slides/slides-84-ecrit-0.pdf> >> <http://tools.ietf.org/id/draft-aboba-rtcweb-ecrit-00.txt> >> >> So my read of the situation is much less dire than James's. As I understand >> it, the upshot of the initial coordination discussions is that there's not a >> single, clear "RTCWEB+ECRIT" story. Instead, there are a few ways you can >> put them together. In the short run, without upgrading PSAPs, RTCWEB VoIP >> services can bridge RTCWEB signaling to ECRIT-compliant SIP, either at the >> server, or at the client using something like SIP-over-WebSockets. In the >> long run, PSAPs can just advertise an RTCWEB service like they would >> advertise a SIP service today (in LoST). Neither of these is incompatible >> with RTCWEB or ECRIT as they're being specified today. >> >> I expect there are probably some ECRIT considerations that aren't naturally >> supported in RTCWEB. Things like real-time text come to mind. However, it >> doesn't seem to me that there's gross incompatibility. >> >> --Richard >> >> >> >> >> On Sat, May 25, 2013 at 10:18 AM, John C Klensin <john-i...@jck.com> wrote: >> >> >> --On Saturday, May 25, 2013 10:10 +0300 Jari Arkko >> <jari.ar...@piuha.net> wrote: >> >> >... >> > I didn't know about the details of the emergency >> > communications situation. But it is always difficult to >> > balance getting something out early vs. complete. I know how >> > much pressure there is on the working groups to keep up with >> > things actually happening in the browsers and organisations >> > setting up to use this technology. Do you think the retrofit >> > will be problematic, and do you have a specific suggestion >> > about what should be included today? >> >> Jari, >> >> James will probably have a different answer and perspective, but >> I suggest that retrofits of security-sensitive features are so >> often problematic to make "always" not much of an exaggeration. >> >> I don't think there is any general solution to the "early vs. >> complete" tradeoff [1], nor, as long as we keep trying to deal >> with things as collections of disconnected pieces rather than >> systems, to the issues created by WGs with significant overlaps >> in either scope or technology. What I think we can do is to be >> particularly vigilant to be sure that the two WGs are tracking >> and frequently reviewing each other's work. At least RTCWEB >> and ECRIT are in the same area, which should make that >> coordination easier than it might be otherwise. >> >> john >> >> >> [1] Watch for a note about this that I've been trying to >> organize for about two weeks and hope to finish and post this >> weekend. >> >> >> >> > >
