datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Application Techniques for Checking and Transformation of Names
RFC 3696

Document type: RFC - Informational (February 2004; Errata)
Document stream: ISE
Last updated: 2013-03-02
Other versions: plain text, pdf, html

ISE State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 3696 (Informational)
Responsible AD: Ted Hardie
IESG Note: Published as RFC 3696 in March 2004
Send notices to: No addresses provided

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

[include full document text]