home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1312.txt < prev    next >
Text File  |  1994-06-03  |  18KB  |  451 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          R. Nelson
  8. Request for Comments: 1312                               Crynwr Software
  9. Obsoletes: RFC 1159                                            G. Arnold
  10.                                                   Sun Microsystems, Inc.
  11.                                                               April 1992
  12.  
  13.  
  14.                         Message Send Protocol 2
  15.  
  16. Status of this Memo
  17.  
  18.    This memo defines an Experimental Protocol for the Internet
  19.    community.  Discussion and suggestions for improvement are requested.
  20.    Please refer to the current edition of the "IAB Official Protocol
  21.    Standards" for the standardization state and status of this protocol.
  22.    Distribution of this memo is unlimited.
  23.  
  24. Discussion
  25.  
  26.    The Message Send Protocol is used to send a short message to a given
  27.    user on a given terminal on a given host.  Unix's write command
  28.    offers a limited form of this service through its host-local write
  29.    command.  This service is also known on some hosts as "SEND".
  30.  
  31.    As the Internet grows, more and more people are using hosts that do
  32.    not run Internet protocols at all times.  These hosts may be able to
  33.    use a simple protocol that can be implemented using UDP and IP.  The
  34.    Message Send Protocol is one such protocol.
  35.  
  36.    Note that a message sending protocol is already defined using TCP.
  37.    The SMTP protocol includes a "SEND" command that will direct mail to
  38.    a user's terminal.  SMTP's SEND is not useful in this instance
  39.    because SMTP's SEND is not implemented by the majority of vendors at
  40.    this time, and is difficult to use by unskilled users.  For the
  41.    purposes of standardization, we will include a TCP based Message Send
  42.    Service.
  43.  
  44. Message Syntax
  45.  
  46.    The message consists of several parts, all of which must be present
  47.    The first part is a single octet indicating the protocol revision,
  48.    currently decimal 66, 'B'. The remaining parts are null-terminated
  49.    sequences of eight-bit characters in the ISO 8859/1 alphabet. Some
  50.    parts may be empty. All comparisons of parts (e.g., recipient,
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Nelson & Arnold                                                 [Page 1]
  59.  
  60. RFC 1312                Message Send Protocol 2               April 1992
  61.  
  62.  
  63.    cookie, etc.) are case-insensitive. The parts are as follows:
  64.  
  65.    RECIPIENT      The name of the user that the message is directed to.
  66.                   If this part is empty, the message may be delivered to
  67.                   any user of the destination system.
  68.  
  69.    RECIP-TERM     The name of the terminal to which the message is to be
  70.                   delivered. The syntax and semantics of terminal names
  71.                   are outside the scope of this specification. If this
  72.                   part is empty, the "right" terminal is chosen. This is
  73.                   a system-dependent function.  If this part consists of
  74.                   the string "*", all terminals on the destination
  75.                   system are implied.  If the RECIPIENT part is empty
  76.                   but the RECIP-TERM is not, the message is written on
  77.                   the specified terminal.  If both the RECIPIENT and
  78.                   RECIP-TERM parts are empty, the message should be
  79.                   written on the "console", which is defined as some
  80.                   place where the message is most likely to be seen by a
  81.                   human operator or administrator.
  82.  
  83.    MESSAGE        The actual message. The server need not preserve the
  84.                   formatting and white-space content of the message if
  85.                   this is necessary to display it.  New lines should be
  86.                   represented using the usual Netascii CR + LF.
  87.                   (Following the Internet tradition, a server should
  88.                   probably be prepared to accept a message in which some
  89.                   other end-of-line convention is followed, but a
  90.                   conforming client must use CR + LF.)
  91.  
  92.                   The message text may only contain printable characters
  93.                   from the ISO 8859/1 set, which is upward compatible
  94.                   from USASCII, plus CR, LF and TAB. No other control
  95.                   codes or escape sequences may be included: the client
  96.                   should strip them from the message before it is
  97.                   transmitted, and the server must check each incoming
  98.                   message for illegal codes. (A server may choose to
  99.                   display the message after stripping out such codes, or
  100.                   may reject the entire message.) If the MESSAGE part is
  101.                   empty, the message may be discarded by the server.
  102.  
  103.    SENDER         The username of the sender. (This and subsequent parts
  104.                   were not present in version 1 of the Message Send
  105.                   Protocol.) This part should not be empty. A server may
  106.                   choose to accept, reject or ignore messages in which
  107.                   the SENDER part is empty.
  108.  
  109.    SENDER-TERM    The name of the sending user's terminal. This part may
  110.                   be empty. The intention is that a recipient may reply
  111.  
  112.  
  113.  
  114. Nelson & Arnold                                                 [Page 2]
  115.  
  116. RFC 1312                Message Send Protocol 2               April 1992
  117.  
  118.  
  119.                   to a message by sending the reply to the user SENDER
  120.                   at terminal SENDER-TERM on the originating system.
  121.                   (The sender's hostname should be retrieved from the
  122.                   transport software.)
  123.  
  124.    COOKIE         A magic cookie. This part must be present in all
  125.                   messages, but is only of significance for the UDP
  126.                   service. The combination of the sender's UDP port
  127.                   number and this cookie should be unique. A client may
  128.                   elect to transmit a particular message several times
  129.                   to increase the chances of its reception; a server may
  130.                   use the cookie and port to identify duplicate messages
  131.                   and discard them. A reasonable cookie is the time of
  132.                   day represented in a readable format. The maximum
  133.                   length of a cookie is 32 octets, excluding the
  134.                   terminating null.
  135.  
  136.    SIGNATURE      A token which, if present, may be used by the server
  137.                   to verify the identity of the sender. The use of the
  138.                   SIGNATURE part is discussed further in the section on
  139.                   Security, below.
  140.  
  141.  
  142.    The total length of the message shall be less than 512 octets.  This
  143.    includes all eight parts, and any terminating nulls.  UDP packets are
  144.    limited to 512 octets.
  145.  
  146.    If this protocol is changed, the revision number will be changed.
  147.  
  148.    TCP Based Message Send Service
  149.  
  150.    One Message Send Service is defined as a connection based application
  151.    on TCP.  A server listens for TCP connections on TCP port 18.  Once a
  152.    connection is established a message is sent by the client over the
  153.    connection.
  154.  
  155.    The server replies with a single character indicating positive ("+")
  156.    or negative ("-") acknowledgment, immediately followed by an optional
  157.    message of explanation, terminated with a null.  The positive
  158.    acknowledgement means that the message was successfully delivered to
  159.    some user/terminal, and that the negative acknowledgement means that
  160.    the message was NOT delivered to any terminal.
  161.  
  162.    The positive acknowledgement message can contain information about
  163.    what user and terminal the message was delivered to in the case of
  164.    incomplete user/terminal fields in the message.  The negative
  165.    acknowledgement can contain information about WHY the message was not
  166.    delivered (no such user/terminal, system failure, user doesn't accept
  167.  
  168.  
  169.  
  170. Nelson & Arnold                                                 [Page 3]
  171.  
  172. RFC 1312                Message Send Protocol 2               April 1992
  173.  
  174.  
  175.    messages, etc).
  176.  
  177.    Multiple messages can be sent over the same channel.  The client
  178.    should close first (the server may/should not close directly after
  179.    the acknowledgement is sent) and the server may close after some
  180.    timeout on the order of minutes. If the sever is unable to decode a
  181.    message, or no message is received within a suitable timeout, it may
  182.    close the channel (on the assumption that the sender may have
  183.    formatted the data incorrectly).
  184.  
  185.    UDP Based Message Send Service
  186.  
  187.    Another Message Send Service is defined as a datagram based
  188.    application on UDP.  A server listens for UDP datagrams on UDP port
  189.    18.  When a datagram is received by the server, an answering datagram
  190.    may be sent back to the client.  If the message was addressed to a
  191.    particular user (i.e., the RECIPIENT part was non-empty) and was
  192.    successfully delivered to that user, a positive acknowledgement
  193.    should be sent (as described above). If the message was directed at
  194.    any user (i.e., the RECIPIENT part is empty), or if the message could
  195.    not be delivered for some reason, no reply is sent.
  196.  
  197.    The reason for this policy is that the UDP service may be used to
  198.    broadcast messages addressed to a particular user on an unknown
  199.    system or all users on all systems. In either case, it is
  200.    inappropriate for all servers to send replies. An alternative
  201.    approach might have been to require that a server only send a reply
  202.    if a message was addressed explicitly to that system and was not
  203.    broadcast. Unfortunately, the most popular network programming API
  204.    does not provide an easy way for an application to determine this;
  205.    furthermore such a policy would provide no feedback to the sender of
  206.    a broadcast message to a particular recipient. The approach adopted
  207.    here provides a reasonable compromise.
  208.  
  209.    Example of Message Encoding
  210.  
  211.    Consider a situation in which the user "sandy" is logged into the
  212.    console of system "alpha", and wishes to send a message to the user
  213.    "chris". "chris" is known to be logged in on the system "beta" but
  214.    the exact terminal is unknown. The message consists of two lines of
  215.    text, "Hi" followed by "How about lunch?".
  216.  
  217.    The message would be encoded as follows:
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Nelson & Arnold                                                 [Page 4]
  227.  
  228. RFC 1312                Message Send Protocol 2               April 1992
  229.  
  230.  
  231.  
  232.  
  233.              +--------+---------+---------+---------+
  234.            0 |    B   |    c    |    h    |    r    |
  235.              +--------+---------+---------+---------+
  236.            4 |    i   |    s    |  <NULL> |  <NULL> |
  237.              +--------+---------+---------+---------+
  238.            8 |    H   |    i    |   <CR>  |   <LF>  |
  239.              +--------+---------+---------+---------+
  240.           12 |    H   |    o    |    w    |         |
  241.              +--------+---------+---------+---------+
  242.           16 |    a   |    b    |    o    |    u    |
  243.              +--------+---------+---------+---------+
  244.           20 |    t   |         |    l    |    u    |
  245.              +--------+---------+---------+---------+
  246.           24 |    n   |    c    |    h    |    ?    |
  247.              +--------+---------+---------+---------+
  248.           28 |  <NULL>|    s    |    a    |    n    |
  249.              +--------+---------+---------+---------+
  250.           32 |    d   |    y    |  <NULL> |    c    |
  251.              +--------+---------+---------+---------+
  252.           36 |    o   |    n    |    s    |    o    |
  253.              +--------+---------+---------+---------+
  254.           40 |    l   |    e    |  <NULL> |    9    |
  255.              +--------+---------+---------+---------+
  256.           44 |    1   |    0    |    8    |    0    |
  257.              +--------+---------+---------+---------+
  258.           48 |    6   |    1    |    2    |    1    |
  259.              +--------+---------+---------+---------+
  260.           52 |    3   |    2    |    5    |  <NULL> |
  261.              +--------+---------+---------+---------+
  262.           56 | <NULL> |
  263.              +--------+
  264.  
  265.  
  266.    Note that the RECIP-TERM  and SIGNATURE parts are empty. The COOKIE
  267.    is the string "910806121325", which in this implementation indicates
  268.    that the message was sent at 12:13:25 on the 6th of August, 1991.
  269.    The identity if the sending and receiving systems is not included in
  270.    the message; the server must obtain this information from the
  271.    transport service.
  272.  
  273.    Advisories
  274.  
  275.    Client and server implementations must follow the character set
  276.    restrictions noted in the MESSAGE part description. Failure to do so
  277.    may have undesirable effects on the operation of the receiver's
  278.    terminal; more seriously, it may open up a significant security
  279.  
  280.  
  281.  
  282. Nelson & Arnold                                                 [Page 5]
  283.  
  284. RFC 1312                Message Send Protocol 2               April 1992
  285.  
  286.  
  287.    "hole". The checks must be made on any part of the message which may
  288.    be displayed, including the sender's name and terminal.  This is one
  289.    case where the admonition to "be liberal in what you accept" is not
  290.    applicable. A server may chose to apply additional checks to an
  291.    incoming message, and to reject any message which may pose a security
  292.    risk. For example, a system using a PostScript-based display may
  293.    reject a message which might be interpreted as an executable
  294.    PostScript program.
  295.  
  296.    The underlying transport, whether TCP or UDP, is expected to provide
  297.    checksums for the message and any response.
  298.  
  299.    The semantics of the various RECIPIENT and RECIP-TERM combinations
  300.    may be confusing. The introduction of the "*" wildcard designation in
  301.    the RECIP-TERM part makes it possible to send a message to all
  302.    terminals on the designated system (if RECIPIENT is empty), or to all
  303.    terminals at which a particular recipient has logged in.
  304.  
  305.    A positive acknowledgement may indicate only that the Message Send
  306.    server was able to successfully invoke a local message delivery
  307.    service. It may not be possible for true end-to-end semantics to be
  308.    inferred.
  309.  
  310.    For example, a Message Send server may employ a local delivery
  311.    mechanism which calls upon the services of a window system to display
  312.    the message in a pop-up window. This process may take some
  313.    significant time to complete, and it is unclear whether it is useful
  314.    for the server to wait for an indeterminate period before returning
  315.    an acknowledgement.  Therefore, this specification does not prescribe
  316.    whether the acknowledgement is associated with delivery of the
  317.    message to the local service, the display of the message, or
  318.    confirmation by the user that the message has been read by, e.g.,
  319.    dismissing the pop-up window.
  320.  
  321. Security Considerations
  322.  
  323.    Those who plan to implement this service must ensure that the
  324.    following issues are reflected in the documentation of their
  325.    products, and that their implementations include sufficient
  326.    configuration controls to allow systems and network administrators to
  327.    achieve the appropriate levels of usability and security.
  328.  
  329.    First, this service may allow someone to write on a user's terminal
  330.    without the user giving his or her permission.  Where possible, users
  331.    should be provided with a mechanism for disabling this.
  332.  
  333.    Second, it is extremely important for implementors to observe the
  334.    rules for filtering message text as discussed under Message Syntax
  335.  
  336.  
  337.  
  338. Nelson & Arnold                                                 [Page 6]
  339.  
  340. RFC 1312                Message Send Protocol 2               April 1992
  341.  
  342.  
  343.    above. Failure to do this may introduce major security holes.
  344.  
  345.    The third issue concerns the verification of the sender's identity.
  346.    If the recipient is fooled into believing that a message is from a
  347.    particular user, various security issues may arise. For example, the
  348.    recipient may send a reply containing confidential material.
  349.  
  350.    This service is primarily intended for "open" environments:
  351.    controlled local area networks used by reasonably trusted
  352.    participants, in which security considerations may be relaxed in the
  353.    interests of ease of use and administration. In such an environment
  354.    it is appropriate to trust the user name and source IP address as
  355.    identifying the actual sender of the message.
  356.  
  357.    Within more security-conscious environments, this assumption is
  358.    probably unacceptable. As has been widely noted, there is no way
  359.    within the current Internet architecture to ensure that the source
  360.    address of an IP datagram is correct. Hence it is entirely possible
  361.    for someone to spoof the IP address.
  362.  
  363.    The obvious, and simplest, answer is to disallow the use of this
  364.    protocol in such situations.  However a more constructive approach is
  365.    to incorporate within the protocol some mechanism by which a server
  366.    can reliably identify the sender.
  367.  
  368.    In this version of the protocol specification, we define a SIGNATURE
  369.    part within a message. If this part is empty, the identity of the
  370.    sender cannot be verified, and the server implementation may elect to
  371.    reject all such requests.  If the part is not empty, it is treated as
  372.    a case-insensitive text encoding of some security token. This RFC
  373.    does not define the encoding or interpretation of this token. We
  374.    expect that such matters will form part of future RFCs on security
  375.    and privacy issues; at an appropriate time, this RFC will be re-
  376.    issued to include references to these RFCs.
  377.  
  378. Acknowledgements
  379.  
  380.    PostScript is a trademark of Adobe Systems, Inc.
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Nelson & Arnold                                                 [Page 7]
  395.  
  396. RFC 1312                Message Send Protocol 2               April 1992
  397.  
  398.  
  399. Authors' Addresses
  400.  
  401.    Russell Nelson
  402.    Crynwr Software
  403.    11 Grant St.
  404.    Potsdam, NY 13676
  405.  
  406.    Phone:  (315) 268-1925
  407.    EMail:  nelson@crynwr.com
  408.  
  409.  
  410.    Geoff Arnold
  411.    Sun Microsystems, Inc.
  412.    2 Federal Street
  413.    Billerica, MA 01821
  414.  
  415.    Phone:  (508) 671-0317
  416.    EMail:  geoff@east.sun.com
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Nelson & Arnold                                                 [Page 8]
  451.