doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc1645.txt b/doc/rfc/rfc1645.txt
new file mode 100644
index 0000000..bf888b3
--- /dev/null
+++ b/doc/rfc/rfc1645.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                           A. Gwinn
+Request for Comments: 1645                 Southern Methodist University
+Obsoletes: 1568                                                July 1994
+Category: Informational
+
+
+               Simple Network Paging Protocol - Version 2
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This RFC suggests a simple way for delivering both alphanumeric and
+   numeric pages (one-way) to radio paging terminals.  Gateways
+   supporting this protocol, as well as SMTP, have been in use for
+   several months for nationwide paging and messaging.  In addition,
+   email filters and SNPP client software for Unix and Windows are
+   available at no cost.  Please contact the author for more
+   information.
+
+   Earlier versions of this specification were reviewed by IESG members
+   and the "822 Extensions" Working Group.  They preferred an alternate
+   strategy, as discussed under "Relationship to Other IETF Work",
+   below.
+
+1. Introduction
+
+   Beepers are as much a part of computer nerdom as X-terminals
+   (perhaps, unfortunately, more).  The intent of Simple Network Paging
+   Protocol is to provide a standard whereby pages can be delivered to
+   individual paging terminals.  The most obvious benefit is the
+   elimination of the need for modems and phone lines to produce
+   alphanumeric pages, and the added ease of delivery of pages to
+   terminals in other cities or countries.  Additionally, automatic page
+   delivery should be somewhat more simplified.
+
+2. System Philosophy
+
+   Radio paging is somewhat taken for granted, because of the wide
+   availability and wide use of paging products.  However, the actual
+   delivery of the page, and the process used (especially in wider area
+   paging) is somewhat complicated.  When a user initiates a page, by
+   dialing a number on a telephone, or entering an alphanumeric page
+   through some input device, the page must ultimately be delivered to
+
+
+
+Gwinn                                                           [Page 1]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+   some paging terminal, somewhere.  In most cases, this delivery is
+   made using TAP (Telocator Alphanumeric input Protocol, also known as
+   IXO).  This protocol can be a somewhat convoluted, and complicated
+   protocol using older style ASCII control characters and a non-
+   standard checksumming routine to assist in validating the data.
+
+   Even though TAP is widely used throughout the industry, there are
+   plans on the table to move to a more flexible "standard" protocol
+   referred to as TME (Telocator Message Entry Protocol).  The level two
+   enhancements to SNPP (as described below) are intended for use with
+   this forthcoming standard.
+
+   However, acknowledging the complexity and flexibility of the current
+   protocols (or the lack thereof), the final user function is quite
+   simple: to deliver a page from point-of-origin to someone's beeper.
+   That is the simple, real-time function that the base protocol
+   attempts to address.  Validation of the paging information is left
+   completely up to the paging terminal, making an SNPP gateway a direct
+   "shim" between a paging terminal and the Internet.
+
+3. Why not just use Email and SMTP?
+
+   Email, while quite reliable, is not always timely.  A good example of
+   this is deferred messaging when a gateway is down. Suppose Mary Ghoti
+   (fish@hugecompany.org) sends a message to Zaphod Beeblebrox's beeper
+   (5551212@pager.pagingcompany.com). Hugecompany's gateway to the
+   Internet is down causing Mary's message to be deferred.  Mary,
+   however, is not notified of this delay because her message has not
+   actually failed to reach its destination.  Three hours later, the
+   link is restored, and (as soon as sendmail wakes up) the message is
+   sent.  Obviously, if Mary's page concerned a meeting that was
+   supposed to happen 2 hours ago, there will be some minor
+   administrative details to work out between Mary and Zaphod!
+
+   On the other hand, if Mary had used her SNPP client (or simply
+   telnetted to the SNPP gateway), she would have immediately discovered
+   the network problem.  She would have decided to invoke plan "B" and
+   call Zaphod's pager on the telephone, ringing him that way.
+
+   The obvious difference here is not page delivery, but the immediate
+   notification of a problem that affects your message. Standard email
+   and SMTP, while quite reliable in most cases, cannot be positively
+   guaranteed between all nodes at all times, making it less desirable
+   for emergency or urgent paging.  This inability to guarantee delivery
+   could, whether rightly or wrongly, place the service provider in an
+   uncomfortable position with a client who has just received his or her
+   emergency page, six hours too late.
+
+
+
+
+Gwinn                                                           [Page 2]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+   Another advantage of using a separate protocol for paging delivery is
+   that it gives the sender absolute flexibility over what is sent to
+   the pager.  For instance, in the paging arena, where messages are
+   sent to alphanumeric pagers, it is less desirable to send the
+   recipient general header lines from a standard SMTP message.  Much of
+   the information is useless, possibly redundant, and a waste of
+   precious RF bandwidth.
+
+   Therefore, when implementing an SMTP gateway, the service provider
+   should elect to parse out needed information (such as the sender, and
+   possibly subject) such to maximize the utility of the transmission.
+   Parsing generally means less control over content and format by the
+   message originator.  SNPP provides a clean, effective way to send a
+   message, as written, to the recipient's pager.
+
+   The other consideration is the relative simplicity of the SNPP
+   protocol for manual telnet sessions versus someone trying to manually
+   hack a mail message into a gateway.
+
+4. The SNPP Protocol
+
+   The SNPP protocol is a sequence of commands and replies, and is based
+   on the philosophy of many other Internet protocols currently in use.
+   SNPP has several input commands (the first 4 characters of each are
+   significant) that solicit various server responses falling into four
+   categories:
+
+    2xx - Successful, continue
+    3xx - Begin DATA input (see "DATA" command)
+    4xx - Failed with connection terminated
+    5xx - Failed, but continue session
+
+   The first character of every server response code is a digit
+   indicating the category of response.  The text portion of the
+   response following the code may be altered to suit individual
+   applications.
+
+   The session interaction is actually quite simple (hence the name).
+   The client initiates the connection with the listening server.  Upon
+   opening the connection, the server issues a "220" level message
+   (indicating the willingness of the server to accept SNPP commands).
+   The client passes pager ID information, and a message, then issues a
+   "SEND" command.  The server then feeds the information to the paging
+   terminal, gathers a response, and reports the success or failure to
+   the client.
+
+
+
+
+
+
+Gwinn                                                           [Page 3]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+4.1 Examples of SNPP Transactions
+
+   The following illustrate examples of client-server communication
+   using SNPP.
+
+4.1.1 A Typical Level One Connection
+
+            Client                         Server
+
+    Open Connection               -->
+                                  <--  220 SNPP Gateway Ready
+    PAGE 5551212                  -->
+                                  <--  250 Pager ID Accepted
+    MESS Your network is hosed    -->
+                                  <--  250 Message OK
+    SEND                          -->
+                                  <--  250 Message Sent OK
+    QUIT                          -->
+                                  <--  221 OK, Goodbye
+
+4.1.2 A Typical Level Two, Multiple Transaction
+
+   The following example illustrates a single message sent to two
+   pagers.  Using this level protocol, pager-specific options may be
+   selected for each receiver by specifying the option prior to issuing
+   the "PAGEr" command.  In this example, an alternate coverage area is
+   selected for the first pager, while delayed messaging is specified
+   for the second.
+
+            Client                         Server
+
+    Open Connection               -->
+                                  <--  220 SNPP Server Ready
+    COVE 2                        -->
+                                  <--  250 Alternate Area Selected
+    PAGE 5551212 FOOBAR           -->
+                                  <--  250 Pager ID Accepted
+    HOLD 9401152300 -0600         -->
+                                  <--  250 Delayed Message OK
+    PAGE 5552323 XYZZY            -->
+                                  <--  250 Pager ID Accepted
+    SUBJ Seattle Meeting          -->
+                                  <--  250 Message Subject OK
+    DATA                          -->
+                                  <--  354 Begin Input, End With '.'
+    Please meet me tomorrow at    -->
+    the Seattle office            -->
+                                  <--  250 DATA Accepted
+
+
+
+Gwinn                                                           [Page 4]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+    SEND                          -->
+                                  <--  250 Message Sent OK
+    QUIT                          -->
+                                  <--  221 OK, Goodbye
+
+4.2 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.2.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)
+
+   The level 2 enhancements affect the PAGEr command.  Please refer to
+   the appropriate section for details.
+
+4.2.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
+
+
+
+Gwinn                                                           [Page 5]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+   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.2.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.2.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:
+
+    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]
+
+
+
+
+
+Gwinn                                                           [Page 6]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+   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.
+
+4.2.5 QUIT
+
+   The QUIT command terminates the current session.  The server should
+   simply respond:
+
+    221 OK, Goodbye"
+
+   and close the connection.
+
+4.2.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.3 Level 2 - Minimum Extensions
+
+   This section specifies minimum enhancements to the SNPP protocol for
+   added functionality.
+
+4.3.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.
+
+
+
+
+Gwinn                                                           [Page 7]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+   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.4 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.4.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.
+   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)
+
+
+
+Gwinn                                                           [Page 8]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+    421 Illegal Access Attempt
+    550 Error, Invalid LoginID or Password
+    554 Error, failed (technical reason)
+
+4.4.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.
+
+   When the PAGEr command is processed, the pager ID (and password) is
+   submitted to the paging terminal with LEVEl, COVErage, HOLDtime, and
+   ALERt.  If these parameters have not been altered, then their
+   defaults are assumed for the transaction.  After the next PAGEr
+   command has been processed, these option parameters are reset their
+   defaults.  Using this type of "option-option- option-go" scheme, it
+   is possible to specify a different priority level for "Jeff," and an
+   alternate coverage area for "Kathy," while sending the same message
+   to each.
+
+   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 or Password
+    554 Error, failed (technical reason)
+
+4.4.3 LEVEl <ServiceLevel>
+
+   The LEVEl function is used to specify an optional alternate level of
+   service for the next PAGEr command.  Ideally, "ServiceLevel" should
+   be an integer between 0 and 11 inclusive.  The TME protocol specifies
+   ServiceLevel as follows:
+
+    0 - Priority
+    1 - Normal (default)
+    2 - Five minutes
+    3 - Fifteen minutes
+    4 - One hour
+    5 - Four hours
+
+
+
+Gwinn                                                           [Page 9]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+    6 - Twelve hours
+    7 - Twenty Four hours
+    8 - Carrier specific '1'
+    9 - Carrier specific '2'
+   10 - Carrier specific '3'
+   11 - Carrier specific '4'
+
+   The choice on how to implement this feature, or to what level it
+   should be implemented, should be optional and up to the discretion of
+   the carrier.
+
+   Possible responses from the SNPP server, with suggested text, in
+   response to a LEVEl command are:
+
+    250 OK, Alternate Service Level Accepted
+    421 Too Many Errors, Goodbye (terminate connection)
+    421 Gateway Service Unavailable (terminate connection)
+    500 Command Not Implemented
+    550 Error, Invalid Service Level Specified
+    554 Error, failed (technical reason)
+
+4.4.4 ALERt <AlertOverride>
+
+   The optional ALERt command may be used to override the default
+   setting and specify whether or not to alert the subscriber upon
+   receipt of a message.  This option, like the previous command, alters
+   the parameters submitted to the paging terminal using the PAGEr
+   command.  The TME protocol specifies AlertOverride as either 0-
+   DoNotAlert, or 1-Alert.
+
+   Possible responses from the SNPP server, with suggested text, in
+   response to a ALERt command are:
+
+    250 OK, Alert Override Accepted
+    421 Too Many Errors, Goodbye (terminate connection)
+    421 Gateway Service Unavailable (terminate connection)
+    500 Command Not Implemented
+    550 Error, Invalid Alert Parameter
+    554 Error, failed (technical reason)
+
+4.4.5 COVErage <AlternateArea>
+
+   The optional COVErage command is used to override the subscriber's
+   default coverage area, and allow for the selection of an alternate
+   region.  This option, like the previous command, alters the
+   parameters submitted to the paging terminal using the PAGEr command.
+   AlternateArea is a designator for one of the following:
+
+
+
+
+Gwinn                                                          [Page 10]
+
+RFC 1645                    SNPP - Version 2                   July 1994
+
+
+    - 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:  214/768-3186
+   EMail:  allen@mail.cox.smu.edu  or  allen@sulaco.lonestar.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gwinn                                                          [Page 15]
+