Subject: [Sipping] New ID on Emergency Calling

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 11 Feb 2004 09:48:51 -0500

This draft is proposed as part of how emergency calls will be routed.
It explains how you find the appropriate Emergency Response Center, and how
you convert geo to civil for dispatch.  Probably, this will be pursued
in DNSEXT, but comments on sipping are appropriate with respect to how
the draft solves the problem.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Emergency Call Information in the Domain Name
System
	Author(s)	: B. Rosen
	Filename	: draft-rosen-dns-sos-00.txt
	Pages		: 20
	Date		: 2004-2-10
	
Location of a caller is essential to processing an emergency call.
Location is needed to correctly route the call, and to correctly
dispatch help to the right place.  Location can be specified in
geographic (lat/lon/altitude) or civil (country/provin ce/city/
street/floor/room) forms.  Determining which Emergency Response
Center (ERC) should receive the call requires comparing the callers
location to a service area boundary description, which may require
location in geo form.  Dispatching a call generally requires a civil
location.  There is a need for a way to translate a civil to a geo or
vice versa to the resolution of a room.  There is also a need to
publish the service area boundary of the ERC and the emergency
responders.  Further, there is a need for a database of legal civil
addresses (sometimes called a Master Street Address Guide) that civil
locations may be verified against to assure correctness, and
uniformity of naming so that dispatch is accurate.  The memo proposes 
a new DDDS application and a new POLY RR to assist emergency calls.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosen-dns-sos-00.txt

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Feb 2004 07:56:51 -0800

One small nit on polygons. Need to specify that the vertexes are in
clockwise order. Failing to do this caused endless arguments in air traffic
control specifications of airspaces. Probably needs a way to deal with what
geographic coordinate grid is being used or fix it. Should warn implementers
that polygon will include the poles and the vertex may even be a pole. Polar
flights have caused more than one geographic information system to crash.
Many systems translate the 3 tupple coordinates into 4 tupple coordinates
for all calculations to avoid the singularities that a spherical coordinate
system introduces. Probably need a header format that allows an arbitrary
number of vertexes -  the top level polygons are going to be big. I don't
like the implied additive subtractive form of the poly. I would prefer poly
explicitly identify as additive or subtractive with the region covered being
formed by taking the union of all the additive then subtracting each of the
subtractive polygons. Points on a vertex or edge would be considered in the
region for additive polygons and out for subtractive polygons. None of the
polygons forming a region are allowed to share an edge. The altitudes need
to be altitude ranges to specify a volume that can be clipped. Seems like
you need this to figure out which floor in a building I am on. Recommend
that min alt is include in the volume but max alt is outside the volume. The
specification of points on the surface of the volume being in or out is
important or users can, excuse the pun, fall thought the cracks.

I was not sold on DNS to start with but your arguments about the pleasures
of forming a new global root convinced me DNS is right if it will work. More
text explaining it would work would make me feel warm and fluffy.

Cullen