[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-geopriv-lbyr-requirements

GeoPriv                                                 R. Marshall, Ed.
Internet-Draft                                                       TCS
Intended status: Standards Track                           March 4, 2007
Expires: September 5, 2007

  Requirements for a Location-by-Reference Mechanism used in Location
                      Configuration and Conveyance

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 5, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Marshall                Expires September 5, 2007               [Page 1]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007


   This document defines terminology and enumerates requirements for a
   location-by-reference approach to location configuration and
   conveyance interactions useful for emergency call routing for voice-
   over-IP (VoIP) and general Internet multimedia systems, where
   Internet protocols are used end-to-end.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Terminology . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Terms  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Examples of various LRI Model  . . . . . . . . . . . . . . . .  8
   5.  High-Level Requirements  . . . . . . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21

Marshall                Expires September 5, 2007               [Page 2]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

1.  Introduction

   This document identifies the individual requirements underlying how a
   Location-by-Reference (LbyR) mechanism is to be used over the
   Internet, applied to either a Conveyance protocol or to a
   Configuration protocol.  The LbyR approach is in contrast to the
   Location-by-Value (LbyV) model, which uses a "location object" (e.g.,
   PIDF-LO) exclusively.  Examples using the Location-by-Value method
   are beyond the scope of this document.

   A mechanism for either (or both) location configuration and location
   conveyance may rely on either a location-by-value approach,
   containing and transporting location information along every leg of
   the signaling path, or alternatively, a different approach, using a
   location-by-reference technique, which may be used to reference a
   location with some identifier, and to de-reference the location when
   needed for a location-based decision.

   draft-ietf-sip-location-conveyance-07.txt] For an application of LbyR
   Conveyance, we choose to use the example of SIP signaling within an
   emergency services context, though we also talk about LbyR in a more
   general sense.  In this case, a SIP user agent, or SIP proxy server
   acting on behalf of a user agent, to another user agent via the SIP
   protocol [RFC3261].  In place of the actual value for a "Location", a
   Location Reference ID (LRI) is used to represent the "value" of the
   location, stored in some Internet-connected host, which we call a
   location server.

   For a LbyR Configuration protocol mechanism, even for the emergency
   service context mentioned, many different protocol choices exist.
   These include DHCP, LLDP-MED, and several Layer 7 protocols being
   considered for standardization.  Regardless of the variety of
   choices, the general concept of how LbyR is used for configuration,
   is not specific to any particular protocol choice.

   A Location which is referenced can be either Geographic location [RFC
   3693] (e.g., lat/lon), or a Civic location (e.g., street address).

   We reintroduce a few basic entities [RFC3693] into the Location-by-
   Reference discussion.  These include a "target" as the entity whose
   location is being transmitted, (e.g., a user agent's (UA) location.
   A "using protocol", defined as how a "location server" transmits a
   "location reference identifier" to a "location recipient".  Privacy
   of a target's location, with repect to identity is important to
   protect, hence all examples shown assume that any user identity
   associated with the target is not included with location.

Marshall                Expires September 5, 2007               [Page 3]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

   Location can be pushed from one host to another, as part of a
   signaling protocol, in order to be used for location-based routing
   (or other purposes, outside the scope here), or it can alternatively
   be queried via a client request to a server which provides location
   [ref. drafft-sip-conveyance- TBD].  In the case of LbyR Conveyance,
   the actual location (i.e., location object) never gets pushed along,
   but is replaced by a Location Reference Identifier.  In the case of a
   client which queries a server for location, the query is either to
   obtain a Location Reference Identifier, or to obtain an actual
   Location (e.g., location object) based the input of an LRI in the

   The draft-sip-conveyance- document details how SIP proxies treat LbyV
   or LbyR scenarios for conveying location via the SIP protocol.

   Whereas location objects are readily consumable by the hosts that
   using protocols deliver to, a Location Reference ID must first go
   through a dereference step in order to be useful.

   In our SIP example, for LbyR, instead of having a content identifier
   (cid:) pointing to a location object within a SIP body, the LRI is
   carried in the Geolocation header of a SIP message which is used to
   get a location via a dereference.

   A common example use case is the "emergency services call" case,
   where an request for emergency services is initiated over the
   Internet via the SIP protocol (i.e., a '9-1-1' or '1-1-2' call).  In
   order to route the call to the appropriate PSAP, the UA client
   location is required.

   This document uses as a baseline scenario, the example of an
   emergency call, where an request for emergency services is initiated
   over the Internet using the SIP protocol (e.g., a '9-1-1' or '1-1-2'
   call).  In order to route the call to the appropriate PSAP, since
   PSAPs are divided regionally, the UA client location is required.

   We first define terminology in Section 3.  The document then outlines
   baseline requirements (Section 5), around the referencing and
   dereferencing of location via some location identifier in lieu of the
   emergency caller's actual location.

   Identification of the caller, as associated information to location
   or location reference, either in conveyance or configuration, is out
   of scope in this document.

   Location-by-reference is a mechanism which is in use in VoIP 9-1-1
   systems at the time of this writing, and justified based on the
   requirements listed in this document.

Marshall                Expires September 5, 2007               [Page 4]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

2.  Requirements Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119 [RFC2119].

Marshall                Expires September 5, 2007               [Page 5]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

3.  Terminology

3.1.  Terms

   Several of the terms presented below are based on RFC3693, and in
   some cases, extended to include additional language to support the
   Location-by-Reference model.

   Dereference Protocol:  A protocol which is used to query a Location
      server based on an LRI as input.

   Location Reference Identifier (LRI):  An identifier (e.g., URI) which
      is a pointer to a target's location record on a remote host (e.g.,
      location server), and is used by a dereferencing protocol for
      retrieval of that specific location.

   Location Server (LS):  A network host which is designed to store
      location and to provide that same location to appropriate location
      client requests.  May also be referred to as a Location
      Information Server (LIS).

   LoST Mapping Server (LMS):  A network host which provides a URI
      response based on input of a location and service identifier [ref.

   Using Protocol:  A protocol that carries a Location Object or an
      Location Reference Identifier (i.e., LRI).

   Target:  A person or other entity whose location is communicated by a
      Geopriv Location Object.

   Location Recipient (LR):  The entity that receives location
      information.  It may have asked for this location explicitly (by
      sending a query containing an LRI to a location server), or it may
      receive this location asynchronously.  Also may be referred to as
      a Dereference client within this document, in the context of the
      Location-by-Reference model.

   Location Server (LS):  The entity to which a LG publishes location
      objects, the recipient of queries from location receivers, and the
      entity that applies rules designed by the rule maker.  Also may be
      referred to as a Dereference server within this document, in the
      context of the Location-by-Reference model.

   Location:  A geographic identification assigned to a region or
      feature based on a specific coordinate system, or by other precise
      information such as a street number and name.  It can be either a
      civic or geographic location.

Marshall                Expires September 5, 2007               [Page 6]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

   Civic location:  A described location based on some reference system,
      such a jurisdictions or postal delivery.  A street address is a
      common example.

   Geographic location:  A reference to a point which is able to be
      located as described by a set of defined coordinates within a
      geographic coordinate system, such as latitude and longitude
      within the WGS-84 datum.  For example, 2-D geographic location is
      defined as an (x,y) coordinate value pair according to the
      distance north or south of the equator and east or west of the
      prime meridian.

   Location-by-Value:  The mechanism of representing location either in
      conveyance protocols or configuration protocols as fully
      specified, (i.e., including the actual location value itself).

   Location-by-Reference:  The mechanism of representing location either
      in conveyance protocols or configuration protocols as an
      identifier which refers to a fully specified location, (i.e.,
      including a pointer to the actual location value itself).

Marshall                Expires September 5, 2007               [Page 7]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

4.  Examples of various LRI Model

   To support the referencing or de-referencing of a location, it is
   appropriate to describe a diagram consisting of network elements
   around which this might be done.  These elements include, the UA
   (User Agent), P (Proxy), LS (Location Server), and a UA at the PSAP

   This section outlines which entities will be considered in the
   referernce/dereference scenarios discussed.

   <figure anchor="LRI Indirection" title="LRI query/response - where
   Target = Location Recipient.">

   +--------+                              +--------+
   | Target |<---------response w/LO-------|        |
   |   ==   |                              |   LS   |
   |   LR   |-----------query w/LRI------->|        |
   +--------+                              +--------+

    Figure 1: Framework for referencing or de-referencing location in a
                               SIP session.

   Above figure shows simplest LRI interaction, when target happens to
   also be the Location Recipient [ref.  RFC3693 terms]

  +--------+                              +--------+          +--------+
  |        |                              |        |          |        |
  | Target |<----------acquire LO---------|   LS   |<--deref--|   LR   |
  |        |                              |        |    LRI   |        |
  +--------+                              +--------+          +--------+
      |                                                            |
      +----------------convey LRI--------------------------------->+

                 Figure 2: Setup showing LRI indirection.

   The above interaction reduces to two basic interactions: 1.  Location
   provision from LS/LIS to target by reference (LRI). 2.  Location
   indirection by the LS/LIS, at the request of the Target.  Location

Marshall                Expires September 5, 2007               [Page 8]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

   updates, are possible in either case.

   +--------+          +--------+          +--------+
   |        |          |        |          |        |-------LO------+
   | Target |<........>|   LG   |--LI/LO-->| LS/DS  |               |
   |        |          |        |          |        |<---LRI---+    |
   +--------+          +--------+          +--------+          |    |
                                                               |    |
                                                               |    v
                       +--------+          +--------+        +--------+
                       |        |          |        |        |        |
                       |  LRG   |---LRI--->|   LT   |--LRI-->|  LR/DC |
                       |        |          |        |        |        |
                       +--------+          +--------+        +--------+

                 Figure 3: General Setup - LG interaction.

   Definitions: Target, LG, LR, LI, LO as in RFC 3693.  LRG = Location
   Reference Generator (creates reference) LT = Location Transmitter
   (one party to Conveyance Protocol) DS/DC = Dereference Server /
   Client Protocols: Dereference Protocol is between DS and DC
   Conveyance Protocol is between LT and LR

Marshall                Expires September 5, 2007               [Page 9]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

                      |        |
       +--------------|   LS   |-----------------------------------+
       |              |        |                                   |
       |              + -------+                                   |
      LCP                  ^                                      LDP
       |                  LDP                                      |
       V                   V                                       V
  +--------+          +--------+          +--------+          +--------+
  |        |          |        |          |        |          |        |
  |  UA1   |--------->|   P1   |--------->|   P2   |--------->|   UA2  |
  |        |          |        |          |        |          |        |
  +--------+          +--------+          +--------+          +--------+
                      |        |
                      |  LMS   |
                      |        |

                     Figure 4: Example of a SIP call.

   Definitions: LS = Location Server (as in RFC 3693) LCP = Location
   Configuration Protocol LDP = Location Dereference Protocol LMP =
   Location Mapping Protocol Sequence: 1.  UA1 acquires LRI from its LS
   (acting as LRG) 2.  UA1 sends an INVITE to a service URN via P1 3.
   P1 dereferences the LRI and uses it to get a URI from the LMS 4.  UA2
   may also wish to dereference the LRI, e.g., to get the current
   location of UA1.

   Figure 1 shows the interaction between the entities involved in the
   call, as to how location is referenced and subsequently de-
   referenced.  The figure proposes that location reference is conveyed
   from the endpoint-to-endpoint via each middlebox (SIP Proxy), and
   undergoes a de-referencing operation at each step.  The figure also
   depicts a LMS (Location-to-Mapping Server) element which is used to
   determine the next target destination, based on the de-referenced

   At the PSAP, the end device also receives a location reference, (as
   indicated in this figure), and executes a de-reference quiery.

   Various potential interactions between the entities depicted in
   Figure 1 are described below:

Marshall                Expires September 5, 2007              [Page 10]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

   1.  Location information might be generated by the end host itself,
       in which case it may then request reference identifier based on
       the location that it generated and provided to the LS.

   2.  Alternately, location information might be either generated,
       provisioned, or stored by the LS (Location Server), and
       represented to the end device as a location reference, via a
       location configuration protocol (e.g., using DHCP or some L7LCP
       (Layer 7 Location Configuration Protocol).

   3.  The location reference is only useful to mask the actual
       location, but must be de-referenced in order to be useful for
       location-based routing.  Once the location is de-referenced at
       the LS and returned to the requestor, it can then be used as
       input to a location-to-mapping service (e.g., LoST).  The mapping
       server returns a URI which can be used to establish the signaling
       to the next target destination.  This returned target identifier
       may be the URI of the next SIP Proxy (or any other element along
       the routing path), or may be the URI of the appropriate IP-based

   4.  The PSAP, consistent with the figure, may choose to de-reference
       the location identifier, once it is received, in order to view
       the location, and to request subsequent location-based actions.

Marshall                Expires September 5, 2007              [Page 11]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

5.  High-Level Requirements

   Below, we summarize high-level design requirements needed for a
   location-by-reference mechanism.

   Rq1.  Location Reference Identifier as a URI:  The dereferencing
      protocol MUST support an LRI in URI form, and may support other
      non-URI forms.

   Rq2.  Dereference Protocol Confidentiality:  The dereferencing
      protocol MUST support mechanisms for encrypting messages sent
      between client (Location recipient) and server (Location server).

   Rq3.  Dereference Protocol Transparancy:  The dereferencing protocol
      MUST support the exchange of messages without encryption (i.e., in

      Motivation: In the case where encrypted message exchange is
      unsuccessful, there must be a way to try to dereference a location
      reference identifier with less restriction (e..g., in the
      emergency service case, where every call always needs answered).

   Rq4.  Location Reference Expiry:  The dereference protocol MUST
      support specification of a finite period of validity for the LRI.

      Motivation: Location references are not intended to represent a
      location forever, and the identifier eventually may need to be
      recycled, or may be subject to a specific window of validity,
      after which the location reference fails to yield a location, or
      the location is determined to be kept confidential.  An expiry
      timer for a location reference ensures that the location reference
      becomes invalid based on configuration.

   Rq5.  Dereference Protocol Transport:  The de-reference protocol MUST
      support TCP/IP and MAY support UDP/IP.

      Motivation: Practical, near-term deployment issues may make TCP/IP
      implementations unachievable.

   Rq6''.  Dereference Protocol Authentication:  The dereferencing
      protocol MUST support both client-side and server-side

      Motivation: It is reasonable to expect implementations of
      authentication to vary.  Some implementations may choose to
      support both client-side and server-side authentication, might
      support one only, or may support neither.

Marshall                Expires September 5, 2007              [Page 12]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

   Rq7.  Location Privacy:  The dereference protocol MUST support the
      application of privacy rules to the dissemination of a requested
      location object.

   Rq8.  Dereferenced PIDF-LO Result:  The dereferencing of an LRI MUST
      result in a well-formed PIDF-LO.

      Motivation: This is in order to ensure adequate privacy rules can
      be adhered to, since the PIDF-LO format comprises the necessary
      structures to maintain location privacy.

Marshall                Expires September 5, 2007              [Page 13]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

6.  Security Considerations

   Considerations for security to a Location-by-Reference model for the
   dereference protocol, include, 1.  Privacy Privacy of the LRI itself
   Privacy of the dereferenced location object 2.  Expiry Expiry of the
   LRI.  Expiry of the dereferenced location object. 3.  Theft Theft of
   a LRI.  Theft of a dereferenced location object. 4.  Replay/Reuse
   Replay of a stolen LRI to perform a dereference operation.  Reuse
   using the dereference location object. 5.  Impact of the two forms of
   location reference.  Location provision from LIS by reference.
   Location indirection by the LIS, at the request of the Target.  May
   also reference security considerations found within document

Marshall                Expires September 5, 2007              [Page 14]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

7.  IANA Considerations

   This document does not require actions by the IANA.

Marshall                Expires September 5, 2007              [Page 15]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

8.  Contributors

   Andrew Newton, James Polk, Martin Thompson, Richard Barnes, Barbara
   Stark, James Winterbottom, Hannes Tschofenig

   The contributors can be reached at:

   Name          user@example.com

Marshall                Expires September 5, 2007              [Page 16]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

9.  Acknowledgments


Marshall                Expires September 5, 2007              [Page 17]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

              Hardie, T., "LoST: A Location-to-Service Translation
              Protocol", draft-hardie-ecrit-lost-00 (work in progress),
              March 2006.

              Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              draft-ietf-ecrit-requirements-12 (work in progress),
              August 2006.

              Taylor, T., "Security Threats and Requirements for
              Emergency Call Marking and Mapping",
              draft-ietf-ecrit-security-threats-03 (work in progress),
              July 2006.

              Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic  Addresses
              Configuration Information",
              draft-ietf-geopriv-dhcp-civil-09 (work in progress),
              January 2006.

              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-00 (work in
              progress), January 2007.

              Wijk, A. and G. Gybels, "Framework for real-time text over
              IP using the Session Initiation Protocol  (SIP)",
              draft-ietf-sipping-toip-07 (work in progress),
              August 2006.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,

Marshall                Expires September 5, 2007              [Page 18]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

              June 2002.

   [RFC3351]  Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A.
              van Wijk, "User Requirements for the Session Initiation
              Protocol (SIP) in Support of Deaf, Hard of Hearing and
              Speech-impaired Individuals", RFC 3351, August 2002.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.

   [RFC3860]  Peterson, J., "Common Profile for Instant Messaging
              (CPIM)", RFC 3860, August 2004.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, June 2005.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [RFC4412]  Schulzrinne, H. and J. Polk, "Communications Resource
              Priority for the Session Initiation Protocol (SIP)",
              RFC 4412, February 2006.

Marshall                Expires September 5, 2007              [Page 19]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

Author's Address

   Roger Marshall (editor)
   TeleCommunication Systems, Inc.
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA  98121

   Phone: +1 206 792 2424
   Email: rmarshall@telecomsys.com
   URI:   http://www.telecomsys.com

Marshall                Expires September 5, 2007              [Page 20]

Internet-Draft          GEOPRIV LbyR Requirements             March 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Marshall                Expires September 5, 2007              [Page 21]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/