RFC 3696 (rfc3696) - Page 2 of 16
Application Techniques for Checking and Transformation of Names
Alternative Format: Original Text Document
RFC 3696 Checking and Transformation of Names February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Restrictions on domain (DNS) names . . . . . . . . . . . . . . 3
3. Restrictions on email addresses . . . . . . . . . . . . . . . 5
4. URLs and URIs . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. URI syntax definitions and issues . . . . . . . . . . . 7
4.2. The HTTP URL . . . . . . . . . . . . . . . . . . . . . . 8
4.3. The MAILTO URL . . . . . . . . . . . . . . . . . . . . . 9
4.4. Guessing domain names in web contexts . . . . . . . . . 11
5. Implications of internationalization . . . . . . . . . . . . . 11
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Designers of user interfaces to Internet applications have often
found it useful to examine user-provided values for validity before
passing them to the Internet tools themselves. This type of test,
most commonly involving syntax checks or application of other rules
to domain names, email addresses, or "web addresses" (URLs or,
occasionally, extended URI forms (see Section 4)) may enable better-
quality diagnostics for the user than might be available from the
protocol itself. Local validity tests on values are also thought to
improve the efficiency of back-office processing programs and to
reduce the load on the protocols themselves. Certainly, they are
consistent with the well-established principle that it is better to
detect errors as early as possible.
The tests must, however, be made correctly or at least safely. If
criteria are applied that do not match the protocols, users will be
inconvenienced, addresses and sites will effectively become
inaccessible to some groups, and business and communications
opportunities will be lost. Experience in recent years indicates
that syntax tests are often performed incorrectly and that tests for
top-level domain names are applied using obsolete lists and
conventions. We assume that most of these incorrect tests are the
result of the inability to conveniently locate exact definitions for
the criteria to be applied. This document draws summaries of the
applicable rules together in one place and supplies references to the
Klensin Informational