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

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

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

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

Example: 2 naptrs & an srv

Example: across domains

Example: primary target fails

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

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

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

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