GeoPriv R. Marshall, Ed. Internet-Draft TCS Intended status: Informational July 9, 2007 Expires: January 10, 2008 Requirements for a Location-by-Reference Mechanism used in Location Configuration and Conveyance draft-marshall-geopriv-lbyr-requirements-02 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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Marshall Expires January 10, 2008 [Page 1]
Internet-Draft GEOPRIV LbyR Requirements July 2007 Abstract This document defines terminology and enumerates requirements for a Location-by-Reference approach to the configuration, dereferencing, and conveyance of location for SIP signaling, and other Internet messaging, including 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 . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Routing Models . . . . . . . . . . . . . . . . . . . . . . . . 9 5. LbyR Basic Actors . . . . . . . . . . . . . . . . . . . . . . 10 6. LbyR Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. LbyR via L7LCP . . . . . . . . . . . . . . . . . . . . . . . . 13 8. LbyR via DHCP . . . . . . . . . . . . . . . . . . . . . . . . 16 9. LbyR via LLDP-MED . . . . . . . . . . . . . . . . . . . . . . 17 10. LbyR via SUPL . . . . . . . . . . . . . . . . . . . . . . . . 18 11. High-Level Requirements . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 16.1. Normative References . . . . . . . . . . . . . . . . . . . 26 16.2. Informative References . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 29 Marshall Expires January 10, 2008 [Page 2]
Internet-Draft GEOPRIV LbyR Requirements July 2007 1. Introduction Any location-based service which utilizes SIP signaling, needs to have some form of location information available, to serve as the basis of performing a location-based mapping operation in order to know where to route. To enable any location-based service, whether for an end device or middlebox, (e.g., SIP Proxy), location must be acquired, either directly or indirectly, location information, either in the form of a PIDF-LO or a Location Reference Identifier. This document defines the requirements for a Location-by-Reference mechanism, its use, and its alternatives. It contrasts the Location- by-Reference routing model to the Location-by-Value model, and describes the ways in which a Location-by-Reference mechanism is used, such as for requesting a reference, resolving a reference, and conveying a reference. The document also talks about the two primary network models which may use Location-by-Reference, "Edge" routed and "Proxy" routed scenarios. When describing the use of location within messaging, it is essential to discuss the scope of how location is handled within this document. We talk about how location is 'acquired', or 'configured' within a host, but we do not address the mechanisms involved in 'determinining' (i.e., the methods or process of coming up with the location information). The action of passing location from one entity to another entity along a SIP signaling path is referred to as "conveyance", and is discussed separately from that of configuration. The commonly used example of a SIP-based emergency call may include both elements of configuration and conveyance, in order to be able to appropriately route and deliver location to an IP-enabled PSAP. Location determination, which may include the processes of manual provisioning, automated measurements, or derivation steps (e.g., geo- coding/reverse geo-coding), is out of scope for this document. A detailed description and usage guidelines for Location-by-Value are out of scope in this document. 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 Dereference protocol, Conveyance protocol, or a Configuration protocol. For an application of LbyR, we often cite the use case of a SIP-based Marshall Expires January 10, 2008 [Page 3]
Internet-Draft GEOPRIV LbyR Requirements July 2007 signaling to emergency services, 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 URI is used to indirectly represent the location via a dereference step. Stored in some Internet- connected host, which we call a Location Configuration Server (LCS). In the LbyR context, the Configuration protocol mechanism is used to fetch a location reference, and in this case, the protocols which have been identified for this use, includes DHCP, LLDP-MED, HELD, and potentially, SUPL. Regardless of protocol choices, the underlying approach to how LbyR is used for configuration is not specific to any particular protocol choice. A Location which is referenced can be either Coordinate location [RFC 3693] (e.g., lat/lon), or a Civic location (e.g., street address). We reintroduce a few of the building blocks to location [RFC3693] into the LbyR discussion. Included in this list is the "target", the entity whose location is transmitted, (e.g., UA location). A "using protocol", defined as how a "target" (in this model) transmits a "location reference identifier" to a "location recipient". Privacy of a target's location, with repect to user identity is important to protect. Therefore, any examples shown will assume that any user identity associated with the target is not included with location. Location can be pushed from one host to another, via a conveyance protocol, 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. draft-sip-conveyance- XXX]. 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 query. The draft-sip-conveyance- document [draft-sip-conveyance] details how SIP proxies treat LbyR (and LbyV) 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 Marshall Expires January 10, 2008 [Page 4]
Internet-Draft GEOPRIV LbyR Requirements July 2007 (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 step. The structure of this document first defines terminology in Section 3. Then a short discussion on actors, Section 5. Routing models, considering both "Edge" and "Proxy" routed models are shown by example, Figure 1 and Figure 2, respectively, followed by a more specific model which shows a Layer 7 LCP context model. [Placeholders for...] More models are included for comparison, including those for LbyR by DHCP, LLDP-MED, and by SUPL. A high- level list of baseline requirements are outlined for the LbyR mechanism, (Section 11), and generally apply to configuration, dereferencing, and conveyance of location by means of a Location Reference Identifier in lieu of the an actual location, as would otherwise be included within a PIDF-LO structure. Any detailed discussion of Identification information about the caller, subscriber, or device, as associated information to location or a location reference, for either Conveyance, Dereference, or Configuration, is out of scope in this document. Marshall Expires January 10, 2008 [Page 5]
Internet-Draft GEOPRIV LbyR Requirements July 2007 2. Requirements Terminology In this document, 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 RFC 2119 [RFC2119]. Marshall Expires January 10, 2008 [Page 6]
Internet-Draft GEOPRIV LbyR Requirements July 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 Configuration Server based on an LRI as input, and which returns a location value (.e.g, PIDF-LO). Location Reference Identifier (LRI): An identifier which serves as a pointer to a target's location record on a remote host (e.g., location configuration server), and is used by a dereferencing protocol for retrieval of the associated specific location. LoST Server: A network entity which provides a URI response based on input of a location and service identifier [ref. draft-ecrit-lost-]. Using Protocol: A protocol (e.g., SIP) which carries a Location Object or an Location Reference Identifier. Target: A person, end device, 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 configuration server), or it may receive this location asynchronously. Location Server (LS): The entity to which a LG publishes location objects, is the recipient of queries from location recipients, and is the entity that applies rules designed by the Rule Maker (RM) [ref. RFC4119]. Also may be referred to as a Presence Server (PS). Location Configuration Server (LCS): The entity which receives a client request for either location or a location reference. In the latter case, also performs the dereference function for a Location Refernce Identifier, in the context of the Location-by- Reference model. May also be referred to as a Location Information Server (LIS). Marshall Expires January 10, 2008 [Page 7]
Internet-Draft GEOPRIV LbyR Requirements July 2007 Location: Either a coordinate (geographic) identification assigned to a region or feature based on a specific coordinate system, or by other identifiable information such as a street number and street name within a civic location reference system. Civic location: A described location based on some understood location reference system, such a jurisdictions or postal delivery grid. A street address valid within the USPS system is a common example. Coordinate 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 January 10, 2008 [Page 8]
Internet-Draft GEOPRIV LbyR Requirements July 2007 4. Routing Models This document describes the two primary network models which may use Location-by-Reference, these are often referred to as either "Edge" routed or "Proxy" routed messaging. Since Location-by-Value is an alternative approach which deals with acquiring and conveying location information directly, and in the general case where LbyV does not include a Location Reference Identifier, LbyV is deemed out of scope in this document, except where noted, and so the following examples will only deal with LbyR scenarios. 1. The Edge routed model consists of the end device acquiring a location reference identifier, dereferencing the LRI, and performing the routing based on the dereferenced location. Location information might be generated by the end host itself, in which case the end host itself may request a location reference identifier, based on its location, from the LCS. 2. The Proxy routed approach relies on some kind of middlebox (e.g., Proxy) inserting an LRI into the SIP messaging, and would be required for non-location-aware end devices. In this case, location information might be generated by, provisioned into, or stored by the LCS, and represented to the end device as a location reference identifier, delivered via a location configuration protocol (e.g., using DHCP, LLDP-MED, or an L7 LCP. The Location Reference Identifier is useful to point to a location value or mask the actual location value. Since possessing the LRI alone is insufficient to perform location-based routing, the LRI must be de-referenced. Once the location is de-referenced and returned to the location recipient, it can then be used as input to some location-based service (e.g., LoST). Marshall Expires January 10, 2008 [Page 9]
Internet-Draft GEOPRIV LbyR Requirements July 2007 5. LbyR Basic Actors The basic actors shown in an "Edge" routing model. +-------------+ | | | LCS +<-----------------+-------------------------+ | | | | +--+-------+--+ | | ^ ^ | | | | | | Configuration | | Protocol | | | (a) (b) Dereference (b) (b) | | Protocol | | | | | | v v v v +--+-------+--+ Conveyance +-----+------+ +-----+-----+ | Target / | Protocol | Proxy / | | Term./ | | End Host +----(c)---->+ UAS +----(c)---->+ UAS | | | | | | | +-------------+ +------------+ +-----------+ Figure 1: Shows the basic model shows Edge routing inter- relationship between Configuration, Dereference, and Conveyance protocols: In the case of Edge routing, the following applies, as shown in the above figure, the Target / End Host: (a) Acquires an LRI from the LCS (b) Dereferences the LRI, receiving the location Uses the location to determine routing instructions in the form of a destination URI (step not shown) (c) Conveys the LRI to the destination URI obtained in the previous step (b) Additional Dereference steps may be necessary on the way to and at the terminating UAS. Marshall Expires January 10, 2008 [Page 10]
Internet-Draft GEOPRIV LbyR Requirements July 2007 The basic actors shown in an "Proxy" routing model. +-------------+ | | | LCS +<-----------------+-------------------------+ | | | | +--+-------+--+ | | : ^ | | : | | | : | (b) Dereference (b) : +--------(a)-------+ | Protocol | (0) Configuration | | | Determination Protocol | | | Mechanism | | | : v v v +--+-------+--+ +--+--+------+ Conveyance +-----+-----+ | Target / | | Proxy / | Protocol | Term./ | | End Host +----------->+ UAS +----(c)---->+ UAS | | | | | | | +-------------+ +------------+ +-----------+ Figure 2: Shows the basic model shows Proxy routed inter- relationship between Configuration, Dereference, and Conveyance protocols: In the case of Proxy routing, this time it's the Proxy, serving the Target / End Host, which acts as follows to: (a) Acquire an LRI from the LCS (b) Dereference the LRI, receiving the location Use the location to determine routing instructions in the form of a destination URI (step not shown) (c) Convey the LRI to the destination URI obtained in the previous step Marshall Expires January 10, 2008 [Page 11]
Internet-Draft GEOPRIV LbyR Requirements July 2007 6. LbyR Actions The LbyR mechanism has three distinct actions which describe its use. 1. An LRI is 'acquired' via a Configuration protocol request/ response (which implies its creation and receipt). This action is performed by the entity which needs the location reference to resolve it via the dereference step, then send it on to the next destination (conveyance). 2. An LRI 'resolved', via a Dereferencing protocol request/response. This is the action of exchanging the reference for an actual location. 3. An LRI is 'pushed' via a Conveyance protocol mechanism. This action is accomplished by a using protocol, such as SIP, in which case it would be included in a specific SIP header. Note: An LRI may also be conveyed alongside a PIDF-LO, (which enables the Terminating UAS a convenient mechanism to perform location updates). Marshall Expires January 10, 2008 [Page 12]
Internet-Draft GEOPRIV LbyR Requirements July 2007 7. LbyR via L7LCP Location-by-Reference with Location Subscriptions In mobile wireless networks it is not efficient for the end host to periodically query the LCS for up-to-date location information. Furthermore, the end host might want to delegate the task of retrieving and publishing location information to a third party, such as a presence server. Finally, in some deployments the network operator might not want to make location information available to the end hosts. These usage scenarios motivated the introduction of the location-by- reference concept. Depending on the type of reference, such as HTTP/ HTTPS or SIP presence URI, different operations can be performed. While an HTTP/HTTPS URI can be resolved to location information, a SIP presence URI provides further benefits from the SUBSCRIBE/NOTIFY concept that can additionally be combined with location filters [13]. +-----------+ Dereferencing +-----------+ | | Protocol (3) | Location | | LCS +---------------+ Recipient | | | | | +-----+-----+ +----+------+ | -- | -- | Geopriv-L7 -- | Protocol -- | (1) -- | -- Geopriv | -- Using Protocol | -- (e.g., SIP) +-----+-----+ -- (2) | Target / |-- | End Host + | | +-----------+ Figure 3: Shows the assumed communication model for a L7 LCP: Note that there is no requirement for using the same protocol in (1) and (3). Marshall Expires January 10, 2008 [Page 13]
Internet-Draft GEOPRIV LbyR Requirements July 2007 The following list describes the location subscription idea: 1. The end host discovers the LCS. 2. The end host sends a request to the LCS asking for a location-by- reference, as shown in (1) of Figure 4. 3. The LCS responds to the request and includes a location object together with a subscription URI. 4. The Target puts the subscription URI into a SIP message as described in [14] forwards it to a Location Recipient, as shown in (2) of Figure 4. The Location Recipient subscribes to the obtained subscription URI (see (3) of Figure 4) and potentially uses a location filter (see [13]) to limit the notification rate. 5. If the Target moves outside a certain area, indicated by the location filter, then the Location Recipient will receive a notification. Note that the Target may also act in the role of the Location Recipient whereby it would subscribe to its own location information. For example, the Target obtains a subscription URI from the Geopriv-L7 protocol. It subscribes to the URI in order to obtain its currently location information, which then serves as input to a LoST query (see [15]) in order to acquire the service boundary (e.g., PSAP boundary). The service boundary indicates the region where the device can move without the need to re-query since the returned answer remains unchanged. The Target uses this service boundary to location filters and updates the subscription. If the Target moves outside a certain area, indicated by the location filter, it will receive a notification and knows that re- querying LoST to obtain a new service boundary is necessary. For location-by-reference, the LCS needs to maintain a list of randomized URIs for each host, timing out these URIs after the reference expires. References need to expire to prevent the recipient of such a URL from being able to (in some cases) permanently track a host. Furthermore, this mechanism also offers garbage collection capability for the LIS. Location references must prevent adversaries from obtaining the Target's location. There are at least two approaches: The location reference contains a random component and allows any holder of the reference to obtain location information. Alternatively, the reference can be public and the LIS performs access control via a separate authentication mechanism, such as HTTP digest or TLS client side authentication, when resolving the Marshall Expires January 10, 2008 [Page 14]
Internet-Draft GEOPRIV LbyR Requirements July 2007 reference to a location object. Marshall Expires January 10, 2008 [Page 15]
Internet-Draft GEOPRIV LbyR Requirements July 2007 8. LbyR via DHCP [Place text here.] Marshall Expires January 10, 2008 [Page 16]
Internet-Draft GEOPRIV LbyR Requirements July 2007 9. LbyR via LLDP-MED [Place text here.] Marshall Expires January 10, 2008 [Page 17]
Internet-Draft GEOPRIV LbyR Requirements July 2007 10. LbyR via SUPL [Place text here.] Marshall Expires January 10, 2008 [Page 18]
Internet-Draft GEOPRIV LbyR Requirements July 2007 11. 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 Configuration Server). Rq3. Dereference Protocol Transparancy: The dereferencing protocol MUST support the exchange of messages without encryption (i.e., in plaintext). 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 Expiration: The Location Reference mechanism MUST provide a way to limit the validity of that reference (and SHOULD also provide a way to extend or shorten the validity period). 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 dereference 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 The Location dereferencing protocol MUST support both client-side and server- side authentication between server and client. Marshall Expires January 10, 2008 [Page 19]
Internet-Draft GEOPRIV LbyR Requirements July 2007 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. Rq7. Location Privacy: The Location Reference MUST NOT reveal any personal identification information along with 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. Rq9. Time Limitation: The reference MUST be valid for a limited amount of time. Motivation: Rq10. : The reference MUST be hard to guess, i.e., it MUST contain a cryptographically random component. Motivation: Rq11. : The reference MUST NOT contain any information that identifies the user, device or address of record. Motivation: Rq12. : The Location Recipient MUST be able to resolve the reference more than once (i.e., there is no implicit limit on the number of dereferencing actions). Motivation: Rq13. : Possessing a reference to location information allows a Location Recipient to repeately obtain the latest information about the Target with the same granularity. Motivation: Rq14. : The Target MUST be able to resolve the reference itself. Marshall Expires January 10, 2008 [Page 20]
Internet-Draft GEOPRIV LbyR Requirements July 2007 Motivation: Marshall Expires January 10, 2008 [Page 21]
Internet-Draft GEOPRIV LbyR Requirements July 2007 12. Security Considerations The LbyR mechanism currently addresses security issues as follows. 1. A pawn ticket where possession implies permission, and 2. Identifiers that are public which are protected by privacy rules at the dereference server. 3. Additional security issues will be discussed in a separate geopriv document (based on a prior version of the l7-lcp-ps draft). Marshall Expires January 10, 2008 [Page 22]
Internet-Draft GEOPRIV LbyR Requirements July 2007 13. IANA Considerations This document does not require actions by the IANA. Marshall Expires January 10, 2008 [Page 23]
Internet-Draft GEOPRIV LbyR Requirements July 2007 14. Contributors Andrew Newton; Martin Dawson; Henning Schulzrinne; Marc Linsner; Brian Rosen; Ted Hardie; James M. Polk; James Winterbottom; Martin Thomson; John Schnizlein; Barbara Stark; Jon Peterson; Allison Mankin; Randall Gellens; Cullen Jennings; Richard Barnes; Keith Drage; Rohan Mahy; Hannes Tschofenig The contributors can be reached at: Name user@example.com Marshall Expires January 10, 2008 [Page 24]
Internet-Draft GEOPRIV LbyR Requirements July 2007 15. Acknowledgments [TBD] Marshall Expires January 10, 2008 [Page 25]
Internet-Draft GEOPRIV LbyR Requirements July 2007 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 16.2. Informative References [I-D.ietf-ecrit-lost] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-ietf-ecrit-lost-05 (work in progress), March 2007. [I-D.ietf-ecrit-requirements] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", draft-ietf-ecrit-requirements-13 (work in progress), March 2007. [I-D.ietf-ecrit-security-threats] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 (work in progress), April 2007. [I-D.ietf-geopriv-dhcp-civil] 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. [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in progress), April 2007. [I-D.ietf-geopriv-loc-filters] Mahy, R., "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", draft-ietf-geopriv-loc-filters-01 (work in progress), March 2007. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Marshall Expires January 10, 2008 [Page 26]
Internet-Draft GEOPRIV LbyR Requirements July 2007 Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 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. Marshall Expires January 10, 2008 [Page 27]
Internet-Draft GEOPRIV LbyR Requirements July 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 January 10, 2008 [Page 28]
Internet-Draft GEOPRIV LbyR Requirements July 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 January 10, 2008 [Page 29]