1. July 2006IETF66 - ECRIT1 RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-00 Henning Schulzrinne

2. July 2006IETF66 - ECRIT2 Motivation Layer-7 mapping of identifier to location –typically network termination equipment DSL modem, 802.11 AP Work behind NAT Narrowly-focused protocol -- one purpose –make it easier to specify interoperability Since just mapping, could map SNR measurements to location…

3. July 2006IETF66 - ECRIT3 Discovery Currently, S-NAPTR –should probably be U-NAPTR –domain from host configuration (DHCP) or reverse DNS

4. July 2006IETF66 - ECRIT4 Query Just send HTTP GET –TLS RECOMMENDED Could also use GET parameters, as in –http://example.com? by=value& type=civic

5. July 2006IETF66 - ECRIT5 Response Returns location object or URI: – sip:155yojglky@example.com Uses HTTP Expires header to indicate validity If error, use HTTP response To subscribe to location, insert Subscribe HTTP header (and maybe Event) –see SIP configuration framework for HTTP Event header

6. July 2006IETF66 - ECRIT6 Design decisions No notion of context -- stateless –no need for state maintenance Just location, no PIDF-LO –avoid having to obscure privacy-sensitive information such as entity URL First-party retrieval (mainly) –reduce privacy risks Specify discovery mechanism –use S-NAPTR (or U-NAPTR) via host name Allow other identifiers –but only IP address specified until others are better understood Uses HTTP error codes, rather than define own Subscribe URL in response header –separate discussion (tactical and technical)

7. July 2006IETF66 - ECRIT7 Open issues What other identifiers? –must survive NAT and home routers e.g., MAC address unlikely to be useful –examples: circuit ID signal strength and AP MACs