rfc1568.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 451 行 · 第 1/2 页


RFC 1568                  SNPP - Version 1(b)               January 1994


    250 Page Sent         - successful delivery
    554 Failed, <reason>  - unsuccessful, and gives a 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 enter another page.

6.2.5 QUIT

   The QUIT command terminates the current session.  The server should
   respond "221 OK, Goodbye" and close the connection.

6.2.6 HELP

   The HELP command (optional) 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 OK" is issued.

6.3 Illegal Commands

   Should the client issue an illegal command, the server should respond
   "421 ERROR, Goodbye" and close the connection immediately.
   Optionally, the server may respond "502 Command Error, try again"
   should it be desirable to leave the connection open.

6.4 Timeouts

   The SNPP server can, optionally, have an inactivity timeout
   implemented.  At the expiration of the allotted time, the server
   responds "421 Timeout, Goodbye" and closes the connection.

6.5 Rigidity of Command Structure

   The commands from client to server should remain constant.  However,
   since the first character of the response indicates success or
   failure, the text of the server responses could be altered should one
   desire.  The following is a hunk of C code that is used currently in
   an SNPP gateway.  The only response that has not been discussed is
   "421 SERVER DOWN, Goodbye" and is used when the gateway is
   administratively down, or when there are communication problems with
   the TAP/IXO paging terminal.



Gwinn                                                           [Page 5]

RFC 1568                  SNPP - Version 1(b)               January 1994


   /* SNPP Client Commands */

   #define PAGER        "PAGE"
   #define MESSAGE      "MESS"
   #define SEND         "SEND"
   #define QUIT         "QUIT"
   #define RESET        "RESE"
   #define HELP         "HELP"

   /* Responses from SNPP server to client */

   #define SNPP_OK      "250 OK"
   #define SNPP_RESET   "250 Reset OK"
   #define SNPP_SENT    "250 Page Sent"
   #define SNPP_BADPIN  "550 Failed,"
   #define SNPP_NOTSENT "554 Failed,"
   #define SNPP_ENTERR  "503 Error, Already Entered"
   #define SNPP_ERRINC  "503 Error, Incomplete Info"
   #define SNPP_OKCLOS  "221 OK, Goodbye"
   #define SNPP_TIMEOUT "421 Timeout, Goodbye"
   #define SNPP_ERRCLOS "421 ERROR, Goodbye"
   #define SNPP_DOWN    "421 SERVER DOWN, Goodbye"

7. Revision History

   Originally, when proposed, the author employed POP2 style
   result/response codes.  The Internet community suggested that this
   '+' and '-' style theory be altered to provide numeric response codes
   -- similar to those used in other services such as SMTP.  The
   protocol has been altered to this specification from the first
   proposed draft.

   When a bad pager ID message (IXO/TAP administrative failure was
   received from the paging terminal, a 554 series (general failure) was
   returned.  This has been changed to a 550 failure code allowing a
   distinction to be made.

8. Relationship to Other IETF Work

   The strategy of this specification, and many of its details, were
   reviewed by an IETF Working Group and three IESG members.  They
   concluded that an approach using the existing email infrastructure
   was preferable, due in large measure to the very high costs of
   deploying a new protocol and the advantages of using the Internet's
   most widely-distributed applications protocol infrastructure.  Most
   reviewers felt that no new protocol was needed at all because the
   special "deliver immediately or fail" requirements of SNPP could be
   accomplished by careful configuration of clients and servers.  The



Gwinn                                                           [Page 6]

RFC 1568                  SNPP - Version 1(b)               January 1994


   experimental network printing protocol [3] was identified as an
   example of an existing infrastructure approach to an existing
   problem.  Other reviewers believed that a case could be made for new
   protocol details to identify paging clients and servers to each other
   and negotiate details of the transactions, but that it would be
   sensible to handle those details as extensions to SMTP [1,2] rather
   than deploying a new protocol structure.

   The author, while recognizing these positions, believes that there is
   merit in a separate protocol to isolate details of TAP/IXO and its
   evolving successors from users and, indeed, from mail-based
   approaches that might reach systems that would act as SMTP/MIME [4]
   to SNPP gateways.  Such systems and gateways are, indeed, undergoing
   design and development concurrent with this work.  See the section
   "Why not just use Email and SMTP?" for additional discussion of the
   author's view of the classical electronic email approach.

9. References

   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

   [2] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
       "SMTP Service Extensions", United Nations University, Innosoft,
       Dover Beach Consulting, Inc., Network Management Associates,
       Inc., The Branch Office, February 1993.

   [3] Rose, M., and C. Malamud, "An Experiment in Remote Printing", RFC
       1486, Dover Beach Consulting, Inc., Internet Multicasting
       Service, July 1993.

   [4] Borenstein, N., and N. Freed, "MIME  (Multipurpose Internet Mail
       Extensions) Part One:  Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies", RFC 1521, Bellcore,
       Innosoft, September 1993.
















Gwinn                                                           [Page 7]

RFC 1568                  SNPP - Version 1(b)               January 1994


10.  Security Considerations

   Security issues are not discussed in this memo.

11. Author's Address

   R. Allen Gwinn, Jr.
   Associate Director, Computing Services
   Business Information Center
   Southern Methodist University
   Dallas, TX  75275

   Phone:  [phone]
   EMail:  [e-mail] or [e-mail]





































Gwinn                                                           [Page 8]