1. URI Records

2. What's the point? • URI records provide an extra layer of abstraction to separate a domain name from a point of service. • One use case is when there are multiple valid domain names, but a single point of service. • Under the current proposal, these RRs are found by prepending service fields, e.g: • _http._web.example.com • Note that neither “http”, nor “web” are protocols, but instead tokens registered with IANA. • Reuses SRV and Enumservice registrations

3. What's the issue? • Is this the right mechanism to bind service to the URI at which the service is delivered? • Limiting this to registered services limits the applicability in theory. Will it in practice? • Many services run using the same underlying protocols, and this would fail if you cannot distinguish among the different uses using the registeredservice definition(s). It is possible to have two service definitions using the same protocol. But the quality of the service definition is potentially critical, which creates a gating registration requirement. • This proposal reuses some of the weighting mechanism from DDDS and friends. Are they right for this?

4. Are there alternatives? • In short, yes. • But the design criteria by which to evaluate this or its alternatives is not entirely clear. • Are we aiming for the widest possible applicability? • Then unregistered services need to be supported, which creates a requirement for further disambiguation methods.. • Are we aiming for the tightest possible binding? • The _ convention and registered services may not be enough to create tight bindings. Correct review and registration of services is required before they are actually used. • Are we aiming for something that plays well with specific other proposals? (In the domain equivalence space in particular?)