Internet Engineering Task Force James M. Polk Internet Draft Cisco Systems Expiration: February 14th, 2002 File: draft-polk-sipping-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