Names and Identifiers (inip) Concluded Program
Note: The data for concluded Programs is occasionally incorrect.
|Program||Name||Names and Identifiers|
|Dependencies||Document dependency graph (SVG)|
The Names and Identifiers Program covers various topics concerning naming and resolution. As RFC 6055 points out, the DNS is not the only way that naming and resolution happens. Identifiers — not just domain names, but all identifiers — and the resolution of them are important both to users and applications on the Internet. Further, as Internet infrastructure becomes more complex and ubiquitous, the need for powerful, flexible systems of identifiers gets more important. However, in many ways we’re limited by the success of the DNS: it’s used so widely and successfully, for so many things, that compatibility with it is essential, even as demands grow for namespace characteristics and protocol behavior that aren’t included in the DNS and may be fundamentally incompatible with it.
The IAB has worked on these issues before, but there are several things that have recently changed which make the topic worth revisiting. First, we’re pushing the limits of flexibility in the DNS in new ways: there are growing numbers of protocols and applications (some of them built outside the IETF) that are creating DNS-like naming systems, but that differ from naming rules, wire protocol, or operational restrictions implicit in DNS. We’ve particularly seen cases where these protocols and applications expect to be able to use “domain name slots” where domain names have traditionally appeared in protocols, and the potential for subtle incompatibilities among them provides an opportunity for various forms of surprising results, from unexpected comparison failures to name collisions. In addition, it may be that as a consequence of the vast expansion of the root zone, the intended hierarchical structure of the DNS namespace could be lost, which raises not only operational concerns but also architectural questions of what characteristics are necessary in naming systems for various uses.
At the same time as that is changing, pressures to provide facilities not previously imagined for the DNS (such as bidirectional aliasing, or better protection for privacy, or context information such as localization or administrative boundaries) require that naming systems for the internet will continue to evolve.
Beyond specific stresses provided by the practical need for compatibility with DNS and its limitations, there are questions about the implications of identifier resolution more widely. For example, various methods for treating different domain names as “the same” have implications for email addresses, and this might have implications for identifier use and comparison more generally, including for i18n. Perhaps more broadly yet, we see an impact on naming systems as we examine needs such as support for scaling in new environments (mobile, IoT) and new priorities such as supporting widespread encryption.
The program seeks to provide a useful framework for thinking about naming and resolution issues for the internet in general, and to deliver recommendations for future naming or resolution systems.
The scope of initial investigations is deliberately somewhat open, but could include:
- some basic terminology: what do we mean by “names,” “identifiers,” and “name resolution” in the internet? What attributes of naming systems and identifiers are important with regards to comparison, search, human accessibility, and other interactions?
- overview: where are naming protocols and infrastructure important to the work of the IETF (and perhaps elsewhere)? Where is the DNS being used (and perhaps stretched too far)? What other identifier systems are we coming up with, and how well are those efforts working? This area will include examination of some of the naming systems under development or in use elsewhere, such as NDN, as a way of informing our thinking.
- For protocols (inside the IETF or outside), what should protocol designers know about re-using existing naming systems or inventing their own? Are there guidelines we can usefully provide?