Application Techniques for Checking and Transformation of Names
RFC 3696
|
Document |
Type |
|
RFC - Informational
(February 2004; Errata)
|
|
Author |
|
John Klensin
|
|
Last updated |
|
2020-01-21
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
html
pdf
htmlized
with errata
bibtex
|
Stream |
ISE state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 3696 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Ted Hardie
|
|
IESG note |
|
Published as RFC 3696 in March 2004
|
|
Send notices to |
|
(None)
|
Network Working Group J. Klensin
Request for Comments: 3696 February 2004
Category: Informational
Application Techniques for Checking and Transformation of Names
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Many Internet applications have been designed to deduce top-level
domains (or other domain name labels) from partial information. The
introduction of new top-level domains, especially non-country-code
ones, has exposed flaws in some of the methods used by these
applications. These flaws make it more difficult, or impossible, for
users of the applications to access the full Internet. This memo
discusses some of the techniques that have been used and gives some
guidance for minimizing their negative impact as the domain name
environment evolves. This document draws summaries of the applicable
rules together in one place and supplies references to the actual
standards.
Klensin Informational [Page 1]
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 [Page 2]
RFC 3696 Checking and Transformation of Names February 2004
actual standards. It does not add anything to those standards; it
merely draws the information together into a form that may be more
accessible.
Many experts on Internet protocols believe that tests and rules of
these sorts should be avoided in applications and that the tests in
the protocols and back-office systems should be relied on instead.
Certainly implementations of the protocols cannot assume that the
data passed to them will be valid. Unless the standards specify
particular behavior, this document takes no position on whether or
not the testing is desirable. It only identifies the correct tests
Show full document text