RFC 3696 (rfc3696) - Page 2 of 16

Application Techniques for Checking and Transformation of Names

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