idnits 2.17.1 draft-moonesamy-apps-domain-names-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2012) is 4317 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Ldh-str' is mentioned on line 183, but not defined -- Obsolete informational reference (is this intentional?): RFC 821 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 974 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Applications Area S. Moonesamy 3 Internet-Draft 4 Intended Status: Informational 5 Expires: January 2, 2013 July 1, 2012 7 Domain Names in Application-Layer Protocols 8 draft-moonesamy-apps-domain-names-00 10 Abstract 12 Application-layer protocols generally use global addresses. The 13 global address is based on the Domain Name System (DNS) as it 14 provides a namespace structure which can used to generate a global 15 address. This document discusses about domain names in applications 16 and the history of domain names in application-layer protocols. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright and License Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Domain Names in Application-Layer Protocols . . . . . . . . . . 3 59 3.1. File Transfer Protocol . . . . . . . . . . . . . . . . . . 3 60 3.2. Hypertext Transfer Protocol . . . . . . . . . . . . . . . . 3 61 3.3. Simple Mail Transfer Protocol . . . . . . . . . . . . . . . 3 62 4. Domain Part . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4.1. Domain Name System . . . . . . . . . . . . . . . . . . . . 3 64 4.2. Domain Part Syntax . . . . . . . . . . . . . . . . . . . . 4 65 4.3 Using the Domain Part . . . . . . . . . . . . . . . . . . . 4 66 5. Internationalization Considerations . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Application-layer protocols generally use global addresses. The 78 global address is based on the Domain Name System (DNS) [RFC1034] as 79 it provides namespace where authority can be delegated. In addition, 80 DNS can provide the information which is necessary for applications 81 to exchange messages. This document discusses about domain names in 82 applications and the history of domain names in application 83 protocols. 85 2. History 87 The Simple Mail Transfer Protocol (SMTP) was specified as a standard 88 in RFC 821 [RFC0821]. It used the then recently introduced concept 89 of domains in the ARPA Internet mail system. The use of domains 90 changed the address space from a flat global space of simple 91 character string host names to a hierarchically structured rooted 92 tree of global addresses. The host name was replaced by a domain and 93 host designator which is a sequence of domain element strings 94 separated by periods. 96 It was usually assumed that a mail service would be available at a 97 domain name. There were situations where hosts were not accessible 98 over the Internet. The DNS mail-exchange (MX) Resource Record 99 [RFC1035] was specified RFC 974 [RFC0974] to provide routing 100 information which can be used to locate a mail service for a domain 101 name. Some general requirements which may be applicable to all 102 application-layer protocols were set in RFC 1123 [RFC1123]. That 103 document introduced the term "fully-qualified domain name" (FQDN). 105 3. Domain Names in Application-Layer Protocols 107 3.1. File Transfer Protocol 109 The File Transfer protocol (FTP) [RFC0959] requires IP addresses 110 instead of domain names to transfer files from or to a host. 112 3.2. Hypertext Transfer Protocol 114 A fully-qualified domain name is generally used by the Hypertext 115 Transfer Protocol (HTTP) [RFC2616] to access a resource referenced by 116 a Uniform Resource Identifier (URI) [RFC3986]. URIs generally 117 contain a fully-qualified domain name component which is intended for 118 lookup in the DNS. 120 3.3. Simple Mail Transfer Protocol 122 The domain part used in the Simple Mail Transfer Protocol (SMTP) 123 [RFC5321] are expected to be fully-qualified domain names. 125 4. Domain Part 127 The syntax of a valid Internet hostname was specified in RFC 952 128 [RFC0952]. The determination of what constitutes a valid hostname or 129 fully-qualified domain name is known as the LDH rule. Components of 130 a fully-qualified domain are delimited by a period ("."). The (DNS) 131 term "label" is used to refer to a component. A label can contain 132 characters such as letters, digits or hyphens. The first and last 133 characters in a label cannot be a hyphen. 135 It is recommended to use a fully-qualified domain name in an 136 application-layer protocol as such a domain part is globally 137 addressable. Using a fully-qualified domain name also ensures that 138 the domain part can be interpreted consistently regardless of 139 context. 141 4.1. Domain Name System 143 The Domain Name System (DNS) protocol [RFC1035] uses the following 144 syntax: 146 ::= | " " 148 ::=