[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Applications Area                                           S. Moonesamy
Internet-Draft
Intended Status: Informational
Expires: January 2, 2013                                    July 1, 2012

              Domain Names in Application-Layer Protocols
                  draft-moonesamy-apps-domain-names-00

Abstract

   Application-layer protocols generally use global addresses.  The
   global address is based on the Domain Name System (DNS) as it
   provides a namespace structure which can used to generate a global
   address.  This document discusses about domain names in applications
   and the history of domain names in application-layer protocols.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must



Moonesamy               Expires January 2, 2013                 [Page 1]


Internet-Draft        Domain Names in Applications          July 1, 2012


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3. Domain Names in Application-Layer Protocols . . . . . . . . . .  3
     3.1. File Transfer Protocol  . . . . . . . . . . . . . . . . . .  3
     3.2. Hypertext Transfer Protocol . . . . . . . . . . . . . . . .  3
     3.3. Simple Mail Transfer Protocol . . . . . . . . . . . . . . .  3
   4. Domain Part . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     4.1. Domain Name System  . . . . . . . . . . . . . . . . . . . .  3
     4.2. Domain Part Syntax  . . . . . . . . . . . . . . . . . . . .  4
     4.3 Using the Domain Part  . . . . . . . . . . . . . . . . . . .  4
   5. Internationalization Considerations . . . . . . . . . . . . . .  5
   6. Security Considerations . . . . . . . . . . . . . . . . . . . .  5
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  5
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  5
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     9.1. Normative References  . . . . . . . . . . . . . . . . . . .  5
     9.2. Informative References  . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  6

1. Introduction

   Application-layer protocols generally use global addresses.  The
   global address is based on the Domain Name System (DNS) [RFC1034] as
   it provides namespace where authority can be delegated.  In addition,
   DNS can provide the information which is necessary for applications
   to exchange messages.  This document discusses about domain names in
   applications and the history of domain names in application
   protocols.

2. History

   The Simple Mail Transfer Protocol (SMTP) was specified as a standard
   in RFC 821 [RFC0821].  It used the then recently introduced concept
   of domains in the ARPA Internet mail system.  The use of domains
   changed the address space from a flat global space of simple
   character string host names to a hierarchically structured rooted
   tree of global addresses.  The host name was replaced by a domain and
   host designator which is a sequence of domain element strings
   separated by periods.

   It was usually assumed that a mail service would be available at a
   domain name.  There were situations where hosts were not accessible



Moonesamy               Expires January 2, 2013                 [Page 2]


Internet-Draft        Domain Names in Applications          July 1, 2012


   over the Internet.  The DNS mail-exchange (MX) Resource Record
   [RFC1035] was specified RFC 974 [RFC0974] to provide routing
   information which can be used to locate a mail service for a domain
   name.  Some general requirements which may be applicable to all
   application-layer protocols were set in RFC 1123 [RFC1123].  That
   document introduced the term "fully-qualified domain name" (FQDN).

3. Domain Names in Application-Layer Protocols

3.1. File Transfer Protocol

   The File Transfer protocol (FTP) [RFC0959] requires IP addresses
   instead of domain names to transfer files from or to a host.

3.2. Hypertext Transfer Protocol

   A fully-qualified domain name is generally used by the Hypertext
   Transfer Protocol (HTTP) [RFC2616] to access a resource referenced by
   a Uniform Resource Identifier (URI) [RFC3986].  URIs generally
   contain a fully-qualified domain name component which is intended for
   lookup in the DNS.

3.3. Simple Mail Transfer Protocol

   The domain part used in the Simple Mail Transfer Protocol (SMTP)
   [RFC5321] are expected to be fully-qualified domain names.

4. Domain Part

   The syntax of a valid Internet hostname was specified in RFC 952
   [RFC0952].  The determination of what constitutes a valid hostname or
   fully-qualified domain name is known as the LDH rule.  Components of
   a fully-qualified domain are delimited by a period (".").  The (DNS)
   term "label" is used to refer to a component.  A label can contain
   characters such as letters, digits or hyphens.  The first and last
   characters in a label cannot be a hyphen.

   It is recommended to use a fully-qualified domain name in an
   application-layer protocol as such a domain part is globally
   addressable.  Using a fully-qualified domain name also ensures that
   the domain part can be interpreted consistently regardless of
   context.

4.1. Domain Name System

   The Domain Name System (DNS) protocol [RFC1035] uses the following
   syntax:




Moonesamy               Expires January 2, 2013                 [Page 3]


Internet-Draft        Domain Names in Applications          July 1, 2012


     <domain> ::= <subdomain> | " "

     <subdomain> ::= <label> | <subdomain> "." <label>

     <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

     <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

     <let-dig-hyp> ::= <let-dig> | "-"

     <let-dig> ::= <letter> | <digit>

     <letter> ::= any one of the 52 alphabetic characters A through Z in
     upper case and a through z in lower case

     <digit> ::= any one of the ten digits 0 through 9

   Note that while upper and lower case letters are allowed in domain
   names, no significance is attached to the case.  That is, two names
   with the same spelling but different case are to be treated as if
   identical.

   There are also some restrictions on the length [RFC1035].  A label is
   63 octets or less.  A (domain) name is 255 octets or less.

4.2. Domain Part Syntax

   The DNS specifications provide general rules for constructing domain
   names.  Both the rules defined in the DNS specifications and the
   application-layer protocol specification are applicable for a domain
   part.

   RFC 5321 [RFC5321] uses the following Augmented Backus-Naur Form
   (ABNF) [RFC5234]:

     Domain         = sub-domain *("." sub-domain)

     sub-domain     = Let-dig [Ldh-str]

     Let-dig        = ALPHA / DIGIT

     Ldh-str        = *( ALPHA / DIGIT / "-" ) Let-dig

   To ensure consistency, this syntax is recommended when designing a
   new application-layer protocol which defines a domain part.

4.3 Using the Domain Part




Moonesamy               Expires January 2, 2013                 [Page 4]


Internet-Draft        Domain Names in Applications          July 1, 2012


   Application-layer protocols use the domain part in different ways.
   In HTTP, for example, the domain part can be resolved to an IP
   address to connect to the target host.  In SMTP, the target host is
   not necessarily the final destination of a message; the domain part
   can be used to derive routing information.

5. Internationalization Considerations

   RFC 5890 [RFC5890] discusses about Internationalized Domain Names for
   Applications (IDNA).  It is recommended that application-layer
   protocol implementers read the document if they are taking decisions
   about the handling of domain name strings.

6. Security Considerations

   The DNS security extensions, known as DNSSEC [RFC4033], provides
   origin authentication and integrity assurance services for DNS data.
   Any application should use a security-aware resolver for DNS queries.

7. IANA Considerations

   This document does not require any action from IANA.

   [RFC Editor: Please remove this section]

8.  Acknowledgments

   The idea for this document came up after the author read a message
   from Barry Leiba about the domain names.  Some parts of the document
   would never have been written if John Klensin did not patiently
   explain why the author was wrong in discussions about RFC 5321.  The
   author would like to thank Craig Partridge for taking the time to
   reply to a question about RFC 974 a few years ago.  David H. Crocker
   introduced the term "global address" in RFC 822.  Parts of Section
   4.1 was extracted from RFC 1035 written by P. Mockapetris.  Section
   4.2 is from RFC 5321 written by John Klensin.

9. References

9.1. Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.




Moonesamy               Expires January 2, 2013                 [Page 5]


Internet-Draft        Domain Names in Applications          July 1, 2012


   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", STD 68, RFC 5234, January
              2008.

9.2. Informative References

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
              RFC 821, August 1982.

   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
              host table specification", RFC 952, October 1985.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD
              9, RFC 959, October 1985.

   [RFC0974]  Partridge, C., "Mail routing and the domain system", STD
              10, RFC 974, January 1986.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123, October 1989.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.


Authors' Addresses


   S. Moonesamy
   76, Ylang Ylang Avenue
   Quatre Bornes
   Mauritius




Moonesamy               Expires January 2, 2013                 [Page 6]


Internet-Draft        Domain Names in Applications          July 1, 2012


   EMail: sm+ietf@elandsys.com


















































Moonesamy               Expires January 2, 2013                 [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/