1 / 8

LoST

A Lo cation-to- S ervice T ranslation Protocol draft-hardie-ecrit-lost-00.txt. LoST. History. Originally 3 proposals 1 DNS-based 2 XML-based LUMP IRIS/ECON

fuller-santiago
Download Presentation

LoST

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. A Location-to-Service Translation Protocol draft-hardie-ecrit-lost-00.txt LoST

  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. <mapping> <request> <operation>recurse</operation> <service>urn:service:sos</service> <gp:location-info> <cl:civicAddress> <cl:country>US</cl:country> <cl:A1>New York</cl:A1> <cl:A3>New York</cl:A3> <cl:A6>Broadway</cl:A6> <cl:HNO>123</cl:HNO> <cl:LOC>Suite 75</cl:LOC> <cl:PC>10027-0401</cl:PC> </cl:civicAddress> </gp:location-info> </request> </mapping> Example for a Mapping Request

  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)

More Related