1. LoST A Location-to-Service Translation Protocol draft-hardie-ecrit-lost-00.txt

2. History ● Originally 3 proposals – 1 DNS-based – 2 XML-based ● LUMP ● IRIS/ECON ● This proposal merges LUMP & ECON after discussion at Washington interim meeting indicated the DNS-based approach did not have consensus to go forward.

3. Key Features ● Satisfies the requirements for mapping protocols. ● Supports queries using civic as well as geospatial location information and mapping can be based on either. ● Can be used in both recursive and iterative resolution. ● Query structure is independent of hierarchy ● Minimizes round trips by caching individual mappings as well as coverage regions ("hinting"). ● Facilitates reuse of TLS

4. Things not do do ● Avoid geocoding – mapping server never converts civic to geo (or vice versa) ● Avoid dependence on single root ● Avoid dependence on single server discovery method – DHCP, DNS,.... ● Don’t invent new transport  re-use one or more of – Rest – SOAP – Raw UDP

5. Example for a Mapping Request recurse urn:service:sos US New York Broadway 123 Suite 75 10027-0401

6. When is LoST run? ● Short answer—whenever – When location is first received (e.g., at boot time) ● REST/SOAP ● Validation possible – When location changes sufficiently ● i.e., outside the current validity region – After time passes (end of validity period) – At call time ● Raw UDP or REST/SOAP

7. Who runs LoST queries? ● Short answer-whoever needs to ● Draft-schulzrinne-ecrit-mapping-arch describes the overall architecure this is designed to fit within. Discussion of this point should focus there.

8. TBD ● Complete schema ● Error conditions and error codes ● Transport mechanism resolution – REST or SOAP? Vanilla HTTP? ● Integration of dialstring discovery ● Security Considerations – Countermeasures – Applicability statement for UDP ● IANA Considerations ● Internationalization Considerations? – probably similar to PIDF-LO (civic objects only) ● Describe load balancing/service discovery interaction (see also service URN)