1. Service location & discovery: S-NAPTR Open APPs Area Meeting November 10, 2003 Leslie Daigle

2. Background draft-daigle-napstr-03.txt –Leslie Daigle –Andy Newton

3. What it is “Service location/discovery instead of transport location/discovery” within a domain Distinguishes: –application service (e.g., instant messaging) –application protocol (e.g., simple) A layer above SRV records An application of DDDS (RFC 3401 and friends) –using NAPTR DNS RRs

4. S-NAPTR naptr rr example thinkingcat.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.com. IN NAPTR 100 20 "" "IM:ProtB:ProtC" “” thinkingcat.example.com. Notes: Immediately determine all IM service targets thinkingcat.com ProtB & ProtC handled at example.com

5. Example: 2 naptrs & an srv

6. Example: across domains

7. Example: primary target fails

8. Implications for protocol developers Flexibility in naming Need proper mechanisms for authenticating endpoint –may have a different domain label (example.com working for thinkingcat.com) –should have this anyway – not a new problem with s-naptr

9. Implications for system administrators Need to support NAPTR and SRV records Ought not build unnecessarily bushy trees

10. Implications for software writers Find most appropriate service/protocol target If it is not available, need to backtrack Need to implement proper mechanisms for authenticating endpoint –should do this anyway – not a new problem with s-naptr proposal

11. Final thoughts Andy Newton’s sample python implementation is available at –??