Some Considerations for the Use of Domain Names in non-DNS Protocols
draft-stw-whatsinaname-01

Document Type Expired Internet-Draft (individual)
Last updated 2017-05-04 (latest revision 2016-10-31)
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-stw-whatsinaname-01.txt

Abstract

From time to time, networking protocols need to be able to name things used within the protocol, and resolve the names created or referenced. It's common for protocol designers in this predicament to attempt to use domain names as the starting point for their systems of names, and the DNS as the starting point for name resolution. There is existing guidance on how to think about application-specific extensions to DNS if the protocol or software designer is re-using both domain name abstractions and DNS protocol assumptions (see RFC 6950). However, recently there's also a tendency to re-use a domain- name-based namespace without necessarily re-using DNS protocol for name resolution. This document acknowledges that class of extensions to the shared domain namespace and considers a framework for the properties a naming and resolution convention should have in the internet protocol environment, including the avoidance of collision with other uses of the namespace. Depending to the answers to the suggested questions, the answer may be that domain names will not meet the constraints at hand.

Authors

Suzanne Woolf (suzworldwide@gmail.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)