| écrit | B. Rosen |
| Internet-Draft | Neustar |
| Intended status: Standards Track | November 04, 2013 |
| Expires: May 08, 2014 |
Validation of Locations Around a Planned Change
draft-rosen-ecrit-lost-planned-changes-00
This document defines an extension to LoST (RFC5222) that allows a planned change to the data in the LoST server to occur. Records that previously were valid will become invalid at a date in the future, and new locations will become valid after the date. The extension adds two elements to the <findservice> request: a URI to be used to inform the LIS that previously valid locations will be invalid after the planned change date, and add a date which requests the server to perform validation as of the date specified.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 08, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes an update to the LoST protocol [RFC5222] which allows a <findservice> request to add a URI and a date to be used with planned changes to the underlying location information in the server which is used by the validation function. The URI is retained by the LoST server, associated with the data record that was validated, and used to notify the LIS (the LoST client) when a location which was previously valid will become invalid. The date is used by the client to ask the server to perform validation as of a future date.
Validation of civic locations involves dealing with data that changes over time. A typical example is a portion of a county or province that was not part of a municipality is “annexed” to a municipality. Prior to the change, the content of the PIDF A3 element would be blank, or represent some other value and after the change would be the municipality that annexed that part of the county/province. This kind of annexation has an effectivity date (typically 00:00 on some date).
Records in a LIS must change around these kinds of events. The old record must be discarded, and a new, validated record must be loaded into the LIS. It is often difficult for the LIS operator to know that records must be changed. There are other circumstances where locations that were previously valid become invalid. As RFC5222 defines validation, the only way for a LIS to discover such changes was to periodically revalidate its entire database. Of course, this would not facilitate timely changes, and also adds significant load to the LoST server.
This extension allows the client to provide a stable URI that is retained by the server associated with the location provided that the location information in the request was valid. In the event of a planned change, or any other circumstance where the LI becomes invalid, the server sends a notification to the URI informing it of a change. The notification contains the date and time when the LI becomes invalid.
Ideally, the LIS will prepare a new record, to be inserted in its active database, that becomes valid at the precise planned event date and time, at which point it would also delete the old record. However, the new record has to be valid, and the LIS would like to validate it prior to the planned change event. If it requests validation before the planned event, the server (without this extension) would inform the client that the location was invalid. This extension includes an optional “asOf” date and time in the request that allows the LoST server to provide validation as of the date and time specified, as opposed to the “as of now” implied in the current LoST protocol.
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 [RFC2119].
”Server” in this document refers to the LoST server and “Client” is the LoST client, even when the server is performing an operation on the client.
This document defines a new element to <findService> called ‘plannedChange’. This element contains two attributes: ‘uri’ and ‘asOf’. The ‘uri’ attribute MUST be a URI with a scheme of https. The URI will be stored by the server against the location in the request for subsequent use with the notification function defined below. To minimize storage requirements of at the server, the length of the URI MUST be less than 256 bytes. Each client of the server may only store one URI against a location, where “location” is defined by policy at the server, since a given unique location may have many combinations of LI elements that resolve to the same location. If the server receives a ‘uri’ for the same location from the same client, the URI in the request replaces the URI it previously retained. Policy at the server may limit how many uris it retains for a given location. A new warning is defined below to be used to indicate that the URI has not been stored.
When the server needs to invalidate a location where the client provided a URI in <plannedChange>, the server sends <locationInvalidated> to the URI previously provided. This is the notice from the server to the client that the location may be invalid and should be revalidated. <locationInvalidated> contains an asOf attribute that specifies when the location may become invalid. If the date/time in asOf is earlier than the time the <locationInvalidated> was sent, the location may already be invalid and the LIS should take immediate action.
The Relax NG schema in [RFC5222] is modified to be:
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost-plannedChange1“
##
## Extension to Location-to-Service Translation (LoST) Protocol
## to support a planned change to location data
##
## plannedChange is used in the extensionPoint of
## commonRequestPattern in a findService request
##
## locationInvalidated is used by the LoST server to notify a
## LIS that a previously valid location may be (or will become)
## invalid
##
## uriNotStored is a new warning to be used in a
## exceptionContainer in the warnings element of a
## findServiceResponse
##
start =
plannedChange
| locationInvalidated
| uriNotStored
##
## plannedChange
##
div {
plannedChange =
element plannedChange {
attribute uri {
xsd:anyURI }?,
attribute asOf {
xsd:dateTime }?,
extensionPoint+
}
}
##
## locationInvalidated
##
div {
locationInvalidated =
element locationInvalidated {
attribute asOf {
xsd:dateTime }?,
extensionPoint+
}
}
##
## uriNotStored
##
div {
uriNotStored =
element uriNotStored { basicException }
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST namespace.
##
notLostChange = element * - (ns1:* | ns1:*) { anyElement }
##
## A wildcard pattern for including any element
## from any other namespace.
##
anyElement =
(element * { anyElement }
| attribute * { text }
| text)*
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLostChanged*
}
As an extension to LoST, this document inherits the security issues raised in [RFC5222]. The server could be tricked into storing a malicious URI which, when sent the locationInvalidated object could trigger something untoward. The server MUST NOT accept any data from the client in response to POSTing the locationInvalidated.
The server is subject to abuse by clients because it is being asked to store something and may need to send data to an uncontrolled URI. Clients could request many URIs for the same location for example. The server MUST have policy that limits use of this mechanism by a given client. If the policy is exceeded, the server returns the uriNotStored warning. The server MUST validate that the content of the uri sent is syntactically valid and meets the 256 byte limit. When sending the locationInvalidated object to the uri stored, the server MUST protect itself against common http vulnerabilities.
The mutual authentication between client and server when is RECOMMENDED for both the initial findService operation that requests storing the uri and the sending of the locationInvalidated object. The server should be well known to the client, and its credential can be learned in a reliable way. For example, a public safety system operating the LoST server may have a credential traceable to a well known Certificate Authority known to provide credentials for public safety agencies. Many of the clients will be operated by local ISPs or other service providers where the server operator can reasonably obtain a good credential to use for the URI. Where the server does not recognize the client, it’s policy MAY limit the use of this feature beyond what it would limit a client it recognized.
URI: urn:ietf:params:xml:schema:lost-planedChange1
Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianrosen.net).
Relax NG Schema: The Relax NG schema to be registered is contained
in Section 5. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost-PlannedChange1
and its last line is
}
URI: urn:ietf:params:xml:ns:lost-plannedChange1
Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianrosen.net).
XML:
BEGIN
<?xml version="2.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Planned Change Namespace</title>
</head>
<body>
<h1>Namespace for LoST Planned Change extension</h1>
<h2>urn:ietf:params:xml:ns:lost-plannedChange1</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc????.txt">
RFC????</a>.</p>
</body>
</html>
END
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5222] | Hardie, T., Newton, A., Schulzrinne, H. and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. |