idnits 2.17.1
draft-ietf-lemonade-server-to-client-notifications-00.txt:
-(159): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(584): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing revision: the document name given in the document,
'draft-ietf-lemonade-server-to-client-', does not give the document
revision number
~~ Missing draftname component: the document name given in the document,
'draft-ietf-lemonade-server-to-client-', does not seem to contain all the
document name components required ('draft' prefix, document source,
document name, and revision) -- see
https://www.ietf.org/id-info/guidelines#naming for more information.
== Mismatching filename: the document gives the document name as
'draft-ietf-lemonade-server-to-client-', but the file name used is
'draft-ietf-lemonade-server-to-client-notifications-00'
== There are 5 instances of lines with non-ascii characters in the document.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 20 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There is 1 instance of too long lines in the document, the longest one
being 68 characters in excess of 72.
** The abstract seems to contain references ([RFC3501]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The "Author's Address" (or "Authors' Addresses") section title is
misspelled.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
The UID of email messages MUST not change across sessions.
Changing the UID of email messages requires a heavy computational burden
on the mobile client, so the server should avoid doing so. The UID of
email messages MUST not change for the duration of a session.
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- The document date (July 2004) is 7223 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '1' on line 510
-- Looks like a reference, but probably isn't: '2' on line 519
-- Looks like a reference, but probably isn't: '3' on line 526
== Unused Reference: 'IMAP-DISC' is defined on line 691, but no explicit
reference was found in the text
== Unused Reference: 'RFC2180' is defined on line 699, but no explicit
reference was found in the text
== Unused Reference: 'RFC2234' is defined on line 703, but no explicit
reference was found in the text
== Unused Reference: 'RFC2420' is defined on line 707, but no explicit
reference was found in the text
== Unused Reference: 'RFC2616' is defined on line 711, but no explicit
reference was found in the text
== Unused Reference: 'RFC2617' is defined on line 715, but no explicit
reference was found in the text
== Unused Reference: 'RFC2683' is defined on line 719, but no explicit
reference was found in the text
== Unused Reference: 'RFC2177' is defined on line 723, but no explicit
reference was found in the text
== Unused Reference: 'RFC2818' is defined on line 726, but no explicit
reference was found in the text
== Unused Reference: 'RFC2822' is defined on line 729, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-EN'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IMAP-DISC'
** Downref: Normative reference to an Informational RFC: RFC 2180
** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
** Downref: Normative reference to an Informational RFC: RFC 2683
** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322)
** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051)
== Outdated reference: A later version (-07) exists of
draft-ietf-lemonade-profile-00
-- Possible downref: Normative reference to a draft: ref. 'EXTENSIONS'
Summary: 14 errors (**), 1 flaw (~~), 19 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Lemonade
2 Internet Draft: Lemonade Server to Client S. H. Maes
3 Notifications
4 Document: draft-ietf-lemonade-server-to-client- C. Wilson
5 notifications-00.txt
6 Expires: January 2005 July 2004
8 Lemonade Server to Client Notifications
10 Status of this Memo
12 This document is an Internet-Draft and is subject to all provisions
13 of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 Abstract
33 Lemonade server to client notifications provides some extensions to
34 the IMAPv4 Rev1 protocol [RFC3501] for optimization in a mobile
35 setting, aimed at delivering extended functionality for mobile
36 devices with limited resources. These notifications support pushing
37 crucial changes actively to a client, rather than requiring the
38 client to initiate contact to ask for state changes.
40 Conventions used in this document
42 In examples, "C:" and "S:" indicate lines sent by the client and
43 server respectively.
45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
47 document are to be interpreted as described in [RFC2119].
49 An implementation is not compliant if it fails to satisfy one or more
50 of the MUST or REQUIRED level requirements for the protocol(s) it
51 implements. An implementation that satisfies all the MUST or REQUIRED
52 level and all the SHOULD level requirements for a protocol is said to
53 be "unconditionally compliant" to that protocol; one that satisfies
54 all the MUST level requirements but not all the SHOULD level
55 requirements is said to be "conditionally compliant." When
56 describing the general syntax, some definitions are omitted as they
57 are defined in [RFC3501].
59 Table of Contents
61 Status of this Memo...............................................1
62 Abstract..........................................................1
63 Conventions used in this document.................................1
64 Table of Contents.................................................2
65 1. Introduction...................................................3
66 1.1. The Poll Model vs. the Push Model.........................3
67 1.2. The Server-Side Filtering in Lemonade.....................4
68 1.3. Synchronization Techniques................................5
69 1.3.1. State-Comparison-Based Synchronization...............5
70 1.3.2. Event-based Synchronization..........................6
71 2. The Lemonade Server to Client Notification Design..............7
72 2.1. Implementing Filters......................................7
73 2.1.1. The View Filter......................................8
74 2.1.2. The Priority/Notification Filter.....................8
75 2.1.3. The Syntax to define Priority/Notification Filters...8
76 2.2. Connectivity Models.......................................9
77 2.2.1. In-Response Connectivity.............................9
78 2.2.2. Inband Connectivity..................................9
79 2.2.3. Outband Connectivity................................10
80 2.3. Keeping the Client In Sync with the Mobile Repository....10
81 3. Events........................................................11
82 3.1. Message Events Sent During Inband and Inresponse Mode....11
83 3.2. Folder Events............................................12
84 3.3. PIM Events...............................................12
85 4. Interactions between the Lemonade Client and Lemonade Server..12
86 4.1. Revisions to IMAPv4 Rev1 Behavior........................12
87 4.1.1. UID.................................................12
88 4.1.2. Mobile Repository...................................12
89 4.1.3. IDLE................................................13
90 4.1.4. LEMONADESETPREF & LEMONADEGETPPREFS.................13
91 4.1.5. LEMONADEFILTER......................................13
92 Security Considerations..........................................15
93 References.......................................................15
94 Normative Appendices.............................................16
95 A. Event Payload..............................................16
96 A.1. Event Payload in Clear Text for Lemonade Sessions.....16
97 A.2. Outband Channel Event Payload.........................16
98 Non-Normative Appendices.........................................17
99 B. Use Cases..................................................17
100 B.1. State Comparison-Based Sync...........................17
101 B.2. Event-Based Sync......................................18
102 Authors Addresses................................................19
103 Intellectual Property Statement..................................19
104 Full Copyright Statement.........................................19
106 1. Introduction
108 The Lemonade Server to Client Notifications extends IMAPv4 Rev1
109 [RFC3501]. The client devices in this document are assumed to be
110 wireless with limited resources. However, this should not be seen as
111 constraining. The Lemonade Server to Client Notifications can be
112 bound to any transport protocol for inband and outband connectivity.
113 These notifications inform the client of changes in an end user's
114 mailbox. This document will define what events and conditions
115 generate notifications, as well as how the server will inform the
116 client of these notifications. In addition, it covers how the client
117 will process these notifications to maintain email synchrony.
119 The organization of this document is as follows. The rest of this
120 section introduces the concepts of Lemonade Server to Client
121 Notifications so the reader can gain an understanding of the concepts
122 that drive this design. Section 2 discusses actual design decisions
123 for Lemonade Server to Client Notifications. Section 3 defines the
124 bindings for expressing events, while Section 4 is the main body of
125 the protocol, which describes the interactions between the Lemonade
126 server and client. Next are sections concerning security
127 considerations, and references. Finally, there are normative and
128 non-normative appendices, which provide useful information for those
129 who wish to implement the Lemonade Server to Client Notifications.
131 1.1. The Poll Model vs. the Push Model
133 This section discusses two different models for exchanging
134 notifications from the server to the client. Today, most of the
135 existing email clients implement a polling model, where the end user
136 is notified of changes to an email account only after the email
137 client polls the server for changes. How long it takes a client to
138 learn of a change on the server is thus dependent on how often the
139 client polls for changes. Many clients can poll at high rates so
140 that the client can quickly learn of changes and reflect them on the
141 client display to achieve a quasi-real time synchronization
142 experience for the end user. Because the client must continuously
143 poll the server for changes, the bandwidth requirements can be quite
144 high and the connection quality must be good in order to provide a
145 quasi-real time experience to the user. The periodic poll model is
146 used on conventional email clients and is illustrated in Figure 1.
148 +--------------------+ Poll +--------------+
149 | | <------------ | |
150 | Mail Server | | Email Client |
151 | | ------------> | |
152 +--------------------+ Response +--------------+
154 Figure 1: Periodic Poll Model
156 Another way to achieve synchronization is for the email server to
157 initiate a session with the client when a crucial change to an email
158 occurs, which is the push model. When important events happen to a
159 user�s email account, the server informs the client device about the
160 event, and then the client can respond to that event as necessary. In this case, the client device does not need to periodically poll
161 the mail server, so the push model is particularly effective in the
162 mobile computing environment when the cost of constant polling is
163 high. The Lemonade Server to Client Notification Specifications
164 define the semantics for pushing events to a client. The push model
165 is seen in Figure 2.
167 Event +----------------+ Push +--------------+
168 --------> | Mail Server | ---------> | Email Client |
169 +----------------+ +--------------+
171 Figure 2: Push Model
173 1.2. The Server-Side Filtering in Lemonade
175 The Lemonade profile and Lemonade Server to Client Notification
176 protocol is meant to support mobile client devices with memory and
177 connectivity constraints. Due to these constraints, an end user may
178 want to specify filters to limit the number of notifications sent.
179 These filters separate their emails into different sets that the
180 server should handle differently. All end users have a complete
181 repository, which includes all their email messages that are stored
182 on a server. The end user may want to receive a small subset of
183 these messages on their client device, which are to be included on
184 the mobile device. The messages on the device are split further into
185 two categories, lower priority messages that the user chooses to wait
186 for until it can poll the server and higher priority messages that
187 the user would like to be notified of as soon as possible by the
188 server. All three repositories have the same set of folders.
190 +----------------+ +--------------+ +------------+
191 | COMPLETE | | MOBILE | | MOBILE |
192 | | POLL | Priority / | PUSH |
193 | REPOSITORY | View | REPOSITORY |Notification | REPOSITORY |
194 | all the emails |Filters | emails to be | Filters | important |
195 |in an end user's|=======>|on the mobile |============>| emails of |
196 | email account | | device | | end user |
197 +----------------+ +--------------+ +------------+
199 Figure 3: Filters and Repositories
201 Formally, a repository consists of a set of folders, and each folder
202 has both a name and a set of messages associated with it. While the
203 three repositories all have folders with the same name, there may be
204 different messages in them. The complete repository consists of all
205 folders of an end user and all the associated emails for each of
206 those folders. Messages in the complete repository that pass the
207 view filter make up the poll repository. An end user can specify
208 exactly one view filter per folder per device. In addition, there is
209 a second layer of filtering, called priority or notification filters,
210 and there is exactly one priority filter per folder per device. The
211 push repository is the set of all the messages in the complete
212 repository that pass both the view and the priority filters.
214 From this point forth, it can be assumed that an event in this
215 document refers to only and all changes to messages in the mobile
216 repositories. When the client connects to the server and polls for
217 messages, it can determine what changes have occurred to messages
218 that passed the view filters. Whenever an event occurs to a message
219 that passes the view and priority filters, the server actively pushes
220 a notification to the client.
222 1.3. Synchronization Techniques
224 After a client receives a notification that informs it that changes
225 have occurred to a mailbox, it needs to employ a synchronization
226 technique to reflect the server side changes onto the client device.
227 There are many techniques for determining what the changes between a
228 server and client are. In this section, two techniques are presented
229 that aim to keep a client device in sync with a given email account,
230 meaning the set of emails on the client device is the same as that in
231 the given email account.
233 1.3.1. State-Comparison-Based Synchronization
235 IMAPv4Rev1 clients use a state-comparison-based synchronization
236 technique to be in sync with an email account. This technique
237 requires the client to ask the server for information regarding all
238 the folders and all the messages in each folder stored on the server.
239 The client must then compute the difference between the server state
240 and the client device state, and make all necessary changes so that
241 the client device state matches the server state. An example of the
242 interaction between the client and server in the IMAPv4 Rev1 protocol
243 for performing a state-comparison-based sync follows.
245 First, the client must retrieve the folders from the server.
246 C: A002 LSUB "" "*"
247 S: * LSUB () "/" "Drafts"
248 S: * LSUB () "/" "Friends"
249 S: * LSUB () "/" "INBOX"
250 S: A002 OK LSUB completed
252 The client must compare its folders with the responses of the command
253 above. If it does not have a folder, it must create that folder on
254 the client device. If there is a folder on the device that is not in
255 any of these responses, then the client must delete that folder.
257 Next, the client needs to make sure that the emails in each of its
258 folders match the server. It performs a SELECT and then a FETCH
259 command for each folder. A sample of a SELECT and FETCH command for
260 the inbox is as follows:
261 C: A003 SELECT ~/INBOX
262 S: * 60 EXISTS
263 S: ... more untagged responses with information about the folder
264 S: A003 OK SELECT completed
265 C: A004 FETCH 1:* (FLAGS UID)
266 S: * 1 FETCH (FLAGS (\Answered) UID 120)
267 S: * 2 FETCH (FLAGS (\Seen) UID 121)
268 S: ... flags for messages with message sequence numbers 3-59
269 S: * 60 FETCH (FLAGS () UID 250)
270 S: A004 OK FETCH completed
272 The client must go through the full list of email messages in each
273 folder. It must add an email in this list if it is not already on
274 the client. It must modify any email in this list on the client
275 device to reflect any changes to the mutable flags of that message.
276 Also, it should remove any emails on the client device not in this
277 list. After performing these operations, the client is in sync with
278 the server.
280 1.3.2. Event-based Synchronization
282 Another technique is event-based synchronization. Event-based
283 synchronization is used to keep the client device in sync with the
284 server. This method requires that the client has been fully
285 synchronized with the server at some earlier point. In the IMAPv4
286 Rev1 protocol, the client must perform a state-comparison-based sync
287 when it selects a folder, but then it can use event-based
288 synchronization to keep itself in sync after that. Although event-
289 based synchronization cannot totally replace state-comparison-based
290 synchronization, it is a faster alternative for the client to
291 maintain synchrony when the server is capable of change tracking for
292 a client.
294 In event-based synchronization, the server keeps track of what
295 changes have occurred that are not yet reflected on the client
296 device. Such a change is called an event. When the client finishes
297 processing all events since the last time it was in sync with the
298 server, it is again in sync with the server. Event-based
299 synchronization is particularly effective when the server can push
300 events to the client for immediate processing. In this case, there
301 are likely to be only a small number of events the client needs to
302 process at one time.
304 When a Lemonade client drops a connection or accidentally disconnects
305 the server can retain the session and cache all events during the
306 time the client is disconnected. When the client reconnects it does
307 not need to perform a state-comparison-based synchronization again,
308 instead the server sends the list of pending events to the client.
310 2. The Lemonade Server to Client Notification Design
312 Lemonade Server to Client Notification assumes extensions of IMAP
313 with the same basic model, where the client connects to the server to
314 open a session to access its email account. A Lemonade client may
315 fetch the contents of the email account or make changes to it just as
316 in IMAP.
318 2.1. Implementing Filters
320 A Lemonade server should support multiple mobile devices for each
321 email user, and should allow each device to have one unique event
322 filter and a set of view filters and priority/notification filters.
323 The server only needs to support one connection per mobile device for
324 each email user. A mobile client connects to the Lemonade server by
325 supplying its LOGIN information, and then must inform the server of
326 this mobile client�s device ID, which is some unique identifier for
327 the client device. The server and client should agree on what
328 convention to use for this ID, and it could be a hash of IMEI. If no
329 device ID is given, then a regular IMAP session is initiated. The
330 LOGIN information is used to specify a user, while the device ID is
331 needed to specify the mobile client. Associated with the user and
332 device ID is exactly one view filter and exactly one
333 priority/notification filter for each folder. These filters are
334 saved and thus persist across Lemonade sessions. Filters can be
335 modified when a Lemonade session is open.
337 2.1.1. The View Filter
339 View filters and priority/notification filters are used to filter out
340 email messages which match certain criteria. If an email passes
341 through the view filter, it is stored in the mobile repository. The
342 syntax for defining a view filter or notification filter includes any
343 combination of most of the search criteria as defined for the SEARCH
344 command of IMAP, in Section 6.4.4 and 7.2.5 of RFC 3501, or a days
345 filter. The days filter filters messages received starting a certain
346 number of days before the current day. The ALL search criteria, when
347 used alone, means that every email event satisfies the criteria. By
348 default, view filters are set to ALL.
350 Whenever a view filter is modified, the client needs to perform a
351 state-comparison-based sync to keep in sync with the mobile
352 repository since the messages in the mobile repository may have
353 changed.
355 2.1.2. The Priority/Notification Filter
357 Priority/Notification filters are used to select emails in the mobile
358 repository which match certain criteria. If an email passes through
359 the notification filter, it is stored in the push repository. The
360 syntax for defining a priority/notification filter is discussed
361 below. By default, priority/notification filters are set to NOT ALL
362 to reduce default traffic at the cost of some delays.
364 Because the view filter defaults to ALL and the priority/notification
365 filter to NOT ALL, the mobile repository will mirror the complete
366 repository, but none of the messages are added to the push
367 repository. This implies that the default behavior is equal to the
368 IMAPv4 Rev1 model.
370 The client does not need to do anything after it resets a
371 priority/notification filter or event filter, instead the server
372 should then only send out notifications that correspond to the most
373 up-to-date filters.
375 2.1.3. The Syntax to define Priority/Notification Filters
377 The syntax for defining a priority/notification filter is ALL, NONE,
378 or NEW. A priority/notification filter applies for all folders in a
379 push repository.
380 ALL -- All message events concerning messages of the push
381 repository will be sent to the client, such as if the message becomes
382 seen or deleted.
383 NONE -- No events should be pushed to the client.
384 NEW -- Only events that concern new messages arriving to the push
385 repository should be pushed to the client.
387 This one event filter applies for all folders.
389 2.2. Connectivity Models
391 There are three connectivity models for Lemonade Server to Client
392 Notifications, depending on the capabilities of the Lemonade server,
393 the client, and the connection available between them. These models
394 include in-response, inband, and outband. It is explicitly stated in
395 what situations these three connectivity models arise.
397 2.2.1. In-Response Connectivity
399 The in-response binding scenario is the most basic one and implements
400 the poll model. In this case the client initiates the commands to the
401 Lemonade server and the server responds to client commands with
402 events. In this case there is no need for a persistent connection
403 between the client and the server. The client opens a connection only
404 when it needs to send commands to the Lemonade server, and that is
405 the only time it is notified of new events.
406 +--------+ +++ HTTP, etc. +--------+
407 | | Command +++ | |
408 | Client |--------------------+++--------------->|Lemonade|
409 | Device | +++ | Server |
410 | | Response + Event +++ | |
411 | |<-------------------+++----------------| |
412 +--------+ +++ +--------+
413 Figure 4: In-Response connection
415 An in-response connection can occur in several situations:
416 [1] HTTP/HTTPS binding
417 - Server Requires: HTTP/HTTPS listener for IMAPv4
418 - Client Requires: HTTP/HTTPS client with IMAPv4 processing
419 [2] TCP Binding
420 - Server Requires: IMAPv4
421 - Client Requires: IMAPv4 + no IDLE
423 2.2.2. Inband Connectivity
425 The inband binding scenario corresponds to a reliable push model. In
426 this case the server pushes events to the client whenever they occur.
427 To do so, it must have a reliable means of communication with the
428 client, and the client should be ready to accept such notifications.
429 In this case, there needs to be a persistent connection between the
430 client and the server so that the server can push an event at any
431 time. The client may optionally issue a request to retrieve more
432 information concerning an event.
434 +--------+ OOO TCP, Persistent +--------+
435 | | Push Event OOO HTTP, etc. | |
436 | Client |<------------------OOO-----------------|Lemonade|
437 | Device | OOO | Server |
438 | | Optional Request OOO | |
439 | |...................OOO................>| |
440 +--------+ OOO +--------+
441 Figure 5: Inband Connection
443 An inband connection can occur in the following situations:
444 [1] TCP Binding, Always connected, IDLE
445 - Server Requires: IMAPv4 + IDLE
446 - Client Requires: IMAPv4 + IDLE, constant TCP connection
447 [2] Any other persistent two-way connection
448 - Server Requires: IMAPv4 + IDLE
449 - Client Requires: IMAPv4 + IDLE, constant connection
451 2.2.3. Outband Connectivity
453 The outband binding scenario corresponds to an unreliable push model.
454 In this case the server pushes events to the client whenever they
455 occur, to the best of its ability. To do so, it should be able to
456 send messages to the client without the need for a persistent
457 connection. However, the outband channel can possibly lose and
458 reorder messages, and there are no timing guarantees. Examples of
459 out-band channels include SMS, JMS, WAP Push, and UDP. As in the
460 inband scenario, the client may optionally open a Lemonade session
461 over an inband or in-response connection and send a command as a
462 result of receiving an event.
464 +--------+ Push Event XXX SMS +--------+
465 | |<--------------XXX---------------------| |
466 | Client | XXX |Lemonade|
467 | Device | Inband or | Server |
468 | | Request +O+ In-response | |
469 | |---------------O+O-------------------->| |
470 +--------+ +O+ +--------+
471 Figure 6: Outband Connection
473 Outband connectivity occurs in the following situations:
474 [1] A notification service from the server to the client
475 - Server Requires: A notification generator.
476 - Client Requires: A notification processor.
478 2.3. Keeping the Client In Sync with the Mobile Repository
480 Whenever a client device opens a new session, it must perform a
481 state-comparison-based sync with the email server so that its state
482 is the same as the mobile repository. Since the client has no way of
483 directly detecting only changes to the repository since the last
484 login, it needs to retrieve information about every message in the
485 mobile repository and calculate the changes itself. After that
486 point, the client can use event-based synchronization to keep the
487 device in sync.
489 The Lemonade server can issue a session and track changes to a
490 selected folder for the duration of a session. Until the session is
491 expired, the server must log all events that occur while a client is
492 offline. This way, if the client temporarily loses a connection, it
493 does not have to worry about missing any events and needing to
494 perform another state-comparison-based sync. A client does have the
495 option though to prematurely end a session by issuing a LOGOUT
496 command. Additionally, Lemonade clients can remain inactive for at
497 least twenty four hours without being logged off the server and
498 without the session expiring.
500 3. Events
502 This section contains the syntax that the server uses to send events
503 to the client.
505 3.1. Message Events Sent During Inband and Inresponse Mode
507 The client can receive the following untagged responses from the
508 server:
510 [1] The client receives an EXISTS/RECENT event from the server
511 indicating a new message.
512 S: * 501 EXISTS
513 S: * 1 RECENT
514 Next, the client retrieves this new message using a FETCH command.
515 C: A02 FETCH 501 (ALL BODY[])
516 S: * 501 FETCH ...
517 S: A02 OK FETCH completed
519 [2] The client receives an EXPUNGE event from the server from a
520 message has been permanently removed from a folder.
521 S: * 25 EXPUNGE
522 The client deletes this message from the client device, as it has
523 been removed permanently from the folder. The client does not need
524 to send any command back to the server.
526 [3] The client receives an untagged FETCH event from the server,
527 which can contain just FLAG information if the event is regarding an
528 old message or possibly other information if the event is regarding a
529 new message. This event is received if a message's flags are
530 changed, or in response to a new message if the user's preferences
531 are set to do so.
532 S: * 101 FETCH (FLAGS (\Seen \Deleted))
533 The client saves the information contained in this response
534 accurately in the client device.
536 3.2. Folder Events
538 This section will contain syntax for indicating folder events.
540 3.3. PIM Events
542 This section will contain syntax for indicating PIM events.
544 4. Interactions between the Lemonade Client and Lemonade Server
546 Interactions between Lemonade clients and servers are described in
547 [LEMONADEPROFILE].
549 The Lemonade Server to Client Notifications also define events to be
550 sent by the server to the client. These events notify the client
551 when there are changes to messages that match an end user�s view
552 filters and notification filters, as well as any changes to a
553 client�s email folders. The syntax defined in this section is an
554 abstract syntax, and payloads may vary according to the communication
555 mechanism used. The normative appendix of this document describes
556 some specific payloads.
558 4.1. Revisions to IMAPv4 Rev1 Behavior
560 4.1.1. UID
562 The UID of email messages MUST not change across sessions. Changing
563 the UID of email messages requires a heavy computational burden on
564 the mobile client, so the server should avoid doing so. The UID of
565 email messages MUST not change for the duration of a session.
567 4.1.2. Mobile Repository
569 In a Lemonade session, the client can only access messages in the
570 mobile repository. This affects the messages returned by FETCH, UID
571 FETCH, etc. Message sequence numbers reflect the relative position
572 of messages within the given folders of the mobile repository, so the
573 message sequence number of an email while logged in to Lemonade may
574 also differ from IMAP. When returning information about the email
575 account, only messages in the mobile repository are taken into
576 account.
578 4.1.3. IDLE
580 The server should implement the IDLE command from RFC 2177. When the
581 client issues this command, the server can push changes to a folder
582 to the client. The server may replace the EXISTS/RECENT message with
583 an untagged FETCH command as specified in [EXTENSIONS] (Section on
584 2.2.2. � See LEMONADESETPREF & LEMONADEGETPPREFS). The client should
585 fire this command while in-session to enter inband mode, where the
586 server will actively push notifications to the client.
588 4.1.4. LEMONADESETPREF & LEMONADEGETPPREFS
590 The LEMONADESETPREF command is described in [EXTENSIONS]. It allows a
591 user to define certain configuration parameters, while the
592 LEMONADEGETPREFS command allows a user to retrieve the configuration
593 values. Any server that implements these commands must respond with
594 LEMONADEPREF as one of the capabilities in response to a CAPABILITY
595 command. It must also announce the values these parameters can be
596 set to in the LEMONADEPROVISION command (See [EXTENSIONS]). These
597 parameters affect how outband notifications are sent to the client,
598 as well as the format for sending new event notifications. If the
599 server supports LEMONADEPREF they are required to support all of the
600 following preferences with at least one value to set each preference
601 to. They are described in [EXTENSIONS].
603 4.1.5. LEMONADEFILTER
605 The LEMONADEFILTER command allows users to set up view filters and
606 priority/notification filters. LEMONADEFILTER can be fired when the
607 state is AUTHENTICATED or SELECTED. The first argument to this
608 command is the folder that that filter should be applied to, or "ALL"
609 for all folders. Next the user specifies "V", "N", or "B" to set
610 either a view filter or a priority/notification filter, or both.
611 Following this, it must specify the filter criteria using a
612 combination of search criteria as defined for the SEARCH command of
613 IMAP, in Section 6.4.4 and 7.2.5 of RFC 3501, or the days filter.
614 The ALL search criteria, when used alone, means that every email
615 message satisfies the criteria. Or it can specify "V" or "N" to get
616 a view filter or priority/notification filter. In this case, the
617 last argument is "GET" to retrieve the filter.
618 By default, view filters are set to ALL, while priority/notification
619 filters are set to NOT ALL. This means that the mobile repository
620 includes all the messages in the complete repository, but none are
621 pushed to the client, which is the IMAPv4 Rev1 model.
623 Exactly one view filter and one priority/notification filter is
624 associated with each folder for each device. When a new view filter
625 or priority/notification filter is created, it replaces the previous
626 filter for that folder. When a view filter is modified, the client
627 needs to perform a state-comparison-based sync on the client in order
628 for the device to be in sync with the mobile repository. The server
629 always sends only notifications that correspond to the most up-to-
630 date view filters and priority/notification filters. All filters
631 persist across Lemonade sessions; once set, a filter on a folder
632 applies until the user changes it.
634 Lemonade introduces a filter, the days filter, which allows a user to
635 specify from how many days before today it would like to see emails.
636 To see only today's email, a 0 should be used for the int.
638 lemonadefilter_cmd = tag SP "LEMONADEFILTER" SP ("ALL" / folder) SP
639 (("V" / "N" / "B") SP lemonadefilter_criteria) /
641 (("V" / "N") "GET")
642 lemonadefilter_criteria = (IMAPv4Rev1_searching_criteria /
643 days_filter)
644 [SP lemonadefilter_criteria]
645 days_filter = "DAYSBEFORETODAY" SP int
646 Valid States: AUTHENTICATED or SELECTED
647 Responses: untagged responses: lemonadefilterGet_resp
648 lemonadefilterGet_resp = "*" SP "LEMONADEFILTER" SP folder SP
649 ("V"/"N")
650 lemonadefilter_criteria
651 Result: OK - filter created
652 NO - can't create the filter
653 BAD - invalid arguments
655 Example: The client creates a priority/notification filter for all
656 messages in the Inbox from "John" since Jun. 1st, 2003.
657 C: A001 LEMONADEFILTER INBOX P SINCE 1-Jun-2003 FROM "John"
658 S: A001 OK LEMONADEFILTER completed
660 Example: The client asks for the view filter for all the folders.
661 C: A001 LEMONADEFILTER ALL V GET
662 S: * LEMONADEFILTER ~/INBOX V ALL
663 S: * LEMONADEFILTER ~/TRASH V NOT ALL
664 S: A001 OK LEMONADEFILTER completed
666 Example: Stop notifications on a particular device, fired while in
667 AUTHENTICATED mode.
668 C: A001 LEMONADEFILTER ALL P NOT ALL
669 S: A001 OK LEMONADEFILTER ALL P NOT ALL completed
671 Security Considerations
673 The protocol calls for the same security requirements for an in-
674 response and inband connectivity mode as IMAP.
676 For the outband connectivity mode, servers should use encryption
677 methods for notifications if sensitive information is included in the
678 payload of that notification.
680 When an implementation of Lemonade is proxy-based, this may create
681 new security issues. These issues are discussed in detail in
682 Appendix C, because the issues are dependent on the implementation of
683 this protocol rather than inherent to the protocol itself.
685 References
687 [OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August
688 2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA-
689 Push-EMN-V1_0-20020830-C.pdf
691 [IMAP-DISC] Austein, R. "Synchronization Operations For Disconnected
692 Imap4 Clients", IMAP-DISC, November 1994.
693 http://asg.web.cmu.edu/cyrus/rfc/draft-ietf-imap-disc-01.html
695 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate
696 Requirement Levels", RFC 2119, March 1997.
697 http://www.ietf.org/rfc/rfc2119
699 [RFC2180] Gahrns, M. "IMAP4 Multi-Accessed Mailbox Practice", RFC
700 2180, July 1997.
701 http://www.ietf.org/rfc/rfc2180
703 [RFC2234] Crocker, D. and Overell, P. "Augmented BNF for Syntax
704 Specifications", RFC 2234, Nov 1997.
705 http://www.ietf.org/rfc/rfc2234
707 [RFC2420] Kummert, H. "The PPP Triple-DES Encryption Protocol
708 (3DESE)", RFC 2420, September 1998.
709 http://www.ietf.org/rfc/rfc2420
711 [RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol --
712 HTTP/1.1", RFC 2616, June 1999.
713 http://www.ietf.org/rfc/rfc2616
715 [RFC2617] Franks, J. et al. "HTTP Authentication: Basic and Digest
716 Access Authentication", RFC 2617, June 1999.
717 http://www.ietf.org/rfc/rfc2617
719 [RFC2683] Leiba, B. "IMAP4 Implementation Recommendations", RFC 2683
720 Sep 1999.
721 http://www.ietf.org/rfc/rfc2683
723 [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997.
724 http://www.ietf.org/rfc/rfc2177
726 [RFC2818] Rescorla, E. "HTTP over TLS", RFC 2818, May 2000.
727 http://www.ietf.org/rfc/rfc2818
729 [RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April
730 2001. http://www.ietf.org/rfc/rfc2822
732 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
733 Version 4 rev1", RFC 3501, March 2003.
734 http://www.ietf.org/rfc/rfc3501
736 [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
737 draft-ietf-lemonade-profile-00.txt, (work in progress), July 2004.
739 [EXTENSIONS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
740 Chiu, E., "Lemonade Command Extensions", draft-maes-lemonade-
741 command-extensions-00.txt, (work in progress), July 2004.
743 Normative Appendices
745 A. Event Payload
747 A.1. Event Payload in Clear Text for Lemonade Sessions
749 The event payload for a Lemonade session follows the general format
750 explained in Section 1.3.2, and is in clear text.
752 A.2. Outband Channel Event Payload
754 The suggested payload for notifications is that suggested by the OMA,
755 see [OMA-EN]. This notification informs the client that some push
756 event has happened on the server, so it must connect to fetch the
757 information.
759 When the client finally connects, the Lemonade server has opportunity
760 to send other pending events for this client.
762 Example: new message arrives on the server and this is notified via
763 outband.
764 S: pushes SMS with the following text:
766
769
770 C: needs to connect and send any command to get the pending events
771 and act upon them.
772 C: A00 Login joe password
773 S: * SESSION SELECTED
774 S: * FOLDER INBOX
775 S: * 100 EXITS
776 S: * 87 EXPUNGE
777 S: * 90 FETCH (FLAGS \Seen)
778 S: A00 OK LOGIN completed
779 C: must now act on the events on the order they are received,
780 meaning, first perform a FETCH to get new message, then expunge
781 message 87 and change flags of message 90.
783 Non-Normative Appendices
785 B. Use Cases
787 In this section some use cases on Lemonade are presented so that it
788 is possible to correctly understand concepts and message flow.
790 B.1. State Comparison-Based Sync
792 Each time a client logs into a new Lemonade session, it must perform
793 a state comparison-based sync. To synchronize with the server, the
794 client needs to fetch all the new messages, and all the flags of the
795 old messages.
797 The client has N messages in a given folder with highest UID = X and
798 is disconnected from the Lemonade server. It connects to the server
799 and performs the following command:
801 First, it retrieves all the new messages.
802 C: A01 UID FETCH X+1:* ALL
803 S: * m FETCH ...
804 S: ...
805 S: A01 OK FETCH completed
807 The client stores all this information on the device and displays
808 it. Next, it wishes to sync up the old messages.
809 C: A02 FETCH 1:m-1 (UID FLAGS)
810 S: * 1 FETCH (UID 3242 FLAGS (\Seen ...))
811 S: ...
812 S: * n FETCH (UID 3589 FLAGS (\Seen ...))
813 S: A02 OK FETCH completed
815 B.2. Event-Based Sync
817 During a Lemonade session, the client will receive events in the form
818 of untagged EXISTS, RECENT, EXPUNGE, or FETCH responses. The client
819 must respond to these events. Sometimes, it will receive these
820 events by polling, by issuing a Lemonade command, such as NOOP. It
821 can also use IDLE so that the server can push events to the client.
822 The example following shows how the client acts during an IDLE
823 command, but it should also take the same actions (minus firing and
824 exiting IDLE mode) when it receives these events through polling.
826 A client can choose to issue an IDLE command to get events pushed to
827 it, or it can receive events from polling using NOOP or any other
828 IMAP command. First the client issues the IDLE command:
829 C: A02 IDLE
830 S: + Ready for argument
832 Now the client can receive any of the three following untagged
833 responses from the server.
835 When the client receives an EXISTS/RECENT response from the server:
836 S: * 501 EXISTS
837 First, the client must exit from this IDLE command.
838 C: DONE
839 S: A02 OK IDLE completed
840 Next, the client retrieves this new message using a FETCH command.
841 C: A02 FETCH 501 ALL
842 S: * 501 FETCH ...
843 S: A02 OK FETCH completed
844 The client returns to IDLE mode by issuing another IDLE command.
845 C: A03 IDLE
846 S: + Ready for argument
848 When the client receives an EXPUNGE response from the server:
849 S: * 25 EXPUNGE
850 The client deletes this message from the client device, as it has
851 been removed permanently from the folder. The client can remain in
852 IDLE mode.
854 When the client receives an untagged FETCH response from the server,
855 either signally a flag change to an old message or a new message:
856 S: * 101 FETCH (FLAGS (\Seen \Deleted))
857 The client updates the information on the device for this message
858 appropriately.
860 Authors Addresses
861 Stephane H. Maes
862 Oracle Corporation
863 500 Oracle Parkway
864 M/S 4op634
865 Redwood Shores, CA 94065
866 USA
867 Phone: +1-650-607-6296
868 Email: stephane.maes@oracle.com
870 Corby Wilson
871 Enterprise Mobility Systems
872 Nokia
873 503 Martindale Street
874 Suite 610
875 Pittsburgh, PA 15212
876 USA
877 Phone: +1-412-576-5402
878 Email: Corby.Wilson@nokia.com
880 Intellectual Property Statement
882 The IETF takes no position regarding the validity or scope of any
883 intellectual property or other rights that might be claimed to
884 pertain to the implementation or use of the technology described in
885 this document or the extent to which any license under such rights
886 might or might not be available; neither does it represent that it
887 has made any effort to identify any such rights. Information on the
888 IETF's procedures with respect to rights in standards-track and
889 standards-related documentation can be found in BCP-11. Copies of
890 claims of rights made available for publication and any assurances of
891 licenses to be made available, or the result of an attempt made to
892 obtain a general license or permission for the use of such
893 proprietary rights by implementors or users of this specification can
894 be obtained from the IETF Secretariat.
896 The IETF invites any interested party to bring to its attention any
897 copyrights, patents or patent applications, or other proprietary
898 rights which may cover technology that may be required to practice
899 this standard. Please address the information to the IETF Executive
900 Director.
902 Acknowledgement
904 Funding for the RFC Editor function is currently provided by the
905 Internet Society.
907 Full Copyright Statement
908 Copyright (C) The Internet Society 2003. All Rights Reserved.
910 This document and translations of it may be copied and furnished to
911 others, and derivative works that comment on or otherwise explain it
912 or assist in its implementation may be prepared, copied, published
913 and distributed, in whole or in part, without restriction of any
914 kind, provided that the above copyright notice and this paragraph are
915 included on all such copies and derivative works. However, this
916 document itself may not be modified in any way, such as by removing
917 the copyright notice or references to the Internet Society or other
918 Internet organizations, except as needed for the purpose of
919 developing Internet standards in which case the procedures for
920 copyrights defined in the Internet Standards process must be
921 followed, or as required to translate it into languages other than
922 English.
924 The limited permissions granted above are perpetual and will not be
925 revoked by the Internet Society or its successors or assigns.
927 This document and the information contained herein is provided on an
928 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
929 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
930 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
931 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
932 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
934 Acknowledgement
936 This document is based on the work in progress described in
937 draft-maes-lemonade-p-imap-03.txt.