DNS Endpoint Discovery (DNS-EPD) James M Snell Andrew Donoho

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

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)

DNS-EPD, What is it Two new DNS Resource Record types that support the discovery of Web service endpoints. addressbook._ws.example.com EPR services.example.com /services/examples {urn:addressbook}ABService addressbook._ws.example.com XML 0 EPR may reference an SRV record addressbook._ws.example.com EPR 201 services._http._tcp.example.com /services/examples {urn:addressbook}ABService services._http._tcp.example.com SRV services.example.com

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 – WS-Inspection (dead) WS-Discovery (limited to link-local multicast scope)

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?

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

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 services.example.com /services/myservice {urn:myservice}MyService myservice._ws.example.com EPX {digest} {digest-alg} application/wsdl+xml Myservice._ws.example.com EPX {digest} {digest-alg} application/wsp+xml