July 2006IETF66 - ECRIT1 LoST: A Location-to-Service Translation Protocol draft-ietf-ecrit-lost-00 Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig

July 2006IETF66 - ECRIT2 Status Basic functionality of resolution mechanism documented Example queries and responses

July 2006IETF66 - ECRIT3 Open Issues See ecrit.org:8080/lost/ 1.default service URN 2.both civic and geo? 3.list all services functionality? 4.service URN in response message? 5.PSAP boundary hint 6.“Authority” attribute in LoST response 7.Adding information to LoST response 8.Dial strings 9.LoST response with PSAP preference 10.Extensibility of query 11.Referral protocol 12.Validation response 13.XML Schema vs. RelaxNG 14.Transport mechanism 15.Error codes

July 2006IETF66 - ECRIT4 #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”

July 2006IETF66 - ECRIT5 #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 = / rough consensus: not useful since error prone (which one to use? errors for which?) –geo complemented by civic / ; 3 rd 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

July 2006IETF66 - ECRIT6 #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, …

July 2006IETF66 - ECRIT7 #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

July 2006IETF66 - ECRIT8 #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

July 2006IETF66 - ECRIT9 #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”)

July 2006IETF66 - ECRIT10 #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

July 2006IETF66 - ECRIT11 #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

July 2006IETF66 - ECRIT12 #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 –SRV of –parallel and sequential forking at example.gov more readily controllable than LoST response Resolution: incremental value; omit

July 2006IETF66 - ECRIT13 #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?)

July 2006IETF66 - ECRIT14 #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.

July 2006IETF66 - ECRIT15 #12: Validation Response How does the server indicate which civic elements have been validated? Options: – country A1 A2 A3 – country A1 A2

July 2006IETF66 - ECRIT16 #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

July 2006IETF66 - ECRIT17 #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

July 2006IETF66 - ECRIT18 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

July 2006IETF66 - ECRIT19 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)