idnits 2.17.1 draft-rosen-ecrit-lost-planned-changes-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2013) is 3820 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B. Rosen 3 Internet-Draft Neustar 4 Intended status: Standards Track November 04, 2013 5 Expires: May 08, 2014 7 Validation of Locations Around a Planned Change 8 draft-rosen-ecrit-lost-planned-changes-00 10 Abstract 12 This document defines an extension to LoST (RFC5222) that allows a 13 planned change to the data in the LoST server to occur. Records that 14 previously were valid will become invalid at a date in the future, 15 and new locations will become valid after the date. The extension 16 adds two elements to the request: a URI to be used to 17 inform the LIS that previously valid locations will be invalid after 18 the planned change date, and add a date which requests the server to 19 perform validation as of the date specified. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 08, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 3 57 3. element . . . . . . . . . . . . . . . . . . . 3 58 4. object . . . . . . . . . . . . . . . . 4 59 5. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Relax NG Schema Registration . . . . . . . . . . . . . . 6 63 7.2. LoST Namespace Registration . . . . . . . . . . . . . . . 7 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 This document describes an update to the LoST protocol [RFC5222] 69 which allows a request to add a URI and a date to be 70 used with planned changes to the underlying location information in 71 the server which is used by the validation function. The URI is 72 retained by the LoST server, associated with the data record that was 73 validated, and used to notify the LIS (the LoST client) when a 74 location which was previously valid will become invalid. The date is 75 used by the client to ask the server to perform validation as of a 76 future date. 78 Validation of civic locations involves dealing with data that changes 79 over time. A typical example is a portion of a county or province 80 that was not part of a municipality is "annexed" to a municipality. 81 Prior to the change, the content of the PIDF A3 element would be 82 blank, or represent some other value and after the change would be 83 the municipality that annexed that part of the county/province. This 84 kind of annexation has an effectivity date (typically 00:00 on some 85 date). 87 Records in a LIS must change around these kinds of events. The old 88 record must be discarded, and a new, validated record must be loaded 89 into the LIS. It is often difficult for the LIS operator to know 90 that records must be changed. There are other circumstances where 91 locations that were previously valid become invalid. As RFC5222 92 defines validation, the only way for a LIS to discover such changes 93 was to periodically revalidate its entire database. Of course, this 94 would not facilitate timely changes, and also adds significant load 95 to the LoST server. 97 This extension allows the client to provide a stable URI that is 98 retained by the server associated with the location provided that the 99 location information in the request was valid. In the event of a 100 planned change, or any other circumstance where the LI becomes 101 invalid, the server sends a notification to the URI informing it of a 102 change. The notification contains the date and time when the LI 103 becomes invalid. 105 Ideally, the LIS will prepare a new record, to be inserted in its 106 active database, that becomes valid at the precise planned event date 107 and time, at which point it would also delete the old record. 108 However, the new record has to be valid, and the LIS would like to 109 validate it prior to the planned change event. If it requests 110 validation before the planned event, the server (without this 111 extension) would inform the client that the location was invalid. 112 This extension includes an optional "asOf" date and time in the 113 request that allows the LoST server to provide validation as of the 114 date and time specified, as opposed to the "as of now" implied in the 115 current LoST protocol. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 "Server" in this document refers to the LoST server and "Client" is 124 the LoST client, even when the server is performing an operation on 125 the client. 127 3. element 129 This document defines a new element to called 130 'plannedChange'. This element contains two attributes: 'uri' and 131 'asOf'. The 'uri' attribute MUST be a URI with a scheme of https. 132 The URI will be stored by the server against the location in the 133 request for subsequent use with the notification function defined 134 below. To minimize storage requirements of at the server, the length 135 of the URI MUST be less than 256 bytes. Each client of the server 136 may only store one URI against a location, where "location" is 137 defined by policy at the server, since a given unique location may 138 have many combinations of LI elements that resolve to the same 139 location. If the server receives a 'uri' for the same location from 140 the same client, the URI in the request replaces the URI it 141 previously retained. Policy at the server may limit how many uris it 142 retains for a given location. A new warning is defined below to be 143 used to indicate that the URI has not been stored. 145 4. object 147 When the server needs to invalidate a location where the client 148 provided a URI in , the server sends 149 to the URI previously provided. This is the 150 notice from the server to the client that the location may be invalid 151 and should be revalidated. contains an asOf 152 attribute that specifies when the location may become invalid. If 153 the date/time in asOf is earlier than the time the 154 was sent, the location may already be invalid 155 and the LIS should take immediate action. 157 5. Relax NG Schema 159 The Relax NG schema in [RFC5222] is modified to be: 161 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 162 default namespace ns1 = "urn:ietf:params:xml:ns:lost-plannedChange1" 164 ## 165 ## Extension to Location-to-Service Translation (LoST) Protocol 166 ## to support a planned change to location data 167 ## 168 ## plannedChange is used in the extensionPoint of 169 ## commonRequestPattern in a findService request 170 ## 171 ## locationInvalidated is used by the LoST server to notify a 172 ## LIS that a previously valid location may be (or will become) 173 ## invalid 174 ## 175 ## uriNotStored is a new warning to be used in a 176 ## exceptionContainer in the warnings element of a 177 ## findServiceResponse 178 ## 179 start = 180 plannedChange 181 | locationInvalidated 182 | uriNotStored 183 ## 184 ## plannedChange 185 ## 186 div { 187 plannedChange = 188 element plannedChange { 189 attribute uri { 190 xsd:anyURI }?, 191 attribute asOf { 192 xsd:dateTime }?, 194 extensionPoint+ 195 } 196 } 198 ## 199 ## locationInvalidated 200 ## 201 div { 202 locationInvalidated = 203 element locationInvalidated { 204 attribute asOf { 205 xsd:dateTime }?, 206 extensionPoint+ 207 } 208 } 210 ## 211 ## uriNotStored 212 ## 213 div { 214 uriNotStored = 215 element uriNotStored { basicException } 216 } 218 ## 219 ## Patterns for inclusion of elements from schemas in 220 ## other namespaces. 221 ## 222 div { 224 ## 225 ## Any element not in the LoST namespace. 226 ## 227 notLostChange = element * - (ns1:* | ns1:*) { anyElement } 229 ## 230 ## A wildcard pattern for including any element 231 ## from any other namespace. 232 ## 233 anyElement = 234 (element * { anyElement } 235 | attribute * { text } 236 | text)* 238 ## 239 ## A point where future extensions 240 ## (elements from other namespaces) 241 ## can be added. 243 ## 244 extensionPoint = notLostChanged* 245 } 247 6. Security Considerations 249 As an extension to LoST, this document inherits the security issues 250 raised in [RFC5222]. The server could be tricked into storing a 251 malicious URI which, when sent the locationInvalidated object could 252 trigger something untoward. The server MUST NOT accept any data from 253 the client in response to POSTing the locationInvalidated. 255 The server is subject to abuse by clients because it is being asked 256 to store something and may need to send data to an uncontrolled URI. 257 Clients could request many URIs for the same location for example. 258 The server MUST have policy that limits use of this mechanism by a 259 given client. If the policy is exceeded, the server returns the 260 uriNotStored warning. The server MUST validate that the content of 261 the uri sent is syntactically valid and meets the 256 byte limit. 262 When sending the locationInvalidated object to the uri stored, the 263 server MUST protect itself against common http vulnerabilities. 265 The mutual authentication between client and server when is 266 RECOMMENDED for both the initial findService operation that requests 267 storing the uri and the sending of the locationInvalidated object. 268 The server should be well known to the client, and its credential can 269 be learned in a reliable way. For example, a public safety system 270 operating the LoST server may have a credential traceable to a well 271 known Certificate Authority known to provide credentials for public 272 safety agencies. Many of the clients will be operated by local ISPs 273 or other service providers where the server operator can reasonably 274 obtain a good credential to use for the URI. Where the server does 275 not recognize the client, it's policy MAY limit the use of this 276 feature beyond what it would limit a client it recognized. 278 7. IANA Considerations 280 7.1. Relax NG Schema Registration 282 URI: urn:ietf:params:xml:schema:lost-planedChange1 284 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 285 (br@brianrosen.net). 287 Relax NG Schema: The Relax NG schema to be registered is contained 288 in Section 5. Its first line is 290 default namespace = "urn:ietf:params:xml:ns:lost-PlannedChange1 292 and its last line is 294 } 296 7.2. LoST Namespace Registration 298 URI: urn:ietf:params:xml:ns:lost-plannedChange1 300 Registrant Contact: IETF ECRIT Working Group, Brian Rosen 301 (br@brianrosen.net). 303 XML: 305 BEGIN 306 307 309 310 311 313 LoST Planned Change Namespace 314 315 316

Namespace for LoST Planned Change extension

317

urn:ietf:params:xml:ns:lost-plannedChange1

318

See 319 RFC????.

320 321 322 END 324 8. Normative References 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, March 1997. 329 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 330 Tschofenig, "LoST: A Location-to-Service Translation 331 Protocol", RFC 5222, August 2008. 333 Author's Address 335 Brian Rosen 336 Neustar 337 470 Conrad Dr 338 Mars, PA 16046 339 US 341 EMail: br@brianrosen.net