GEOPRIV                                                         B. Rosen
Internet-Draft                                                   Neustar
Intended status: Standards Track                          H. Schulzrinne
Expires: September 2, 2010                                   Columbia U.
                                                           March 1, 2010


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

Abstract

   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."

   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 September 2, 2010.

Copyright Notice

   Copyright (c) 2010 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



Rosen & Schulzrinne     Expires September 2, 2010               [Page 1]

Internet-Draft         Completing Request Location            March 2010


   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.

Table of Contents

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






























Rosen & Schulzrinne     Expires September 2, 2010               [Page 2]

Internet-Draft         Completing Request Location            March 2010


1.  Introduction

   This document describes an update to the LoST protocol [RFC5222]
   which allows a <findservice> request to complete the location in the
   response.  The PIDF returned would have all of the civic address
   elements of the PIDF in the request, but would contain additional
   elements not in the request PIDF that the LoST server knew were part
   of the location.

   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:

   <country>US</country>
   <A1>PA</A1>
   <PC>16046</PC>
   <PCN>Mars</PCN>
   <RD>Conrad</RD>
   <STS>DR</STS>
   <HNO>470</HNO>

   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



Rosen & Schulzrinne     Expires September 2, 2010               [Page 3]

Internet-Draft         Completing Request Location            March 2010


   include:

   <country>US</country>
   <A1>PA</A1>
   <A2>Allegheny</A2>
   <A3>Pine</A3>
   <PC>16046</PC>
   <PCN>Mars</PCN>
   <RD>Conrad</RD>
   <STS>DR</STS>
   <HNO>470</HNO>

   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

   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].

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



Rosen & Schulzrinne     Expires September 2, 2010               [Page 4]

Internet-Draft         Completing Request Location            March 2010


   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

   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: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" ]



Rosen & Schulzrinne     Expires September 2, 2010               [Page 5]

Internet-Draft         Completing Request Location            March 2010


      }?,
      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
}



Rosen & Schulzrinne     Expires September 2, 2010               [Page 6]

Internet-Draft         Completing Request Location            March 2010


##
##       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 }
}



Rosen & Schulzrinne     Expires September 2, 2010               [Page 7]

Internet-Draft         Completing Request Location            March 2010


##
##       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,



Rosen & Schulzrinne     Expires September 2, 2010               [Page 8]

Internet-Draft         Completing Request Location            March 2010


      (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 }



Rosen & Schulzrinne     Expires September 2, 2010               [Page 9]

Internet-Draft         Completing Request Location            March 2010


}
##
##       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
    }
}



Rosen & Schulzrinne     Expires September 2, 2010              [Page 10]

Internet-Draft         Completing Request Location            March 2010


##
##       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*
}







Rosen & Schulzrinne     Expires September 2, 2010              [Page 11]

Internet-Draft         Completing Request Location            March 2010


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.

7.  IANA Considerations

7.1.  Relax NG Schema Registration

     URI:  urn:ietf:params:xml:schema:lost2

     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 6.  Its first line is

     default namespace = "urn:ietf:params:xml:ns:lost2"

     and its last line is

     }




















Rosen & Schulzrinne     Expires September 2, 2010              [Page 12]

Internet-Draft         Completing Request Location            March 2010


7.2.  LoST Namespace Registration



      URI:  urn:ietf:params:xml:ns:lost2

      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 Namespace</title>
   </head>
   <body>
     <h1>Namespace for LoST</h1>
     <h2>urn:ietf:params:xml:ns:lost2</h2>
   <p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt">
      RFC5222</a>.</p>
   </body>
   </html>
   END

8.  Normative References

   [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.













Rosen & Schulzrinne     Expires September 2, 2010              [Page 13]

Internet-Draft         Completing Request Location            March 2010


Authors' Addresses

   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






























Rosen & Schulzrinne     Expires September 2, 2010              [Page 14]