Completing the Request Location

This document defines an extension to LoST (RFC5222) that allows a request to specify that a PIDF be returned in the response if the location was valid, but there were some missing elements. For example, an civic location that did not include a postal code, but was otherwise a complete, and unambiguous location, would receive a complete PIDF in the response that included the postal code.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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.”

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

1. Introduction
2. Conventions used in this document
3. <requestCompletedLocation> element
4. <responseCompletedLocation> element
5. Relax NG Schema
6. Security Considerations
7. IANA Considerations
7.1. Relax NG Schema Registration
7.2. LoST Namespace Registration
8. Normative References

1. Introduction

When performing a validation function, the criteria to determine if a location is valid used will often be that the information provided was sufficient to uniquely identify the location proffered in the request. It may not be necessary that the request PIDF-LO contain all of the elements that the LoST server may know about for the location. So long as there were sufficient elements to uniquely identify the location, the location could be considered valid. However, when the location is subsequently used (in a LoST request, or for any other use), having those fields that the LoST server has, but the requestor does not, may be valuable.

For example, the input PIDF-LO may contain the <PCN> element (the postal community name) and a <PC> element (the postal code), but may be missing the <A3> element (city, township). Having the postal addressing information may be sufficient (along with the other information in the PIDF-LO) to determine exactly where the PIDF-LO refers to. However, the post office name may be different from the actual municipality, and the PSAP that serves it may depend on the actual municipality. To cite a specific, the Postal Code 16046, with the postal community name "Mars", in the state of Pennsylvania in the United States spans a county boundary and four communities. A street name of "Conrad" is in Allegheny County, in Pine Township. There is a Mars township, but it is in Butler County. Allegheny County is served by the Allegheny PSAP, Butler County is served by the Butler PSAP. If the PIDF-LO in the request included:

the information in this PIDF may be enough to precisely locate the target in Pine Township, Allegheny County (because there is only one Conrad Drive in postal code 16046). The requestor may need to know that this is Pine, and not Mars. The response to this request arising from the use of the extension described in this document may include:

This extension allows the requester to ask the LoST server to complete the location, that is, return a complete PIDF with the elements it may have that were not in the request, provided that the location was valid. If the location was not valid, the LoST server would not know what to return.

This feature is not a 'partial location matching function' which might be used to guess at what a valid location might be given a less-than-unique set of elements. When the LoST server returns additional elements, it does so knowing that the elements it returns indeed belong to the location described by the request.

2. Conventions used in this document

3. <requestCompletedLocation> element

This document defines a new attribute to <findService> called 'requestLocation'. When the LoST server receives a <findService> request containing a 'requestLocation' attribute with values of 'true', and the PIDF in the <location> element within the request is valid, it will include a PIDF in the response.

4. <responseCompletedLocation> element

When the <findService> request contains a requestCompletedLocation attribute set to true, and <location> in the request is valid, then the server MUST include a <responseCompletedLocation> element in the <findServiceResponse> containing a PIDF will all the elements of the <location> PIDF, plus any additional elements that the LoST server may have that pertain to that location.

If the request contains requestLocation, but the location was invalid, the server MUST NOT send a PIDF in the response. The locationInvalid response will indicate to the requestor that no PIDF should be expected in the response. requestLocation is independent of locationValidation in the request.

5. Relax NG Schema

namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost1"

##
##       Location-to-Service Translation (LoST) Protocol

##
##       A LoST XML instance has three request types, each with
##       a corresponding response type: find service, list services,
##       and get service boundary.
##
start =
  findService
  | listServices
  | listServicesByLocation
  | getServiceBoundary
  | findServiceResponse
  | listServicesResponse
  | listServicesByLocationResponse
  | getServiceBoundaryResponse
  | errors
  | redirect

##
##       The queries.
##
div {
  findService =
    element findService {
      requestLocation,
      commonRequestPattern,
      attribute validateLocation {
        xsd:boolean >> a:defaultValue [ "false" ]
      }?,
      attribute requestCompletedLocation {
        xsd:boolean >> a:defaultValue [ "false" ]
      }?,
      attribute serviceBoundary {
        ("reference" | "value") >> a:defaultValue [ "reference" ]
      }?,
      attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
    }
  listServices = element listServices { commonRequestPattern }
  listServicesByLocation =
    element listServicesByLocation {
      requestLocation,
      commonRequestPattern,
      attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
    }
  getServiceBoundary =
    element getServiceBoundary { serviceBoundaryKey, extensionPoint }
}

##
##       The responses.
##
div {
  findServiceResponse =
    element findServiceResponse {
      mapping+, locationValidation?, responseCompletedLocation?,
      commonResponsePattern, locationUsed
    }
  listServicesResponse =
    element listServicesResponse { serviceList, commonResponsePattern }
  listServicesByLocationResponse =
    element listServicesByLocationResponse {
      serviceList, commonResponsePattern, locationUsed
    }
  getServiceBoundaryResponse =
    element getServiceBoundaryResponse {
      serviceBoundary, commonResponsePattern
    }
}

##
##       A pattern common to some of the queries.
##
div {
  commonRequestPattern = service, path?, extensionPoint
}

##
##       A pattern common to responses.
##
div {
  commonResponsePattern = warnings*, path, extensionPoint
}

##
##       Location in Requests
##
div {
  requestLocation =
    element location {
      attribute id { xsd:token },
      locationInformation
    }+
}

