rfc1861.txt

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

   Responses from the SNPP server to the client are:

    250 Response Added to Transaction
    502 Error! Would Duplicate Previously Entered MCResponse
    550 Invalid MCResponse Code
    550 MCResponses Not Enabled
    552 Too Many MCResponses Entered
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    554 Error, failed (technical reason)

4.6.8 PAGEr

   In 2WAY mode, the following enhanced responses are available:

    850 Two-Way Unit Online and Available; Transaction Accepted
    950 Unit NOT Online; Message Will be Queued for Later Delivery
    750 Two-Way Unit NOT Online; Transaction Denied
    550 Error, Pager Not 2WAY Capable
    550 Error, RTYPe Mode Invalid for This Unit
    503 Already Selected PAGEr
    421 Gateway Service Unavailable (terminate connection)
    554 Error, failed (technical reason)

4.6.9 SEND

   Instructs the SNPP server to "launch" the message (plus attached
   response codes) to the field message unit.  A successful SEND command
   will return, to the client, a "Message_Tag" number and a "Pass_Code"
   for periodic status checking.  The client then uses the MSTAtus
   command to check the progression of the transaction. The
   "Message_Tag" functions as a "record locator," while the "Pass_Code"
   should be a randomly generated "PIN" code to authorize checking of
   the "Message_Tag."

   Response codes to a SEND command, as well as the MSTAtus command,
   indicate the degree of "finality" to the transaction.  Based on the



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


   delivery process, there are four categories.  Together with their
   response code prefixes, these are:

    86x - Initial message delivered, awaiting requested action(s)
    87x - Intermediate processing completed, awaiting closure
    88x - Transaction concluded (final)
    96x - Queued transaction
   These prefixes make a multi-tiered transaction relatively simple to
   follow to closure.  When an 88x series response code is received from
   the server, all requested portions of the transaction have been
   processed, and no further status changes will take place.

   The SEND command should reply with the first tier of message
   processing. Following this, the status of the message in the system
   is checked, periodically, using the MSTAtus command.

   Possible responses to a SEND command are:

    860 <Message_Tag> <Pass_Code> Delivered, Awaiting Read Ack
    861 <Message_Tag> <Pass_Code> Delivered, Awaiting Reply (MCR)

    880 <Message_Tag> <Pass_Code> Message Delivered

    960 <Message_Tag> <Pass_Code> OK, Message QUEUED for Delivery

    550 Delivery Failed!  Message destroyed.
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    554 Error, failed (technical reason)

4.6.10 MSTAtus <Message_Tag> <Pass_Code>

   This is used by a client program to periodically check the status of
   delivery and response of a given message.  The SEND command returns
   the "Message_Tag" and "Pass_Code" required to check the status. A
   "Message_Tag" may be (should be) expired by the SNPP server after an
   appropriate amount of time has passed.  Expiration of these tags is
   vendor dependent, and may accelerate after the first check after
   final disposition of the message (such as after a client program has
   successfully received the field unit's response code).

   The tag record contains a "Sequence" number which is an incremental
   counter that rises as the record's status changes (such as from a
   delivery acknowledgment to a reply).  In addition, date and time of
   the current transaction should be kept in the following format:

    YYMMDDHHMMSS+GMT   (example: 950925143501+7)




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


   Because of the tiered structure of replies, possible responses to an
   MSTAtus command are:

    860 <Sequence> <Date&Time> Delivered, Awaiting Read Confirmation
    861 <Sequence> <Date&Time> Delivered, Awaiting Reply (MCR)

    870 <Sequence> <Date&Time> Delivered, Read, Awaiting Reply (MCR)

    880 <Sequence> <Date&Time> Message Delivered (No Reply Pending)
    881 <Sequence> <Date&Time> Message Delivered and Read by Recipient
    888 <Sequence> <Date&Time> <Reply_Code> MCR Reply Received
    889 <Sequence> <Date&Time> <Full_Text_Response>

    960 <Sequence> <Date&Time> Message Queued; Awaiting Delivery

    780 <Sequence> <Date&Time> MESSAGE EXPIRED Before Delivery!

    550 Unknown or Illegal Message_Tag or Pass_Code
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    554 Error, failed (technical reason)

   After a closure-series (88x) command has been returned to the client,
   acceleration of message tag deletion may be desired to maximize use
   of resources on the server.

KTAG <Message_Tag> <Pass_Code>

   Used to "kill" the message tag after final reading (or when no
   further responses are desired).  This is more of a courtesy feature
   that allows the client to "clean up" rather than wait for the SNPP
   server to expire the tag.

4.7 Illegal Commands

   Should the client issue an illegal command, the server may respond in
   one of the two following ways:

    421 Too Many Errors, Goodbye (terminate connection)
    500 Command Not Implemented, Try Again

   The number of illegal commands allowed before terminating the
   connection should be at the discretion of the operator of the SNPP
   server.  The only response that has not been discussed is:

    421 SERVER DOWN, Goodbye





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


   This is used to refuse or terminate connections when the gateway is
   administratively down, or when there is some other technical or
   administrative problem with the paging terminal.

4.8 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.

4.9 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 to suit
   the tastes of the operator of the SNPP server. It is suggested that
   the response codes mirror SMTP response codes as closely as possible.

5. 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.

   Administrative errors (Illegal Pager ID, for example) have been
   separated from technical errors (out-of-space on disk, for example).
   Administrative failures are generally preceded with a 550 series
   response, while technical failures bear a 554 series code.

   Level two enhancements to the protocol have been added in preparation
   for TME deployment.

   Level three enhancements to the protocol have been added in
   preparation for acknowledgment-based messaging.

   Error code "502 Command not implemented" was changed to a general
   "500 Command not recognized" failure result to closer follow SMTP.

6. 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



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


   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
   experimental network printing protocol [4] 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 [3]
   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.

7. 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, RFC 1425, February 1993.

   [3] 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.

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












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


8.  Security Considerations

   Security issues are not discussed in this memo.

9. 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                        Informational                    [Page 23]