home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1869 < prev    next >
Text File  |  1995-11-08  |  23KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               J. Klensin, WG Chair
  8. Request For Comments: 1869                                           MCI
  9. STD: 10                                                 N. Freed, Editor
  10. Obsoletes: 1651                             Innosoft International, Inc.
  11. Category: Standards Track                                        M. Rose
  12.                                             Dover Beach Consulting, Inc.
  13.                                                             E. Stefferud
  14.                                      Network Management Associates, Inc.
  15.                                                               D. Crocker
  16.                                                   Brandenburg Consulting
  17.                                                            November 1995
  18.  
  19.  
  20.                         SMTP Service Extensions
  21.  
  22. Status of this Memo
  23.  
  24.    This document specifies an Internet standards track protocol for the
  25.    Internet community, and requests discussion and suggestions for
  26.    improvements.  Please refer to the current edition of the "Internet
  27.    Official Protocol Standards" (STD 1) for the standardization state
  28.    and status of this protocol.  Distribution of this memo is unlimited.
  29.  
  30. 1.  Abstract
  31.  
  32.    This memo defines a framework for extending the SMTP service by
  33.    defining a means whereby a server SMTP can inform a client SMTP as to
  34.    the service extensions it supports.  Extensions to the SMTP service
  35.    are registered with the IANA. This framework does not require
  36.    modification of existing SMTP clients or servers unless the features
  37.    of the service extensions are to be requested or provided.
  38.  
  39. 2.  Introduction
  40.  
  41.    The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable,
  42.    effective basis for the relay function of message transfer agents.
  43.    Although a decade old, SMTP has proven remarkably resilient.
  44.    Nevertheless, the need for a number of protocol extensions has become
  45.    evident. Rather than describing these extensions as separate and
  46.    haphazard entities, this document enhances SMTP in a straightforward
  47.    fashion that provides a framework in which all future extensions can
  48.    be built in a single consistent way.
  49.  
  50. 3.  Framework for SMTP Extensions
  51.  
  52.    For the purpose of service extensions to SMTP, SMTP relays a mail
  53.    object containing an envelope and a content.
  54.  
  55.  
  56.  
  57.  
  58. Klensin, et al              Standards Track                     [Page 1]
  59.  
  60. RFC 1869                SMTP Service Extensions            November 1995
  61.  
  62.  
  63.  (1)   The SMTP envelope is straightforward, and is sent as a
  64.        series of SMTP protocol units: it consists of an
  65.        originator address (to which error reports should be
  66.        directed); a delivery mode (e.g., deliver to recipient
  67.        mailboxes); and, one or more recipient addresses.
  68.  
  69.  (2)   The SMTP content is sent in the SMTP DATA protocol unit
  70.        and has two parts: the headers and the body. The
  71.        headers form a collection of field/value pairs
  72.        structured according to RFC 822 [2], whilst the body,
  73.        if structured, is defined according to MIME [3]. The
  74.        content is textual in nature, expressed using the US
  75.        ASCII repertoire (ANSI X3.4-1986). Although extensions
  76.        (such as MIME) may relax this restriction for the
  77.        content body, the content headers are always encoded
  78.        using the US ASCII repertoire. The algorithm defined in
  79.        [4] is used to represent header values outside the US
  80.        ASCII repertoire, whilst still encoding them using the
  81.        US ASCII repertoire.
  82.  
  83.    Although SMTP is widely and robustly deployed, some parts of the
  84.    Internet community might wish to extend the SMTP service.  This memo
  85.    defines a means whereby both an extended SMTP client and server may
  86.    recognize each other as such and the server can inform the client as
  87.    to the service extensions that it supports.
  88.  
  89.    It must be emphasized that any extension to the SMTP service should
  90.    not be considered lightly. SMTP's strength comes primarily from its
  91.    simplicity.  Experience with many protocols has shown that:
  92.  
  93.      protocols with few options tend towards ubiquity, whilst
  94.      protocols with many options tend towards obscurity.
  95.  
  96.    This means that each and every extension, regardless of its benefits,
  97.    must be carefully scrutinized with respect to its implementation,
  98.    deployment, and interoperability costs. In many cases, the cost of
  99.    extending the SMTP service will likely outweigh the benefit.
  100.  
  101.    Given this environment, the framework for the extensions described in
  102.    this memo consists of:
  103.  
  104.  (1)   a new SMTP command (section 4)
  105.  
  106.  (2)   a registry of SMTP service extensions (section 5)
  107.  
  108.  (3)   additional parameters to the SMTP MAIL FROM and RCPT TO
  109.        commands (section 6).
  110.  
  111.  
  112.  
  113.  
  114. Klensin, et al              Standards Track                     [Page 2]
  115.  
  116. RFC 1869                SMTP Service Extensions            November 1995
  117.  
  118.  
  119. 4.  The EHLO command
  120.  
  121.    A client SMTP supporting SMTP service extensions should start an SMTP
  122.    session by issuing the EHLO command instead of the HELO command. If
  123.    the SMTP server supports the SMTP service extensions it will give a
  124.    successful response (see section 4.3), a failure response (see 4.4),
  125.    or an error response (4.5). If the SMTP server does not support any
  126.    SMTP service extensions it will generate an error response (see
  127.    section 4.5).
  128.  
  129. 4.1.  Changes to STD 10, RFC 821
  130.  
  131.    This specification is intended to extend STD 10, RFC 821 without
  132.    impacting existing services in any way.  The minor changes needed are
  133.    enumerated below.
  134.  
  135. 4.1.1.  First command
  136.  
  137.    RFC 821 states that the first command in an SMTP session must be the
  138.    HELO command. This requirement is hereby amended to allow a session
  139.    to start with either EHLO or HELO.
  140.  
  141. 4.1.2.  Maximum command line length
  142.  
  143.    This specification extends the SMTP MAIL FROM and RCPT TO to allow
  144.    additional parameters and parameter values.  It is possible that the
  145.    MAIL FROM and RCPT TO lines that result will exceed the 512 character
  146.    limit on command line length imposed by RFC 821.  This limit is
  147.    hereby amended to only apply to command lines without any parameters.
  148.    Each specification that defines new MAIL FROM or RCPT TO parameters
  149.    must also specify maximum parameter value lengths for each parameter
  150.    so that implementors of some set of extensions know how much buffer
  151.    space must be allocated. The maximum command length that must be
  152.    supported by an SMTP implementation with extensions is 512 plus the
  153.    sum of all the maximum parameter lengths for all the extensions
  154.    supported.
  155.  
  156. 4.2.  Command syntax
  157.  
  158.    The syntax for this command, using the ABNF notation of [2], is:
  159.  
  160.      ehlo-cmd ::= "EHLO" SP domain CR LF
  161.  
  162.    If successful, the server SMTP responds with code 250. On failure,
  163.    the server SMTP responds with code 550. On error, the server SMTP
  164.    responds with one of codes 500, 501, 502, 504, or 421.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Klensin, et al              Standards Track                     [Page 3]
  171.  
  172. RFC 1869                SMTP Service Extensions            November 1995
  173.  
  174.  
  175.    This command is issued instead of the HELO command, and may be issued
  176.    at any time that a HELO command would be appropriate.  That is, if
  177.    the EHLO command is issued, and a successful response is returned,
  178.    then a subsequent HELO or EHLO command will result in the server SMTP
  179.    replying with code 503.  A client SMTP must not cache any information
  180.    returned if the EHLO command succeeds. That is, a client SMTP must
  181.    issue the EHLO command at the start of each SMTP session if
  182.    information about extended facilities is needed.
  183.  
  184. 4.3.  Successful response
  185.  
  186.    If the server SMTP implements and is able to perform the EHLO
  187.    command, it will return code 250.  This indicates that both the
  188.    server and client SMTP are in the initial state, that is, there is no
  189.    transaction in progress and all state tables and buffers are cleared.
  190.  
  191.    Normally, this response will be a multiline reply. Each line of the
  192.    response contains a keyword and, optionally, one or more parameters.
  193.    The syntax for a positive response, using the ABNF notation of [2],
  194.    is:
  195.  
  196.      ehlo-ok-rsp  ::=      "250"    domain [ SP greeting ] CR LF
  197.                     / (    "250-"   domain [ SP greeting ] CR LF
  198.                         *( "250-"      ehlo-line           CR LF )
  199.                            "250"    SP ehlo-line           CR LF   )
  200.  
  201.                   ; the usual HELO chit-chat
  202.      greeting     ::= 1*<any character other than CR or LF>
  203.  
  204.      ehlo-line    ::= ehlo-keyword *( SP ehlo-param )
  205.  
  206.      ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
  207.  
  208.                   ; syntax and values depend on ehlo-keyword
  209.      ehlo-param   ::= 1*<any CHAR excluding SP and all
  210.                          control characters (US ASCII 0-31
  211.                          inclusive)>
  212.  
  213.      ALPHA        ::= <any one of the 52 alphabetic characters
  214.                        (A through Z in upper case, and,
  215.                         a through z in lower case)>
  216.      DIGIT        ::= <any one of the 10 numeric characters
  217.                        (0 through 9)>
  218.  
  219.      CR           ::= <the carriage-return character
  220.                        (ASCII decimal code 13)>
  221.      LF           ::= <the line-feed character
  222.                        (ASCII decimal code 10)>
  223.  
  224.  
  225.  
  226. Klensin, et al              Standards Track                     [Page 4]
  227.  
  228. RFC 1869                SMTP Service Extensions            November 1995
  229.  
  230.  
  231.      SP           ::= <the space character
  232.                        (ASCII decimal code 32)>
  233.  
  234.    Although EHLO keywords may be specified in upper, lower, or mixed
  235.    case, they must always be recognized and processed in a case-
  236.    insensitive manner. This is simply an extension of practices begun in
  237.    RFC 821.
  238.  
  239.    The IANA maintains a registry of SMTP service extensions.  Associated
  240.    with each such extension is a corresponding EHLO keyword value. Each
  241.    service extension registered with the IANA must be defined in an RFC.
  242.    Such RFCs must either be on the standards-track or must define an
  243.    IESG-approved experimental protocol.  The definition must include:
  244.  
  245.  (1)   the textual name of the SMTP service extension;
  246.  
  247.  (2)   the EHLO keyword value associated with the extension;
  248.  
  249.  (3)   the syntax and possible values of parameters associated
  250.        with the EHLO keyword value;
  251.  
  252.  (4)   any additional SMTP verbs associated with the extension
  253.        (additional verbs will usually be, but are not required
  254.        to be, the same as the EHLO keyword value);
  255.  
  256.  (5)   any new parameters the extension associates with the
  257.        MAIL FROM or RCPT TO verbs;
  258.  
  259.  (6)   how support for the extension affects the behavior of a
  260.        server and client SMTP; and,
  261.  
  262.  (7)   the increment by which the extension is increasing the
  263.        maximum length of the commands MAIL FROM, RCPT TO, or
  264.        both, over that specified in RFC 821.
  265.  
  266.    In addition, any EHLO keyword value that starts with an upper or
  267.    lower case "X" refers to a local SMTP service extension, which is
  268.    used through bilateral, rather than standardized, agreement. Keywords
  269.    beginning with "X" may not be used in a registered service extension.
  270.  
  271.    Any keyword values presented in the EHLO response that do not begin
  272.    with "X" must correspond to a standard, standards-track, or IESG-
  273.    approved experimental SMTP service extension registered with IANA.  A
  274.    conforming server must not offer non "X" prefixed keyword values that
  275.    are not described in a registered extension.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Klensin, et al              Standards Track                     [Page 5]
  283.  
  284. RFC 1869                SMTP Service Extensions            November 1995
  285.  
  286.  
  287.    Additional verbs are bound by the same rules as EHLO keywords;
  288.    specifically, verbs begining with "X" are local extensions that may
  289.    not be registered or standardized and verbs not beginning with "X"
  290.    must always be registered.
  291.  
  292. 4.4.  Failure response
  293.  
  294.    If for some reason the server SMTP is unable to list the service
  295.    extensions it supports, it will return code 554.
  296.  
  297.    In the case of a failure response, the client SMTP should issue
  298.    either the HELO or QUIT command.
  299.  
  300. 4.5.  Error responses from extended servers
  301.  
  302.    If the server SMTP recognizes the EHLO command, but the command
  303.    argument is unacceptable, it will return code 501.
  304.  
  305.    If the server SMTP recognizes, but does not implement, the EHLO
  306.    command, it will return code 502.
  307.  
  308.    If the server SMTP determines that the SMTP service is no longer
  309.    available (e.g., due to imminent system shutdown), it will return
  310.    code 421.
  311.  
  312.    In the case of any error response, the client SMTP should issue
  313.    either the HELO or QUIT command.
  314.  
  315. 4.6.  Responses from servers without extensions
  316.  
  317.    A server SMTP that conforms to RFC 821 but does not support the
  318.    extensions specified here will not recognize the EHLO command and
  319.    will consequently return code 500, as specified in RFC 821.  The
  320.    server SMTP should stay in the same state after returning this code
  321.    (see section 4.1.1 of RFC 821).  The client SMTP may then issue
  322.    either a HELO or a QUIT command.
  323.  
  324. 4.7.  Responses from improperly implemented servers
  325.  
  326.    Some SMTP servers are known to disconnect the SMTP transmission
  327.    channel upon receipt of the EHLO command. The disconnect can occur
  328.    immediately or after sending a response.  Such behavior violates
  329.    section 4.1.1 of RFC 821, which explicitly states that disconnection
  330.    should only occur after a QUIT command is issued.
  331.  
  332.    Nevertheless, in order to achieve maxmimum interoperablity it is
  333.    suggested that extended SMTP clients using EHLO be coded to check for
  334.    server connection closure after EHLO is sent, either before or after
  335.  
  336.  
  337.  
  338. Klensin, et al              Standards Track                     [Page 6]
  339.  
  340. RFC 1869                SMTP Service Extensions            November 1995
  341.  
  342.  
  343.    returning a reply.  If this happens the client must decide if the
  344.    operation can be successfully completed without using any SMTP
  345.    extensions. If it can a new connection can be opened and the HELO
  346.    command can be used.
  347.  
  348.    Other improperly-implemented servers will not accept a HELO command
  349.    after EHLO has been sent and rejected.  In some cases, this problem
  350.    can be worked around by sending a RSET after the failure response to
  351.    EHLO, then sending the HELO.  Clients that do this should be aware
  352.    that many implementations will return a failure code (e.g., 503 Bad
  353.    sequence of commands) in response to the RSET.  This code can be
  354.    safely ignored.
  355.  
  356. 5.  Initial IANA Registry
  357.  
  358.    The IANA's initial registry of SMTP service extensions consists of
  359.    these entries:
  360.  
  361.    Service Ext   EHLO Keyword Parameters Verb       Added Behavior
  362.    ------------- ------------ ---------- ---------- ------------------
  363.    Send             SEND         none       SEND    defined in RFC 821
  364.    Send or Mail     SOML         none       SOML    defined in RFC 821
  365.    Send and Mail    SAML         none       SAML    defined in RFC 821
  366.    Expand           EXPN         none       EXPN    defined in RFC 821
  367.    Help             HELP         none       HELP    defined in RFC 821
  368.    Turn             TURN         none       TURN    defined in RFC 821
  369.  
  370.    which correspond to those SMTP commands which are defined as optional
  371.    in [5].  (The mandatory SMTP commands, according to [5], are HELO,
  372.    MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.)
  373.  
  374. 6.  MAIL FROM and RCPT TO Parameters
  375.  
  376.    It is recognized that several of the extensions planned for SMTP will
  377.    make use of additional parameters associated with the MAIL FROM and
  378.    RCPT TO command. The syntax for these commands, again using the ABNF
  379.    notation of [2] as well as underlying definitions from [1], is:
  380.  
  381.      esmtp-cmd        ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF
  382.      esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter)
  383.      esmtp-parameter  ::= esmtp-keyword ["=" esmtp-value]
  384.      esmtp-keyword    ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
  385.  
  386.                           ; syntax and values depend on esmtp-keyword
  387.      esmtp-value      ::= 1*<any CHAR excluding "=", SP, and all
  388.                              control characters (US ASCII 0-31
  389.                              inclusive)>
  390.  
  391.  
  392.  
  393.  
  394. Klensin, et al              Standards Track                     [Page 7]
  395.  
  396. RFC 1869                SMTP Service Extensions            November 1995
  397.  
  398.  
  399.                           ; The following commands are extended to
  400.                           ; accept extended parameters.
  401.      inner-esmtp-cmd  ::= ("MAIL FROM:" reverse-path)   /
  402.                           ("RCPT TO:" forward-path)
  403.  
  404.    All esmtp-keyword values must be registered as part of the IANA
  405.    registration process described above. This definition only provides
  406.    the framework for future extension; no extended MAIL FROM or RCPT TO
  407.    parameters are defined by this RFC.
  408.  
  409. 6.1.  Error responses
  410.  
  411.    If the server SMTP does not recognize or cannot implement one or more
  412.    of the parameters associated with a particular MAIL FROM or RCPT TO
  413.    command, it will return code 555.
  414.  
  415.    If for some reason the server is temporarily unable to accomodate one
  416.    or more of the parameters associated with a MAIL FROM or RCPT TO
  417.    command, and if the definition of the specific parameter does not
  418.    mandate the use of another code, it should return code 455.
  419.  
  420.    Errors specific to particular parameters and their values will be
  421.    specified in the parameter's defining RFC.
  422.  
  423. 7.  Received: Header Field Annotation
  424.  
  425.    SMTP servers are required to add an appropriate Received: field to
  426.    the headers of all messages they receive. A "with ESMTP" clause
  427.    should be added to this field when any SMTP service extensions are
  428.    used. "ESMTP" is hereby added to the list of standard protocol names
  429.    registered with IANA.
  430.  
  431. 8.  Usage Examples
  432.  
  433.  (1)   An interaction of the form:
  434.  
  435.        S: <wait for connection on TCP port 25>
  436.        C: <open connection to server>
  437.        S: 220 dbc.mtview.ca.us SMTP service ready
  438.        C: EHLO ymir.claremont.edu
  439.        S: 250 dbc.mtview.ca.us says hello
  440.         ...
  441.  
  442.        indicates that the server SMTP implements only those
  443.        SMTP commands which are defined as mandatory in [5].
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Klensin, et al              Standards Track                     [Page 8]
  451.  
  452. RFC 1869                SMTP Service Extensions            November 1995
  453.  
  454.  
  455.  (2)   In contrast, an interaction of the form:
  456.  
  457.        S: <wait for connection on TCP port 25>
  458.        C: <open connection to server>
  459.        S: 220 dbc.mtview.ca.us SMTP service ready
  460.        C: EHLO ymir.claremont.edu
  461.        S: 250-dbc.mtview.ca.us says hello
  462.        S: 250-EXPN
  463.        S: 250-HELP
  464.        S: 250-8BITMIME
  465.        S: 250-XONE
  466.        S: 250 XVRB
  467.         ...
  468.  
  469.        indicates that the server SMTP also implements the SMTP
  470.        EXPN and HELP commands, one standard service extension
  471.        (8BITMIME), and two nonstandard and unregistered
  472.        service extensions (XONE and XVRB).
  473.  
  474.  (3)   Finally, a server that does not support SMTP service
  475.        extensions would act as follows:
  476.  
  477.        S: <wait for connection on TCP port 25>
  478.        C: <open connection to server>
  479.        S: 220 dbc.mtview.ca.us SMTP service ready
  480.        C: EHLO ymir.claremont.edu
  481.        S: 500 Command not recognized: EHLO
  482.         ...
  483.  
  484.        The 500 response indicates that the server SMTP does
  485.        not implement the extensions specified here.  The
  486.        client would normally send a HELO command and proceed
  487.        as specified in RFC 821.   See section 4.7 for
  488.        additional discussion.
  489.  
  490. 9.  Security Considerations
  491.  
  492.    This RFC does not discuss security issues and is not believed to
  493.    raise any security issues not already endemic in electronic mail and
  494.    present in fully conforming implementations of RFC-821.  It does
  495.    provide an announcement of server mail capabilities via the response
  496.    to the EHLO verb. However, all information provided by announcement
  497.    of any of the initial set of service extensions defined by this RFC
  498.    can be readily deduced by selective probing of the verbs required to
  499.    transport and deliver mail. The security implications of service
  500.    extensions described in other RFCs should be dealt with in those
  501.    RFCs.
  502.  
  503.  
  504.  
  505.  
  506. Klensin, et al              Standards Track                     [Page 9]
  507.  
  508. RFC 1869                SMTP Service Extensions            November 1995
  509.  
  510.  
  511. 10.  Acknowledgements
  512.  
  513.    This document represents a synthesis of the ideas of many people and
  514.    reactions to the ideas and proposals of others.  Randall Atkinson,
  515.    Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas
  516.    and text sufficient to be considered co-authors.  Other important
  517.    suggestions, text, or encouragement came from Harald Alvestrand, Jim
  518.    Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per
  519.    Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A.
  520.    Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan
  521.    Zachariassen, and the contributions of the entire IETF SMTP Working
  522.    Group. Of course, none of the individuals are necessarily responsible
  523.    for the combination of ideas represented here. Indeed, in some cases,
  524.    the response to a particular criticism was to accept the problem
  525.    identification but to include an entirely different solution from the
  526.    one originally proposed.
  527.  
  528. 11.  References
  529.  
  530.    [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  531.        USC/Information Sciences Institute, August 1982.
  532.  
  533.    [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  534.        Messages", STD 11, RFC 822, UDEL, August 1982.
  535.  
  536.    [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
  537.        Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
  538.  
  539.    [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
  540.        Headers", RFC 1522, University of Tennessee, September 1993.
  541.  
  542.    [5] Braden, R., "Requirements for Internet Hosts - Application and
  543.        Support", STD 3, RFC 1123, USC/Information Sciences Institute,
  544.        October 1989.
  545.  
  546. 12.  Chair, Editor, and Author Addresses
  547.  
  548.    John Klensin, WG Chair
  549.    MCI
  550.    2100 Reston Parkway
  551.    Reston, VA 22091
  552.  
  553.    Phone: +1 703 715-7361
  554.    Fax: +1 703 715-7436
  555.    EMail: klensin@mci.net
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Klensin, et al              Standards Track                    [Page 10]
  563.  
  564. RFC 1869                SMTP Service Extensions            November 1995
  565.  
  566.  
  567.    Ned Freed, Editor
  568.    Innosoft International, Inc.
  569.    1050 East Garvey Avenue South
  570.    West Covina, CA 91790
  571.    USA
  572.  
  573.    Phone: +1 818 919 3600
  574.    Fax: +1 818 919 3614
  575.    EMail: ned@innosoft.com
  576.  
  577.  
  578.    Marshall T. Rose
  579.    Dover Beach Consulting, Inc.
  580.    420 Whisman Court
  581.    Moutain View, CA  94043-2186
  582.    USA
  583.  
  584.    Phone: +1 415 968 1052
  585.    Fax: +1 415 968 2510
  586.    EMail: mrose@dbc.mtview.ca.us
  587.  
  588.  
  589.    Einar A. Stefferud
  590.    Network Management Associates, Inc.
  591.    17301 Drey Lane
  592.    Huntington Beach, CA, 92647-5615
  593.    USA
  594.  
  595.    Phone: +1 714 842 3711
  596.    Fax: +1 714 848 2091
  597.    EMail: stef@nma.com
  598.  
  599.  
  600.    Dave Crocker
  601.    Brandenburg Consulting
  602.    675 Spruce Dr.
  603.    Sunnyvale, CA 94086 USA
  604.    USA
  605.  
  606.    Phone: +1 408 246 8253
  607.    Fax: +1 408 249 6205
  608.    EMail: dcrocker@mordor.stanford.edu
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Klensin, et al              Standards Track                    [Page 11]
  619.  
  620.