rfc1645.txt

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

    - A subscriber-specific alternate coverage area
    - A carrier-defined region available to subscribers

   As an example, Mary Ghoti is a subscriber having local service in
   Chicago, Illinois (Mary's region '1').  Her account has been set up
   in such a manner as to allow Mary's pager to be paged nationwide upon
   demand (Mary's region '2').  Specifying "COVErage 2" prior to issuing
   the appropriate "PAGEr" command allows the default Chicago area to be
   overridden, and Mary's pager to be messaged nationally for that
   transaction.  It is assumed that the carrier providing Mary's service
   will keep track of how many pages have been sent to her pager in this
   manner, and will bill her accordingly.

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

    250 Alternate Coverage Selected
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Alternate Region
    554 Error, failed (technical reason)

4.4.6 HOLDuntil <YYMMDDHHMMSS> [+/-GMTdifference]

   The HOLDuntil command allows for the delayed delivery of a message,
   to a particular subscriber, until after the time specified.  The time
   may be specified in local time (e.g. local to the paging terminal),
   or with an added parameter specifying offset from GMT (in other
   words, "-0600" specifies Eastern Standard Time).  This option, like
   the previous command, alters the parameters submitted to the paging
   terminal using the PAGEr command.

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

    250 Delayed Messaging Selected
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Delivery Date/Time
    554 Error, failed (technical reason)

4.4.7 CALLerid <CallerID>

   The CALLerid function is a message-oriented function (as opposed to
   the subscriber-oriented functions just described).  This allows for
   the specification of the CallerIdentifier function as described in



Gwinn                                                          [Page 11]

RFC 1645                    SNPP - Version 2                   July 1994


   TME.  This parameter is optional, and is at the discretion of the
   carrier as to how it should be implemented or used.

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

    250 Caller ID Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Caller ID
    554 Error, failed (technical reason)

4.4.8 SUBJect <MessageSubject>

   The SUBJect function allows is a message-oriented function that
   allows the sender to specify a subject for the next message to be
   sent.  This parameter is optional and is at the discretion of the
   carrier as to how it should be implemented or used.

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

    250 Message Subject Accepted
    421 Too Many Errors, Goodbye (terminate connection)
    421 Gateway Service Unavailable (terminate connection)
    500 Command Not Implemented
    550 Error, Invalid Subject Option
    554 Error, failed (technical reason)

4.5 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

   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.




Gwinn                                                          [Page 12]

RFC 1645                    SNPP - Version 2                   July 1994


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

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



Gwinn                                                          [Page 13]

RFC 1645                    SNPP - Version 2                   July 1994


   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                                                          [Page 14]

RFC 1645                    SNPP - Version 2                   July 1994


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                                                          [Page 15]