rfc1861.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

SEND                          -->
                              <--  860 00321 1234 Message Delivered
QUIT                          -->
                              <--  221 OK, Goodbye

4.2 General Response Code Theory

   Before discussing specific SNPP transactions, it may be helpful to
   discuss some of the response codes.  As mentioned previously, every
   response from the SNPP server to the client contains a 3 digit code
   that categorizes the response. Several of these codes fall into the



Gwinn                        Informational                     [Page 6]

RFC 1861                   SNPP - Version 3                October 1995


   "general" category, and may occur more frequently throughout a given
   SNPP transaction. There are some lesser used (somewhat transaction
   specific) responses that will be discussed in conjunction with the
   format of a specific command.

4.2.1 Code 214 - Multi-line "help/info" message

   This code prefixes a line of response information (such as in
   response to the HELP command).  It should be terminated with a "250
   OK" message.  This code is used when the response will take more than
   one line to display.

4.2.2 Code 218 - Single-line "help/info" message

   This code prefixes a single line of response information (such as the
   request for a single database entry).  Unlike the 214 series, it has
   no "250" series terminator.

4.2.3 Code 250 - Successful Transaction

   This code is a general positive acknowledgment from the server
   indicating that a command was successfully processed. Additionally,
   code 250 can appear at the end of the response to a HELP command (214
   series commands--discussed below).

4.2.4 Code 421 - Fatal Error, Connection Terminated

   This code is displayed just prior to the SNPP server terminating a
   connection with a client for errors. Such a connection termination
   may occur at any time and for any reason (administrative or
   technical).

4.2.5 Code 500 - Command Not Implemented

   This code is a "fail but continue code" that appears when an illegal
   command is entered.

4.2.6 Code 503 - Duplicate Command Entry; Already Entered That

   This code indicates that the specified information has already been
   entered.  This code would appear, for instance, if the client
   attempted to enter a MESSage command after specifying a "DATA"
   sequence.

4.2.7 Codes 550 and 554 - Transaction Failed, but Continue

   These codes indicate a failed command, but the session is allowed to
   continue.  A 550 code should be used to indicate a more



Gwinn                        Informational                     [Page 7]

RFC 1861                   SNPP - Version 3                October 1995


   "administrative" failure (such as an invalid pager ID, or illegal
   parameter), while a 554 series indicates a more technical reason
   (such as a gateway down or equipment failure).  In addition to the
   specified failure codes, additional 550 and 554 failures may be
   specified as necessary to allow for greater flexibility.

4.2.8 Code 552 - Maximum Entries Exceeded

   This code is in response to the entry of the "n+1" item when the
   server only permits "n" items in a category.  As an example, the
   client would expect to see this message when trying to enter the 6th
   PAGEr command when the terminal only supported 5.

4.3 Level 1 Commands

   Level one commands are designed as a minimum implementation of the
   protocol.  This collection of commands may be used with either
   TAP/IXO or TME for message delivery to the paging terminal.

4.3.1 PAGEr <Pager ID>

   The PAGEr command submits a pager ID (PID) number, for inclusion in
   the next messaging transaction.  The PID used must reside in, and be
   validated by the paging terminal.  Limited validation may optionally
   be done on the server (such as all numeric, and ID length), or
   validation can be left up to the terminal at the time the page is
   sent.

   When implementing SNPP, the user may elect to support multiple
   recipients per message sent.  However, be wary that validation-
   prior-to-sending is not possible with TAP/IXO (and is not an official
   option of the current TME specification).  What this means is that in
   order to validate a PID, one must generate a message to the pager.
   The terminal responds favorably or negatively.  When reporting
   failure of a single PID in a sequence, delineating and reporting the
   failure in a "standard format" may prove to be a challenge.

   Possible responses from the SNPP server, with suggested text, in
   response to a PAGEr command are:

    250 Pager ID Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    550 Error, Invalid Pager ID
    554 Error, failed (technical reason)

   Both level 2 and level 3 enhancements affect the PAGEr command.
   Please refer to the appropriate section(s) for details.



Gwinn                        Informational                     [Page 8]

RFC 1861                   SNPP - Version 3                October 1995


4.3.2 MESSage <Alpha or Numeric Message>

   The MESSage command specifies a single-line message, into the
   gateway.  Limited validation of the message may be done on the SNPP
   server (such as length), but type-of-message validation should be
   done by the paging terminal.  Duplicating the MESSage command before
   SENDing the message should produce an "503 ERROR, Message Already
   Entered" message, and allow the user to continue.

   Possible responses from the SNPP server, with suggested text, in
   response to a MESSage command are:

    250 Message OK
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    503 ERROR, Message Already Entered
    550 ERROR, Invalid Message
    554 Error, failed (technical reason)

