DNS Endpoint Discovery (DNS-EPD) ietf/internet-drafts/draft-snell-dnsepd-00.txt

1. DNS Endpoint Discovery (DNS-EPD)http://www.ietf.org/internet-drafts/draft-snell-dnsepd-00.txt James M Snell (jasnell@us.ibm.com) Andrew Donoho (awd@us.ibm.com)

2. Agenda • DNS Endpoint Discovery • What is it • Why does it exist • What are the issues • What do we want to do with it

3. When I say Web services • I’m talking about… • Described using WSDL • Accessible via URL (http by default) • Specs to know • Web Services Description Language (WSDL) • Web Services Addressing (WS-Addressing) • Web Services Policy (WS-Policy)

4. DNS-EPD, What is it • Two new DNS Resource Record types that support the discovery of Web service endpoints. addressbook._ws.example.com EPR 111 0 0 services.example.com /services/examples {urn:addressbook}ABService http://svcs.example.com/abook.wsdl addressbook._ws.example.com XML 0 <EndpointReference xmlns=“…” /> • EPR may reference an SRV record addressbook._ws.example.com EPR 201 services._http._tcp.example.com /services/examples {urn:addressbook}ABService http://services.example.com/abook.wsdl services._http._tcp.example.com SRV 0 0 4400 services.example.com http://services.example.com/services/examples http://services.example.com:4400/services/examples

5. Why does it exist? • Web services need a way of bootstrapping the discovery of infrastructure level services • Other Web service discovery options do not solve the problem* • DNS is already used for bootstrapping infrastructure, logical to use it for Web services infrastructure • * Other WS Discovery mechanisms: • UDDI – http://www.uddi.org • WS-Inspection (dead) • WS-Discovery (limited to link-local multicast scope)

6. What are the issues? • Some Web services are static, others are dynamic. A DNS approach works good for static services, may not work to well for highly dynamic service environments… still exploring this • The XML Resource Record currently shares many of the same characteristics (positive and negative) as the TXT record. • In general, it’s use is optional in DNS-EPD. Clients are not required to ask for it nor are they required to understand it • We could strictly limit the size of the XML RDATA • We could strictly limit the XML RR to Web services related XML • We could rename the XML RR to something Web services related (EPX?) • We could introduce a redirection scheme as an alternative to including XML directly • Is the _ws name segment really needed? • Possibly not needed • It was put in to help avoid name collisions • e.g. differentiate between inquire.uddi._ws.example.com and inquire._ws.uddi.example.com • Could all this be done using NAPTR records? • Possibly, but I’d be concerned about the additional complexity introduced • It may be that I just need my head shaped about NAPTR • any volunteers to help shape my head? • What are the advantages of NAPTR relative to an app specific RR like EPR?

7. What do we want to do with it? • Engage the DNS expert community about the spec. • We need opinions about the general approach and identification of the issues we have yet to resolve • Evolve the spec. • Move it towards RFC status as an individual submission

9. Alternative to XML RR? myservice._ws.example.com EPX URL-Reference Digest Digest-Algorithm-URI Optional-Media-Type This could be made specific to Web services or generic for general purpose use. Example myservice._ws.example.com EPR 11 0 0 services.example.com /services/myservice {urn:myservice}MyService myservice._ws.example.com EPX http://services.example.com/myservice.wsdl {digest} {digest-alg} application/wsdl+xml Myservice._ws.example.com EPX http://services.example.com/myservice.wsp {digest} {digest-alg} application/wsp+xml