rfc1123.txt
上传用户:horngjaan
上传日期:2009-12-12
资源大小:2882k
文件大小:234k
源码类别:

Email服务器

开发平台:

C#

  1. Network Working Group                    Internet Engineering Task Force
  2. Request for Comments: 1123                             R. Braden, Editor
  3.                                                             October 1989
  4.        Requirements for Internet Hosts -- Application and Support
  5. Status of This Memo
  6.    This RFC is an official specification for the Internet community.  It
  7.    incorporates by reference, amends, corrects, and supplements the
  8.    primary protocol standards documents relating to hosts.  Distribution
  9.    of this document is unlimited.
  10. Summary
  11.    This RFC is one of a pair that defines and discusses the requirements
  12.    for Internet host software.  This RFC covers the application and
  13.    support protocols; its companion RFC-1122 covers the communication
  14.    protocol layers: link layer, IP layer, and transport layer.
  15.                            Table of Contents
  16.    1.  INTRODUCTION ...............................................    5
  17.       1.1  The Internet Architecture ..............................    6
  18.       1.2  General Considerations .................................    6
  19.          1.2.1  Continuing Internet Evolution .....................    6
  20.          1.2.2  Robustness Principle ..............................    7
  21.          1.2.3  Error Logging .....................................    8
  22.          1.2.4  Configuration .....................................    8
  23.       1.3  Reading this Document ..................................   10
  24.          1.3.1  Organization ......................................   10
  25.          1.3.2  Requirements ......................................   10
  26.          1.3.3  Terminology .......................................   11
  27.       1.4  Acknowledgments ........................................   12
  28.    2.  GENERAL ISSUES .............................................   13
  29.       2.1  Host Names and Numbers .................................   13
  30.       2.2  Using Domain Name Service ..............................   13
  31.       2.3  Applications on Multihomed hosts .......................   14
  32.       2.4  Type-of-Service ........................................   14
  33.       2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
  34. Internet Engineering Task Force                                 [Page 1]
  35. RFC1123                       INTRODUCTION                  October 1989
  36.    3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
  37.       3.1  INTRODUCTION ...........................................   16
  38.       3.2  PROTOCOL WALK-THROUGH ..................................   16
  39.          3.2.1  Option Negotiation ................................   16
  40.          3.2.2  Telnet Go-Ahead Function ..........................   16
  41.          3.2.3  Control Functions .................................   17
  42.          3.2.4  Telnet "Synch" Signal .............................   18
  43.          3.2.5  NVT Printer and Keyboard ..........................   19
  44.          3.2.6  Telnet Command Structure ..........................   20
  45.          3.2.7  Telnet Binary Option ..............................   20
  46.          3.2.8  Telnet Terminal-Type Option .......................   20
  47.       3.3  SPECIFIC ISSUES ........................................   21
  48.          3.3.1  Telnet End-of-Line Convention .....................   21
  49.          3.3.2  Data Entry Terminals ..............................   23
  50.          3.3.3  Option Requirements ...............................   24
  51.          3.3.4  Option Initiation .................................   24
  52.          3.3.5  Telnet Linemode Option ............................   25
  53.       3.4  TELNET/USER INTERFACE ..................................   25
  54.          3.4.1  Character Set Transparency ........................   25
  55.          3.4.2  Telnet Commands ...................................   26
  56.          3.4.3  TCP Connection Errors .............................   26
  57.          3.4.4  Non-Default Telnet Contact Port ...................   26
  58.          3.4.5  Flushing Output ...................................   26
  59.       3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
  60.    4.  FILE TRANSFER ..............................................   29
  61.       4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
  62.          4.1.1  INTRODUCTION ......................................   29
  63.          4.1.2.  PROTOCOL WALK-THROUGH ............................   29
  64.             4.1.2.1  LOCAL Type ...................................   29
  65.             4.1.2.2  Telnet Format Control ........................   30
  66.             4.1.2.3  Page Structure ...............................   30
  67.             4.1.2.4  Data Structure Transformations ...............   30
  68.             4.1.2.5  Data Connection Management ...................   31
  69.             4.1.2.6  PASV Command .................................   31
  70.             4.1.2.7  LIST and NLST Commands .......................   31
  71.             4.1.2.8  SITE Command .................................   32
  72.             4.1.2.9  STOU Command .................................   32
  73.             4.1.2.10  Telnet End-of-line Code .....................   32
  74.             4.1.2.11  FTP Replies .................................   33
  75.             4.1.2.12  Connections .................................   34
  76.             4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
  77.          4.1.3  SPECIFIC ISSUES ...................................   35
  78.             4.1.3.1  Non-standard Command Verbs ...................   35
  79.             4.1.3.2  Idle Timeout .................................   36
  80.             4.1.3.3  Concurrency of Data and Control ..............   36
  81.             4.1.3.4  FTP Restart Mechanism ........................   36
  82.          4.1.4  FTP/USER INTERFACE ................................   39
  83. Internet Engineering Task Force                                 [Page 2]
  84. RFC1123                       INTRODUCTION                  October 1989
  85.             4.1.4.1  Pathname Specification .......................   39
  86.             4.1.4.2  "QUOTE" Command ..............................   40
  87.             4.1.4.3  Displaying Replies to User ...................   40
  88.             4.1.4.4  Maintaining Synchronization ..................   40
  89.          4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
  90.       4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
  91.          4.2.1  INTRODUCTION ......................................   44
  92.          4.2.2  PROTOCOL WALK-THROUGH .............................   44
  93.             4.2.2.1  Transfer Modes ...............................   44
  94.             4.2.2.2  UDP Header ...................................   44
  95.          4.2.3  SPECIFIC ISSUES ...................................   44
  96.             4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
  97.             4.2.3.2  Timeout Algorithms ...........................   46
  98.             4.2.3.3  Extensions ...................................   46
  99.             4.2.3.4  Access Control ...............................   46
  100.             4.2.3.5  Broadcast Request ............................   46
  101.          4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
  102.    5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
  103.       5.1  INTRODUCTION ...........................................   48
  104.       5.2  PROTOCOL WALK-THROUGH ..................................   48
  105.          5.2.1  The SMTP Model ....................................   48
  106.          5.2.2  Canonicalization ..................................   49
  107.          5.2.3  VRFY and EXPN Commands ............................   50
  108.          5.2.4  SEND, SOML, and SAML Commands .....................   50
  109.          5.2.5  HELO Command ......................................   50
  110.          5.2.6  Mail Relay ........................................   51
  111.          5.2.7  RCPT Command ......................................   52
  112.          5.2.8  DATA Command ......................................   53
  113.          5.2.9  Command Syntax ....................................   54
  114.          5.2.10  SMTP Replies .....................................   54
  115.          5.2.11  Transparency .....................................   55
  116.          5.2.12  WKS Use in MX Processing .........................   55
  117.          5.2.13  RFC-822 Message Specification ....................   55
  118.          5.2.14  RFC-822 Date and Time Specification ..............   55
  119.          5.2.15  RFC-822 Syntax Change ............................   56
  120.          5.2.16  RFC-822  Local-part ..............................   56
  121.          5.2.17  Domain Literals ..................................   57
  122.          5.2.18  Common Address Formatting Errors .................   58
  123.          5.2.19  Explicit Source Routes ...........................   58
  124.       5.3  SPECIFIC ISSUES ........................................   59
  125.          5.3.1  SMTP Queueing Strategies ..........................   59
  126.             5.3.1.1 Sending Strategy ..............................   59
  127.             5.3.1.2  Receiving strategy ...........................   61
  128.          5.3.2  Timeouts in SMTP ..................................   61
  129.          5.3.3  Reliable Mail Receipt .............................   63
  130.          5.3.4  Reliable Mail Transmission ........................   63
  131.          5.3.5  Domain Name Support ...............................   65
  132. Internet Engineering Task Force                                 [Page 3]
  133. RFC1123                       INTRODUCTION                  October 1989
  134.          5.3.6  Mailing Lists and Aliases .........................   65
  135.          5.3.7  Mail Gatewaying ...................................   66
  136.          5.3.8  Maximum Message Size ..............................   68
  137.       5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
  138.    6. SUPPORT SERVICES ............................................   72
  139.       6.1 DOMAIN NAME TRANSLATION .................................   72
  140.          6.1.1 INTRODUCTION .......................................   72
  141.          6.1.2  PROTOCOL WALK-THROUGH .............................   72
  142.             6.1.2.1  Resource Records with Zero TTL ...............   73
  143.             6.1.2.2  QCLASS Values ................................   73
  144.             6.1.2.3  Unused Fields ................................   73
  145.             6.1.2.4  Compression ..................................   73
  146.             6.1.2.5  Misusing Configuration Info ..................   73
  147.          6.1.3  SPECIFIC ISSUES ...................................   74
  148.             6.1.3.1  Resolver Implementation ......................   74
  149.             6.1.3.2  Transport Protocols ..........................   75
  150.             6.1.3.3  Efficient Resource Usage .....................   77
  151.             6.1.3.4  Multihomed Hosts .............................   78
  152.             6.1.3.5  Extensibility ................................   79
  153.             6.1.3.6  Status of RR Types ...........................   79
  154.             6.1.3.7  Robustness ...................................   80
  155.             6.1.3.8  Local Host Table .............................   80
  156.          6.1.4  DNS USER INTERFACE ................................   81
  157.             6.1.4.1  DNS Administration ...........................   81
  158.             6.1.4.2  DNS User Interface ...........................   81
  159.             6.1.4.3 Interface Abbreviation Facilities .............   82
  160.          6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
  161.       6.2  HOST INITIALIZATION ....................................   87
  162.          6.2.1  INTRODUCTION ......................................   87
  163.          6.2.2  REQUIREMENTS ......................................   87
  164.             6.2.2.1  Dynamic Configuration ........................   87
  165.             6.2.2.2  Loading Phase ................................   89
  166.       6.3  REMOTE MANAGEMENT ......................................   90
  167.          6.3.1  INTRODUCTION ......................................   90
  168.          6.3.2  PROTOCOL WALK-THROUGH .............................   90
  169.          6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
  170.    7.  REFERENCES .................................................   93
  171. Internet Engineering Task Force                                 [Page 4]
  172. RFC1123                       INTRODUCTION                  October 1989
  173. 1.  INTRODUCTION
  174.    This document is one of a pair that defines and discusses the
  175.    requirements for host system implementations of the Internet protocol
  176.    suite.  This RFC covers the applications layer and support protocols.
  177.    Its companion RFC, "Requirements for Internet Hosts -- Communications
  178.    Layers" [INTRO:1] covers the lower layer protocols: transport layer,
  179.    IP layer, and link layer.
  180.    These documents are intended to provide guidance for vendors,
  181.    implementors, and users of Internet communication software.  They
  182.    represent the consensus of a large body of technical experience and
  183.    wisdom, contributed by members of the Internet research and vendor
  184.    communities.
  185.    This RFC enumerates standard protocols that a host connected to the
  186.    Internet must use, and it incorporates by reference the RFCs and
  187.    other documents describing the current specifications for these
  188.    protocols.  It corrects errors in the referenced documents and adds
  189.    additional discussion and guidance for an implementor.
  190.    For each protocol, this document also contains an explicit set of
  191.    requirements, recommendations, and options.  The reader must
  192.    understand that the list of requirements in this document is
  193.    incomplete by itself; the complete set of requirements for an
  194.    Internet host is primarily defined in the standard protocol
  195.    specification documents, with the corrections, amendments, and
  196.    supplements contained in this RFC.
  197.    A good-faith implementation of the protocols that was produced after
  198.    careful reading of the RFC's and with some interaction with the
  199.    Internet technical community, and that followed good communications
  200.    software engineering practices, should differ from the requirements
  201.    of this document in only minor ways.  Thus, in many cases, the
  202.    "requirements" in this RFC are already stated or implied in the
  203.    standard protocol documents, so that their inclusion here is, in a
  204.    sense, redundant.  However, they were included because some past
  205.    implementation has made the wrong choice, causing problems of
  206.    interoperability, performance, and/or robustness.
  207.    This document includes discussion and explanation of many of the
  208.    requirements and recommendations.  A simple list of requirements
  209.    would be dangerous, because:
  210.    o    Some required features are more important than others, and some
  211.         features are optional.
  212.    o    There may be valid reasons why particular vendor products that
  213. Internet Engineering Task Force                                 [Page 5]
  214. RFC1123                       INTRODUCTION                  October 1989
  215.         are designed for restricted contexts might choose to use
  216.         different specifications.
  217.    However, the specifications of this document must be followed to meet
  218.    the general goal of arbitrary host interoperation across the
  219.    diversity and complexity of the Internet system.  Although most
  220.    current implementations fail to meet these requirements in various
  221.    ways, some minor and some major, this specification is the ideal
  222.    towards which we need to move.
  223.    These requirements are based on the current level of Internet
  224.    architecture.  This document will be updated as required to provide
  225.    additional clarifications or to include additional information in
  226.    those areas in which specifications are still evolving.
  227.    This introductory section begins with general advice to host software
  228.    vendors, and then gives some guidance on reading the rest of the
  229.    document.  Section 2 contains general requirements that may be
  230.    applicable to all application and support protocols.  Sections 3, 4,
  231.    and 5 contain the requirements on protocols for the three major
  232.    applications: Telnet, file transfer, and electronic mail,
  233.    respectively. Section 6 covers the support applications: the domain
  234.    name system, system initialization, and management.  Finally, all
  235.    references will be found in Section 7.
  236.    1.1  The Internet Architecture
  237.       For a brief introduction to the Internet architecture from a host
  238.       viewpoint, see Section 1.1 of [INTRO:1].  That section also
  239.       contains recommended references for general background on the
  240.       Internet architecture.
  241.    1.2  General Considerations
  242.       There are two important lessons that vendors of Internet host
  243.       software have learned and which a new vendor should consider
  244.       seriously.
  245.       1.2.1  Continuing Internet Evolution
  246.          The enormous growth of the Internet has revealed problems of
  247.          management and scaling in a large datagram-based packet
  248.          communication system.  These problems are being addressed, and
  249.          as a result there will be continuing evolution of the
  250.          specifications described in this document.  These changes will
  251.          be carefully planned and controlled, since there is extensive
  252.          participation in this planning by the vendors and by the
  253.          organizations responsible for operations of the networks.
  254. Internet Engineering Task Force                                 [Page 6]
  255. RFC1123                       INTRODUCTION                  October 1989
  256.          Development, evolution, and revision are characteristic of
  257.          computer network protocols today, and this situation will
  258.          persist for some years.  A vendor who develops computer
  259.          communication software for the Internet protocol suite (or any
  260.          other protocol suite!) and then fails to maintain and update
  261.          that software for changing specifications is going to leave a
  262.          trail of unhappy customers.  The Internet is a large
  263.          communication network, and the users are in constant contact
  264.          through it.  Experience has shown that knowledge of
  265.          deficiencies in vendor software propagates quickly through the
  266.          Internet technical community.
  267.       1.2.2  Robustness Principle
  268.          At every layer of the protocols, there is a general rule whose
  269.          application can lead to enormous benefits in robustness and
  270.          interoperability:
  271.                 "Be liberal in what you accept, and
  272.                  conservative in what you send"
  273.          Software should be written to deal with every conceivable
  274.          error, no matter how unlikely; sooner or later a packet will
  275.          come in with that particular combination of errors and
  276.          attributes, and unless the software is prepared, chaos can
  277.          ensue.  In general, it is best to assume that the network is
  278.          filled with malevolent entities that will send in packets
  279.          designed to have the worst possible effect.  This assumption
  280.          will lead to suitable protective design, although the most
  281.          serious problems in the Internet have been caused by
  282.          unenvisaged mechanisms triggered by low-probability events;
  283.          mere human malice would never have taken so devious a course!
  284.          Adaptability to change must be designed into all levels of
  285.          Internet host software.  As a simple example, consider a
  286.          protocol specification that contains an enumeration of values
  287.          for a particular header field -- e.g., a type field, a port
  288.          number, or an error code; this enumeration must be assumed to
  289.          be incomplete.  Thus, if a protocol specification defines four
  290.          possible error codes, the software must not break when a fifth
  291.          code shows up.  An undefined code might be logged (see below),
  292.          but it must not cause a failure.
  293.          The second part of the principle is almost as important:
  294.          software on other hosts may contain deficiencies that make it
  295.          unwise to exploit legal but obscure protocol features.  It is
  296.          unwise to stray far from the obvious and simple, lest untoward
  297.          effects result elsewhere.  A corollary of this is "watch out
  298. Internet Engineering Task Force                                 [Page 7]
  299. RFC1123                       INTRODUCTION                  October 1989
  300.          for misbehaving hosts"; host software should be prepared, not
  301.          just to survive other misbehaving hosts, but also to cooperate
  302.          to limit the amount of disruption such hosts can cause to the
  303.          shared communication facility.
  304.       1.2.3  Error Logging
  305.          The Internet includes a great variety of host and gateway
  306.          systems, each implementing many protocols and protocol layers,
  307.          and some of these contain bugs and mis-features in their
  308.          Internet protocol software.  As a result of complexity,
  309.          diversity, and distribution of function, the diagnosis of user
  310.          problems is often very difficult.
  311.          Problem diagnosis will be aided if host implementations include
  312.          a carefully designed facility for logging erroneous or
  313.          "strange" protocol events.  It is important to include as much
  314.          diagnostic information as possible when an error is logged.  In
  315.          particular, it is often useful to record the header(s) of a
  316.          packet that caused an error.  However, care must be taken to
  317.          ensure that error logging does not consume prohibitive amounts
  318.          of resources or otherwise interfere with the operation of the
  319.          host.
  320.          There is a tendency for abnormal but harmless protocol events
  321.          to overflow error logging files; this can be avoided by using a
  322.          "circular" log, or by enabling logging only while diagnosing a
  323.          known failure.  It may be useful to filter and count duplicate
  324.          successive messages.  One strategy that seems to work well is:
  325.          (1) always count abnormalities and make such counts accessible
  326.          through the management protocol (see Section 6.3); and (2)
  327.          allow the logging of a great variety of events to be
  328.          selectively enabled.  For example, it might useful to be able
  329.          to "log everything" or to "log everything for host X".
  330.          Note that different managements may have differing policies
  331.          about the amount of error logging that they want normally
  332.          enabled in a host.  Some will say, "if it doesn't hurt me, I
  333.          don't want to know about it", while others will want to take a
  334.          more watchful and aggressive attitude about detecting and
  335.          removing protocol abnormalities.
  336.       1.2.4  Configuration
  337.          It would be ideal if a host implementation of the Internet
  338.          protocol suite could be entirely self-configuring.  This would
  339.          allow the whole suite to be implemented in ROM or cast into
  340.          silicon, it would simplify diskless workstations, and it would
  341. Internet Engineering Task Force                                 [Page 8]
  342. RFC1123                       INTRODUCTION                  October 1989
  343.          be an immense boon to harried LAN administrators as well as
  344.          system vendors.  We have not reached this ideal; in fact, we
  345.          are not even close.
  346.          At many points in this document, you will find a requirement
  347.          that a parameter be a configurable option.  There are several
  348.          different reasons behind such requirements.  In a few cases,
  349.          there is current uncertainty or disagreement about the best
  350.          value, and it may be necessary to update the recommended value
  351.          in the future.  In other cases, the value really depends on
  352.          external factors -- e.g., the size of the host and the
  353.          distribution of its communication load, or the speeds and
  354.          topology of nearby networks -- and self-tuning algorithms are
  355.          unavailable and may be insufficient.  In some cases,
  356.          configurability is needed because of administrative
  357.          requirements.
  358.          Finally, some configuration options are required to communicate
  359.          with obsolete or incorrect implementations of the protocols,
  360.          distributed without sources, that unfortunately persist in many
  361.          parts of the Internet.  To make correct systems coexist with
  362.          these faulty systems, administrators often have to "mis-
  363.          configure" the correct systems.  This problem will correct
  364.          itself gradually as the faulty systems are retired, but it
  365.          cannot be ignored by vendors.
  366.          When we say that a parameter must be configurable, we do not
  367.          intend to require that its value be explicitly read from a
  368.          configuration file at every boot time.  We recommend that
  369.          implementors set up a default for each parameter, so a
  370.          configuration file is only necessary to override those defaults
  371.          that are inappropriate in a particular installation.  Thus, the
  372.          configurability requirement is an assurance that it will be
  373.          POSSIBLE to override the default when necessary, even in a
  374.          binary-only or ROM-based product.
  375.          This document requires a particular value for such defaults in
  376.          some cases.  The choice of default is a sensitive issue when
  377.          the configuration item controls the accommodation to existing
  378.          faulty systems.  If the Internet is to converge successfully to
  379.          complete interoperability, the default values built into
  380.          implementations must implement the official protocol, not
  381.          "mis-configurations" to accommodate faulty implementations.
  382.          Although marketing considerations have led some vendors to
  383.          choose mis-configuration defaults, we urge vendors to choose
  384.          defaults that will conform to the standard.
  385.          Finally, we note that a vendor needs to provide adequate
  386. Internet Engineering Task Force                                 [Page 9]
  387. RFC1123                       INTRODUCTION                  October 1989
  388.          documentation on all configuration parameters, their limits and
  389.          effects.
  390.    1.3  Reading this Document
  391.       1.3.1  Organization
  392.          In general, each major section is organized into the following
  393.          subsections:
  394.          (1)  Introduction
  395.          (2)  Protocol Walk-Through -- considers the protocol
  396.               specification documents section-by-section, correcting
  397.               errors, stating requirements that may be ambiguous or
  398.               ill-defined, and providing further clarification or
  399.               explanation.
  400.          (3)  Specific Issues -- discusses protocol design and
  401.               implementation issues that were not included in the walk-
  402.               through.
  403.          (4)  Interfaces -- discusses the service interface to the next
  404.               higher layer.
  405.          (5)  Summary -- contains a summary of the requirements of the
  406.               section.
  407.          Under many of the individual topics in this document, there is
  408.          parenthetical material labeled "DISCUSSION" or
  409.          "IMPLEMENTATION".  This material is intended to give
  410.          clarification and explanation of the preceding requirements
  411.          text.  It also includes some suggestions on possible future
  412.          directions or developments.  The implementation material
  413.          contains suggested approaches that an implementor may want to
  414.          consider.
  415.          The summary sections are intended to be guides and indexes to
  416.          the text, but are necessarily cryptic and incomplete.  The
  417.          summaries should never be used or referenced separately from
  418.          the complete RFC.
  419.       1.3.2  Requirements
  420.          In this document, the words that are used to define the
  421.          significance of each particular requirement are capitalized.
  422.          These words are:
  423. Internet Engineering Task Force                                [Page 10]
  424. RFC1123                       INTRODUCTION                  October 1989
  425.          *    "MUST"
  426.               This word or the adjective "REQUIRED" means that the item
  427.               is an absolute requirement of the specification.
  428.          *    "SHOULD"
  429.               This word or the adjective "RECOMMENDED" means that there
  430.               may exist valid reasons in particular circumstances to
  431.               ignore this item, but the full implications should be
  432.               understood and the case carefully weighed before choosing
  433.               a different course.
  434.          *    "MAY"
  435.               This word or the adjective "OPTIONAL" means that this item
  436.               is truly optional.  One vendor may choose to include the
  437.               item because a particular marketplace requires it or
  438.               because it enhances the product, for example; another
  439.               vendor may omit the same item.
  440.          An implementation is not compliant if it fails to satisfy one
  441.          or more of the MUST requirements for the protocols it
  442.          implements.  An implementation that satisfies all the MUST and
  443.          all the SHOULD requirements for its protocols is said to be
  444.          "unconditionally compliant"; one that satisfies all the MUST
  445.          requirements but not all the SHOULD requirements for its
  446.          protocols is said to be "conditionally compliant".
  447.       1.3.3  Terminology
  448.          This document uses the following technical terms:
  449.          Segment
  450.               A segment is the unit of end-to-end transmission in the
  451.               TCP protocol.  A segment consists of a TCP header followed
  452.               by application data.  A segment is transmitted by
  453.               encapsulation in an IP datagram.
  454.          Message
  455.               This term is used by some application layer protocols
  456.               (particularly SMTP) for an application data unit.
  457.          Datagram
  458.               A [UDP] datagram is the unit of end-to-end transmission in
  459.               the UDP protocol.
  460. Internet Engineering Task Force                                [Page 11]
  461. RFC1123                       INTRODUCTION                  October 1989
  462.          Multihomed
  463.               A host is said to be multihomed if it has multiple IP
  464.               addresses to connected networks.
  465.    1.4  Acknowledgments
  466.       This document incorporates contributions and comments from a large
  467.       group of Internet protocol experts, including representatives of
  468.       university and research labs, vendors, and government agencies.
  469.       It was assembled primarily by the Host Requirements Working Group
  470.       of the Internet Engineering Task Force (IETF).
  471.       The Editor would especially like to acknowledge the tireless
  472.       dedication of the following people, who attended many long
  473.       meetings and generated 3 million bytes of electronic mail over the
  474.       past 18 months in pursuit of this document: Philip Almquist, Dave
  475.       Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
  476.       Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
  477.       John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
  478.       Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
  479.       (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
  480.       In addition, the following people made major contributions to the
  481.       effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
  482.       (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
  483.       Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
  484.       John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
  485.       Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
  486.       (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
  487.       Technology), and Mike StJohns (DCA).  The following also made
  488.       significant contributions to particular areas: Eric Allman
  489.       (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
  490.       (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
  491.       (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
  492.       (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
  493.       Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
  494.       (Toronto).
  495.       We are grateful to all, including any contributors who may have
  496.       been inadvertently omitted from this list.
  497. Internet Engineering Task Force                                [Page 12]
  498. RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
  499. 2.  GENERAL ISSUES
  500.    This section contains general requirements that may be applicable to
  501.    all application-layer protocols.
  502.    2.1  Host Names and Numbers
  503.       The syntax of a legal Internet host name was specified in RFC-952
  504.       [DNS:4].  One aspect of host name syntax is hereby changed: the
  505.       restriction on the first character is relaxed to allow either a
  506.       letter or a digit.  Host software MUST support this more liberal
  507.       syntax.
  508.       Host software MUST handle host names of up to 63 characters and
  509.       SHOULD handle host names of up to 255 characters.
  510.       Whenever a user inputs the identity of an Internet host, it SHOULD
  511.       be possible to enter either (1) a host domain name or (2) an IP
  512.       address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
  513.       the string syntactically for a dotted-decimal number before
  514.       looking it up in the Domain Name System.
  515.       DISCUSSION:
  516.            This last requirement is not intended to specify the complete
  517.            syntactic form for entering a dotted-decimal host number;
  518.            that is considered to be a user-interface issue.  For
  519.            example, a dotted-decimal number must be enclosed within
  520.            "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
  521.            notation could be made universal within a host system,
  522.            simplifying the syntactic checking for a dotted-decimal
  523.            number.
  524.            If a dotted-decimal number can be entered without such
  525.            identifying delimiters, then a full syntactic check must be
  526.            made, because a segment of a host domain name is now allowed
  527.            to begin with a digit and could legally be entirely numeric
  528.            (see Section 6.1.2.4).  However, a valid host name can never
  529.            have the dotted-decimal form #.#.#.#, since at least the
  530.            highest-level component label will be alphabetic.
  531.    2.2  Using Domain Name Service
  532.       Host domain names MUST be translated to IP addresses as described
  533.       in Section 6.1.
  534.       Applications using domain name services MUST be able to cope with
  535.       soft error conditions.  Applications MUST wait a reasonable
  536.       interval between successive retries due to a soft error, and MUST
  537. Internet Engineering Task Force                                [Page 13]
  538. RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
  539.       allow for the possibility that network problems may deny service
  540.       for hours or even days.
  541.       An application SHOULD NOT rely on the ability to locate a WKS
  542.       record containing an accurate listing of all services at a
  543.       particular host address, since the WKS RR type is not often used
  544.       by Internet sites.  To confirm that a service is present, simply
  545.       attempt to use it.
  546.    2.3  Applications on Multihomed hosts
  547.       When the remote host is multihomed, the name-to-address
  548.       translation will return a list of alternative IP addresses.  As
  549.       specified in Section 6.1.3.4, this list should be in order of
  550.       decreasing preference.  Application protocol implementations
  551.       SHOULD be prepared to try multiple addresses from the list until
  552.       success is obtained.  More specific requirements for SMTP are
  553.       given in Section 5.3.4.
  554.       When the local host is multihomed, a UDP-based request/response
  555.       application SHOULD send the response with an IP source address
  556.       that is the same as the specific destination address of the UDP
  557.       request datagram.  The "specific destination address" is defined
  558.       in the "IP Addressing" section of the companion RFC [INTRO:1].
  559.       Similarly, a server application that opens multiple TCP
  560.       connections to the same client SHOULD use the same local IP
  561.       address for all.
  562.    2.4  Type-of-Service
  563.       Applications MUST select appropriate TOS values when they invoke
  564.       transport layer services, and these values MUST be configurable.
  565.       Note that a TOS value contains 5 bits, of which only the most-
  566.       significant 3 bits are currently defined; the other two bits MUST
  567.       be zero.
  568.       DISCUSSION:
  569.            As gateway algorithms are developed to implement Type-of-
  570.            Service, the recommended values for various application
  571.            protocols may change.  In addition, it is likely that
  572.            particular combinations of users and Internet paths will want
  573.            non-standard TOS values.  For these reasons, the TOS values
  574.            must be configurable.
  575.            See the latest version of the "Assigned Numbers" RFC
  576.            [INTRO:5] for the recommended TOS values for the major
  577.            application protocols.
  578. Internet Engineering Task Force                                [Page 14]
  579. RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
  580.    2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
  581.                                                |          | | | |S| |
  582.                                                |          | | | |H| |F
  583.                                                |          | | | |O|M|o
  584.                                                |          | |S| |U|U|o
  585.                                                |          | |H| |L|S|t
  586.                                                |          |M|O| |D|T|n
  587.                                                |          |U|U|M| | |o
  588.                                                |          |S|L|A|N|N|t
  589.                                                |          |T|D|Y|O|O|t
  590. FEATURE                                        |SECTION   | | | |T|T|e
  591. -----------------------------------------------|----------|-|-|-|-|-|--
  592.                                                |          | | | | | |
  593. User interfaces:                               |          | | | | | |
  594.   Allow host name to begin with digit          |2.1       |x| | | | |
  595.   Host names of up to 635 characters           |2.1       |x| | | | |
  596.   Host names of up to 255 characters           |2.1       | |x| | | |
  597.   Support dotted-decimal host numbers          |2.1       | |x| | | |
  598.   Check syntactically for dotted-dec first     |2.1       | |x| | | |
  599.                                                |          | | | | | |
  600. Map domain names per Section 6.1               |2.2       |x| | | | |
  601. Cope with soft DNS errors                      |2.2       |x| | | | |
  602.    Reasonable interval between retries         |2.2       |x| | | | |
  603.    Allow for long outages                      |2.2       |x| | | | |
  604. Expect WKS records to be available             |2.2       | | | |x| |
  605.                                                |          | | | | | |
  606. Try multiple addr's for remote multihomed host |2.3       | |x| | | |
  607. UDP reply src addr is specific dest of request |2.3       | |x| | | |
  608. Use same IP addr for related TCP connections   |2.3       | |x| | | |
  609. Specify appropriate TOS values                 |2.4       |x| | | | |
  610.   TOS values configurable                      |2.4       |x| | | | |
  611.   Unused TOS bits zero                         |2.4       |x| | | | |
  612.                                                |          | | | | | |
  613.                                                |          | | | | | |
  614. Internet Engineering Task Force                                [Page 15]
  615. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  616. 3.  REMOTE LOGIN -- TELNET PROTOCOL
  617.    3.1  INTRODUCTION
  618.       Telnet is the standard Internet application protocol for remote
  619.       login.  It provides the encoding rules to link a user's
  620.       keyboard/display on a client ("user") system with a command
  621.       interpreter on a remote server system.  A subset of the Telnet
  622.       protocol is also incorporated within other application protocols,
  623.       e.g., FTP and SMTP.
  624.       Telnet uses a single TCP connection, and its normal data stream
  625.       ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
  626.       escape sequences to embed control functions.  Telnet also allows
  627.       the negotiation of many optional modes and functions.
  628.       The primary Telnet specification is to be found in RFC-854
  629.       [TELNET:1], while the options are defined in many other RFCs; see
  630.       Section 7 for references.
  631.    3.2  PROTOCOL WALK-THROUGH
  632.       3.2.1  Option Negotiation: RFC-854, pp. 2-3
  633.          Every Telnet implementation MUST include option negotiation and
  634.          subnegotiation machinery [TELNET:2].
  635.          A host MUST carefully follow the rules of RFC-854 to avoid
  636.          option-negotiation loops.  A host MUST refuse (i.e, reply
  637.          WONT/DONT to a DO/WILL) an unsupported option.  Option
  638.          negotiation SHOULD continue to function (even if all requests
  639.          are refused) throughout the lifetime of a Telnet connection.
  640.          If all option negotiations fail, a Telnet implementation MUST
  641.          default to, and support, an NVT.
  642.          DISCUSSION:
  643.               Even though more sophisticated "terminals" and supporting
  644.               option negotiations are becoming the norm, all
  645.               implementations must be prepared to support an NVT for any
  646.               user-server communication.
  647.       3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
  648.          On a host that never sends the Telnet command Go Ahead (GA),
  649.          the Telnet Server MUST attempt to negotiate the Suppress Go
  650.          Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
  651.          Server Telnet MUST always accept negotiation of the Suppress Go
  652. Internet Engineering Task Force                                [Page 16]
  653. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  654.          Ahead option.
  655.          When it is driving a full-duplex terminal for which GA has no
  656.          meaning, a User Telnet implementation MAY ignore GA commands.
  657.          DISCUSSION:
  658.               Half-duplex ("locked-keyboard") line-at-a-time terminals
  659.               for which the Go-Ahead mechanism was designed have largely
  660.               disappeared from the scene.  It turned out to be difficult
  661.               to implement sending the Go-Ahead signal in many operating
  662.               systems, even some systems that support native half-duplex
  663.               terminals.  The difficulty is typically that the Telnet
  664.               server code does not have access to information about
  665.               whether the user process is blocked awaiting input from
  666.               the Telnet connection, i.e., it cannot reliably determine
  667.               when to send a GA command.  Therefore, most Telnet Server
  668.               hosts do not send GA commands.
  669.               The effect of the rules in this section is to allow either
  670.               end of a Telnet connection to veto the use of GA commands.
  671.               There is a class of half-duplex terminals that is still
  672.               commercially important: "data entry terminals," which
  673.               interact in a full-screen manner.  However, supporting
  674.               data entry terminals using the Telnet protocol does not
  675.               require the Go Ahead signal; see Section 3.3.2.
  676.       3.2.3  Control Functions: RFC-854, pp. 7-8
  677.          The list of Telnet commands has been extended to include EOR
  678.          (End-of-Record), with code 239 [TELNET:9].
  679.          Both User and Server Telnets MAY support the control functions
  680.          EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
  681.          SB, and SE.
  682.          A host MUST be able to receive and ignore any Telnet control
  683.          functions that it does not support.
  684.          DISCUSSION:
  685.               Note that a Server Telnet is required to support the
  686.               Telnet IP (Interrupt Process) function, even if the server
  687.               host has an equivalent in-stream function (e.g., Control-C
  688.               in many systems).  The Telnet IP function may be stronger
  689.               than an in-stream interrupt command, because of the out-
  690.               of-band effect of TCP urgent data.
  691.               The EOR control function may be used to delimit the
  692. Internet Engineering Task Force                                [Page 17]
  693. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  694.               stream.  An important application is data entry terminal
  695.               support (see Section 3.3.2).  There was concern that since
  696.               EOR had not been defined in RFC-854, a host that was not
  697.               prepared to correctly ignore unknown Telnet commands might
  698.               crash if it received an EOR.  To protect such hosts, the
  699.               End-of-Record option [TELNET:9] was introduced; however, a
  700.               properly implemented Telnet program will not require this
  701.               protection.
  702.       3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
  703.          When it receives "urgent" TCP data, a User or Server Telnet
  704.          MUST discard all data except Telnet commands until the DM (and
  705.          end of urgent) is reached.
  706.          When it sends Telnet IP (Interrupt Process), a User Telnet
  707.          SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
  708.          TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
  709.          pointer points to the DM octet.
  710.          When it receives a Telnet IP command, a Server Telnet MAY send
  711.          a Telnet "Synch" sequence back to the user, to flush the output
  712.          stream.  The choice ought to be consistent with the way the
  713.          server operating system behaves when a local user interrupts a
  714.          process.
  715.          When it receives a Telnet AO command, a Server Telnet MUST send
  716.          a Telnet "Synch" sequence back to the user, to flush the output
  717.          stream.
  718.          A User Telnet SHOULD have the capability of flushing output
  719.          when it sends a Telnet IP; see also Section 3.4.5.
  720.          DISCUSSION:
  721.               There are three possible ways for a User Telnet to flush
  722.               the stream of server output data:
  723.               (1)  Send AO after IP.
  724.                    This will cause the server host to send a "flush-
  725.                    buffered-output" signal to its operating system.
  726.                    However, the AO may not take effect locally, i.e.,
  727.                    stop terminal output at the User Telnet end, until
  728.                    the Server Telnet has received and processed the AO
  729.                    and has sent back a "Synch".
  730.               (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
  731.                    all output locally until a WILL/WONT TIMING-MARK is
  732. Internet Engineering Task Force                                [Page 18]
  733. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  734.                    received from the Server Telnet.
  735.                    Since the DO TIMING-MARK will be processed after the
  736.                    IP at the server, the reply to it should be in the
  737.                    right place in the output data stream.  However, the
  738.                    TIMING-MARK will not send a "flush buffered output"
  739.                    signal to the server operating system.  Whether or
  740.                    not this is needed is dependent upon the server
  741.                    system.
  742.               (3)  Do both.
  743.               The best method is not entirely clear, since it must
  744.               accommodate a number of existing server hosts that do not
  745.               follow the Telnet standards in various ways.  The safest
  746.               approach is probably to provide a user-controllable option
  747.               to select (1), (2), or (3).
  748.       3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
  749.          In NVT mode, a Telnet SHOULD NOT send characters with the
  750.          high-order bit 1, and MUST NOT send it as a parity bit.
  751.          Implementations that pass the high-order bit to applications
  752.          SHOULD negotiate binary mode (see Section 3.2.6).
  753.          DISCUSSION:
  754.               Implementors should be aware that a strict reading of
  755.               RFC-854 allows a client or server expecting NVT ASCII to
  756.               ignore characters with the high-order bit set.  In
  757.               general, binary mode is expected to be used for
  758.               transmission of an extended (beyond 7-bit) character set
  759.               with Telnet.
  760.               However, there exist applications that really need an 8-
  761.               bit NVT mode, which is currently not defined, and these
  762.               existing applications do set the high-order bit during
  763.               part or all of the life of a Telnet connection.  Note that
  764.               binary mode is not the same as 8-bit NVT mode, since
  765.               binary mode turns off end-of-line processing.  For this
  766.               reason, the requirements on the high-order bit are stated
  767.               as SHOULD, not MUST.
  768.               RFC-854 defines a minimal set of properties of a "network
  769.               virtual terminal" or NVT; this is not meant to preclude
  770.               additional features in a real terminal.  A Telnet
  771.               connection is fully transparent to all 7-bit ASCII
  772.               characters, including arbitrary ASCII control characters.
  773. Internet Engineering Task Force                                [Page 19]
  774. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  775.               For example, a terminal might support full-screen commands
  776.               coded as ASCII escape sequences; a Telnet implementation
  777.               would pass these sequences as uninterpreted data.  Thus,
  778.               an NVT should not be conceived as a terminal type of a
  779.               highly-restricted device.
  780.       3.2.6  Telnet Command Structure: RFC-854, p. 13
  781.          Since options may appear at any point in the data stream, a
  782.          Telnet escape character (known as IAC, with the value 255) to
  783.          be sent as data MUST be doubled.
  784.       3.2.7  Telnet Binary Option: RFC-856
  785.          When the Binary option has been successfully negotiated,
  786.          arbitrary 8-bit characters are allowed.  However, the data
  787.          stream MUST still be scanned for IAC characters, any embedded
  788.          Telnet commands MUST be obeyed, and data bytes equal to IAC
  789.          MUST be doubled.  Other character processing (e.g., replacing
  790.          CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
  791.          there is no end-of-line convention (see Section 3.3.1) in
  792.          binary mode.
  793.          DISCUSSION:
  794.               The Binary option is normally negotiated in both
  795.               directions, to change the Telnet connection from NVT mode
  796.               to "binary mode".
  797.               The sequence IAC EOR can be used to delimit blocks of data
  798.               within a binary-mode Telnet stream.
  799.       3.2.8  Telnet Terminal-Type Option: RFC-1091
  800.          The Terminal-Type option MUST use the terminal type names
  801.          officially defined in the Assigned Numbers RFC [INTRO:5], when
  802.          they are available for the particular terminal.  However, the
  803.          receiver of a Terminal-Type option MUST accept any name.
  804.          DISCUSSION:
  805.               RFC-1091 [TELNET:10] updates an earlier version of the
  806.               Terminal-Type option defined in RFC-930.  The earlier
  807.               version allowed a server host capable of supporting
  808.               multiple terminal types to learn the type of a particular
  809.               client's terminal, assuming that each physical terminal
  810.               had an intrinsic type.  However, today a "terminal" is
  811.               often really a terminal emulator program running in a PC,
  812.               perhaps capable of emulating a range of terminal types.
  813.               Therefore, RFC-1091 extends the specification to allow a
  814. Internet Engineering Task Force                                [Page 20]
  815. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  816.               more general terminal-type negotiation between User and
  817.               Server Telnets.
  818.    3.3  SPECIFIC ISSUES
  819.       3.3.1  Telnet End-of-Line Convention
  820.          The Telnet protocol defines the sequence CR LF to mean "end-
  821.          of-line".  For terminal input, this corresponds to a command-
  822.          completion or "end-of-line" key being pressed on a user
  823.          terminal; on an ASCII terminal, this is the CR key, but it may
  824.          also be labelled "Return" or "Enter".
  825.          When a Server Telnet receives the Telnet end-of-line sequence
  826.          CR LF as input from a remote terminal, the effect MUST be the
  827.          same as if the user had pressed the "end-of-line" key on a
  828.          local terminal.  On server hosts that use ASCII, in particular,
  829.          receipt of the Telnet sequence CR LF must cause the same effect
  830.          as a local user pressing the CR key on a local terminal.  Thus,
  831.          CR LF and CR NUL MUST have the same effect on an ASCII server
  832.          host when received as input over a Telnet connection.
  833.          A User Telnet MUST be able to send any of the forms: CR LF, CR
  834.          NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
  835.          user-controllable mode to send either CR LF or CR NUL when the
  836.          user presses the "end-of-line" key, and CR LF SHOULD be the
  837.          default.
  838.          The Telnet end-of-line sequence CR LF MUST be used to send
  839.          Telnet data that is not terminal-to-computer (e.g., for Server
  840.          Telnet sending output, or the Telnet protocol incorporated
  841.          another application protocol).
  842.          DISCUSSION:
  843.               To allow interoperability between arbitrary Telnet clients
  844.               and servers, the Telnet protocol defined a standard
  845.               representation for a line terminator.  Since the ASCII
  846.               character set includes no explicit end-of-line character,
  847.               systems have chosen various representations, e.g., CR, LF,
  848.               and the sequence CR LF.  The Telnet protocol chose the CR
  849.               LF sequence as the standard for network transmission.
  850.               Unfortunately, the Telnet protocol specification in RFC-
  851.               854 [TELNET:1] has turned out to be somewhat ambiguous on
  852.               what character(s) should be sent from client to server for
  853.               the "end-of-line" key.  The result has been a massive and
  854.               continuing interoperability headache, made worse by
  855.               various faulty implementations of both User and Server
  856. Internet Engineering Task Force                                [Page 21]
  857. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  858.               Telnets.
  859.               Although the Telnet protocol is based on a perfectly
  860.               symmetric model, in a remote login session the role of the
  861.               user at a terminal differs from the role of the server
  862.               host.  For example, RFC-854 defines the meaning of CR, LF,
  863.               and CR LF as output from the server, but does not specify
  864.               what the User Telnet should send when the user presses the
  865.               "end-of-line" key on the terminal; this turns out to be
  866.               the point at issue.
  867.               When a user presses the "end-of-line" key, some User
  868.               Telnet implementations send CR LF, while others send CR
  869.               NUL (based on a different interpretation of the same
  870.               sentence in RFC-854).  These will be equivalent for a
  871.               correctly-implemented ASCII server host, as discussed
  872.               above.  For other servers, a mode in the User Telnet is
  873.               needed.
  874.               The existence of User Telnets that send only CR NUL when
  875.               CR is pressed creates a dilemma for non-ASCII hosts: they
  876.               can either treat CR NUL as equivalent to CR LF in input,
  877.               thus precluding the possibility of entering a "bare" CR,
  878.               or else lose complete interworking.
  879.               Suppose a user on host A uses Telnet to log into a server
  880.               host B, and then execute B's User Telnet program to log
  881.               into server host C.  It is desirable for the Server/User
  882.               Telnet combination on B to be as transparent as possible,
  883.               i.e., to appear as if A were connected directly to C.  In
  884.               particular, correct implementation will make B transparent
  885.               to Telnet end-of-line sequences, except that CR LF may be
  886.               translated to CR NUL or vice versa.
  887.          IMPLEMENTATION:
  888.               To understand Telnet end-of-line issues, one must have at
  889.               least a general model of the relationship of Telnet to the
  890.               local operating system.  The Server Telnet process is
  891.               typically coupled into the terminal driver software of the
  892.               operating system as a pseudo-terminal.  A Telnet end-of-
  893.               line sequence received by the Server Telnet must have the
  894.               same effect as pressing the end-of-line key on a real
  895.               locally-connected terminal.
  896.               Operating systems that support interactive character-at-
  897.               a-time applications (e.g., editors) typically have two
  898.               internal modes for their terminal I/O: a formatted mode,
  899.               in which local conventions for end-of-line and other
  900. Internet Engineering Task Force                                [Page 22]
  901. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  902.               formatting rules have been applied to the data stream, and
  903.               a "raw" mode, in which the application has direct access
  904.               to every character as it was entered.  A Server Telnet
  905.               must be implemented in such a way that these modes have
  906.               the same effect for remote as for local terminals.  For
  907.               example, suppose a CR LF or CR NUL is received by the
  908.               Server Telnet on an ASCII host.  In raw mode, a CR
  909.               character is passed to the application; in formatted mode,
  910.               the local system's end-of-line convention is used.
  911.       3.3.2  Data Entry Terminals
  912.          DISCUSSION:
  913.               In addition to the line-oriented and character-oriented
  914.               ASCII terminals for which Telnet was designed, there are
  915.               several families of video display terminals that are
  916.               sometimes known as "data entry terminals" or DETs.  The
  917.               IBM 3270 family is a well-known example.
  918.               Two Internet protocols have been designed to support
  919.               generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
  920.               option [TELNET:18, TELNET:19].  The DET option drives a
  921.               data entry terminal over a Telnet connection using (sub-)
  922.               negotiation.  SUPDUP is a completely separate terminal
  923.               protocol, which can be entered from Telnet by negotiation.
  924.               Although both SUPDUP and the DET option have been used
  925.               successfully in particular environments, neither has
  926.               gained general acceptance or wide implementation.
  927.               A different approach to DET interaction has been developed
  928.               for supporting the IBM 3270 family through Telnet,
  929.               although the same approach would be applicable to any DET.
  930.               The idea is to enter a "native DET" mode, in which the
  931.               native DET input/output stream is sent as binary data.
  932.               The Telnet EOR command is used to delimit logical records
  933.               (e.g., "screens") within this binary stream.
  934.          IMPLEMENTATION:
  935.               The rules for entering and leaving native DET mode are as
  936.               follows:
  937.               o    The Server uses the Terminal-Type option [TELNET:10]
  938.                    to learn that the client is a DET.
  939.               o    It is conventional, but not required, that both ends
  940.                    negotiate the EOR option [TELNET:9].
  941.               o    Both ends negotiate the Binary option [TELNET:3] to
  942. Internet Engineering Task Force                                [Page 23]
  943. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  944.                    enter native DET mode.
  945.               o    When either end negotiates out of binary mode, the
  946.                    other end does too, and the mode then reverts to
  947.                    normal NVT.
  948.       3.3.3  Option Requirements
  949.          Every Telnet implementation MUST support the Binary option
  950.          [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
  951.          SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
  952.          Record [TELNET:9], and Extended Options List [TELNET:8]
  953.          options.
  954.          A User or Server Telnet SHOULD support the Window Size Option
  955.          [TELNET:12] if the local operating system provides the
  956.          corresponding capability.
  957.          DISCUSSION:
  958.               Note that the End-of-Record option only signifies that a
  959.               Telnet can receive a Telnet EOR without crashing;
  960.               therefore, every Telnet ought to be willing to accept
  961.               negotiation of the End-of-Record option.  See also the
  962.               discussion in Section 3.2.3.
  963.       3.3.4  Option Initiation
  964.          When the Telnet protocol is used in a client/server situation,
  965.          the server SHOULD initiate negotiation of the terminal
  966.          interaction mode it expects.
  967.          DISCUSSION:
  968.               The Telnet protocol was defined to be perfectly
  969.               symmetrical, but its application is generally asymmetric.
  970.               Remote login has been known to fail because NEITHER side
  971.               initiated negotiation of the required non-default terminal
  972.               modes.  It is generally the server that determines the
  973.               preferred mode, so the server needs to initiate the
  974.               negotiation; since the negotiation is symmetric, the user
  975.               can also initiate it.
  976.          A client (User Telnet) SHOULD provide a means for users to
  977.          enable and disable the initiation of option negotiation.
  978.          DISCUSSION:
  979.               A user sometimes needs to connect to an application
  980.               service (e.g., FTP or SMTP) that uses Telnet for its
  981. Internet Engineering Task Force                                [Page 24]
  982. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  983.               control stream but does not support Telnet options.  User
  984.               Telnet may be used for this purpose if initiation of
  985.               option negotiation is  disabled.
  986.       3.3.5  Telnet Linemode Option
  987.          DISCUSSION:
  988.               An important new Telnet option, LINEMODE [TELNET:12], has
  989.               been proposed.  The LINEMODE option provides a standard
  990.               way for a User Telnet and a Server Telnet to agree that
  991.               the client rather than the server will perform terminal
  992.               character processing.  When the client has prepared a
  993.               complete line of text, it will send it to the server in
  994.               (usually) one TCP packet.  This option will greatly
  995.               decrease the packet cost of Telnet sessions and will also
  996.               give much better user response over congested or long-
  997.               delay networks.
  998.               The LINEMODE option allows dynamic switching between local
  999.               and remote character processing.  For example, the Telnet
  1000.               connection will automatically negotiate into single-
  1001.               character mode while a full screen editor is running, and
  1002.               then return to linemode when the editor is finished.
  1003.               We expect that when this RFC is released, hosts should
  1004.               implement the client side of this option, and may
  1005.               implement the server side of this option.  To properly
  1006.               implement the server side, the server needs to be able to
  1007.               tell the local system not to do any input character
  1008.               processing, but to remember its current terminal state and
  1009.               notify the Server Telnet process whenever the state
  1010.               changes.  This will allow password echoing and full screen
  1011.               editors to be handled properly, for example.
  1012.    3.4  TELNET/USER INTERFACE
  1013.       3.4.1  Character Set Transparency
  1014.          User Telnet implementations SHOULD be able to send or receive
  1015.          any 7-bit ASCII character.  Where possible, any special
  1016.          character interpretations by the user host's operating system
  1017.          SHOULD be bypassed so that these characters can conveniently be
  1018.          sent and received on the connection.
  1019.          Some character value MUST be reserved as "escape to command
  1020.          mode"; conventionally, doubling this character allows it to be
  1021.          entered as data.  The specific character used SHOULD be user
  1022.          selectable.
  1023. Internet Engineering Task Force                                [Page 25]
  1024. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  1025.          On binary-mode connections, a User Telnet program MAY provide
  1026.          an escape mechanism for entering arbitrary 8-bit values, if the
  1027.          host operating system doesn't allow them to be entered directly
  1028.          from the keyboard.
  1029.          IMPLEMENTATION:
  1030.               The transparency issues are less pressing on servers, but
  1031.               implementors should take care in dealing with issues like:
  1032.               masking off parity bits (sent by an older, non-conforming
  1033.               client) before they reach programs that expect only NVT
  1034.               ASCII, and properly handling programs that request 8-bit
  1035.               data streams.
  1036.       3.4.2  Telnet Commands
  1037.          A User Telnet program MUST provide a user the capability of
  1038.          entering any of the Telnet control functions IP, AO, or AYT,
  1039.          and SHOULD provide the capability of entering EC, EL, and
  1040.          Break.
  1041.       3.4.3  TCP Connection Errors
  1042.          A User Telnet program SHOULD report to the user any TCP errors
  1043.          that are reported by the transport layer (see "TCP/Application
  1044.          Layer Interface" section in [INTRO:1]).
  1045.       3.4.4  Non-Default Telnet Contact Port
  1046.          A User Telnet program SHOULD allow the user to optionally
  1047.          specify a non-standard contact port number at the Server Telnet
  1048.          host.
  1049.       3.4.5  Flushing Output
  1050.          A User Telnet program SHOULD provide the user the ability to
  1051.          specify whether or not output should be flushed when an IP is
  1052.          sent; see Section 3.2.4.
  1053.          For any output flushing scheme that causes the User Telnet to
  1054.          flush output locally until a Telnet signal is received from the
  1055.          Server, there SHOULD be a way for the user to manually restore
  1056.          normal output, in case the Server fails to send the expected
  1057.          signal.
  1058. Internet Engineering Task Force                                [Page 26]
  1059. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  1060.    3.5.  TELNET REQUIREMENTS SUMMARY
  1061.                                                  |        | | | |S| |
  1062.                                                  |        | | | |H| |F
  1063.                                                  |        | | | |O|M|o
  1064.                                                  |        | |S| |U|U|o
  1065.                                                  |        | |H| |L|S|t
  1066.                                                  |        |M|O| |D|T|n
  1067.                                                  |        |U|U|M| | |o
  1068.                                                  |        |S|L|A|N|N|t
  1069.                                                  |        |T|D|Y|O|O|t
  1070. FEATURE                                          |SECTION | | | |T|T|e
  1071. -------------------------------------------------|--------|-|-|-|-|-|--
  1072.                                                  |        | | | | | |
  1073. Option Negotiation                               |3.2.1   |x| | | | |
  1074.   Avoid negotiation loops                        |3.2.1   |x| | | | |
  1075.   Refuse unsupported options                     |3.2.1   |x| | | | |
  1076.   Negotiation OK anytime on connection           |3.2.1   | |x| | | |
  1077.   Default to NVT                                 |3.2.1   |x| | | | |
  1078.   Send official name in Term-Type option         |3.2.8   |x| | | | |
  1079.   Accept any name in Term-Type option            |3.2.8   |x| | | | |
  1080.   Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
  1081.   Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
  1082.   Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
  1083.   Server initiate mode negotiations              |3.3.4   | |x| | | |
  1084.   User can enable/disable init negotiations      |3.3.4   | |x| | | |
  1085.                                                  |        | | | | | |
  1086. Go-Aheads                                        |        | | | | | |
  1087.   Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
  1088.   User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
  1089.   User Telnet ignore GA's                        |3.2.2   | | |x| | |
  1090.                                                  |        | | | | | |
  1091. Control Functions                                |        | | | | | |
  1092.   Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
  1093.   Support EOR EC EL Break                        |3.2.3   | | |x| | |
  1094.   Ignore unsupported control functions           |3.2.3   |x| | | | |
  1095.   User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
  1096.   User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
  1097.   Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
  1098.   Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
  1099.   User Telnet can flush output when send IP      |3.2.4   | |x| | | |
  1100.                                                  |        | | | | | |
  1101. Encoding                                         |        | | | | | |
  1102.   Send high-order bit in NVT mode                |3.2.5   | | | |x| |
  1103.   Send high-order bit as parity bit              |3.2.5   | | | | |x|
  1104.   Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
  1105.   Always double IAC data byte                    |3.2.6   |x| | | | |
  1106. Internet Engineering Task Force                                [Page 27]
  1107. RFC1123                  REMOTE LOGIN -- TELNET             October 1989
  1108.   Double IAC data byte in binary mode            |3.2.7   |x| | | | |
  1109.   Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
  1110.   End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
  1111.                                                  |        | | | | | |
  1112. End-of-Line                                      |        | | | | | |
  1113.   EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
  1114.   ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
  1115.   User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
  1116.     ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
  1117.     User Telnet default mode is CR LF            |3.3.1   | |x| | | |
  1118.   Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
  1119.                                                  |        | | | | | |
  1120. User Telnet interface                            |        | | | | | |
  1121.   Input & output all 7-bit characters            |3.4.1   | |x| | | |
  1122.   Bypass local op sys interpretation             |3.4.1   | |x| | | |
  1123.   Escape character                               |3.4.1   |x| | | | |
  1124.      User-settable escape character              |3.4.1   | |x| | | |
  1125.   Escape to enter 8-bit values                   |3.4.1   | | |x| | |
  1126.   Can input IP, AO, AYT                          |3.4.2   |x| | | | |
  1127.   Can input EC, EL, Break                        |3.4.2   | |x| | | |
  1128.   Report TCP connection errors to user           |3.4.3   | |x| | | |
  1129.   Optional non-default contact port              |3.4.4   | |x| | | |
  1130.   Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
  1131.   Can manually restore output mode               |3.4.5   | |x| | | |
  1132.                                                  |        | | | | | |
  1133. Internet Engineering Task Force                                [Page 28]
  1134. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1135. 4.  FILE TRANSFER
  1136.    4.1  FILE TRANSFER PROTOCOL -- FTP
  1137.       4.1.1  INTRODUCTION
  1138.          The File Transfer Protocol FTP is the primary Internet standard
  1139.          for file transfer.  The current specification is contained in
  1140.          RFC-959 [FTP:1].
  1141.          FTP uses separate simultaneous TCP connections for control and
  1142.          for data transfer.  The FTP protocol includes many features,
  1143.          some of which are not commonly implemented.  However, for every
  1144.          feature in FTP, there exists at least one implementation.  The
  1145.          minimum implementation defined in RFC-959 was too small, so a
  1146.          somewhat larger minimum implementation is defined here.
  1147.          Internet users have been unnecessarily burdened for years by
  1148.          deficient FTP implementations.  Protocol implementors have
  1149.          suffered from the erroneous opinion that implementing FTP ought
  1150.          to be a small and trivial task.  This is wrong, because FTP has
  1151.          a user interface, because it has to deal (correctly) with the
  1152.          whole variety of communication and operating system errors that
  1153.          may occur, and because it has to handle the great diversity of
  1154.          real file systems in the world.
  1155.       4.1.2.  PROTOCOL WALK-THROUGH
  1156.          4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
  1157.             An FTP program MUST support TYPE I ("IMAGE" or binary type)
  1158.             as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
  1159.             A machine whose memory is organized into m-bit words, where
  1160.             m is not a multiple of 8, MAY also support TYPE L m.
  1161.             DISCUSSION:
  1162.                  The command "TYPE L 8" is often required to transfer
  1163.                  binary data between a machine whose memory is organized
  1164.                  into (e.g.) 36-bit words and a machine with an 8-bit
  1165.                  byte organization.  For an 8-bit byte machine, TYPE L 8
  1166.                  is equivalent to IMAGE.
  1167.                  "TYPE L m" is sometimes specified to the FTP programs
  1168.                  on two m-bit word machines to ensure the correct
  1169.                  transfer of a native-mode binary file from one machine
  1170.                  to the other.  However, this command should have the
  1171.                  same effect on these machines as "TYPE I".
  1172. Internet Engineering Task Force                                [Page 29]
  1173. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1174.          4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
  1175.             A host that makes no distinction between TYPE N and TYPE T
  1176.             SHOULD implement TYPE T to be identical to TYPE N.
  1177.             DISCUSSION:
  1178.                  This provision should ease interoperation with hosts
  1179.                  that do make this distinction.
  1180.                  Many hosts represent text files internally as strings
  1181.                  of ASCII characters, using the embedded ASCII format
  1182.                  effector characters (LF, BS, FF, ...) to control the
  1183.                  format when a file is printed.  For such hosts, there
  1184.                  is no distinction between "print" files and other
  1185.                  files.  However, systems that use record structured
  1186.                  files typically need a special format for printable
  1187.                  files (e.g., ASA carriage control).   For the latter
  1188.                  hosts, FTP allows a choice of TYPE N or TYPE T.
  1189.          4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
  1190.             Implementation of page structure is NOT RECOMMENDED in
  1191.             general. However, if a host system does need to implement
  1192.             FTP for "random access" or "holey" files, it MUST use the
  1193.             defined page structure format rather than define a new
  1194.             private FTP format.
  1195.          4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
  1196.             An FTP transformation between record-structure and file-
  1197.             structure SHOULD be invertible, to the extent possible while
  1198.             making the result useful on the target host.
  1199.             DISCUSSION:
  1200.                  RFC-959 required strict invertibility between record-
  1201.                  structure and file-structure, but in practice,
  1202.                  efficiency and convenience often preclude it.
  1203.                  Therefore, the requirement is being relaxed.  There are
  1204.                  two different objectives for transferring a file:
  1205.                  processing it on the target host, or just storage.  For
  1206.                  storage, strict invertibility is important.  For
  1207.                  processing, the file created on the target host needs
  1208.                  to be in the format expected by application programs on
  1209.                  that host.
  1210.                  As an example of the conflict, imagine a record-
  1211.                  oriented operating system that requires some data files
  1212.                  to have exactly 80 bytes in each record.  While STORing
  1213. Internet Engineering Task Force                                [Page 30]
  1214. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1215.                  a file on such a host, an FTP Server must be able to
  1216.                  pad each line or record to 80 bytes; a later retrieval
  1217.                  of such a file cannot be strictly invertible.
  1218.          4.1.2.5  Data Connection Management: RFC-959 Section 3.3
  1219.             A User-FTP that uses STREAM mode SHOULD send a PORT command
  1220.             to assign a non-default data port before each transfer
  1221.             command is issued.
  1222.             DISCUSSION:
  1223.                  This is required because of the long delay after a TCP
  1224.                  connection is closed until its socket pair can be
  1225.                  reused, to allow multiple transfers during a single FTP
  1226.                  session.  Sending a port command can avoided if a
  1227.                  transfer mode other than stream is used, by leaving the
  1228.                  data transfer connection open between transfers.
  1229.          4.1.2.6  PASV Command: RFC-959 Section 4.1.2
  1230.             A server-FTP MUST implement the PASV command.
  1231.             If multiple third-party transfers are to be executed during
  1232.             the same session, a new PASV command MUST be issued before
  1233.             each transfer command, to obtain a unique port pair.
  1234.             IMPLEMENTATION:
  1235.                  The format of the 227 reply to a PASV command is not
  1236.                  well standardized.  In particular, an FTP client cannot
  1237.                  assume that the parentheses shown on page 40 of RFC-959
  1238.                  will be present (and in fact, Figure 3 on page 43 omits
  1239.                  them).  Therefore, a User-FTP program that interprets
  1240.                  the PASV reply must scan the reply for the first digit
  1241.                  of the host and port numbers.
  1242.                  Note that the host number h1,h2,h3,h4 is the IP address
  1243.                  of the server host that is sending the reply, and that
  1244.                  p1,p2 is a non-default data transfer port that PASV has
  1245.                  assigned.
  1246.          4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
  1247.             The data returned by an NLST command MUST contain only a
  1248.             simple list of legal pathnames, such that the server can use
  1249.             them directly as the arguments of subsequent data transfer
  1250.             commands for the individual files.
  1251.             The data returned by a LIST or NLST command SHOULD use an
  1252. Internet Engineering Task Force                                [Page 31]
  1253. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1254.             implied TYPE AN, unless the current type is EBCDIC, in which
  1255.             case an implied TYPE EN SHOULD be used.
  1256.             DISCUSSION:
  1257.                  Many FTP clients support macro-commands that will get
  1258.                  or put files matching a wildcard specification, using
  1259.                  NLST to obtain a list of pathnames.  The expansion of
  1260.                  "multiple-put" is local to the client, but "multiple-
  1261.                  get" requires cooperation by the server.
  1262.                  The implied type for LIST and NLST is designed to
  1263.                  provide compatibility with existing User-FTPs, and in
  1264.                  particular with multiple-get commands.
  1265.          4.1.2.8  SITE Command: RFC-959 Section 4.1.3
  1266.             A Server-FTP SHOULD use the SITE command for non-standard
  1267.             features, rather than invent new private commands or
  1268.             unstandardized extensions to existing commands.
  1269.          4.1.2.9  STOU Command: RFC-959 Section 4.1.3
  1270.             The STOU command stores into a uniquely named file.  When it
  1271.             receives an STOU command, a Server-FTP MUST return the
  1272.             actual file name in the "125 Transfer Starting" or the "150
  1273.             Opening Data Connection" message that precedes the transfer
  1274.             (the 250 reply code mentioned in RFC-959 is incorrect).  The
  1275.             exact format of these messages is hereby defined to be as
  1276.             follows:
  1277.                 125 FILE: pppp
  1278.                 150 FILE: pppp
  1279.             where pppp represents the unique pathname of the file that
  1280.             will be written.
  1281.          4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
  1282.             Implementors MUST NOT assume any correspondence between READ
  1283.             boundaries on the control connection and the Telnet EOL
  1284.             sequences (CR LF).
  1285.             DISCUSSION:
  1286.                  Thus, a server-FTP (or User-FTP) must continue reading
  1287.                  characters from the control connection until a complete
  1288.                  Telnet EOL sequence is encountered, before processing
  1289.                  the command (or response, respectively).  Conversely, a
  1290.                  single READ from the control connection may include
  1291. Internet Engineering Task Force                                [Page 32]
  1292. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1293.                  more than one FTP command.
  1294.          4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
  1295.             A Server-FTP MUST send only correctly formatted replies on
  1296.             the control connection.  Note that RFC-959 (unlike earlier
  1297.             versions of the FTP spec) contains no provision for a
  1298.             "spontaneous" reply message.
  1299.             A Server-FTP SHOULD use the reply codes defined in RFC-959
  1300.             whenever they apply.  However, a server-FTP MAY use a
  1301.             different reply code when needed, as long as the general
  1302.             rules of Section 4.2 are followed. When the implementor has
  1303.             a choice between a 4xx and 5xx reply code, a Server-FTP
  1304.             SHOULD send a 4xx (temporary failure) code when there is any
  1305.             reasonable possibility that a failed FTP will succeed a few
  1306.             hours later.
  1307.             A User-FTP SHOULD generally use only the highest-order digit
  1308.             of a 3-digit reply code for making a procedural decision, to
  1309.             prevent difficulties when a Server-FTP uses non-standard
  1310.             reply codes.
  1311.             A User-FTP MUST be able to handle multi-line replies.  If
  1312.             the implementation imposes a limit on the number of lines
  1313.             and if this limit is exceeded, the User-FTP MUST recover,
  1314.             e.g., by ignoring the excess lines until the end of the
  1315.             multi-line reply is reached.
  1316.             A User-FTP SHOULD NOT interpret a 421 reply code ("Service
  1317.             not available, closing control connection") specially, but
  1318.             SHOULD detect closing of the control connection by the
  1319.             server.
  1320.             DISCUSSION:
  1321.                  Server implementations that fail to strictly follow the
  1322.                  reply rules often cause FTP user programs to hang.
  1323.                  Note that RFC-959 resolved ambiguities in the reply
  1324.                  rules found in earlier FTP specifications and must be
  1325.                  followed.
  1326.                  It is important to choose FTP reply codes that properly
  1327.                  distinguish between temporary and permanent failures,
  1328.                  to allow the successful use of file transfer client
  1329.                  daemons.  These programs depend on the reply codes to
  1330.                  decide whether or not to retry a failed transfer; using
  1331.                  a permanent failure code (5xx) for a temporary error
  1332.                  will cause these programs to give up unnecessarily.
  1333. Internet Engineering Task Force                                [Page 33]
  1334. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1335.                  When the meaning of a reply matches exactly the text
  1336.                  shown in RFC-959, uniformity will be enhanced by using
  1337.                  the RFC-959 text verbatim.  However, a Server-FTP
  1338.                  implementor is encouraged to choose reply text that
  1339.                  conveys specific system-dependent information, when
  1340.                  appropriate.
  1341.          4.1.2.12  Connections: RFC-959 Section 5.2
  1342.             The words "and the port used" in the second paragraph of
  1343.             this section of RFC-959 are erroneous (historical), and they
  1344.             should be ignored.
  1345.             On a multihomed server host, the default data transfer port
  1346.             (L-1) MUST be associated with the same local IP address as
  1347.             the corresponding control connection to port L.
  1348.             A user-FTP MUST NOT send any Telnet controls other than
  1349.             SYNCH and IP on an FTP control connection. In particular, it
  1350.             MUST NOT attempt to negotiate Telnet options on the control
  1351.             connection.  However, a server-FTP MUST be capable of
  1352.             accepting and refusing Telnet negotiations (i.e., sending
  1353.             DONT/WONT).
  1354.             DISCUSSION:
  1355.                  Although the RFC says: "Server- and User- processes
  1356.                  should follow the conventions for the Telnet
  1357.                  protocol...[on the control connection]", it is not the
  1358.                  intent that Telnet option negotiation is to be
  1359.                  employed.
  1360.          4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
  1361.             The following commands and options MUST be supported by
  1362.             every server-FTP and user-FTP, except in cases where the
  1363.             underlying file system or operating system does not allow or
  1364.             support a particular command.
  1365.                  Type: ASCII Non-print, IMAGE, LOCAL 8
  1366.                  Mode: Stream
  1367.                  Structure: File, Record*
  1368.                  Commands:
  1369.                     USER, PASS, ACCT,
  1370.                     PORT, PASV,
  1371.                     TYPE, MODE, STRU,
  1372.                     RETR, STOR, APPE,
  1373.                     RNFR, RNTO, DELE,
  1374.                     CWD,  CDUP, RMD,  MKD,  PWD,
  1375. Internet Engineering Task Force                                [Page 34]
  1376. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1377.                     LIST, NLST,
  1378.                     SYST, STAT,
  1379.                     HELP, NOOP, QUIT.
  1380.             *Record structure is REQUIRED only for hosts whose file
  1381.             systems support record structure.
  1382.             DISCUSSION:
  1383.                  Vendors are encouraged to implement a larger subset of
  1384.                  the protocol.  For example, there are important
  1385.                  robustness features in the protocol (e.g., Restart,
  1386.                  ABOR, block mode) that would be an aid to some Internet
  1387.                  users but are not widely implemented.
  1388.                  A host that does not have record structures in its file
  1389.                  system may still accept files with STRU R, recording
  1390.                  the byte stream literally.
  1391.       4.1.3  SPECIFIC ISSUES
  1392.          4.1.3.1  Non-standard Command Verbs
  1393.             FTP allows "experimental" commands, whose names begin with
  1394.             "X".  If these commands are subsequently adopted as
  1395.             standards, there may still be existing implementations using
  1396.             the "X" form.  At present, this is true for the directory
  1397.             commands:
  1398.                 RFC-959   "Experimental"
  1399.                   MKD        XMKD
  1400.                   RMD        XRMD
  1401.                   PWD        XPWD
  1402.                   CDUP       XCUP
  1403.                   CWD        XCWD
  1404.             All FTP implementations SHOULD recognize both forms of these
  1405.             commands, by simply equating them with extra entries in the
  1406.             command lookup table.
  1407.             IMPLEMENTATION:
  1408.                  A User-FTP can access a server that supports only the
  1409.                  "X" forms by implementing a mode switch, or
  1410.                  automatically using the following procedure: if the
  1411.                  RFC-959 form of one of the above commands is rejected
  1412.                  with a 500 or 502 response code, then try the
  1413.                  experimental form; any other response would be passed
  1414.                  to the user.
  1415. Internet Engineering Task Force                                [Page 35]
  1416. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1417.          4.1.3.2  Idle Timeout
  1418.             A Server-FTP process SHOULD have an idle timeout, which will
  1419.             terminate the process and close the control connection if
  1420.             the server is inactive (i.e., no command or data transfer in
  1421.             progress) for a long period of time.  The idle timeout time
  1422.             SHOULD be configurable, and the default should be at least 5
  1423.             minutes.
  1424.             A client FTP process ("User-PI" in RFC-959) will need
  1425.             timeouts on responses only if it is invoked from a program.
  1426.             DISCUSSION:
  1427.                  Without a timeout, a Server-FTP process may be left
  1428.                  pending indefinitely if the corresponding client
  1429.                  crashes without closing the control connection.
  1430.          4.1.3.3  Concurrency of Data and Control
  1431.             DISCUSSION:
  1432.                  The intent of the designers of FTP was that a user
  1433.                  should be able to send a STAT command at any time while
  1434.                  data transfer was in progress and that the server-FTP
  1435.                  would reply immediately with status -- e.g., the number
  1436.                  of bytes transferred so far.  Similarly, an ABOR
  1437.                  command should be possible at any time during a data
  1438.                  transfer.
  1439.                  Unfortunately, some small-machine operating systems
  1440.                  make such concurrent programming difficult, and some
  1441.                  other implementers seek minimal solutions, so some FTP
  1442.                  implementations do not allow concurrent use of the data
  1443.                  and control connections.  Even such a minimal server
  1444.                  must be prepared to accept and defer a STAT or ABOR
  1445.                  command that arrives during data transfer.
  1446.          4.1.3.4  FTP Restart Mechanism
  1447.             The description of the 110 reply on pp. 40-41 of RFC-959 is
  1448.             incorrect; the correct description is as follows.  A restart
  1449.             reply message, sent over the control connection from the
  1450.             receiving FTP to the User-FTP, has the format:
  1451.                 110 MARK ssss = rrrr
  1452.             Here:
  1453.             *    ssss is a text string that appeared in a Restart Marker
  1454. Internet Engineering Task Force                                [Page 36]
  1455. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1456.                  in the data stream and encodes a position in the
  1457.                  sender's file system;
  1458.             *    rrrr encodes the corresponding position in the
  1459.                  receiver's file system.
  1460.             The encoding, which is specific to a particular file system
  1461.             and network implementation, is always generated and
  1462.             interpreted by the same system, either sender or receiver.
  1463.             When an FTP that implements restart receives a Restart
  1464.             Marker in the data stream, it SHOULD force the data to that
  1465.             point to be written to stable storage before encoding the
  1466.             corresponding position rrrr.  An FTP sending Restart Markers
  1467.             MUST NOT assume that 110 replies will be returned
  1468.             synchronously with the data, i.e., it must not await a 110
  1469.             reply before sending more data.
  1470.             Two new reply codes are hereby defined for errors
  1471.             encountered in restarting a transfer:
  1472.               554 Requested action not taken: invalid REST parameter.
  1473.                  A 554 reply may result from a FTP service command that
  1474.                  follows a REST command.  The reply indicates that the
  1475.                  existing file at the Server-FTP cannot be repositioned
  1476.                  as specified in the REST.
  1477.               555 Requested action not taken: type or stru mismatch.
  1478.                  A 555 reply may result from an APPE command or from any
  1479.                  FTP service command following a REST command.  The
  1480.                  reply indicates that there is some mismatch between the
  1481.                  current transfer parameters (type and stru) and the
  1482.                  attributes of the existing file.
  1483.             DISCUSSION:
  1484.                  Note that the FTP Restart mechanism requires that Block
  1485.                  or Compressed mode be used for data transfer, to allow
  1486.                  the Restart Markers to be included within the data
  1487.                  stream.  The frequency of Restart Markers can be low.
  1488.                  Restart Markers mark a place in the data stream, but
  1489.                  the receiver may be performing some transformation on
  1490.                  the data as it is stored into stable storage.  In
  1491.                  general, the receiver's encoding must include any state
  1492.                  information necessary to restart this transformation at
  1493.                  any point of the FTP data stream.  For example, in TYPE
  1494. Internet Engineering Task Force                                [Page 37]
  1495. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1496.                  A transfers, some receiver hosts transform CR LF
  1497.                  sequences into a single LF character on disk.   If a
  1498.                  Restart Marker happens to fall between CR and LF, the
  1499.                  receiver must encode in rrrr that the transfer must be
  1500.                  restarted in a "CR has been seen and discarded" state.
  1501.                  Note that the Restart Marker is required to be encoded
  1502.                  as a string of printable ASCII characters, regardless
  1503.                  of the type of the data.
  1504.                  RFC-959 says that restart information is to be returned
  1505.                  "to the user".  This should not be taken literally.  In
  1506.                  general, the User-FTP should save the restart
  1507.                  information (ssss,rrrr) in stable storage, e.g., append
  1508.                  it to a restart control file.  An empty restart control
  1509.                  file should be created when the transfer first starts
  1510.                  and deleted automatically when the transfer completes
  1511.                  successfully.  It is suggested that this file have a
  1512.                  name derived in an easily-identifiable manner from the
  1513.                  name of the file being transferred and the remote host
  1514.                  name; this is analogous to the means used by many text
  1515.                  editors for naming "backup" files.
  1516.                  There are three cases for FTP restart.
  1517.                  (1)  User-to-Server Transfer
  1518.                       The User-FTP puts Restart Markers <ssss> at
  1519.                       convenient places in the data stream.  When the
  1520.                       Server-FTP receives a Marker, it writes all prior
  1521.                       data to disk, encodes its file system position and
  1522.                       transformation state as rrrr, and returns a "110
  1523.                       MARK ssss = rrrr" reply over the control
  1524.                       connection.  The User-FTP appends the pair
  1525.                       (ssss,rrrr) to its restart control file.
  1526.                       To restart the transfer, the User-FTP fetches the
  1527.                       last (ssss,rrrr) pair from the restart control
  1528.                       file, repositions its local file system and
  1529.                       transformation state using ssss, and sends the
  1530.                       command "REST rrrr" to the Server-FTP.
  1531.                  (2)  Server-to-User Transfer
  1532.                       The Server-FTP puts Restart Markers <ssss> at
  1533.                       convenient places in the data stream.  When the
  1534.                       User-FTP receives a Marker, it writes all prior
  1535.                       data to disk, encodes its file system position and
  1536. Internet Engineering Task Force                                [Page 38]
  1537. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1538.                       transformation state as rrrr, and appends the pair
  1539.                       (rrrr,ssss) to its restart control file.
  1540.                       To restart the transfer, the User-FTP fetches the
  1541.                       last (rrrr,ssss) pair from the restart control
  1542.                       file, repositions its local file system and
  1543.                       transformation state using rrrr, and sends the
  1544.                       command "REST ssss" to the Server-FTP.
  1545.                  (3)  Server-to-Server ("Third-Party") Transfer
  1546.                       The sending Server-FTP puts Restart Markers <ssss>
  1547.                       at convenient places in the data stream.  When it
  1548.                       receives a Marker, the receiving Server-FTP writes
  1549.                       all prior data to disk, encodes its file system
  1550.                       position and transformation state as rrrr, and
  1551.                       sends a "110 MARK ssss = rrrr" reply over the
  1552.                       control connection to the User.  The User-FTP
  1553.                       appends the pair (ssss,rrrr) to its restart
  1554.                       control file.
  1555.                       To restart the transfer, the User-FTP fetches the
  1556.                       last (ssss,rrrr) pair from the restart control
  1557.                       file, sends "REST ssss" to the sending Server-FTP,
  1558.                       and sends "REST rrrr" to the receiving Server-FTP.
  1559.       4.1.4  FTP/USER INTERFACE
  1560.          This section discusses the user interface for a User-FTP
  1561.          program.
  1562.          4.1.4.1  Pathname Specification
  1563.             Since FTP is intended for use in a heterogeneous
  1564.             environment, User-FTP implementations MUST support remote
  1565.             pathnames as arbitrary character strings, so that their form
  1566.             and content are not limited by the conventions of the local
  1567.             operating system.
  1568.             DISCUSSION:
  1569.                  In particular, remote pathnames can be of arbitrary
  1570.                  length, and all the printing ASCII characters as well
  1571.                  as space (0x20) must be allowed.  RFC-959 allows a
  1572.                  pathname to contain any 7-bit ASCII character except CR
  1573.                  or LF.
  1574. Internet Engineering Task Force                                [Page 39]
  1575. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1576.          4.1.4.2  "QUOTE" Command
  1577.             A User-FTP program MUST implement a "QUOTE" command that
  1578.             will pass an arbitrary character string to the server and
  1579.             display all resulting response messages to the user.
  1580.             To make the "QUOTE" command useful, a User-FTP SHOULD send
  1581.             transfer control commands to the server as the user enters
  1582.             them, rather than saving all the commands and sending them
  1583.             to the server only when a data transfer is started.
  1584.             DISCUSSION:
  1585.                  The "QUOTE" command is essential to allow the user to
  1586.                  access servers that require system-specific commands
  1587.                  (e.g., SITE or ALLO), or to invoke new or optional
  1588.                  features that are not implemented by the User-FTP.  For
  1589.                  example, "QUOTE" may be used to specify "TYPE A T" to
  1590.                  send a print file to hosts that require the
  1591.                  distinction, even if the User-FTP does not recognize
  1592.                  that TYPE.
  1593.          4.1.4.3  Displaying Replies to User
  1594.             A User-FTP SHOULD display to the user the full text of all
  1595.             error reply messages it receives.  It SHOULD have a
  1596.             "verbose" mode in which all commands it sends and the full
  1597.             text and reply codes it receives are displayed, for
  1598.             diagnosis of problems.
  1599.          4.1.4.4  Maintaining Synchronization
  1600.             The state machine in a User-FTP SHOULD be forgiving of
  1601.             missing and unexpected reply messages, in order to maintain
  1602.             command synchronization with the server.
  1603. Internet Engineering Task Force                                [Page 40]
  1604. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1605.       4.1.5   FTP REQUIREMENTS SUMMARY
  1606.                                            |               | | | |S| |
  1607.                                            |               | | | |H| |F
  1608.                                            |               | | | |O|M|o
  1609.                                            |               | |S| |U|U|o
  1610.                                            |               | |H| |L|S|t
  1611.                                            |               |M|O| |D|T|n
  1612.                                            |               |U|U|M| | |o
  1613.                                            |               |S|L|A|N|N|t
  1614.                                            |               |T|D|Y|O|O|t
  1615. FEATURE                                    |SECTION        | | | |T|T|e
  1616. -------------------------------------------|---------------|-|-|-|-|-|--
  1617. Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
  1618. File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
  1619. User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
  1620. Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
  1621.   PASV is per-transfer                     |4.1.2.6        |x| | | | |
  1622. NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
  1623. Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
  1624. SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
  1625. STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
  1626. Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
  1627.                                            |               | | | | | |
  1628. Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
  1629. Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
  1630.   New reply code following Section 4.2     |4.1.2.11       | | |x| | |
  1631. User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
  1632. User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
  1633. User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
  1634.                                            |               | | | | | |
  1635. Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
  1636. User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
  1637. User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
  1638. Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
  1639. Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
  1640. Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
  1641.     Configurable idle timeout              |4.1.3.2        | |x| | | |
  1642. Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
  1643. Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
  1644.                                            |               | | | | | |
  1645. Support TYPE:                              |               | | | | | |
  1646.   ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
  1647.   ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
  1648.   ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
  1649.   EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
  1650.   IMAGE                                    |4.1.2.1        |x| | | | |
  1651.   LOCAL 8                                  |4.1.2.1        |x| | | | |
  1652. Internet Engineering Task Force                                [Page 41]
  1653. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1654.   LOCAL m                                  |4.1.2.1        | | |x| | |2
  1655.                                            |               | | | | | |
  1656. Support MODE:                              |               | | | | | |
  1657.   Stream                                   |4.1.2.13       |x| | | | |
  1658.   Block                                    |959 3.4.2      | | |x| | |
  1659.                                            |               | | | | | |
  1660. Support STRUCTURE:                         |               | | | | | |
  1661.   File                                     |4.1.2.13       |x| | | | |
  1662.   Record                                   |4.1.2.13       |x| | | | |3
  1663.   Page                                     |4.1.2.3        | | | |x| |
  1664.                                            |               | | | | | |
  1665. Support commands:                          |               | | | | | |
  1666.   USER                                     |4.1.2.13       |x| | | | |
  1667.   PASS                                     |4.1.2.13       |x| | | | |
  1668.   ACCT                                     |4.1.2.13       |x| | | | |
  1669.   CWD                                      |4.1.2.13       |x| | | | |
  1670.   CDUP                                     |4.1.2.13       |x| | | | |
  1671.   SMNT                                     |959 5.3.1      | | |x| | |
  1672.   REIN                                     |959 5.3.1      | | |x| | |
  1673.   QUIT                                     |4.1.2.13       |x| | | | |
  1674.                                            |               | | | | | |
  1675.   PORT                                     |4.1.2.13       |x| | | | |
  1676.   PASV                                     |4.1.2.6        |x| | | | |
  1677.   TYPE                                     |4.1.2.13       |x| | | | |1
  1678.   STRU                                     |4.1.2.13       |x| | | | |1
  1679.   MODE                                     |4.1.2.13       |x| | | | |1
  1680.                                            |               | | | | | |
  1681.   RETR                                     |4.1.2.13       |x| | | | |
  1682.   STOR                                     |4.1.2.13       |x| | | | |
  1683.   STOU                                     |959 5.3.1      | | |x| | |
  1684.   APPE                                     |4.1.2.13       |x| | | | |
  1685.   ALLO                                     |959 5.3.1      | | |x| | |
  1686.   REST                                     |959 5.3.1      | | |x| | |
  1687.   RNFR                                     |4.1.2.13       |x| | | | |
  1688.   RNTO                                     |4.1.2.13       |x| | | | |
  1689.   ABOR                                     |959 5.3.1      | | |x| | |
  1690.   DELE                                     |4.1.2.13       |x| | | | |
  1691.   RMD                                      |4.1.2.13       |x| | | | |
  1692.   MKD                                      |4.1.2.13       |x| | | | |
  1693.   PWD                                      |4.1.2.13       |x| | | | |
  1694.   LIST                                     |4.1.2.13       |x| | | | |
  1695.   NLST                                     |4.1.2.13       |x| | | | |
  1696.   SITE                                     |4.1.2.8        | | |x| | |
  1697.   STAT                                     |4.1.2.13       |x| | | | |
  1698.   SYST                                     |4.1.2.13       |x| | | | |
  1699.   HELP                                     |4.1.2.13       |x| | | | |
  1700.   NOOP                                     |4.1.2.13       |x| | | | |
  1701.                                            |               | | | | | |
  1702. Internet Engineering Task Force                                [Page 42]
  1703. RFC1123                   FILE TRANSFER -- FTP              October 1989
  1704. User Interface:                            |               | | | | | |
  1705.   Arbitrary pathnames                      |4.1.4.1        |x| | | | |
  1706.   Implement "QUOTE" command                |4.1.4.2        |x| | | | |
  1707.   Transfer control commands immediately    |4.1.4.2        | |x| | | |
  1708.   Display error messages to user           |4.1.4.3        | |x| | | |
  1709.     Verbose mode                           |4.1.4.3        | |x| | | |
  1710.   Maintain synchronization with server     |4.1.4.4        | |x| | | |
  1711. Footnotes:
  1712. (1)  For the values shown earlier.
  1713. (2)  Here m is number of bits in a memory word.
  1714. (3)  Required for host with record-structured file system, optional
  1715.      otherwise.
  1716. Internet Engineering Task Force                                [Page 43]
  1717. RFC1123                  FILE TRANSFER -- TFTP              October 1989
  1718.    4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
  1719.       4.2.1  INTRODUCTION
  1720.          The Trivial File Transfer Protocol TFTP is defined in RFC-783
  1721.          [TFTP:1].
  1722.          TFTP provides its own reliable delivery with UDP as its
  1723.          transport protocol, using a simple stop-and-wait acknowledgment
  1724.          system.  Since TFTP has an effective window of only one 512
  1725.          octet segment, it can provide good performance only over paths
  1726.          that have a small delay*bandwidth product.  The TFTP file
  1727.          interface is very simple, providing no access control or
  1728.          security.
  1729.          TFTP's most important application is bootstrapping a host over
  1730.          a local network, since it is simple and small enough to be
  1731.          easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
  1732.          urged to support TFTP for booting.
  1733.       4.2.2  PROTOCOL WALK-THROUGH
  1734.          The TFTP specification [TFTP:1] is written in an open style,
  1735.          and does not fully specify many parts of the protocol.
  1736.          4.2.2.1  Transfer Modes: RFC-783, Page 3
  1737.             The transfer mode "mail" SHOULD NOT be supported.
  1738.          4.2.2.2  UDP Header: RFC-783, Page 17
  1739.             The Length field of a UDP header is incorrectly defined; it
  1740.             includes the UDP header length (8).
  1741.       4.2.3  SPECIFIC ISSUES
  1742.          4.2.3.1  Sorcerer's Apprentice Syndrome
  1743.             There is a serious bug, known as the "Sorcerer's Apprentice
  1744.             Syndrome," in the protocol specification.  While it does not
  1745.             cause incorrect operation of the transfer (the file will
  1746.             always be transferred correctly if the transfer completes),
  1747.             this bug may cause excessive retransmission, which may cause
  1748.             the transfer to time out.
  1749.             Implementations MUST contain the fix for this problem: the
  1750.             sender (i.e., the side originating the DATA packets) must
  1751.             never resend the current DATA packet on receipt of a
  1752. Internet Engineering Task Force                                [Page 44]
  1753. RFC1123                  FILE TRANSFER -- TFTP              October 1989
  1754.             duplicate ACK.
  1755.             DISCUSSION:
  1756.                  The bug is caused by the protocol rule that either
  1757.                  side, on receiving an old duplicate datagram, may
  1758.                  resend the current datagram.  If a packet is delayed in
  1759.                  the network but later successfully delivered after
  1760.                  either side has timed out and retransmitted a packet, a
  1761.                  duplicate copy of the response may be generated.  If
  1762.                  the other side responds to this duplicate with a
  1763.                  duplicate of its own, then every datagram will be sent
  1764.                  in duplicate for the remainder of the transfer (unless
  1765.                  a datagram is lost, breaking the repetition).  Worse
  1766.                  yet, since the delay is often caused by congestion,
  1767.                  this duplicate transmission will usually causes more
  1768.                  congestion, leading to more delayed packets, etc.
  1769.                  The following example may help to clarify this problem.
  1770.                      TFTP A                  TFTP B
  1771.                  (1)  Receive ACK X-1
  1772.                       Send DATA X
  1773.                  (2)                          Receive DATA X
  1774.                                               Send ACK X
  1775.                         (ACK X is delayed in network,
  1776.                          and  A times out):
  1777.                  (3)  Retransmit DATA X
  1778.                  (4)                          Receive DATA X again
  1779.                                               Send ACK X again
  1780.                  (5)  Receive (delayed) ACK X
  1781.                       Send DATA X+1
  1782.                  (6)                          Receive DATA X+1
  1783.                                               Send ACK X+1
  1784.                  (7)  Receive ACK X again
  1785.                       Send DATA X+1 again
  1786.                  (8)                          Receive DATA X+1 again
  1787.                                               Send ACK X+1 again
  1788.                  (9)  Receive ACK X+1
  1789.                       Send DATA X+2
  1790.                  (10)                         Receive DATA X+2
  1791.                                               Send ACK X+3
  1792.                  (11) Receive ACK X+1 again
  1793.                       Send DATA X+2 again
  1794.                  (12)                         Receive DATA X+2 again
  1795.                                               Send ACK X+3 again
  1796. Internet Engineering Task Force                                [Page 45]
  1797. RFC1123                  FILE TRANSFER -- TFTP              October 1989
  1798.                  Notice that once the delayed ACK arrives, the protocol
  1799.                  settles down to duplicate all further packets
  1800.                  (sequences 5-8 and 9-12).  The problem is caused not by
  1801.                  either side timing out, but by both sides
  1802.                  retransmitting the current packet when they receive a
  1803.                  duplicate.
  1804.                  The fix is to break the retransmission loop, as
  1805.                  indicated above.  This is analogous to the behavior of
  1806.                  TCP.  It is then possible to remove the retransmission
  1807.                  timer on the receiver, since the resent ACK will never
  1808.                  cause any action; this is a useful simplification where
  1809.                  TFTP is used in a bootstrap program.  It is OK to allow
  1810.                  the timer to remain, and it may be helpful if the
  1811.                  retransmitted ACK replaces one that was genuinely lost
  1812.                  in the network.  The sender still requires a retransmit
  1813.                  timer, of course.
  1814.          4.2.3.2  Timeout Algorithms
  1815.             A TFTP implementation MUST use an adaptive timeout.
  1816.             IMPLEMENTATION:
  1817.                  TCP retransmission algorithms provide a useful base to
  1818.                  work from.  At least an exponential backoff of
  1819.                  retransmission timeout is necessary.
  1820.          4.2.3.3  Extensions
  1821.             A variety of non-standard extensions have been made to TFTP,
  1822.             including additional transfer modes and a secure operation
  1823.             mode (with passwords).  None of these have been
  1824.             standardized.
  1825.          4.2.3.4  Access Control
  1826.             A server TFTP implementation SHOULD include some
  1827.             configurable access control over what pathnames are allowed
  1828.             in TFTP operations.
  1829.          4.2.3.5  Broadcast Request
  1830.             A TFTP request directed to a broadcast address SHOULD be
  1831.             silently ignored.
  1832.             DISCUSSION:
  1833.                  Due to the weak access control capability of TFTP,
  1834.                  directed broadcasts of TFTP requests to random networks
  1835. Internet Engineering Task Force                                [Page 46]
  1836. RFC1123                  FILE TRANSFER -- TFTP              October 1989
  1837.                  could create a significant security hole.
  1838.       4.2.4  TFTP REQUIREMENTS SUMMARY
  1839.                                                  |        | | | |S| |
  1840.                                                  |        | | | |H| |F
  1841.                                                  |        | | | |O|M|o
  1842.                                                  |        | |S| |U|U|o
  1843.                                                  |        | |H| |L|S|t
  1844.                                                  |        |M|O| |D|T|n
  1845.                                                  |        |U|U|M| | |o
  1846.                                                  |        |S|L|A|N|N|t
  1847.                                                  |        |T|D|Y|O|O|t
  1848. FEATURE                                          |SECTION | | | |T|T|e
  1849. -------------------------------------------------|--------|-|-|-|-|-|--
  1850. Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
  1851. Transfer modes:                                  |        | | | | | |
  1852.   netascii                                       |RFC-783 |x| | | | |
  1853.   octet                                          |RFC-783 |x| | | | |
  1854.   mail                                           |4.2.2.1 | | | |x| |
  1855.   extensions                                     |4.2.3.3 | | |x| | |
  1856. Use adaptive timeout                             |4.2.3.2 |x| | | | |
  1857. Configurable access control                      |4.2.3.4 | |x| | | |
  1858. Silently ignore broadcast request                |4.2.3.5 | |x| | | |
  1859. -------------------------------------------------|--------|-|-|-|-|-|--
  1860. -------------------------------------------------|--------|-|-|-|-|-|--
  1861. Internet Engineering Task Force                                [Page 47]
  1862. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  1863. 5.  ELECTRONIC MAIL -- SMTP and RFC-822
  1864.    5.1  INTRODUCTION
  1865.       In the TCP/IP protocol suite, electronic mail in a format
  1866.       specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
  1867.       Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
  1868.       While SMTP has remained unchanged over the years, the Internet
  1869.       community has made several changes in the way SMTP is used.  In
  1870.       particular, the conversion to the Domain Name System (DNS) has
  1871.       caused changes in address formats and in mail routing.  In this
  1872.       section, we assume familiarity with the concepts and terminology
  1873.       of the DNS, whose requirements are given in Section 6.1.
  1874.       RFC-822 specifies the Internet standard format for electronic mail
  1875.       messages.  RFC-822 supercedes an older standard, RFC-733, that may
  1876.       still be in use in a few places, although it is obsolete.  The two
  1877.       formats are sometimes referred to simply by number ("822" and
  1878.       "733").
  1879.       RFC-822 is used in some non-Internet mail environments with
  1880.       different mail transfer protocols than SMTP, and SMTP has also
  1881.       been adapted for use in some non-Internet environments.  Note that
  1882.       this document presents the rules for the use of SMTP and RFC-822
  1883.       for the Internet environment only; other mail environments that
  1884.       use these protocols may be expected to have their own rules.
  1885.    5.2  PROTOCOL WALK-THROUGH
  1886.       This section covers both RFC-821 and RFC-822.
  1887.       The SMTP specification in RFC-821 is clear and contains numerous
  1888.       examples, so implementors should not find it difficult to
  1889.       understand.  This section simply updates or annotates portions of
  1890.       RFC-821 to conform with current usage.
  1891.       RFC-822 is a long and dense document, defining a rich syntax.
  1892.       Unfortunately, incomplete or defective implementations of RFC-822
  1893.       are common.  In fact, nearly all of the many formats of RFC-822
  1894.       are actually used, so an implementation generally needs to
  1895.       recognize and correctly interpret all of the RFC-822 syntax.
  1896.       5.2.1  The SMTP Model: RFC-821 Section 2
  1897.          DISCUSSION:
  1898.               Mail is sent by a series of request/response transactions
  1899.               between a client, the "sender-SMTP," and a server, the
  1900. Internet Engineering Task Force                                [Page 48]
  1901. RFC1123                  MAIL -- SMTP & RFC-822             October 1989
  1902.               "receiver-SMTP".  These transactions pass (1) the message
  1903.               proper, which is composed of header and body, and (2) SMTP
  1904.               source and destination addresses, referred to as the
  1905.               "envelope".
  1906.               The SMTP programs are analogous to Message Transfer Agents
  1907.               (MTAs) of X.400.  There will be another level of protocol
  1908.               software, closer to the end user, that is responsible for
  1909.               composing and analyzing RFC-822 message headers; this
  1910.               component is known as the "User Agent" in X.400, and we
  1911.               use that term in this document.  There is a clear logical
  1912.               distinction between the User Agent and the SMTP
  1913.               implementation, since they operate on different levels of
  1914.               protocol.  Note, however, that this distinction is may not
  1915.               be exactly reflected the structure of typical
  1916.               implementations of Internet mail.  Often there is a
  1917.               program known as the "mailer" that implements SMTP and
  1918.               also some of the User Agent functions; the rest of the
  1919.               User Agent functions are included in a user interface used
  1920.               for entering and reading mail.
  1921.               The SMTP envelope is constructed at the originating site,
  1922.               typically by the User Agent when the message is first
  1923.               queued for the Sender-SMTP program.  The envelope
  1924.               addresses may be derived from information in the message
  1925.               header, supplied by the user interface (e.g., to implement
  1926.               a bcc: request), or derived from local configuration
  1927.               information (e.g., expansion of a mailing list).  The SMTP
  1928.               envelope cannot in general be re-derived from the header
  1929.               at a later stage in message delivery, so the envelope is
  1930.               transmitted separately from the message itself using the
  1931.               MAIL and RCPT commands of SMTP.
  1932.               The text of RFC-821 suggests that mail is to be delivered
  1933.               to an individual user at a host.  With the advent of the
  1934.               domain system and of mail routing using mail-exchange (MX)
  1935.               resource records, implementors should now think of
  1936.               delivering mail to a user at a domain, which may or may
  1937.               not be a particular host.  This DOES NOT change the fact
  1938.               that SMTP is a host-to-host mail exchange protocol.
  1939.       5.2.2  Canonicalization: RFC-821 Section 3.1
  1940.          The domain names that a Sender-SMTP sends in MAIL and RCPT
  1941.          commands MUST have been  "canonicalized," i.e., they must be
  1942.          fully-qualified principal names or domain literals, not
  1943.          nicknames or domain abbreviations.  A canonicalized name either
  1944.          identifies a host directly or is an MX name; it cannot be a
  1945. Internet Engineering Task Force                                [Page 49]