1 / 19

LoST: A Location-to-Service Translation Protocol draft-ietf-ecrit-lost-00

LoST: A Location-to-Service Translation Protocol draft-ietf-ecrit-lost-00. Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig. Status. Basic functionality of resolution mechanism documented Example queries and responses. See http://www.ietf-ecrit.org:8080/lost/

kramerd
Télécharger la présentation

LoST: A Location-to-Service Translation Protocol draft-ietf-ecrit-lost-00

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. LoST: A Location-to-Service Translation Protocoldraft-ietf-ecrit-lost-00 Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig IETF66 - ECRIT

  2. Status • Basic functionality of resolution mechanism documented • Example queries and responses IETF66 - ECRIT

  3. See http://www.ietf-ecrit.org:8080/lost/ default service URN both civic and geo? list all services functionality? service URN in response message? PSAP boundary hint “Authority” attribute in LoST response Adding information to LoST response Dial strings LoST response with PSAP preference Extensibility of query Referral protocol Validation response XML Schema vs. RelaxNG Transport mechanism Error codes Open Issues IETF66 - ECRIT

  4. #1: Do we need a default service URN for the LoST query? • Should one be able to omit the service URN in the query? • Resolution: The LoST query MUST carry a service identifier. A default service is therefore NOT needed. • Motivation: LoST will be used for many different services and there is no great advantage of omitting the URN (but some potential for unexpected behavior). “Principle of least surprise” IETF66 - ECRIT

  5. #2: Is it allowed to specify civic and geospatial info in the query? • When does it make sense to specify both civic and geo in a query? • Two cases: • same location, but different expression • e.g., 123 Main Street = 40.858111/-73.988115 • rough consensus: not useful since error prone (which one to use? errors for which?) • geo complemented by civic • 40.858111/-73.988115; 3rd floor, Room 315 • discussion: • what will generate such location information (vs. all civic)? • will LoST need to resolve to floor & room level? (unlikely) • more complicated (restrict what combinations of geo and civic elements are allowed) • Suggested resolution: Do not support for now IETF66 - ECRIT

  6. #3: List all Services Functionality • Do we need the capability to list all services supported by the LoST server? Would this feature be useful if the service list is constraint to a certain branch of the tree? • Resolution: Return the child elements of a given service URN for the area. • urn:service:sos would return urn:service:sos.police, urn:service:sos.fire, … IETF66 - ECRIT

  7. #4: Service URN in Response Message • If there is no mapping for a specific query, should the result be returned for a more generic query? • No clear resolution • Four suggestions: • If there’s no urn:service:sos.foo, the server automatically returns the generic PSAP URI, since PSAPs by default handle all emergencies -- there’s no need to provide a more specific mechanism (server configuration) • Return nearest guess and actual service • “you wanted animal control; the fire department does cat-in-tree around here” • Return error (“you’re in Holland and there is no mountain rescue”) – client can then make generic query if desired  avoid ½ error case and pretend that a service exist that doesn’t • No need since we have the sub-service listing IETF66 - ECRIT

  8. #5: PSAP Boundary Hint • Should the LoST client indicate whether it wants to have the PSAP boundary as hint included in the response message? • It is not seen onerous to always return the hint. • Alternative: return region identifier; query for region if not cached • advantage: allow re-use of regions across services and allow caching • disadvantage: more complex IETF66 - ECRIT

  9. #6: 'Authority' Attribute in LoST Response • In ECON-IRIS, there was an ‘authority’ attribute about the authoritative source of the mapping data. • loop prevention? • tracing and error resolution • Provide resolution or redirection chain (“via”) IETF66 - ECRIT

  10. #7: Adding Additional Info to LoST Response • Should the response annotate the URL returned? • Examples: • is location required/helpful in the protocol request? • does the end system need/want location information? • Resolution: • unclear if complexity warranted • maybe allow may-ignore extensions IETF66 - ECRIT

  11. #8: Dial Strings in LoST • Should dial strings be expressed as just numbers, some dial-string format or as KPML? • numbers: • 0-9, A-D, *, # • no pauses, wait-for-dial-tone, patterns • dial-string format • draft-rosen-iptel-dialstring-04 • digits + pauses (P), wait (X), flash, … • KPML • patterns, long digits, no pauses/flash IETF66 - ECRIT

  12. #9: LoST Response with PSAP Preference • Should the answer contain multiple URIs with preference values? • Need to define purpose: • fall back after non-reachability • Note: already have • NAPTR resolution of urn:service • NAPTR resolution of sip:fire@example.gov • SRV of sip:fire@example.gov • parallel and sequential forking at example.gov • more readily controllable than LoST response • Resolution: incremental value; omit IETF66 - ECRIT

  13. #10: Extensibility of the LoST Query • Can the client include additional query attributes beyond the location and the service? • more likely useful for non-emergency services • e.g., “free services only” • Resolution: Yes, either marked as optional (server may ignore if not understood) or required (server must return error if not understood) • only support optional (and maybe indicate parameters matched?) IETF66 - ECRIT

  14. #11: Referral Protocol Mechanisms • Need to be able to refer (redirect) to another server • Resolution: Agreed; return LoST URL or host/port. • include Via (previous servers) in query? • no need for cross-protocol referral • I.e., no referral to some other lookup protocol (LoST --> LDAP) • Issue: Is reason needed? • Unclear what client would do with this information. IETF66 - ECRIT

  15. #12: Validation Response • How does the server indicate which civic elements have been validated? • Options: • <validated>country A1 A2 A3</validated> • <validated>country</validated><validated>A1</validated><validated>A2</validated> IETF66 - ECRIT

  16. #13: XML Schema vs. Relax NG • -00 contains XML Schema. Switch to Relax NG? • Yes, but not in critical path. Avoid length explosion. • only one, not both IETF66 - ECRIT

  17. #14: Transport mechanisms • -00 does not describe different transport mechanisms: UDP, HTTP, SOAP. • Need to motivate usage of UDP • can’t contain full area • if last minute, adds peak load • MUST implement or MAY? • Note: HELD uses WSDL without full SOAP? • Suggestion: HTTP plain MUST, SOAP MAY, UDP MAY IETF66 - ECRIT

  18. Error Codes • How should error codes be structured? • IANA registry • Both machine and human-readable • with language tags • Need to be able to add codes later without upgrading clients • redirection • client error (like HTTP/SIP 4xx)  don’t retry as-is • server error (5xx)  retry later • Options: • symbol + severity + human-readable text • numeric (3xx, 4xx, 5xx) + text IETF66 - ECRIT

  19. Other open issues • Other types of location information • provider + cell/face (see 3GPP discussion) • Discovery of servers • Currently specified as S-NAPTR in service URN draft (domain-based) • Also DHCP (see Polk draft) • How to encode civic regions • just provide matching subset of civic object (e.g., A1, A2, A3) IETF66 - ECRIT

More Related