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

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

3. Open Issues 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
July 2006
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”
July 2006
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 = /
rough consensus: not useful since error prone (which one to use? errors for which?)
geo complemented by civic
/ ; 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
July 2006
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, …
July 2006
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
July 2006
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
July 2006
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”)
July 2006
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
July 2006
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
July 2006
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
SRV of
parallel and sequential forking at example.gov
more readily controllable than LoST response
Resolution: incremental value; omit
July 2006
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?)
July 2006
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.
July 2006
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>
July 2006
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
July 2006
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
July 2006
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
July 2006
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)
July 2006
IETF66 - ECRIT