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

Request/Response Pattern XML was refactored so that every request has a corresponding reply. 3 types of requests, 3 type of replies. – ->

<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"> Germany Bavaria Munich Neu Perlach urn:service:sos.police Find Service Include Attribute Enables the clients to specify the information they wish returned.

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"> Germany Bavaria Munich country A1 A3 A6 PC

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

Address Validation 3 indicators – - elements with valid content – - elements with invalid content – - 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’

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: – in requests – in responses Each location profile may contain multiple XML elements from varying namespaces.

Location Profile Example <findService xmlns="urn:ietf:params:xml:ns:lost1” xmlns:p2=" recursive="true" include="uri serviceNumber">

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

Definition of a Location Profile 1)The token identifying it in the LoST location profile registry; 2)The formal definition of the XML to be used in requests, i.e., an enumeration and definition of the XML child elements of the element; 3)The formal definition of the XML to be used in responses, i.e., an enumeration and definition of the XML child elements of the element; 4)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.

Basic Interaction Rules 1)A client MUST be capable of understanding the response for the baseline profiles it used in the request. 2)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. 3)Servers MUST implement the geodetic-2d and civic profiles. 4)A server ignores any location information using non-baseline profiles it does not understand. 5)If a server receives a request that only contains location information using profiles it does not understand, the server responds with a.

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,, and. Order preference of location profiles. Algorithm for adding. Loosen service boundary key reference syntax. Signing of service boundaries. –This is not location signing.

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: <notFound message=“you may find what you are looking for in the last place you search.” /> …

Find Service Response/Warning Example (author team proposal) München Polizei-Abteilung urn:service:sos.police Germany Bavaria Munich lost:esgw.uber-110.de.example lost:polizei.munchen.de.example

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.

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 optional to specify which semantic is desired. Response to be similar to, with instead of.