rfc1196.txt

RFC 的详细文档！

Network Working Group                                       D. Zimmerman
Request for Comments: 1196           Center for Discrete Mathematics and
Obsoletes: RFCs 1194, 742                   Theoretical Computer Science
                                                           December 1990


                  The Finger User Information Protocol

Status of this Memo

   This memo defines a protocol for the exchange of user information.
   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This memo describes the Finger User Information Protocol.  This is a
   simple protocol which provides an interface to a remote user
   information program.

   Based on RFC 742, a description of the original Finger protocol, this
   memo attempts to clarify the expected communication between the two
   ends of a Finger connection.  It also tries not to invalidate the
   many existing implementations or add unnecessary restrictions to the
   original protocol definition.  This edition corrects and clarifies in
   a minor way, RFC 1194.

Table of Contents

1.      Introduction  ...........................................   2
  1.1.    Intent  ...............................................   2
  1.2.    History  ..............................................   3
  1.3.    Requirements  .........................................   3
2.      Use of the protocol  ....................................   3
  2.1.    Flow of events  .......................................   3
  2.2.    Data format  ..........................................   4
  2.3.    Query specifications  .................................   4
  2.4.    RUIP {Q2} behavior  ...................................   4
  2.5.    Expected RUIP response  ...............................   5
    2.5.1.  {C} query  ..........................................   5
    2.5.2.  {U}{C} query  .......................................   6
    2.5.3.  {U} ambiguity  ......................................   6
    2.5.4.  /W query token  .....................................   6
    2.5.5.  Vending machines  ...................................   7
3.      Security  ...............................................   7



Zimmerman                                                       [Page 1]

RFC 1196                         Finger                    December 1990


  3.1.    Implementation security  ..............................   7
  3.2.    RUIP security  ........................................   7
    3.2.1.  {Q2} refusal  .......................................   7
    3.2.2.  {C} refusal  ........................................   8
    3.2.3.  Atomic discharge  ...................................   8
    3.2.4.  User information files  .............................   8
    3.2.5.  Execution of user programs  .........................   9
    3.2.6.  {U} ambiguity  ......................................   9
    3.2.7.  Audit trails  .......................................   9
  3.3.    Client security  ......................................   9
4.      Examples  ...............................................  10
  4.1.    Example with a null command line ({C})  ...............  10
  4.2.    Example with name specified ({U}{C})  .................  10
  4.3.    Example with ambiguous name specified ({U}{C})  .......  11
  4.4.    Example of query type {Q2} ({U}{H}{H}{C})  ............  11
5.      Acknowledgments  ........................................  12
6.      Security Considerations  ................................  12
7.      Author's Address  .......................................  12

1.  Introduction

1.1.  Intent

   This memo describes the Finger User Information Protocol.  This is a
   simple protocol which provides an interface to a remote user
   information program (RUIP).

   Based on RFC 742, a description of the original Finger protocol, this
   memo attempts to clarify the expected communication between the two
   ends of a Finger connection.  It also tries not to invalidate the
   many current implementations or add unnecessary restrictions to the
   original protocol definition.

   The most prevalent implementations of Finger today seem to be
   primarily derived from the BSD UNIX work at the University of
   California, Berkeley.  Thus, this memo is based around the BSD
   version's behavior.

   However, the BSD version provides few options to tailor the Finger
   RUIP for a particular site's security policy, or to protect the user
   from dangerous data.  Furthermore, there are MANY potential security
   holes that implementors and administrators need to be aware of,
   particularly since the purpose of this protocol is to return
   information about a system's users, a sensitive issue at best.
   Therefore, this memo makes a number of important security comments
   and recommendations.





Zimmerman                                                       [Page 2]

RFC 1196                         Finger                    December 1990


1.2.  History

   The FINGER program at SAIL, written by Les Earnest, was the
   inspiration for the NAME program on ITS.  Earl Killian at MIT and
   Brian Harvey at SAIL were jointly responsible for implementing the
   original protocol.

   Ken Harrenstien is the author of RFC 742, "Name/Finger", which this
   memo began life as.

1.3.  Requirements

   In this document, the words that are used to define the significance
   of each particular requirement are capitalized.  These words are:

   * "MUST"

      This word or the adjective "REQUIRED" means that the item is an
      absolute requirement of the specification.

   * "SHOULD"

      This word or the adjective "RECOMMENDED" means that there may
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before choosing a different course.

   * "MAY"

      This word or the adjective "OPTIONAL" means that this item is
      truly optional.  One vendor may choose to include the item because
      a particular marketplace requires it or because it enhances the
      product, for example; another vendor may omit the same item.

   An implementation is not compliant if it fails to satisfy one or more
   of the MUST requirements.  An implementation that satisfies all the
   MUST and all the SHOULD requirements is said to be "unconditionally
   compliant"; one that satisfies all the MUST requirements but not all
   the SHOULD requirements is said to be "conditionally compliant".

2.  Use of the protocol

2.1.  Flow of events

   Finger is based on the Transmission Control Protocol, using TCP port
   79 decimal (117 octal).  A TCP connection is opened to a remote host
   on the Finger port.  An RUIP becomes available on the remote end of
   the connection to process the request.  The RUIP is sent a one line



