GeoPriv R. Marshall, Ed. Internet-Draft TCS Intended status: Informational
July 9,November 3, 2008 Expires: January 10,May 7, 2009 Requirements for a Location-by-Reference Mechanism draft-ietf-geopriv-lbyr-requirements-03draft-ietf-geopriv-lbyr-requirements-04 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,May 7, 2009. Abstract This document defines terminology and provides requirements relating to Location-by-Reference approach using a location URI to handle location information within signaling and other Internet messaging. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 56 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 67 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 910 4.1. Requirements for a Location Configuration Protocol . . . 910 4.2. Requirements for a Location Dereference Protocol . . . . 1112 5. Security Considerations . . . . . . . . . . . . . . . . . . . 1415 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1516 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 1617 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1718 8.1. Normative References . . . . . . . . . . . . . . . . . . . 1718 8.2. Informative References . . . . . . . . . . . . . . . . . . 1718 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 1819 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 2022 Intellectual Property and Copyright Statements . . . . . . . . . . 2123 1. Introduction Location-basedSince all location-based services rely on ready access to location information, whichthis can beaccomplished through asome direct means, or alternatively, through some indirect mechanism. While there are mechanisms for providing location directly, (e.g.,means as part of the SIP signaling protocol), an alternative mechanism has been developed for handling location indirectly, via a location reference,a pointer to the actuallocation information. This reference is called a location URI, and is used by the mechanismThe direct vs. indirect approach we generally call the Location-by- Reference mechanism,characterize as either Location-by-Value (LbyV), or simply, LbyR. The use ofLocation-by-Reference (LbyR). While it is the case that within SIP, location can be handled in a direct manner, (i.e., passing the actual location URI is generally appliedinformation around in one ofthe following ways: 1. Creation/allocationform of a PIDF-LO*), there are additional location URI,requirements which apply to certain applications and/or location architectures that are only satisfied by aspecifying an indirect location server based on some requestmechanism. 2. As part of a Location Configuration Protocol, between a target and location server*. 3. The location dereference process, (betweenThis document puts forth a dereference client and dereference server). 4. Cancellation/expirationset of arequirements for such an indirect location URI, by aapproach, namely, the LbyR location server based on eithermodel. As justification for a direct target request orLbyR model, consider the following. In some other action (e.g., timer). *In this document, we make no differentiation between a LS, per RFC3693, and a LIS, but may refermobile networks it is not efficient for the end host to either of them as a location server interchangeably. These four things fall under two general protocol mechanisms, location configuration protocols and location dereference protocols. A fifth use ofperiodically query the LIS for up-to-date location URIinformation. This is withinespecially the context of whatcase when power is calleda constraint or when a location conveyance. Location conveyanceupdate is definednot immediately needed. Furthermore, the end host might want to delegate the task of retrieving and publishing location information to a third party, such as partto a presence server. Additionally, in some deployments, the network operator may not want to make location information widely available. These kinds of location scenarios, and more, such as whether a Target is mobile and whether a mobile device needs to be located on demand or according to some pre-determined interval, together form the basis of motivation for the LbyR concept. The concept of an LbyR mechanism is simple. It is made up of a pointer which makes reference to the actual location information by some combination of key value and fully qualified domain name. This combination of data elements, in the form of a URI, is referred to specifically as a "location URI". The LbyR mechanism itself works according to an information lifecycle. Within the LbyR mechanism, location URIs are temporary identifiers, each undergoing the following uses: Creation; Distribution; Conveyance; Dereference; and Termination. The use of a location URI according to these various states is generally applied in one of the following ways: 1. Creation of a location URI, within a location server, based on some request for its creation. 2. Distribution of a location URI, via a Location Configuration Protocol, between a target and a location server**. 3. Conveyance, applied to LbyR, in SIP, is the transporting of the location URI, in this case, between any successive signaling nodes***. 4. Dereference of a location URI, a request/response between a client having a location URI and a location server holding the location information that the location URI references. 5. Termination of a location URI, either due to expiration or cancellation within a location server, and which is based on a target cancellation request or some other action, such as timer expiration. Location determination, different than location configuration or dereferencing, often includes topics related to manual provisioning processes, automated location calculations based on a variety of measurement techniques, and/or location transformations, (e.g., geo- coding), and is beyond the scope of this document. *The standard mechanism for LbyV has been defined around the use of the SIP protocol,PIDF-LO (Presence Information Document Format - Location Object [RFC4119]]), and is explicitly out of scope forin this document. **This document make no differentiation between a LS, per RFC3693, and a LIS [ref. draft-ietf-geopriv-l7-lcp-ps], but may refer to either of them as a location server interchangeably. ***Location Conveyance for either LbyR or LbyV, within SIP signaling is considered out of scope for this document (see [I-D.ietf-sip-location-conveyance] for an explanation of location conveyance offor either LbyR or LbyV scenarios.) Except for location usingconveyance, the above stages in the LbyR lifecycle fall into one of two general categories of protocols, either a location URI.Location Configuration Protocol or a Location Dereference Protocol. The stages of LbyR Creation, Distribution, and Termination, are each found within the set of Location Configuration Protocols (LCP). The Dereference stage belongs solely to the set of Location Dereference Protocols. The issues around location configuration protocols have been documented in a location configuration protocol problem statement and requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are currently aseveral examples of a location configuration protocol. These includeprotocols currently proposed, including, DHCP, LLDP-MED, and HELD [I-D.ietf-geopriv-http-location-delivery]) protocols. For dereferencing of a location URI, depending on the type of reference used, such as a 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 [I-D.ietf-geopriv-loc-filters]. The structure of this document includes terminology, Section 2, followed by a discussion of the basic elements that surround how a location URI is used. These elements, or actors, are discussed in an overview section, Section 3, accompanied by a graph and associated processing steps. Requirements are outlined accordingly, separated as location configuration requirements, Section 4.1, and location dereference requirements, Section 4.2. In contrast to using a location URI as the mechanism to support a Location-by-Reference model, it may be worth mentioning the common alternative model, that of Location-by-Value (LbyV), which provides location directly. LbyV uses a location object, (e.g., a PIDF-LO, [RFC4119]) within SIP signaling. Using the LbyV model for location configuration is considered out of scope for this document (see [I-D.ietf-sip-location-conveyance] for an explanation of location conveyance for either LbyR or LbyV scenarios. Location determination, different thana graph and associated processing steps. Requirements are outlined accordingly, separated as location configuration or dereferencing, often includes topics related to manual provisioning processes, automated measurements, and/or location transformations, (e.g., geo-coding),requirements, Section 4.1, and are beyond the scope of this document.location dereference requirements, Section 4.2. 2. Terminology 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]. This document reuses the terminology of [RFC3693], such as Location Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Location Generator (LG), Location Object (LO), and Using Protocol: Location-by-Value (LbyV): The mechanism of representing location either in configuration or conveyance protocols, (i.e., the actual included location value). Location-by-Reference (LbyR): The mechanism of representing location by means of a location URI for use in either a location configuration, conveyance, or dereferencing protocol, and which refers to a fully specified location. Location Configuration Protocol: A protocol which is used by a client to acquire either location or a location URI from a location configuration server, based on information unique to the client. Location Dereference Protocol: A protocol which is used by a client to query a location dereference server, based on location URI input and which returns location information. Location URI: An identifier which serves as a pointer to a location record on a remote host (e.g., LIS). Used within an Location-by- Reference mechanism, a location URI is provided by a location configuration server, and is used as input by a dereference protocol to retrieve location from a dereference server. 3. Overview of Location-by-Reference In mobile wireless networks it is not efficient for the end host to periodically query the LIS for up-to-date location information.This is especially the case when power is a constraint or a location update is not immediately needed. Furthermore, the end host might want to delegatesection describes the task of retrievingentities and publishing location information to a third party, such as to a presence server. Finally,interactions involved in some deployments, the network operator may not want to make location information widely available. Different location scenarios, such as whether a Target is mobile and whether a mobile device needs to be located on demand or according to some pre-determined interval motivated the introduction ofthe LbyR 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 [I-D.ietf-geopriv-loc-filters].model. +-----------+ Geopriv +-----------+ | | Location | Location | | LIS +---------------+ Recipient | | | Dereference | | +-+---+-----+ Protocol (3) +----+------+ * | -- Rulemaker * | Geopriv -- Policy * | Location -- Exchange * | Configuration -- (1b) * | Protocol -- * | (1a) -- Geopriv * | -- Using Protocol + - - - -*- - - - - -|- - - -+ -- (e.g., SIP) |+------+----+ +-----+-----+ |-- (2) | Rulemaker | | Target / |-- || / owner | | End Host + | | | | | |+-----------+ +-----------+ | | User of Target | + - - - - - - - - - - - - - -+ Figure 1: Shows the assumed communication model for both a layer 7 location configuration protocolLocation Reference Entities and a dereference protocol:Interactions Figure 1: Shows1 shows the assumed communication model for both a layer 7 location configuration protocol and a location dereference protocol. (1a). Target requests reference from server; and receives back, a location URI in server response (1b). Rulemaker policy is consulted (interface out of scope) (2). Target conveys reference to recipient (out of scope) (3). Recipient dereferences location URI, by a choice of methods, including a request/response (e.g., HTTP) or publish/subscription (e.g., SIP SUBSCRIBE/NOTIFY) Note A. There is no requirement for using the same protocol in (1a) and (3). Note B. Figure 1 includes the interaction between the owner of the Target and the LIS to establish Rulemaker policies. This is communications path (1b). This interaction needs to be done before the LIS will authorize anything ofother than default policies to a dereference request for location of the Target. Note C. that theThe Target may take on the role of the Location Recipient whereby it would dereference the location URI to obtain its own location information. An example scenario of how this might work, is where the Target obtains a location URI in the form of a subscription URI (e.g., a SIP URI) via HELD,HELD (a Geopriv layer 7 location configuration protocol). Since, inIn this casecase, the Target equalsis the same as the Recipient, thentherefore the Target can subscribe to the URI in order to be notified of its current location based on subscription parameters. In the example, parameters (see [I-D.ietf-geopriv-loc-filters]). Additionally,are set up for a geospatial boundary can bespecific Target/Recipient along with an expressed (ref. [I-D.ietf-geopriv-policy]),geospatial boundary, so that the Target/Recipient will get itsreceives an updated location notification once it crossesthe specified boundary.boundary is crossed (see [I-D.ietf-geopriv-loc-filters]). Location URIs may have an expiry associated towith them, primarily for security considerations, and generally so that the LIS is able to keep track of the location URIs that have been handed out, to know whether a location URI is still valid once the LIS receives it in a request, and in order for a recipient of such a URI from being able to (in some cases) permanently track a host. Expiration of a location URI limits the time that accidental leaking of a location URI introduces. Other justifications for expiration of location URIs include the ability for a LIS to do garbage collection. Because a location URI is a pointer to the Target's location, it is important that it be constructed in such a way that it does not unintentionally reveal any usable information about the Target it represents. For example, it is important to prevent adversaries from obtaining any information that may be revealed about a Target by direct examination of the location URI itself, (e.g., names, identifiers, etc.), some determinable pattern or syntax (e.g., sequence of numbers), or guessable codes (e.g., weak encryption). Therefore, each location URI must be constructed with security safeguards in mind. How a location URI is will ultimately be used within the dereference step is an important consideration at the time that the location URI is requested via a location configuration protocol. Since dereferencing of location URIs could be done according to one of two authorization models, either an "access control" modelcontrol authorization model" or a "possession" model"possession authorization model" (see definitions, below), it is important that location configuration protocols indicate the type of a location URI that is being requested, (and also which type is returned). Dereference protocols must support both types.1. Access control use type:authorization model: Access to the location URI is limited by policy. This isIn this case, the case where, for location configuration,Rule Maker (owner/Target) is able to provide authorization policies to the LIS applies (server side) authentication and access control at the location configuration step, and repeats authentication and authorization for each dereference operation of thatduring this stage, or through some other parallel mechanism (e.g., interface 1b., Figure 1.). Policies are attached to a location URI.URI through an (undisclosed) mechanism. 2. Possession use type:authorization model: The possession use typeauthorization model is described as having no authentication and/or authorization requirement aside from only possessing the location URI itself (initself. In this case, possession implies authorization).authorization. Access to the location URI is limited by distribution only. Whoever possesses the location URI has the ability to dereference it. Possession use typesauthorization models may be used within specified domains only, or might be used across wide open public networks. In either of the above cases, a location URI needs to be constructed is such a way as to make it difficult to guess. The form of the URI is constrained by the degree of randomness and uniqueness applied to it. It is important to protect the actual location information from an intermediate node (despite the fact that in the possession model there would be nothing to prevent an interceptor from seeking to dereference the location URI). Obfuscating the location URI safeguards against the undetected stripping off of what would otherwise be evident location information, since it forces a dereference operation by the location dereference server, an important step for the purpose of providing statistics, audit trails, and general logging for many different kinds of location based services. 4. High-Level Requirements This document outlines the requirements for an Location by Reference mechanism which can be used by a number of underlying protocols. Requirements here address two general types of such protocols, a general location configuration protocol, and a general location dereferencing protocol. Each of these two general protocols has multiple specific protocol implementations. Location configuration protocols include, HELD, DHCP, and LLDP-MED, whereas current location dereferencing protocols include HELD Deref, HTTP GET, and SIP SUBSCRIBE/NOTIFY. Because each of these specific protocol implementations has its own unique client and server interactions, the requirements here are not intended to state what a client or server is expected to do, but rather which requirements must be met separately by any location configuration protocol or location dereference protocol, for the purposes of using a location URI. The requirements are broken into two sections. 4.1. Requirements for a Location Configuration Protocol Below, we summarize high-level design requirements needed for a location-by-reference mechanism as used within the location configuration protocol. C1. Location URI support: The configuration protocol MUST support a location reference in URI form. Motivation: It is helpful to have a consistent form of key for the LbyR mechanism. C2. Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated. Motivation: A location URI may not intend 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. C3. Location URI cancellation: The location configuration protocol SHOULDMUST support the ability to request a cancellation of a specific location URI. Motivation: If the client determines that in its best interest to destroy the ability for a location URI to effectively be used to dereference a location, then there should be a way to nullify the location URI. C4. Location Information Masking: The location URI form MUST, through randomization and uniqueness, ensure that any location specific information embedded within the location URI itself is kept obscure during location configuration. Motivation: It is important to keep any location information masked from a casual observing node. C5. User Identity Protection: The location URI MUST NOT contain any user identifying information that identifies the user, device or address of record, (e.g., which includes phone extensions, badge numbers, first or last names, etc.), within the URI form. Motivation: It is important to protect caller identity or contact address from being included in the form of the location URI itself when it is generated. C6. Reuse indicator: There SHOULD be a way to allow a client to control whether a location URI can be resolved once only, or multiple times. Motivation: The client requesting a location URI may request a location URI which has a 'one-time-use' only characteristic, as opposed to a location URI having multiple reuse capability. C7. Location URI Valid-for:Validity Interval Indication: A location URI validity interval, if used,configuration protocol MUST include the validity time, in seconds, asprovide an indication of how longthe client can consider alocation URI to be valid.validity interval (i.e., expiry time) when present. Motivation: It is important to be able to determine how long a location URI is to remain useful for, and when it must be refreshed. C8. Location URI Anonymous:only: The location URI MUST NOT point to any information about the Target other than it's location. Motivation: A user should have the option to control how much information is revealed about them. This provides that control by not forcing the inclusion of other information with location, (e.g., to not include any identification information in the location URI.) C9. Location URI Not guessable: Where location URIs are used publicly, any location URI MUST be constructed using properties of uniqueness and cryptographically random sequences so that it is not guessable. (Note that the number of bits depends to some extent on the number of active location URIs that might exist at the one time; 128-bit is most likely enough for the near term.) Motivation: Location URIs need to guard against any observing node or individual stripping off meaningful information about the Target. C10. Location URI Optional: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support optional location URI forms. Motivation: Users don't always have such strict privacy requirements, but may opt to specify their own location URI, or components thereof. C11. Location URI Use Type:Authorization Model: The location configuration protocol MUSTSHOULD indicate whether the requested location URI conforms to the access control authorization model or the possession authorization model. Motivation: Downstream dereference clients and servers need to know whether a location URI provided by the location configuration protocol conforms to an access control authorization model or a possession authorization model. C12. Location URI Lifetime: A location URI SHOULD have an associated expiration lifetime (i.e., validity interval), and MUST have an validity interval if used with the possession authorization model. Motivation: If a location URI is unintentionally leaked, then the amount of time that the reference can be potentially used by an unknown attacker (or, casual observer) needs to be limited. 4.2. Requirements for a Location Dereference Protocol Below, we summarize high-level design requirements needed for a location-by-reference mechanism as used within the location dereference protocol. D1. Location URI support: The location dereference protocol MUST support a location reference in URI form. Motivation: It is required that there be consistency of use between location URI formats used in an configuration protocol and those used by a dereference protocol. D2. Location URI expiration indicator: TheValidity Interval Indication: A location dereference protocol MUST supportprovide an indicator showing that, if it isindication of the case, that alocation URI validity interval (i.e., expiry time) when present. Motivation: It is no longer valid dueimportant to expiration. Motivation: Location URIs are expectedbe able to expire, based ondetermine how long a location configuration protocol parameters, and itURI is therefore usefulto convey the expired status of the location URI in the location dereference protocol.remain useful for, and what time it will no longer be usable. D3. Authentication: The location dereference protocol MUST include mechanisms to authenticate both the client and the server. Motivation: Although the implementations must support authentication of both parties, any given transaction has the option not to authenticate one or both parties. D4. Dereferenced Location Form: The value returned by the dereference protocol MUST contain a well-formed PIDF-LO document. Motivation: This is in order to ensure that adequate privacy rules can be adhered to, since the PIDF-LO format comprises the necessary structures to maintain location privacy. D5. Location URI Repeated Use: The location dereference protocol MUST support the ability for the same location URI to be resolved more than once, based on dereference server configuration. Motivation: Through dereference server configuration, for example, it may be useful to not only allow more than one dereference request, but, in some cases, to also limit the number of dereferencing attempts by a client. D6. Location URI Valid-for:Validity Interval Indication: A location URI validity interval, if used,dereference protocol MUST include the validity time, in seconds, asprovide an indication of how longthe client can consider alocation URI to be valid.validity interval (i.e., expiry time) when present. Motivation: It is important to be able to determine how long a location URI is to remain useful for, and when dereferencing a location URI.it must be refreshed. D7. Location URI anonymized: Any location URI whose dereference will not be subject to authentication and access control MUST be anonymized. Motivation: The dereference protocol must define an anonymized format for location URIs. This format must identify the desired location information via a random token with at least 128 bits of entropy (rather than some kind of explicit identifier, such as an IP address). D8. Location Information Masking: The location URI form MUST, through randomization and uniqueness, ensure that any location specific information embedded within the location URI itself is kept obscure during location URI dereferencing. Motivation: It is important to keep any location information masked from a casual observing node, requiring instead a discrete dereference operation in order to return location information. D9. Location Privacy: The location dereference protocol MUST support the application of privacy rules to the dissemination of a requested location object. Motivation: The dereference server must obey all provisioned privacy rules that apply to a requested location object. D10. Location Confidentiality: The dereference protocol MUST support encryption of messages sent between the location dereference client and the location dereference server, and MAY alternatively provide messaging unencrypted. Motivation: Environmental and local configuration policy will guide the requirement for encryption for certain transactions. In some cases, encryption may be the rule, in others, it may be acceptable to send and receive messages without encryption. D11. Location URI Use Type:Authorization Model: The location dereference protocol MUSTSHOULD indicate whether the requested location URI conforms to the access control authorization model or the possession authorization model. Motivation: Downstream dereference clients need to know whether a location URI provided by the location configuration protocol conforms to an access control authorization model or a possession authorization model in order to save time processing dereference attempts. 5. Security Considerations The LbyR mechanism currently addresses security issues as follows.A location URI, regardless of its construction, if public, by itself, implies no safeguard against anyone being able to dereference and get the location. The method of constructing the location URI form to include randomization along with encryption does help prevent some potential pattern guessing. In the case of one time use location URIs, (referred to as a pawn ticket), the argument can be made that possession implies permission, and location URIs that are public are protected only by privacy rules enforced at the dereference server. Any location URI, by necessity, indicates the server (name) that hosts the location information. Knowledge of the server in some specific domain could therefore reveal something about the location of the Target. This kind of threat may be mitigated somewhat by introducing another layer of indirection: namely the use of a (remote) presence server. 6. IANA Considerations This document does not require actions by the IANA. 7. Acknowledgements WeI would like to thank the present IETF GEOPRIV working group chair for their continued support in progressing this document along, as well, I wish to thank past chairs, Andy Newton, Allison Mankin and Randall Gellens, for creating the design team which initiated this requirements work. We'dI'd also like to thank those original design team participants for their inputs, comments, and insightful reviews. The design team included the following folks: Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes Tschofenig; Martin Thomson; and James Winterbottom. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-07draft-ietf-geopriv-http-location-delivery-10 (work in progress), AprilOctober 2008. [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-08 (work in progress), June 2008. [I-D.ietf-geopriv-loc-filters] Mahy, R.,R. and B. Rosen, "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", draft-ietf-geopriv-loc-filters-01draft-ietf-geopriv-loc-filters-02 (work in progress), March 2007.July 2008. [I-D.ietf-geopriv-policy] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-17 (work in progress), June 2008. [I-D.ietf-sip-location-conveyance] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sip-location-conveyance-10draft-ietf-sip-location-conveyance-11 (work in progress), FebruaryOctober 2008. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Appendix A. Change log Changes to this draft in comparison to the previous version (-04 vs. -03): 1. Changed wording of section 1 "Introduction", (Thompson ~ 7/09/08 list comments). 1. Relocated text in section 3 "Overview of Location-by-Reference" to section 1 (Intro), (Thompson comments). 2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thompson comments). 3. Fixed minor spelling errors, incl. Note B., Note C., etc., based on (Thompson comments). 4. Added some qualifying text (security) around possession model, based on (Thompson comments). 5. Replaced "use type" labels with "authorization models", "access authorization model", and "possession authorization model", (Thompson comments). 6. Changed the entity role of applying security from LIS (Server- side authentication), to the Rule-Maker (owner/Target) providing policies to the LIS, (Thompson comments). 7. Changed requirement C3 to a MUST, (Thompson comments). 8. Added new requirement, C12, "C12. Location URI Lifetime:" as a SHOULD for all, and MUST for possession auth model, (Thompson comments). 9. Changed name of requirement C8 to "Location Only", (Thompson comments). 10. Reworded C7 and D6 to be less implementation specific, (Thompson comments). 11. Changed requirements C11, D11 to SHOULD, (Thompson comments). 12. (Section 5:) Removed lead in sentence for readibility, (Thompson comments). 13. Remove "pawn ticket" reference - replaced with "possession authorization model", (Thompson comments). 14. Added new paragraph to the security section (Thompson, 7/09/08 comments). 15. Corrected other minor spelling and wording errors and deficiencies (refer to diff 04/03) (-Editor). Changes to this draft in comparison to the previous version (-03 vs. -02): 1. Changed wording of section 3 "Overview of Location-by-Reference" (Polk, Thomson, Winterbottom ~ 4/1/08 list comments). 2. Added new requirement C4. "Location Information Masking:", based on (Thomson ~4/1/08 list comment). 3. Added new requirement C11. "Location URI Use Type:", based on (~4/1/08 list comments). 4. Added new requirement D11. "Location URI Use Type:", for deref. based on (~4/1/08 list comments). 5. Replaced requirement D8. "Location URI Non-Anonymized" with "Location Information Masking:". Changes to this draft in comparison to the previous version (-02 vs. -01): 1. Reworded Introduction (Barnes 12/6 list comments). 2. Changed name of "Basic Actors" section to "Overview of Location by Reference" (Barnes). 3. Keeping the LCP term away (for now) since it is used as Link Control Protocol elsewhere (IETF). 4. Changed formatting of Terminology section (Barnes). 5. Requirement C2. changed to indicate that if the URI has a lifetime, it has to have an expiry (Barnes) 6. C7. Changed title and wording based on suggested text and dhcp- uri-option example (Polk). 7. The new C2 req. describing valid-for, was also added into the deref section, as D6 8. Changed C4 based on much list discussion - replaced by 3 new requirements... 9. Reworded C5 based on the follow-on C4 thread/discussion on list (~2/18). 10. Changed wording of D3 based on suggestion (Barnes). 11. Reworded D4 per suggestion (Barnes). 12. Changed D5 based on comment (Barnes), and additional title and text changes for clarity. 13. Added D9 and D10 per Richard Barnes suggestions - something needed in addition to his own security doc. 14. Deleted reference to individual Barnes-loc-sec draft per wg list suggestion (Barnes), but need more text for this draft's security section. Author's Address Roger Marshall (editor) TeleCommunication Systems, Inc. 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 US Phone: +1 206 792 2424 Email: email@example.com URI: http://www.telecomsys.com Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 firstname.lastname@example.org.