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

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

GeoPriv                                                 R. Marshall, Ed.
Internet-Draft                                                       TCS
Expires: August 9, 2007                                 February 5, 2007


  Requirements for  a Location-by-Reference Mechanism used in Location
                      Configuration and Conveyance
               draft-marshall-geopriv-lbyr-requirements-00

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-
   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.

   This Internet-Draft will expire on August 9, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Marshall                 Expires August 9, 2007                 [Page 1]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


Abstract

   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 . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Terms  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Actors . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Location . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  High-Level Requirements  . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18























Marshall                 Expires August 9, 2007                 [Page 2]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


1.  Introduction

   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.

   This document uses as a baseline condition, the primary example of an
   emergency call, which includes a request for emergency services via a
   SIP-enabled end device, connecting through the Internet to an IP-
   enabled PSAP (Public Service Answering Point).

   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 August 9, 2007                 [Page 3]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


2.  Requirements Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],
   with the qualification that unless otherwise stated these words apply
   to the design of the location-by-reference mechanism, and not its
   implementation or application.











































Marshall                 Expires August 9, 2007                 [Page 4]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


3.  Terminology

3.1.  Terms

   Location Reference Identifier (LRI):  An identifier (could be of the
      form of any URI) which is designed to represent a location object.

   Location Server (LS):  A network host which is designed to store
      location and to provide that same location to appropriate location
      client requests.

   Location-to Mapping Server (LMS):  A network host which provides a
      URI mapping service based on an input location and service
      identifier.

   Call Server/Proxy (CS/P):  A network host which plays the role of a
      SIP Proxy.

3.2.  Actors

   de-reference protocol client:  The term to describe the entity
      requesting a Location Object in exchange for a Location Reference
      Identifier provided.

   de-reference protocol server:  The term to describe the entity
      providing a Location Object as an output based on a Location
      Reference Identifier input.

3.3.  Location

   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.

   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.





Marshall                 Expires August 9, 2007                 [Page 5]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


   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 August 9, 2007                 [Page 6]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


4.  Basic Actors

   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), CS/P (Call Server/Proxy), a LS (Location Server), and a
   PSAP UA.

   This section outlines which entities will be considered in the
   referernce de-reference scenarios discussed.



      +-------+
      |       |   |-------------------------------
      |  LMS  |---|----------------               \
      |       |   |---             \               \
      +-------+       \             \               \
                       \             \               \
                        \             \               \
                         \             \               \
      +-------+      +-------+      +-------+      +-------+
      |       |      |       |      |       |      |       |
      |  UA1  |------|  P1   |------|  P2   |------|  UA2  |
      |       |      |       |      |       |      |       |
      +-------+      +-------+      +-------+      +-------+
          |             /              /              /
          |            /              /              /
          |           /              /              /
      +-------+      /              /              /
      |       |   |--              /              /
      |  LS   |---|----------------              /
      |       |   |------------------------------
      +-------+


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

   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
   location.




Marshall                 Expires August 9, 2007                 [Page 7]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


   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:

   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
       PSAP.

   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 August 9, 2007                 [Page 8]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


5.  High-Level Requirements

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

   Rq1.  Location Conveyance By Value (LbyV):  The conveyance protocol
      MUST support the conveyance of location information in its fully-
      contained form, i.e., a PIDF-LO.  (I know this isn't a requirement
      for LbyR, but is included for balance.)

   Rq2.  Location Conveyance By Reference (LbyR):  The conveyance
      protocol MAY support the conveyance of a location information
      reference identifier, in the form of 'any URI', which can be used
      to de-reference the location into its fully-contained form, (e.g.,
      a PIDF-LO).

   Rq3.  Location Conveyance Duality:  The location conveyance protocol
      MAY support both location value and location reference identifier
      in the same message.

   Rq4.  Private Location Reference Id.:  The dereferencing protocol
      MUST support the encryption of a location reference identifier.

   Rq5.  Public Location Reference Id.:  The dereferencing protocol MAY
      convey a location reference identifier in plaintext.

   Rq6.  Location Reference Expiry:  There MUST exist, a location
      reference uri format that includes a specified, finite period of
      validity.

      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.

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

   Rq8.  LRI Distribution:  The location reference standard MUST allow
      construction of location references that can be distributed to and
      de-referenced by multiple parties, and MAY support references that
      are restricted to a single de-referencer"






Marshall                 Expires August 9, 2007                 [Page 9]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


   Rq9''. de-reference Protocol Authentication:  The dereferencing
      protocol MUST support both client-side and server-side
      authentication.

      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.

   Rq10.  Location Privacy:  The de-reference protocol MUST support the
      application of privacy rules to the dissemination of a requested
      location object.  The entity that receives requests through the
      de-reference protocol MUST obey all privacy rules that apply to a
      requested location object.

   Rq11.  De-referenced 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.

   Rq12.  Expiry of de-referenced Location:  The de-referenced location,
      in PIDF-LO format, MUST include a configurable expiry timer to
      signal the point after which the PIDF-LO contained location is no
      longer considered usable.

      Motivation: Once the location is de-referenced, it would be
      difficult to keep it from being passed around further 'as a plain
      old PIDF-LO', hence a timer expiry is specified.  (This technique
      does not prevent would-be 'black-hats' from reusing the PIDF-LO,
      but provides some additional functionality within a proper use
      context.

   Rq13.  De-reference Protocol Selection:  Location by reference
      systems MUST support at least one, and MAY support multiple
      dereferencing protocols.














Marshall                 Expires August 9, 2007                [Page 10]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


6.  Security Considerations

   Threats and security requirements are discussed in a separate
   document document [11].















































Marshall                 Expires August 9, 2007                [Page 11]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


7.  IANA Considerations

   This document does not require actions by the IANA.
















































Marshall                 Expires August 9, 2007                [Page 12]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


8.  Contributors

   [TBD]

   The contributors can be reached at:

   Name          user@example.com












































Marshall                 Expires August 9, 2007                [Page 13]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


9.  Acknowledgments

   [TBD]
















































Marshall                 Expires August 9, 2007                [Page 14]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


10.  References

10.1.  Normative References

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

10.2.  Informative References

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

   [3]   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.

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

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

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

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

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

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

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

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

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



Marshall                 Expires August 9, 2007                [Page 15]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


         August 2006.

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

   [14]  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.

   [15]  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.






































Marshall                 Expires August 9, 2007                [Page 16]


Internet-Draft          GEOPRIV LbyR Requirements          February 2007


Author's Address

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

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







































Marshall                 Expires August 9, 2007                [Page 17]


Internet-Draft          GEOPRIV LbyR Requirements          February 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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.


Acknowledgment

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





Marshall                 Expires August 9, 2007                [Page 18]


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