1 / 16

LoST draft-ietf-ecrit-lost-02

This draft presents the request/response pattern, XML structure, and various features of the LoST Location Service Protocol, including find service, list services, and get service boundary. It also explains address validation, service boundary references, location profiles, and the requirement for implementing baseline profiles.

ddavid
Download Presentation

LoST draft-ietf-ecrit-lost-02

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LoSTdraft-ietf-ecrit-lost-02 ECRIT Working Group IETF 67 7 November 2006 Andrew Newton Henning Schulzrinne Hannes Tschofenig Ted Hardie

  2. Request/Response Pattern • XML was refactored so that every request has a corresponding reply. • 3 types of requests, 3 type of replies. • <findService> -> <findServiceResponse> • <listServices> -> <listServicesResponse> • <getServiceBoundary> -> <getServiceBoundaryResponse>

  3. Find Service Include Attribute • Enables the clients to specify the information they wish returned. <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" include="serviceBoundary invalid valid unchecked"> <location profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Neu Perlach</A6> <HNO>96</HNO> <PC>81675</PC> </civicAddress> </location> <service>urn:service:sos.police</service> </findService>

  4. Validation Response Example(current draft XML) <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> <serviceBoundary profile=” urn:ietf:params:lost:location-profile:civic"> <civicAddress xmlns=” urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <PC>81675</PC> </civicAddress> </serviceBoundary> <valid>country A1 A3 A6</valid> <invalid>PC</invalid> <unchecked/> </findServiceResponse>

  5. Service Boundary References • Clients indicate their preference for a reference with the include attribute: • Contains either serviceBoundary or serviceBoundaryReference • They then use the <getServiceBoundary> request to obtain the service boundary if they need it.

  6. Address Validation • 3 indicators • <valid> - elements with valid content • <invalid> - elements with invalid content • <unchecked> - elements that were not used in the address validation process. • Clients use the include attribute to specify which indicators they wish to see: • include=‘invalid valid unchecked’

  7. Location Profiles • Clients and servers denote how they are expressing location using a location profile ID. • It is currently a URN, but will be changed to a simple token (author team proposal). • Multiple locations, each denoted by a location profile ID, may be used in requests and responses: • <location> in requests • <serviceBoundary> in responses • Each location profile may contain multiple XML elements from varying namespaces.

  8. Location Profile Example <findService xmlns="urn:ietf:params:xml:ns:lost1” xmlns:p2="http://www.opengis.net/gml" recursive="true" include="uri serviceNumber"> <location profile="urn:ietf:params:lost:location-profile:geodetic-2d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:pos>37.775 -122.422</p2:pos> </p2:Point> </location> <location profile="urn:ietf:params:lost:location-profile:uber-complex-3d"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:pos>37.775 -122.422</p2:pos> </p2:Point> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:exterior> <p2:LinearRing> <p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4194</p2:pos> </p2:LinearRing> </p2:exterior> </p2:Polygon> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:pos>-122.422 37.775</p2:pos> </p2:Point> </location> </findService>

  9. MUST Implement Profiles • Every server and client MUST implement two baseline location profiles. • Enables a response in all circumstances. • “geodetic-2d” • Client sends a GML position • Server responds with a GML polygon • “civic” • Client sends draft-ietf-geopriv-revised-civic • Server responds with draft-ietf-geopriv-revised-civic

  10. Definition of a Location Profile • The token identifying it in the LoST location profile registry; • The formal definition of the XML to be used in requests, i.e., an enumeration and definition of the XML child elements of the <location> element; • The formal definition of the XML to be used in responses, i.e., an enumeration and definition of the XML child elements of the <serviceBoundary> element; • The declaration of whether geodetic-2d or civic is to be used as the baseline profile. It is necessary to explicitly declare the baseline profile as future profiles may be combinations of geodetic and civic location information.

  11. Basic Interaction Rules • A client MUST be capable of understanding the response for the baseline profiles it used in the request. • If a client sends location information conformant to any location profile other than geodetic-2d or civic, it MUST also send, in the same request, location information conformant to one of the baseline profiles. Otherwise, the server might not be able to understand the request. • Servers MUST implement the geodetic-2d and civic profiles. • A server ignores any location information using non-baseline profiles it does not understand. • If a server receives a request that only contains location information using profiles it does not understand, the server responds with a <locationProfileError>.

  12. Open Issues • Error responses • More streamlining to be done. • Look for more changes to the XML. • Time-To-Live • Absolute vs. Relative • ‘include’ attribute processing • Minimum set vs. strict set. • Impacts caching. • Ordering of element names in <invalid>, <valid>, and <unchecked>. • Order preference of location profiles. • Algorithm for adding <via>. • Loosen service boundary key reference syntax. • Signing of service boundaries. • This is not location signing.

  13. Errors vs. Warnings(author team proposal) • Separation of errors and warnings • Errors contained in their own response • Warnings packaged with query responses • Interaction with SIP to be specified in another document • SIP/ECRIT chairs get to argue over who gets the headache. • Error example: <errors source=“lost:example.com”> <notFound message=“you may find what you are looking for in the last place you search.” /> … </errors>

  14. Find Service Response/Warning Example(author team proposal) <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <mapping ttl=“1990-12-31T23:59:60Z”> <displayName xml:lang="de">München Polizei-Abteilung</displayName> <service>urn:service:sos.police</service> <serviceBoundary profile=”civic”> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <PC>81675</PC> </civicAddress> </serviceBoundary> <uri>sip:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri> <serviceNumber>110</serviceNumber> </mapping> <validation><unchecked/></validation> <warnings> <locationProfileUnrecognized profile=“martion-civic”/> </warnings> <via>lost:esgw.uber-110.de.example</via> <via>lost:polizei.munchen.de.example</via> </findServiceResponse>

  15. Reasons for Change(author team proposal) • More context sensible errors/warnings. • Enable insertion of data by resolvers, etc… without modifying data from the authority. • Should help caching implementation/performance. • Absolute TTL and more modular elements to accommodate future XML D-SIG work. • But we aren’t doing XML D-SIG in this pass.

  16. List Services Query(author team proposal) • In-line with Shida’s comment, there is a difference between asking a local resolver what services it supports and asking which services are supported for a location. • Query to make <location> optional to specify which semantic is desired. • Response to be similar to <findServicesResponse>, with <services> instead of <mapping>.

More Related