1 / 4

URI Records

URI Records. 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.

dionne
Download Presentation

URI Records

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?)

More Related