Smart Notification and Alarm Protocol (SNAP) January 2001
Internet Draft N. Flatau
Document: 101_00_SNAP-RFC.txt Comverse Ltd
Category: Informational January 2001
Smart 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 client that changes have
occurred in a mailbox (new message arrived, mailbox is full,
etc.).
Flatau Informational - Expires July 2001 Page [1]
Smart Notification and Alarm Protocol (SNAP) January 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 Body ................................................ 7
2.1.4 Keep-alive Header ................................... 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.1.8 ResponseType (M) .................................... 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.2.11 CounterQuery ....................................... 10
3.2.12 FullStatusQuery .................................... 11
3.3 Response Types .......................................... 11
3.3.1 HTML ................................................ 11
3.3.2 XML ................................................. 11
3.4 MailboxGroup ............................................ 11
3.4.1 EmailAddress (M) .................................... 11
3.4.2 SubscribrerId ....................................... 11
3.4.3 ServerName .......................................... 11
3.4.4 MailboxName ......................................... 11
3.4.5 UserName ............................................ 11
3.4.6 Password ............................................ 11
3.4.7 AuthenticationKey ................................... 12
Flatau Informational - Expires July 2001 Page [2]
Smart Notification and Alarm Protocol (SNAP) January 2001
3.5 MessageGroup ............................................ 12
3.5.1 MessageType (M) ..................................... 12
3.5.2 RequiredMessageTypes ................................ 12
3.5.3 RequiredDetailsLevel ................................ 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 MsgSensitivity ..................................... 13
3.5.15 ReplyRequested ..................................... 13
3.5.16 MessageId .......................................... 13
3.5.17 RTSFlag ............................................ 13
3.5.18 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
3.9 AccountLockGroup ........................................ 15
3.9.1 AccountLockReason ................................... 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
Flatau Informational - Expires July 2001 Page [3]
Smart Notification and Alarm Protocol (SNAP) January 2001
5.2.2 Attribute Groups .................................... 18
5.2.3 Attributes .......................................... 19
5.3 Response Syntax ......................................... 21
6 Security .................................................... 21
7 References .................................................. 21
8 Authors' Addresses .......................................... 22
Flatau Informational - Expires July 2001 Page [4]
Smart Notification and Alarm Protocol (SNAP) January 2001
1. Introduction
The suite of Internet mail protocols (SMTP, 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
an instant messaging 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 "rejected".
Each notification should include additional information that is
available to the sender such as the number of messages in the
mailbox, mailbox quota, and MIME headers of incoming message.
The suggested protocol is an extension of HTTP. The email server
sends a HTTP request with the POST method. The messaging service
replies with a HTTP response.
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 instant messaging service as the "service".
In client / server terms, the source is the client and the
service is the server.
Flatau Informational - Expires July 2001 Page [5]
Smart Notification and Alarm Protocol (SNAP) January 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 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.
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].
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].
Flatau Informational - Expires July 2001 Page [6]
Smart Notification and Alarm Protocol (SNAP) January 2001
2.1.3 Body
The source SHOULD send the body of the MIME message in certain
responses 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.
2.1.4 Keep-alive Header
The source MAY send a keep-alive header if it wants to use a
persistent connection.
The service SHOULD support keep-alive and keep the connection
open.
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.
Flatau Informational - Expires July 2001 Page [7]
Smart Notification and Alarm Protocol (SNAP) January 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 attributes which appear in "field=value"
pairs in the query string. This section describes the attributes.
The full syntax is listed 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.
Flatau Informational - Expires July 2001 Page [8]
Smart Notification and Alarm Protocol (SNAP) January 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.1.8 ResponseType (M)
A string specifying the type of the response. Response types are
listed in section 3.3.
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.
Flatau Informational - Expires July 2001 Page [9]
Smart Notification and Alarm Protocol (SNAP) January 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.
3.2.11 CounterQuery
Query :The client queries for his mailbox status (counters).
Groups : MailboxGroup(M) , CountersGroup.
Flatau Informational - Expires July 2001 Page [10]
Smart Notification and Alarm Protocol (SNAP) January 2001
3.2.12 FullStatusQuery
Query :The client queries for message headers in his mailbox.
Groups : MailboxGroup(M) , CountersGroup.
3.3 Response Types
This section describes the trigger response for sending one of the
request types. This will be the type of the content file which will
be returned to the client.
3.3.1 HTML
A formatted HTML file.
3.3.2 XML
A formatted XML file.
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.
3.4.4 MailboxName
If the source is an email server, the value of this field MUST be
the email address, or the attribute CAN be omitted.
3.4.5 UserName
The subscriber user name.
3.4.6 Password
The subscriber password.
Flatau Informational - Expires July 2001 Page [11]
Smart Notification and Alarm Protocol (SNAP) January 2001
3.4.7 AuthenticationKey
The subscriber authentication key.
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 RequiredMessageTypes
A bit mask integer that represent the required message types
for the client. Can be of the following:
1=Email, 2=Voice, 3=Fax, 4=Video.
3.5.3 RequiredDetailsLevel
A bit mask integer that represent the required information
details level of the subscriber mailbox. Can be of the following:
1=Total, 2=Seen, 3=Priority.
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.
Flatau Informational - Expires July 2001 Page [12]
Smart Notification and Alarm Protocol (SNAP) January 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 MsgSensitivity
If the Sensitivity: header is present, the string value SHOULD be
provided in this attribute.
3.5.15 ReplyRequested
Yes if reply is requested. See RFC TBD
3.5.16 MessageId
Unique identifier [RFC-822]. The sender SHOULD use the IMAP4
message id
3.5.17 RTSFlag
Return-To-Sender flag as defined in RFC TBD. One of the following
Strings: NotRTS (Default value), NotDelivered, Purged.
3.5.18 DeliveryReportMsg
If the message received is a DSN or a MDN, a string with value
Yes. See RFC TBD
Flatau Informational - Expires July 2001 Page [13]
Smart Notification and Alarm Protocol (SNAP) January 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.
Flatau Informational - Expires July 2001 Page [14]
Smart Notification and Alarm Protocol (SNAP) January 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".
3.9 AccountLockGroup
3.9.1 AccountLockReason
A string containing description of the lock reason.
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.
Flatau Informational - Expires July 2001 Page [15]
Smart Notification and Alarm Protocol (SNAP) January 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.
Flatau Informational - Expires July 2001 Page [16]
Smart Notification and Alarm Protocol (SNAP) January 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>
Flatau Informational - Expires July 2001 Page [17]
Smart Notification and Alarm Protocol (SNAP) January 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
5.2.2 Attribute Groups
AttributeGroup =
MailboxGroup |
MessageGroup |
CountersGroup |
RejectGroup |
MailboxCapacityGroup |
AccountLockGroup
ProtocolHeader =
NotificationProtocolVersion
ApplicationName
ApplicationVersion
ServerType
RequestType
[ResponseType]
[RequestTime]
[RequestId]
MailboxGroup =
EmailAddress
[SubscribrerId]
[ServerName]
[MailboxName]
[UserName]
[Password]
[AuthenticationKey]
MessageGroup =
MessageType
[RequiredMessageTypes]
[RequiredDetailsLevel]
[From]
[To]
[CC]
[Subject]
[MessageSendTime]
[MessageRecievedime]
[MessageSize]
Flatau Informational - Expires July 2001 Page [18]
Smart Notification and Alarm Protocol (SNAP) January 2001
[Body
[nAttachments]
[MsgPriority]
[MsgSensitivity]
[ReplyRequested]
[MessageId]
[FirstNew]
[RTSFlag]
[MessageContext]
[DeliveryReportMsg]
CountersGroup =
[nVoiceMessages]
[nNewVoiceMessages]
[nNewUrgentVoiceMessages]
[nFaxMessages]
[nNewFaxMessages]
[nNewUrgentFaxMessages]
[nEmailMessages]
[nNewEmailMessages]
[nNewUrgentEmailMessages]
RejectGroup = [RejectReason]
MailboxCapacityGroup =
[MailboxCapacity]
[MailboxCapacityThreshold]
[MailboxFullStatus]
AccountLockGroup = [AccountLockReason]
5.2.3 Attributes
NotificationProtocolVersion=1*DIGIT "."1*DIGIT
[1*DIGIT "." 1*DIGIT]
ApplicationName = token
ApplicationVersion = token
ServerType = ("email" | "voice")
RequestType = ("newmsg" | "readmsg" | "deletemsg" |
"purgemsg" | "rejectmsg" | "login" |
"logout" | "update" | "mailboxfull" |
"accountlocked" | "CounterQuery" | "FullStatusQuery")
ResponseType = ("HTML" | "XML")
Flatau Informational - Expires July 2001 Page [19]
Smart Notification and Alarm Protocol (SNAP) January 2001
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
end TBD
SubscribrerId = token
ServerName = token
MailboxName = token
UserName = token
Password = token
Authentication = token
MessageType = "email" | "voice" | "fax" | "Video" | "number" |
"emptycaptured"
RequiredMessageTypes = *DIGITS
RequiredDetailsLevel = *DIGITS
From = see [RFC-822]
To = see [RFC-822]
CC = see [RFC-822]
Subject = 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"
MessageSendTime= datetime
MessageRecievedime = datetime
MessageSize = *DIGITS
nAttachments = *DIGITS
MsgPriority = ("Urgent","Normal","Low")
MsgSensitivity = ("Confidential","Normal")
ReplyRequested = ("Yes","No")
MessageId = token
RTSFlag = ("NotRTS","NotDelivered","Purged")
DeliveryReportMsg = ("Yes","No")
counter = ("-1" | *DIGIT)
nVoiceMessages = counter
nNewVoiceMessages = counter
nNewUrgentVoiceMessages= counter
nFaxMessages = counter
nNewFaxMessages = counter
nNewUrgentFaxMessages counter
nEmailMessages counter
nNewEmailMessages = counter
nNewUrgentEmailMessages = counter
Flatau Informational - Expires July 2001 Page [20]
Smart Notification and Alarm Protocol (SNAP) January 2001
pecentage = ("0".."100")
RejectReason = phrase
MailboxCapacity = percentage
MailboxCapacityThreshold = percentage
MailboxFullStatus = phrase
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
For example (1):
HTTP/1.1 200 OK CLRF
Request Id: 9941401AA CLRF
Request processed successfully CLRF
For example (2):
SIP/1.0 200 OK CLRF
Request processed successfully CLRF
6. Security
This memo does suggest security measurements. Implementers MAY use
security measures of underlying protocol transport.
7. 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.
Flatau Informational - Expires July 2001 Page [21]
Smart Notification and Alarm Protocol (SNAP) January 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.
8. Authors' Addresses
Nir Flatau
29 Habarzel st.
Tel-Aviv
Israel
Phone: +972-3-6452385
Fax: +972-3-6454866
EMail: nir.flatau@comverse.com
Flatau Informational - Expires July 2001 Page [22]