4.3.3 RESEt

   The RESEt command clears already entered information from the server
   session, resetting it to the state of a freshly opened connection.
   This is provided, primarily, as a means to reset accidentally entered
   information during a manual session.

   Possible responses from the SNPP server, with suggested text, in
   response to a RESEt command are:

    250 RESET OK
    421 Too Many Errors, Goodbye (terminate connection
    421 Gateway Service Unavailable (terminate connection)

4.3.4 SEND

   The SEND command finalizes the current message transaction, and
   processes the page to the paging terminal.  Prior to processing, the
   PAGEr and MESSage fields (or message DATA when using the level two
   option) should be checked for the existence of information.  Should
   one of these required fields be missing, the server should respond
   "503 Error, Incomplete Information" and allow the user to continue.
   Assuming that the information is complete, the SNPP server should
   format and send the page to the paging terminal, and await a
   response.

   Possible responses from the SNPP server, with suggested text, in
   response to a SEND command are:




Gwinn                        Informational                     [Page 9]

RFC 1861                   SNPP - Version 3                October 1995


    250 Message Sent Successfully
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    503 Error, Pager ID or Message Incomplete
    554 Message Failed [non-administrative reason]

   Or, in the case of an illegal or non-existent pager ID, or some other
   administrative reason for rejecting the page, the server should
   respond:

    550 Failed, Illegal Pager ID (or other explanation)

   After processing a SEND command, the server should remain online to
   allow the client to submit another transaction.

   Level 3 enhancements to this command allow for other responses.
   Please refer to the appropriate section for discussion.

4.3.5 QUIT

   The QUIT command terminates the current session.  The server should
   simply respond:

    221 OK, Goodbye"

   and close the connection.

4.3.6 HELP (optional)

   The optional HELP command displays a screen of information about
   commands that are valid on the SNPP server.  This is primarily to
   assist manual users of the gateway.  Each line of the HELP screen
   (responses) are preceded by a code "214".  At the end of the HELP
   sequence, a "250" series message is issued.

   Possible responses from the SNPP server, with suggested text, in
   response to a HELP command are:

    214 [Help Text]  (repeated for each line of information)
    250 End of Help Information
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented

4.4 Level 2 - Minimum Extensions

   This section specifies minimum enhancements to the SNPP protocol for
   added functionality.



Gwinn                        Informational                    [Page 10]

RFC 1861                   SNPP - Version 3                October 1995


4.4.1 DATA

   The DATA command is an alternate form of the MESSage command,
   allowing for multiple line delivery of a message to the paging
   terminal.  This command's function is similar to the DATA command
   implemented in SMTP (Internet STD10, RFC821).  The SNPP server should
   only allow one DATA or MESSage command to be issued prior to a SEND.

   Possible responses from the SNPP server, with suggested text, in
   response to a DATA command are:

    354 Begin Input; End with <CRLF>'.'<CRLF>
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    503 ERROR, Message Already Entered
    500 Command Not Implemented
    550 ERROR, failed (administrative reason)
    554 ERROR, failed (technical reason)

   Upon receiving a "354" response, the client begins line input of the
   message to send to the pager.  A single period ("."), in the first
   position of the line, terminates input.  After input, the server may
   respond:

    250 Message OK
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    550 ERROR, Invalid Message (or administrative reason)
    554 ERROR, Failed (technical reason)

4.5 Level 2 - Optional Extensions

   This section discusses enhancements to the SNPP protocol for more
   control over paging functions.  These are primarily designed to
   mirror the added functionality built into the Telocator Message Entry
   (TME) protocol as specified in the TDP protocol suite. These
   functions may, optionally (as is being done by the author), be
   integrated into a paging terminal.  There is no requirement to
   implement all of these functions.  Requests for invalid functions
   should return a "500 Function Not Implemented" error.

   It is important to note that, at the time of this publication, the
   TME standard is still not finalized.

4.5.1 LOGIn <loginid> [password]

   This command allows for a session login ID to be specified.  It is
   used to validate the person attempting to access the paging terminal.



Gwinn                        Informational                    [Page 11]

RFC 1861                   SNPP - Version 3                October 1995


   If no LOGIn command is issued, "anonymous" user status is assumed.

   Possible responses from the SNPP server, with suggested text, in
   response to a LOGIn command are:

    250 Login Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    421 Illegal Access Attempt
    550 Error, Invalid LoginID or Password
    554 Error, failed (technical reason)

4.5.2 PAGEr <PagerID> [Password/PIN]

   This PAGEr command is an enhancement to the level one specification.
   The primary difference is the ability to specify a password or PIN
   for validation or feature access.

   Before proceeding, it is important to understand the logical function
   of the PAGEr command with respect to the LEVEl, COVErage, HOLDtime,
   and ALERt commands (option parameters as described below).  Each time
   a PAGEr command is issued, it should be thought of as the last step
   in a multiple step transaction.