Simple Notification and Alarm Protocol (SNAP) July 2001 Internet Draft Noam Shapira Document: draft-shapira-snap-01 Nir Flatau Category: Informational Eran Aloni Comverse Technology July 2001 Simple Notification and Alarm Protocol (SNAP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo suggests a protocol for mail status notification in which an email server notifies a notification gateway that changes have occurred in a mailbox (new message arrived, mailbox is full, etc.). A mailing list was establish to discuss this draft and promote the issue of Notification to RFC. You can do it by sending email with 'subscribe snap' to majordomo(_at_)lists(_dot_)neystadt(_dot_)org or using web at http://www.neystadt.org/cgi-bin/majordomo. Shapira Informational - Expires December 2001 Page [1] Simple Notification and Alarm Protocol (SNAP) July 2001 Table of Contents 1 Introduction ................................................ 5 1.1 Terminology ............................................. 5 2 Basic Operation ............................................. 6 2.1 The Method .............................................. 6 2.1.1 Query String ........................................ 6 2.1.2 Charset and Encoding ................................ 6 2.1.3 Persistent Connections .............................. 7 2.2 Request Flow ............................................ 7 2.2.1 Request Order ....................................... 7 2.2.2 Coherence ........................................... 7 2.2.3 Response ............................................ 7 2.2.4 Retries ............................................. 8 2.2.5 Pipelining .......................................... 8 3 Request ..................................................... 8 3.1 Protocol Header ......................................... 8 3.1.1 NotificationProtocolVersion (M) ..................... 8 3.1.2 ApplicationName (M) ................................. 8 3.1.3 ApplicationVersion (M) .............................. 8 3.1.4 ServerType (M) ...................................... 8 3.1.5 RequestType (M) ..................................... 9 3.1.6 RequestTime ......................................... 9 3.1.7 RequestId ........................................... 9 3.2 Request Types ........................................... 9 3.2.1 NewMsg .............................................. 9 3.2.2 ReadMsg ............................................. 9 3.2.3 DeleteMsg ........................................... 9 3.2.4 PurgeMsg ............................................ 10 3.2.5 RejectMsg ........................................... 10 3.2.6 Login ............................................... 10 3.2.7 Logout .............................................. 10 3.2.8 Update .............................................. 10 3.2.9 MailboxFull ......................................... 10 3.2.10 AccountLocked ...................................... 10 3.3 AccountLockGroup ........................................ 10 3.3.1 AccountLockReason ................................... 10 3.4 MailboxGroup ............................................ 11 3.4.1 EmailAddress (M) .................................... 11 3.4.2 SubscribrerId ....................................... 11 3.4.3 ServerName .......................................... 11 Shapira Informational - Expires December 2001 Page [2] Simple Notification and Alarm Protocol (SNAP) July 2001 3.5 MessageGroup ............................................ 12 3.5.1 MessageType (M) ..................................... 12 3.5.2 MsgSensitivity ..................................... 12 3.5.3 MessageId .......................................... 12 3.5.4 From ................................................ 12 3.5.5 To .................................................. 12 3.5.6 CC .................................................. 12 3.5.7 Subject ............................................. 12 3.5.8 MessageSendTime ..................................... 12 3.5.9 MessageReceiveTime .................................. 12 3.5.10 MessageSize ........................................ 13 3.5.11 AttachmentNames .................................... 13 3.5.12 nAttachments ....................................... 13 3.5.13 MsgPriority ........................................ 13 3.5.14 Body ................................................13 3.5.15 DeliveryReportMsg .................................. 13 3.6 CountersGroup ........................................... 14 3.6.1 nVoiceMessages ...................................... 14 3.6.2 nNewVoiceMessages ................................... 14 3.6.3 nNewUrgentVoiceMessages ............................. 14 3.6.4 nFaxMessages ........................................ 14 3.6.5 nNewFaxMessages ..................................... 14 3.6.6 nNewUrgentFaxMessages ............................... 14 3.6.7 nEmailMessages ...................................... 14 3.6.8 nNewEmailMessages ................................... 14 3.6.9 nNewUrgentEmailMessages ............................. 15 3.7 RejectGroup ............................................. 15 3.7.1 RejectReason ........................................ 15 3.8 MailboxCapacityGroup .................................... 15 3.8.1 MailboxCapacity ..................................... 15 3.8.2 MailboxCapacityThreshold ............................ 15 3.8.3 MailboxFullStatus ................................... 15 4 Response .................................................... 15 4.1 Status Codes ............................................ 16 4.1.1 Informational (1xx) Status Codes .................... 16 4.1.2 Successful (2xx) Status Codes .................... 16 4.1.3 Redirection (3xx) Status Codes .................... 16 4.1.4 Client Error (4xx) Status Codes .................... 16 4.1.5 Server Error (5xx) Status Codes .................... 17 4.1.6 "404 Not Found" ..................................... 17 4.2 Request-Id .............................................. 17 4.3 Description ............................................. 17 5 Protocol Syntax ............................................. 17 5.1 Basic Rules ............................................. 17 5.2 Request Syntax .......................................... 18 5.2.1 Query Syntax ........................................ 18 Shapira Informational - Expires December 2001 Page [3] Simple Notification and Alarm Protocol (SNAP) July 2001 5.2.2 Attribute Groups .................................... 18 5.2.3 Attributes .......................................... 19 5.3 Response Syntax ......................................... 21 6 Security .................................................... 21 7 Security .................................................... 21 8 References .................................................. 21 9 Authors' Addresses .......................................... 22 Shapira Informational - Expires December 2001 Page [4] Simple Notification and Alarm Protocol (SNAP) July 2001 1. Introduction The suite of Internet mail protocols (POP3, IMAP4) requires that a subscriber log in to his mailbox to discover new mail. This is a limitation, such as when the subscriber has multiple mailboxes or is expecting important mail and is not logged in. This memo suggests a protocol in which an email server notifies a notification gateway service of events occurring in the mailbox. For example, when a message is deposited (SMTP), the email server sends a "new message" notification to the service, which may then notify the subscriber by sending him a Short Text Message (SMS). This can be extended to include other mailbox events that are of importance to a subscriber, such as "mailbox full" and "message rejected". Each notification should include additional information that is available to the user such as the number of messages in the mailbox, mailbox quota, and MIME headers of incoming message. The suggested protocol separates the content and the transport. Current proposal binds SNAP to HTTP, however it is possible to define BEEP or SIP based transport binding. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-KEYWORDS]. The email server is referred to as the "source" of the notification and the notification gateway service as the "service". In client / server terms, the source is the client and the service is the server. Shapira Informational - Expires December 2001 Page [5] Simple Notification and Alarm Protocol (SNAP) July 2001 2. Basic Operation The email server sends requests to the service to notify it about events that have occurred in a subscriber's mailbox. The server can be roughly broken down into the following processes: SMTP process - Receives mail from SMTP clients and deposits it in a subscriber's mailbox. The SMTP process will send a "new message" request if the message was stored successfully or a "message reject" request if it was rejected. The request will include partial MIME headers of the incoming message. IMAP4 process - Handles subscriber interaction with mailbox. The process sends requests when a subscriber logs in, logs out, reads a message, or deletes a message. These requests will help the service to hold email counters and operate the Message Waiting Indication (MWI) mechanism. For example subscriber’s login can trigger notification event that will eventually turn MWI off. Management process - purges old messages, locks a mailbox if it has exceeded its quota, etc. The management process sends "purge message", "mailbox full", and "account locked" requests. The above breakdown serves to illustrate the flow and is not part of the suggested protocol. The syntax of each request is described later in the memo. The service "listens" for the requests. When a request is accepted it processes it and returns a response. 2.1 The Method 2.1.1 Query String The source MUST send the protocol fields in the query string. The syntax of the query string MUST comply with [RFC-2396]. The set of protocol fields to send in the header will be described in section 5. 2.1.2 Charset and Encoding The source MUST send a charset header if the protocol fields are not in the ISO-8859-1 char set as described in [RFC-2616]. The source MAY specify parameter values in character sets other than US-ASCII as specified in [RFC-2184]. Shapira Informational - Expires December 2001 Page [6] Simple Notification and Alarm Protocol (SNAP) July 2001 2.1.3 Persistent Connections The underlying transport may support sending multiple requests over same connection. An example of a such is Keep-Alive header of HTTP. The source MAY use transport’s means to request persistent connection. The service SHOULD support persistent connections and use them upon source requests. The motivation for this is that Notification Service is assumed to be handling big amount of requests and this will optimize its operation significantly. 2.2 Request Flow 2.2.1 Request Order The source MUST send the requests in the same order as the events that triggered them. This ensures a consistent behavior. For example: if there are two notifications, one indicating the subscriber has one new message and the second indicating he has two new messages, the subscriber must receive the first before the second. 2.2.2 Coherence The source MUST send a request only after the action was completed successfully. For example, "new message" notification MUST be sent only after the message has been deposited in the user mailbox. 2.2.3 Response Upon receiving a request, the service MUST return a response including a status code. The source SHOULD parse the response to retrieve the error code and determine success or failure of the request. Shapira Informational - Expires December 2001 Page [7] Simple Notification and Alarm Protocol (SNAP) July 2001 2.2.4 Retries The source SHOULD retry the request in case of failure. 2.2.5 Pipelining The source SHOULD pipeline requests according to [RFC-2616] par. 8.1.2. If the source pipelines requests, the service SHOULD send its responses in the same order they where received. 3. Request Each Request includes Header and Body. Each of them consists of attributes which appear in "field=value" pairs in the query string. This section describes the attributes. There are two alternative syntaxes for Request Body. One is XML based, while other is simple list of value-pairs. Both variants are fully described in section 5 in ABNF syntax. Each request MUST include a protocol header. One of the attributes in the protocol header is the RequestType. The value of RequestType describes the trigger of the request (for example "NewMessage") and which additional attributes are included in the request. The additional attributes are grouped. The groups and attributes in each group are listed in this section. Mandatory attributes in each group are marked with (M). Mandatory groups tied to a request type are also marked with (M). If a group is mandatory for a request type , the mandatory attributes of the group MUST appear in the request. 3.1 Protocol Header The header consists of the following attributes: 3.1.1 NotificationProtocolVersion (M) The version of this protocol MUST be 1.0. 3.1.2 ApplicationName (M) The name of the application sending the request. This name identifies the sending and need not be unique. 3.1.3 ApplicationVersion (M) The version of the application sending the request. 3.1.4 ServerType (M) The type of server sending the request. Source MUST send "EMAIL" in this field. In the future the protocol may be extended to add additional values. Shapira Informational - Expires December 2001 Page [8] Simple Notification and Alarm Protocol (SNAP) July 2001 3.1.5 RequestType (M) A string specifying the type of the request. Request types are listed in section 3.2. 3.1.6 RequestTime The time the request was sent by the source. Value MUST be in GMT. 3.1.7 RequestId A unique identifier in the server of the request. This MAY be an incremental counter or a text value. The server SHOULD set the RequestId attribute if it is pipelining in order to retry failed requests, since the order of responses in not guaranteed. The server is RECOMMENDED to set this attribute for debugging and logging purposes. 3.2 Request Types This section describes the trigger for sending each request type and lists the groups of attributes that SHOULD appear in the request. 3.2.1 NewMsg Trigger: A new message has been deposited in the subscriber's mailbox. Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. 3.2.2 ReadMsg Trigger: Subscriber reads a message from mailbox in IMAP4/POP3 session. Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. 3.2.3 DeleteMsg Trigger: Subscriber deletes a message from mailbox in IMAP4/POP3 session. Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. Shapira Informational - Expires December 2001 Page [9] Simple Notification and Alarm Protocol (SNAP) July 2001 3.2.4 PurgeMsg Trigger: Email server purges a message from mailbox. Groups: MailboxGroup(M) ,MessageGroup(M), CountersGroup. 3.2.5 RejectMsg Trigger: Email server rejects a message destined to a subscriber. Groups: MailboxGroup(M) ,MessageGroup(M), RejectGroup, CountersGroup. 3.2.6 Login Trigger: Subscriber logs into mailbox in IMAP4/POP3 session. Groups: MailboxGroup(M) , CountersGroup. 3.2.7 Logout Trigger: Subscriber logs out of mailbox in IMAP4/POP3 session. Groups: MailboxGroup(M) , CountersGroup. 3.2.8 Update Trigger: An event has occurred in the mailbox but Email server is unaware of the event type. Groups: MailboxGroup(M) ,MessageGroup, CountersGroup. 3.2.9 MailboxFull Trigger: The subscriber mailbox has exceeded its threshold. Groups: MailboxGroup(M) , CountersGroup, MailboxCapacityGroup. 3.2.10 AccountLocked Trigger :The subscriber mailbox has been locked for administrative reasons. Groups : MailboxGroup(M) , CountersGroup, AccountLockGroup. Shapira Informational - Expires December 2001 Page [10] Simple Notification and Alarm Protocol (SNAP) July 2001 3.3 AccountLockGroup 3.3.1 AccountLockReason A string containing description of the lock reason. 3.4 MailboxGroup 3.4.1 EmailAddress (M) The fully qualified e-mail address for the mailbox. 3.4.2 SubscribrerId In certain scenarios the source may have an additional subscriber id associated with the request. The source SHOULD use the subscriber id in such a scenario. 3.4.3 ServerName The name of the host the source is running on. Shapira Informational - Expires December 2001 Page [11] Simple Notification and Alarm Protocol (SNAP) July 2001 3.5 MessageGroup 3.5.1 MessageType (M) The message type can be of the following strings: Email, Voice, Fax, Video, Number, EmptyCaptured, VoiceFax 3.5.2 MsgSensitivity If the Sensitivity: header is present, the string value SHOULD be provided in this attribute. 3.5.3 MessageId Unique identifier [RFC-822]. The sender SHOULD use the IMAP4 message id 3.5.4 From The message "From" header as in [RFC-822]. 3.5.5 To The message "To" header as in [RFC-822]. 3.5.6 CC The message "cc" header as in [RFC-822]. 3.5.7 Subject The message "Subject" header as in [RFC-822]. 3.5.8 MessageSendTime A string in the format MM/DD/YYYY HH:MM:SS containing the value carried in the Date: header . The value MUST be converted to GMT time. 3.5.9 MessageReceiveTime A string in the format MM/DD/YYYY HH:MM:SS containing the time the message was received in the source expressed in GMT time. This MAY be the value of the IMAP4 INTERNALDATE attribute. Shapira Informational - Expires December 2001 Page [12] Simple Notification and Alarm Protocol (SNAP) July 2001 3.5.10 MessageSize A number that indicates the message size in bytes. If there are attachments to the message, the size SHOULD include the size of the attachments. 3.5.11 AttachmentNames A comma-separated list of possible filenames extracted from the Content-Disposition header [RFC-2183]. 3.5.12 nAttachments The number of attachments as described above. 3.5.13 MsgPriority Priority of message. Legal values are 'Urgent', 'Low' or 'Normal'. If X-Priority headers is present its value SHOULD be used; values of 1 or 2 for urgent, 3 for normal, 4 or 5 for low. If Importance header is present, its value SHOULD be used. If both are present, source SHOULD use the Importance header. 3.5.14 Body The source SHOULD send the body of the MIME message in certain request as described later. When doing so, the following apply: The source MUST copy the Content-Type header from the MIME message to the request header. The source MUST NOT send the body if the Content-Type is not "text". All text subtypes are allowed. The source MAY send only part of the body (for example the first 100 octets). The source MUST add a Content-Length header to the request specifying the size of the body. 3.5.15 DeliveryReportMsg If the message received is a DSN or a MDN, a string with value Yes. See RFC [RFC-1894] and [RFC-2298] Shapira Informational - Expires December 2001 Page [13] Simple Notification and Alarm Protocol (SNAP) July 2001 3.6 CountersGroup The counter group includes the count of messages in the subscriber mailbox according to categories. The categories are type (Voice, Fax or Email), Freshness (New or not) and Urgency (Urgent or not). A message is considered fresh if its unseen flag is true. It is considered Urgent if the MsgPriority attribute as described in the MessageGroup is urgent. Categorization to type is a proprietary vendor feature. The source SHOULD categorize all messages as Email messages. The value of each counter MUST be 0 or higher; or (-1) CAN be used if value is unknown. 3.6.1 nVoiceMessages Total number of voice messages in mailbox. 3.6.2 nNewVoiceMessages Number of new voice messages in mailbox. This includes messages that are new and urgent. 3.6.3 nNewUrgentVoiceMessages Number of new urgent voice messages in mailbox. 3.6.4 nFaxMessages Total number of fax messages in mailbox. 3.6.5 nNewFaxMessages Number of new fax messages in mailbox. This includes messages that are new and urgent. 3.6.6 nNewUrgentFaxMessages Number of new urgent fax messages in mailbox. 3.6.7 nEmailMessages Total number of email messages in mailbox. 3.6.8 nNewEmailMessages Number of new email messages in mailbox. This includes messages that are new and urgent. Shapira Informational - Expires December 2001 Page [14] Simple Notification and Alarm Protocol (SNAP) July 2001 3.6.9 nNewUrgentEmailMessages Number of new urgent email messages in mailbox. 3.7 RejectGroup 3.7.1 RejectReason A string containing description of the reject reason. 3.8 MailboxCapacityGroup 3.8.1 MailboxCapacity Actual usage percentage of subscriber mailbox. 3.8.2 MailboxCapacityThreshold Usage percentage threshold of subscriber mailbox. If MailboxCapacity > MailboxCapacityThreshold --> Mailbox is full. This is also the default if one of these attributes (or both) are not part of the request. If MailboxCapacity <= MailboxCapacityThreshold --> Mailbox was full, but it is not full any more (capacity is now below threshold) 3.8.3 MailboxFullStatus The mailbox full status attribute SHOULD be used to describe the implications of the fact that the mailbox is full, e.g. "Message retrieval disabled" or "No more messages can be stored in the mailbox". 4. Response The service MUST send a response for each request. The response MUST include a standard status code [RFC-2616]. The service MAY use proprietary status codes, as long as they comply with the standard classification of status codes according to their numbering convention. The syntax of the response in ABNF is listed in section 5. Shapira Informational - Expires December 2001 Page [15] Simple Notification and Alarm Protocol (SNAP) July 2001 4.1 Status Codes 4.1.1 Informational (1xx) Status Codes The service SHOULD not send any informational status codes. The source MUST ignore all informational status codes sent by the service. 4.1.2 Successful (2xx) Status Codes The service SHOULD return "200 Ok" status code if request succeeded. The service MAY return additional success (2xx) codes. After receiving a successful status code, the source MUST NOT perform retries. 4.1.3 Redirection (3xx) Status Codes 4.1.3.1 "301 Moved Permanently" Upon receiving this status code, the source MUST resend the notification request to the new URI specified in the location field of the response. When sending other requests after receiving this response, the source SHOULD use the new URL that is part of the URI returned in the "location" field. 4.1.3.2 "307 Temporary Redirect" Upon receiving this status code, the source MUST resend the request to the new URI specified in the location field of the response. The source MUST NOT change its behavior when sending future requests. 4.1.4 Client Error (4xx) Status Codes The service MUST send a client error status code when it finds out that the request format or content are illegal. The service SHOULD use the "400 Bad Request" status code, but MAY also use other (including proprietary) client error status codes. The source MUST NOT perform retries upon receiving one of these status codes as a reply. Shapira Informational - Expires December 2001 Page [16] Simple Notification and Alarm Protocol (SNAP) July 2001 4.1.5 Server Error (5xx) Status Codes The service MUST return a server error status code when it fails to process the request due to some internal error. The service SHOULD use the "500 Internal Server Error" status code, but MAY also use other (including proprietary) server error status codes. Upon receiving any server error status code, the source SHOULD perform retries. 4.1.6 "404 Not Found" The service MUST NOT return a "404 Not Found" status code. The Internet server will return this status code when it cannot find the service. The source MUST treat this error as if it were a Server error par 4.1.5 above). 4.2 Request-Id The response SHOULD include the request id of the request it is referring to. 4.3 Description The response MAY include additional text description. 5. Protocol Syntax 5.1 Basic Rules The following rules are defined in [RFC-2616] OCTET = CHAR = UPALPHA = LOALPHA = ALPHA = UPALPHA | LOALPHA DIGIT = CTL = CR = LF = SP = HT = <"> = token = 1* phrase = * Shapira Informational - Expires December 2001 Page [17] Simple Notification and Alarm Protocol (SNAP) July 2001 5.2 Request Syntax The syntax of the request is as described in [RFC-2616] section 5. 5.2.1 Query Syntax This section describes the syntax of the query component ([RFC-2396] section 3.4). Query = ProtocolHeader 1*AttributeGroup | ProtocolHeader ProtocolBody 5.2.2 Attribute Groups ProtocolHeader = NotificationProtocolVersion &ApplicationName &ApplicationVersion &ServerType &RequestType [&RequestTime] [&RequestId] AttributeGroup = MailboxGroup | MessageGroup | CountersGroup | RejectGroup | MailboxCapacityGroup | AccountLockGroup MailboxGroup = &EmailAddress [&SubscribrerId] [&ServerName] MessageGroup = &MessageType [&From] [&To] [&CC] [&Subject] [&MessageSendTime] [&MessageRecievedtime] [&MessageSize] Shapira Informational - Expires December 2001 Page [18] Simple Notification and Alarm Protocol (SNAP) July 2001 [&Body] [&AttachmentNames] [&nAttachments] [&MsgPriority] [&MsgSensitivity] [&ReplyRequested] [&MessageId] [&DeliveryReportMsg] CountersGroup = [&nVoiceMessages] [&nNewVoiceMessages] [&nNewUrgentVoiceMessages] [&nFaxMessages] [&nNewFaxMessages] [&nNewUrgentFaxMessages] [&nEmailMessages] [&nNewEmailMessages] [&nNewUrgentEmailMessages] RejectGroup = [RejectReason] MailboxCapacityGroup = [&MailboxCapacity] [&MailboxCapacityThreshold] [&MailboxFullStatus] AccountLockGroup = [AccountLockReason] ProtocolBody = XMLProlog CR LF NotificationXML CR LF XMLProlog = ""1.1"<">" xmlns:snap="http://www.comverse.com/2001/SNAP"?>" NotificationXML = "" GroupsElement "<\NotificationRequest>" GroupsElement = 1*GroupElement [see 3.2] GroupElement = Value 1 <\AttX1> : : Value N <\AttXN> <\GroupX> For each GroupElement, the following apply: - GroupX is the name of one of the attributes groups (AttributeGroup). - Attribute AttXi refers to the i'th attribute in group X as defined in chapter 3 in this document. 5.2.3 Attributes NotificationProtocolVersion= "NotificationProtocolVersion=" 1*DIGIT "."1*DIGIT ApplicationName = "ApplicationName=" token ApplicationVersion = "ApplicationVersion=" token ServerType = "ServerType=EMAIL" RequestType = "RequestType=" ("newmsg" | "readmsg" | "deletemsg" | "purgemsg" | "rejectmsg" | "login" | "logout" | "update" | "mailboxfull" | "accountlocked" ) Shapira Informational - Expires December 2001 Page [19] Simple Notification and Alarm Protocol (SNAP) July 2001 EmailAddress = "EmailAddress=" addr-spec ; see [RFC-822] mailbox = addr-spec ; simple address route-addr = "<" [route] addr-spec ">" route = 1#("@" domain) ":" ; path-relative addr-spec = local-part "@" domain ; global address local-part = word *("." word) ; uninterpreted ; case-preserved domain = sub-domain *("." sub-domain SubscribrerId = "SubscribrerId=" token ServerName = "ServerName=" token MessageType = "MessageType=" ("email" | "voice" | "fax" | "Video" | "number" | "emptycaptured" | "VoiceFax") From = "From=" addr-spec ;see [RFC-822] To = "To=" addr-spec ;see [RFC-822] CC = "CC=" addr-spec ;see [RFC-822] Subject = "Subject=" Token ;see [RFC-822] MM = ("01".."12") DD = ("01".."31") YYYY = ("1900".."9999") H = ("00".."23") M = ("00".."59") S = ("00".."59") datetime = MM "/" DD "/" YYYY H ":" M":" S 1*WS "GMT" requestTime = "requestTime=" datetime MessageSendTime= "MessageSendTime=" datetime MessageRecievedtime = "MessageRecievedtime=" datetime MessageSize = "MessageSize=" *DIGITS Body = "Body=" Token AttachmentNames = "AttachmentNames=" Token 1*[","Token] nAttachments = "nAttachments=" *DIGITS MsgPriority = "MsgPriority=" ("Urgent" | "Normal" |"Low") MsgSensitivity = "MsgSensitivity=" ("Confidential"|"Normal") MessageId = "MessageId=" token DeliveryReportMsg = "DeliveryReportMsg=" ("Yes"|"No") counter = "counter=" ("-1" | *DIGIT) nVoiceMessages = "nVoiceMessages=" counter nNewVoiceMessages = "nNewVoiceMessages=" counter nNewUrgentVoiceMessages= "nNewUrgentVoiceMessages=" counter nFaxMessages = "nFaxMessages=" counter nNewFaxMessages = "nNewFaxMessages=" counter nNewUrgentFaxMessages = "nNewUrgentFaxMessages=" counter nEmailMessages = "nEmailMessages=" counter nNewEmailMessages = "nNewEmailMessages=" counter nNewUrgentEmailMessages = "nNewUrgentEmailMessages=" counter Shapira Informational - Expires December 2001 Page [20] Simple Notification and Alarm Protocol (SNAP) July 2001 pecentage = ("0".."100") RejectReason = "RejectReason=" phrase MailboxCapacity = "MailboxCapacity=" percentage MailboxCapacityThreshold = "MailboxCapacityThreshold=" percentage MailboxFullStatus = "MailboxFullStatus=" phrase AccountLockReason = "AccountLockReason=" phrase 5.3 Response Syntax Protocol-Version = "Protocol Name" "/" 1*DIGIT "." 1*DIGIT Status-Code = "1" 2*DIGIT | "2" 2*DIGIT |"3" 2*DIGIT |"4" 2*DIGIT |"5" 2*DIGIT Reason-Phrase = * Status-Line = Protocol-Version SP Status-Code SP Reason-Phrase CRLF Request-Id = * Request-Id-Line = "REQUEST-ID:" *WS 1*request-id *WS CRLF Description-Line = * Response = 1Status-Line *1Request-Id-Line *1Description-Line 5.4 Examples: Request example (in ProtocolHeader 1*AttributeGroup format) - based on HTTP: POST /Notification-Service/notif.cgi?NotificationProtocolVersion=1.1& \ ApplicationName=Applic&ApplicationVersion=1.0&ServerType=Email& \ RequestType=NewMsg&RequestTime=07/31/2000%2012:02:00&RequestId=123456& \ MessageType=Email&MessageId=&EmailAddress=joe(_at_)email(_dot_)com& \ SubscriberId=10000&ServerName=ES1&nMsgs=20& \ nUrgentVoiceMsgs=5&nNormalVoiceMsgs=2&nLowVoiceMsgs=3& \ nNewUrgentFaxMsgs=1&nUrgentBillMsgs=1&MailboxCapacity=70& \ MailboxCapacityThreshold=80&MailboxFullStatus=Not%20Full& \ MessageSendTime=07/31/2000%2012:00:00& \ MessageRecieveTime=07/31/2000%2012:01:00&MessageSize=20000& \ MsgPriority=Urgent&MsgSensitivity=Normal&ReplyRequested=No& \ From=Budd(_at_)email(_dot_)com&To=joe(_at_)email(_dot_)com&Subject=Hello%20Joe Response example (1): HTTP/1.1 200 OK CLRF Request Id: 9941401AA CLRF Request processed successfully CLRF Response example (2): SIP/1.0 200 OK CLRF Request processed successfully CLRF 6. Appendix A. Historical Overview of Notification Issue. During previous years and even now there were a number of proposals in IETF regarding Notification. It is possible to retrieve the attempts documentation according the following documents: draft-roach-sip-subscribe-notify draft-martin-sieve-notify draft-mahy-sip-message-waiting draft-khare-notification (ISENS at 1998) draft-nerenberg-sin-framework draft-nerenberg-sin-imap We made an attempt to take into consideration all those. 7. Security This memo does suggest security measurements. Implementers MAY use security measures of underlying protocol transport. 8. References [1] Fielding, et al, "Hypertext Transfer Protocol HTTP/1.1", RFC 2616, June 1999 [2] Freed, N., and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [3] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", University of Delaware, STD 11, RFC 822, August 1982. Shapira Informational - Expires December 2001 Page [21] Simple Notification and Alarm Protocol (SNAP) July 2001 [4] Crocker, D., Editor, and Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [7] Troost, R., Dorner, S., and Moore, K., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183,August 1997. [8] Freed, N., and Moore, K., "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997. 9. Authors' Addresses Noam Shapira Comverse Technology 29 Habarzel st. Tel-Aviv Israel Phone: +972-3-7663605 Fax: +972-3-6454866 EMail: noam(_dot_)shapira(_at_)comverse(_dot_)com Shapira Informational - Expires December 2001 Page [22]