Neystadt, John (John@comverse.com)
Sun, 22 Jul 2001 11:17:34 +0300
Hi!
At the Minneapolis IETF, I have raised the idea of Email Notification
Protocol. Since there was quite an interest of this I have submitted an I-D
and opened a mailing list for the discussion of the protocol. The proposed
name is SNAP - Simple Notification and Alarm protocol.
The I-D is named draft-shapira-snap, but I was late for the cut-off with the
latest revision. The 01 draft (rejected because missed deadline) is attached
here.
I invite all interested parties to join the mailing list by sending
'subscribe snap' to majordomo@lists.neystadt.org or using the web at
http://www.neystadt.org/cgi-bin/majorodomo.
John Neystadt
john@neystadt.org
http://www.neystadt.org/john/
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@lists.neystadt.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 = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
token = 1*<any CHAR except CTLs or separators>
phrase = *<TEXT, excluding CR ,LF>
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 = "<?xml version = <">"1.1"<">"
xmlns:snap="http://www.comverse.com/2001/SNAP"?>"
NotificationXML =
"<NotificationRequest>" GroupsElement "<\NotificationRequest>"
GroupsElement = 1*GroupElement [see 3.2]
GroupElement = <GroupX>
<AttX1> Value 1 <\AttX1>
:
:
<AttXN> 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 = *<TEXT, excluding CR ,LF>
Status-Line = Protocol-Version SP Status-Code SP Reason-Phrase CRLF
Request-Id = *<ALPHA | DIGIT>
Request-Id-Line = "REQUEST-ID:" *WS 1*request-id *WS CRLF
Description-Line = *<TEXT, excluding CR ,LF>
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@email.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@email.com&To=joe@email.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.shapira@comverse.com
Shapira Informational - Expires December 2001 Page [22]
This archive was generated by hypermail 2.0b3 on Sun Jul 22 2001 - 11:18:48 IDT