Internet DRAFT - draft-polk-coordinate-loc-header-reqs
draft-polk-coordinate-loc-header-reqs
Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems
Expiration: February 14th, 2002
File: draft-polk-coordinate-loc-header-reqs-00.txt
Requirements for a Coordinate Location Header
Within the Session Initiation Protocol
February 24th, 2002
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Abstract
This document calls for an extension to the Session Initiation Protocol
for a Coordinate Location Header principally to be used in times of
emergency.
Polk Page 1
Internet Draft Coordinate Location Header in SIP Aug 14th, 2003
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Overview of the Coordinate Location . . . . . . . . . . . . . . . . 2
3.0 Coordinate Location Requirements . . . . . . . . . . . . . . . . . 3
4.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 4
5.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . . 4
6.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.0 Author Information . . . . . . . . . . . . . . . . . . . . . . . . 4
1.0 Introduction
This document calls for an extension to the Session Initiation Protocol
for a Coordinate Location Header principally to be used in times of
emergency.
1.1 Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
1.2 Motivation
When a SIP UA initiates a session to a well-known emergency response URI,
such as "sos@any_erc.domain" from [2], providing the emergency response
center with the UA's Coordinate location could be beneficial, especially
if the caller is signaling for "help".
1.3 Terminology
The following terms and acronyms will be used throughout this document:
ERC = Emergency Response Center
2.0 Overview of the Coordinate Location
A Coordinate is a Latitude value, a Longitude value or an Altitude value.
A Coordinate Location is these 3 values in a group. Resolution is the
knowledge that a thing or device or person is within a defined boundary.
The level of resolution is termed precision. How precise a coordinate
location is depends on how much area (either 2 or 3 dimensionally) is
provided between given boundaries. If none is given, this should be
considered a coordinate intersection, or a point (either 2 or 3
dimensionally).
Polk Page 2
Internet Draft Coordinate Location Header in SIP Aug 14th, 2003
When the precision is between two Latitude lines, there must be derived a
latitude pair (which the object is between). Couple this with the
Longitude pair, and the result is a 2 dimensional location area. If the
object is a person, a building or a handheld device for instance, and the
latitude (and maybe the longitude) pair(s) is miles apart, the precision
is minimal (or small or less). If the same object were described with a
precision of latitude pairing of millimeters, the precision is great (or
high). If there is no longitude pairings, the object has been given a
maximum (or best) known resolution (or precision).
In the cases of UAs initiating session with emergency response centers,
the best available known precision is desired.
In a voice application today, emergency response centers typically want 3
things from in an emergency call:
#1 - the call itself
#2 - the call back number
#3 - the location of the caller
SIP with [2] can provide the call and the return URI (either in the From
or Contact fields). The location of the caller is difficult, and one
solution for this is the caller tells the emergency response center where
they are. Technically, the UA can transmit this location information in
the original INVITE via the proposed extension here if the UA knows its
location already.
One mechanism for the UA learning its location is described in [3]. This
DHCP Option provides all that is necessary for the emergency response
center to know where the session initiator is.
Although this Geopriv/DHC Option is based on a wired UA, this header is
connectivity type unaware, and can be used if the location of a UA were
learned through other means.
3.0 Coordinate Location Requirements
The following are the requirements for the creation of this Header-field
REQ# 1 - The Coordinate Header consist of Latitude, Longitude and
Altitude
REQ# 2 - The resolution of the coordinates be the most precise known to
the UA
REQ# 3 - An optional field, one each for Latitude and Longitude
coordinates, is supplied for each coordinate to give the known
boundaries
For example, if the UA knows it is between two latitude lines (the
equivalent of two latitude numbers), this be included in the Coordinate
Polk Page 3
Internet Draft Coordinate Location Header in SIP Aug 14th, 2003
Header in such a way as both appear as a pair for Latitude and/or
Longitude.
REQ# 4 - To ensure numbers or decimals aren't rounded off, all digits
should be included that are know in each Coordinate field
(Lat/Long/Alt)
REQ# 5 - No digits should be rounded up or down, making the coordinate
location less precise
REQ# 6 - A Datum Field must be present to ensure the local significance
of the Coordinate Location given
REQ# 7 - When the Coordinate header is to be included in a SIP message,
even during emergency conditions, it should be considered a
"Using Protocol" as defined within [4], and follow the
policies and security considerations as outlined within that
document
4.0 Security Considerations
Just as stated in the last requirement above, when a SIP message includes
the Coordinate Header, SIP (or the UA) should incorporate the guidelines
set forth in [4] to ensure the correct policies and security information
is fully utilized - based upon the reason why the header is included in
that message.
5.0 IANA Considerations
There are no IANA considerations within this document
6.0 References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] H. Schulzrinne, "draft-schulzrinne-sipping-sos-04.txt", Internet
Draft, work in progress, January 2003
[3] J. Polk, J. Schnizlein, M. Linsner, "draft-ietf-geopriv-dhcp-lo-
option-00.txt", Internet Draft, work in progress, January 2003
[4] J. Cuellar, J. Morris, D. Mulligan, "draft-ietf-geopriv-reqs-02.txt",
Internet Draft, work in progress, January 2003
7.0 Author Information
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
jmpolk@cisco.com
Polk Page 4
Internet Draft Coordinate Location Header in SIP Aug 14th, 2003
"Copyright (C) The Internet Society (February 23rd, 2001).
All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
The Expiration date for this Internet Draft is:
Aug 14th, 2003
Polk Page 5