Zimmerman                                                       [Page 3]

RFC 1196                         Finger                    December 1990


   query based upon the Finger query specification.  The RUIP processes
   the query, returns an answer, then closes the connection normally.

2.2.  Data format

   Any data transferred MUST be in ASCII format, with no parity, and
   with lines ending in CRLF (ASCII 13 followed by ASCII 10).  This
   excludes other character formats such as EBCDIC, etc.  This also
   means that any characters between ASCII 128 and ASCII 255 should
   truly be international data, not 7-bit ASCII with the parity bit set.

2.3.  Query specifications

   An RUIP MUST accept the entire Finger query specification.

   The Finger query specification is defined:

        {Q1}    ::= [{U}] [/W] {C}

        {Q2}    ::= [{U}]{H} [/W] {C}

        {U}     ::= username

        {H}     ::= @hostname | @hostname{H}

        {C}     ::= <CRLF>

   {H}, being recursive, means that there is no arbitrary limit on the
   number of @hostname tokens in the query.  In examples of the {Q2}
   request specification, the number of @hostname tokens is limited to
   two, simply for brevity.

   Be aware that {Q1} and {Q2} do not refer to a user typing "finger
   user@host" from an operating system prompt.  It refers to the line
   that an RUIP actually receives.  So, if a user types "finger
   user@host<CRLF>", the RUIP on the remote host receives "user<CRLF>",
   which corresponds to {Q1}.

   As with anything in the IP protocol suite, "be liberal in what you
   accept".

2.4.  RUIP {Q2} behavior

   A query of {Q2} is a request to forward a query to another RUIP.  An
   RUIP MUST either provide or actively refuse this forwarding service
   (see section 3.2.1).  If an RUIP provides this service, it MUST
   conform to the following behavior:




Zimmerman                                                       [Page 4]

RFC 1196                         Finger                    December 1990


   Given that:

         Host <H1> opens a Finger connection <F1-2> to an RUIP on host
         <H2>.

         <H1> gives the <H2> RUIP a query <Q1-2> of type {Q2}
         (e.g., FOO@HOST1@HOST2).

   It should be derived that:

         Host <H3> is the right-most host in <Q1-2> (i.e., HOST2)

         Query <Q2-3> is the remainder of <Q1-2> after removing the
         right-most "@hostname" token in the query (i.e., FOO@HOST1)

   And so:

         The <H2> RUIP then must itself open a Finger connection <F2-3>
         to <H3>, using <Q2-3>.

         The <H2> RUIP must return any information received from <F2-3>
         to <H1> via <F1-2>.

         The <H2> RUIP must close <F1-2> in normal circumstances only
         when the <H3> RUIP closes <F2-3>.

2.5.  Expected RUIP response

   For the most part, the output of an RUIP doesn't follow a strict
   specification, since it is designed to be read by people instead of
   programs.  It should mainly strive to be informative.

   Output of ANY query is subject to the discussion in the security
   section.

2.5.1.  {C} query

   A query of {C} is a request for a list of all online users.  An RUIP
   MUST either answer or actively refuse (see section 3.2.2).  If it
   answers, then it MUST provide at least the user's full name.  The
   system administrator SHOULD be allowed to include other useful
   information (per section 3.2.3), such as:

      -    terminal location
      -    office location
      -    office phone number
      -    job name
      -    idle time (number of minutes since last typed input, or



Zimmerman                                                       [Page 5]

RFC 1196                         Finger                    December 1990


           since last job activity).

2.5.2.  {U}{C} query

   A query of {U}{C} is a request for in-depth status of a specified
   user {U}.  If you really want to refuse this service, you probably
   don't want to be running Finger in the first place.

   An answer MUST include at least the full name of the user.  If the
   user is logged in, at least the same amount of information returned
   by {C} for that user MUST also be returned by {U}{C}.

   Since this is a query for information on a specific user, the system
   administrator SHOULD be allowed to choose to return additional useful
   information (per section 3.2.3), such as:

      -    office location
      -    office phone number
      -    home phone number
      -    status of login (not logged in, logout time, etc)
      -    user information file

   A user information file is a feature wherein a user may leave a short
   message that will be included in the response to Finger requests.
   (This is sometimes called a "plan" file.)  This is easily implemented
   by (for example) having the program look for a specially named text
   file in the user's home directory or some common area; the exact
   method is left to the implementor.  The system administrator SHOULD
   be allowed to specifically turn this feature on and off.  See section
   3.2.4 for caveats.

   There MAY be a way for the user to run a program in response to a
   Finger query.  If this feature exists, the system administrator
   SHOULD be allowed to specifically turn it on and off.  See section
   3.2.5 for caveats.

2.5.3.  {U} ambiguity

   Allowable "names" in the command line MUST include "user names" or
   "login names" as defined by the system.  If a name is ambiguous, the
   system administrator SHOULD be allowed to choose whether or not all
   possible derivations should be returned in some fashion (per section
   3.2.6).

2.5.4.  /W query token

   The token /W in the {Q1} or {Q2} query types SHOULD at best be
   interpreted at the last RUIP to signify a higher level of verbosity



Zimmerman                                                       [Page 6]