##
##       Completed Location in Responses
##
div {
  responseCompletedLocation =
    element location {
      attribute id { xsd:token },
      locationInformation
    }+
}

##
##       Location Information
##
div {
  locationInformation =
    extensionPoint+,
    attribute profile { xsd:NMTOKEN }?
}

##
##       Service Boundary
##
div {
  serviceBoundary = element serviceBoundary { locationInformation }+
}

##
##       Service Boundary Reference
##
div {
  serviceBoundaryReference =
    element serviceBoundaryReference {
      source, serviceBoundaryKey, extensionPoint
    }
  serviceBoundaryKey = attribute key { xsd:token }
}

##
##       Path -
##       Contains a list of via elements -
##       places through which information flowed
##
div {
  path =
    element path {
      element via { source, extensionPoint }+
    }
}

##
##       Location Used
##
div {
  locationUsed =
    element locationUsed {
      attribute id { xsd:token }
    }?
}

##
##       Expires pattern
##
div {
  expires =
    attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}

##
##       A QName list
##
div {
  qnameList = list { xsd:QName* }
}

##
##       A location-to-service mapping.
##
div {
  mapping =
    element mapping {
      element displayName {
        xsd:string,
        attribute xml:lang { xsd:language }
      }*,
      service,
      (serviceBoundary | serviceBoundaryReference)?,
      element uri { xsd:anyURI }*,
      element serviceNumber {
        xsd:token { pattern = "[0-9*#]+" }
      }?,
      extensionPoint,
      expires,
      attribute lastUpdated { xsd:dateTime },
      source,
      attribute sourceId { xsd:token },
      message
    }
}

##
##       Location validation
##
div {
  locationValidation =
    element locationValidation {
      element valid { qnameList }?,
      element invalid { qnameList }?,
      element unchecked { qnameList }?,
      extensionPoint
    }
}

##
##       Errors and Warnings Container.
##
div {
  exceptionContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & defaultMappingReturned?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & locationInvalid?
     & locationProfileUnrecognized?),
    extensionPoint,
    source
  errors = element errors { exceptionContainer }
  warnings = element warnings { exceptionContainer }
}
##
##       Basic Exceptions
##
div {

  ##
  ##         Exception pattern.
  ##
  basicException = message, extensionPoint
  badRequest = element badRequest { basicException }
  internalError = element internalError { basicException }
  serviceSubstitution = element serviceSubstitution { basicException }
  defaultMappingReturned =
    element defaultMappingReturned { basicException }
  forbidden = element forbidden { basicException }
  notFound = element notFound { basicException }
  loop = element loop { basicException }
  serviceNotImplemented =
    element serviceNotImplemented { basicException }
  serverTimeout = element serverTimeout { basicException }
  serverError = element serverError { basicException }
  locationInvalid = element locationInvalid { basicException }
  locationValidationUnavailable =
    element locationValidationUnavailable { basicException }
  locationProfileUnrecognized =
    element locationProfileUnrecognized {
      attribute unsupportedProfiles { xsd:NMTOKENS },
      basicException
    }
}

##
##       Redirect.
##
div {

  ##
  ##         Redirect pattern
  ##
  redirect =
    element redirect {
      attribute target { appUniqueString },
      source,
      message,
      extensionPoint
    }
}
##
##       Some common patterns.
##
div {
  message =
    (attribute message { xsd:token },
     attribute xml:lang { xsd:language })?
  service = element service { xsd:anyURI }?
  appUniqueString =
    xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
  source = attribute source { appUniqueString }
  serviceList =
    element serviceList {
      list { xsd:anyURI* }
    }
}

##
##       Patterns for inclusion of elements from schemas in
##       other namespaces.
##
div {

  ##
  ##         Any element not in the LoST namespace.
  ##
  notLost = 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 = notLost*
}

6. Security Considerations

The <responseCompletedLocation> contains more information than the requestor originally had. However, the response does provide any more fine grained location ability: the request needed to have sufficient information to uniquely locate the target in order to be valid, and the response only contains additional information the LoST server may know about the location. For this reason, the privacy implications of this feature are not any more significant that those raised in RFC5222.

The addition of the PIDF in the response does not have any other security implications beyond those discussed in RFC5222.

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC5222]	Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, “LoST: A Location-to-Service Translation Protocol,” RFC 5222, August 2008 (TXT).

	Brian Rosen
	Neustar
	470 Conrad Dr
	Mars, PA 16046
	US
EMail:	br@brianrosen.net

	Henning Schulzrinne
	Columbia University
	Department of Computer Science
	450 Computer Science Building
	New York, NY 10027
	US
Phone:	+1 212 939 7042
EMail:	hgs@cs.columbia.edu
URI:	http://www.cs.columbia.edu

Completing the Request Location
draft-rosen-ecrit-completed-location-00

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Conventions used in this document

3. <requestCompletedLocation> element

4. <responseCompletedLocation> element

5. Relax NG Schema

6. Security Considerations

7. IANA Considerations

7.1. Relax NG Schema Registration

7.2. LoST Namespace Registration

8. Normative References

Authors' Addresses

Completing the Request Locationdraft-rosen-ecrit-completed-location-00

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Conventions used in this document

3. <requestCompletedLocation> element

4. <responseCompletedLocation> element

5. Relax NG Schema

6. Security Considerations

7. IANA Considerations

7.1. Relax NG Schema Registration

7.2. LoST Namespace Registration

8. Normative References

Authors' Addresses

Completing the Request Location
draft-rosen-ecrit-completed-location-00