rfc5437.txt - rohrpost - A commandline mail client to change the world as we see it.
(HTM) git clone git://r-36.net/rohrpost
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
rfc5437.txt (28448B)
---
1
2
3
4
5
6
7 Network Working Group P. Saint-Andre
8 Request for Comments: 5437 Cisco
9 Category: Standards Track A. Melnikov
10 Isode Limited
11 January 2009
12
13
14 Sieve Notification Mechanism:
15 Extensible Messaging and Presence Protocol (XMPP)
16
17 Status of This Memo
18
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
24
25 Copyright Notice
26
27 Copyright (c) 2009 IETF Trust and the persons identified as the
28 document authors. All rights reserved.
29
30 This document is subject to BCP 78 and the IETF Trust's Legal
31 Provisions Relating to IETF Documents (http://trustee.ietf.org/
32 license-info) in effect on the date of publication of this document.
33 Please review these documents carefully, as they describe your rights
34 and restrictions with respect to this document.
35
36 Abstract
37
38 This document describes a profile of the Sieve extension for
39 notifications, to allow notifications to be sent over the Extensible
40 Messaging and Presence Protocol (XMPP), also known as Jabber.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Saint-Andre & Melnikov Standards Track [Page 1]
59
60 RFC 5437 Sieve Notify Method: XMPP January 2009
61
62
63 Table of Contents
64
65 1. Introduction ....................................................3
66 1.1. Overview ...................................................3
67 1.2. Terminology ................................................3
68 2. Definition ......................................................3
69 2.1. Notify Parameter "method" ..................................3
70 2.2. Test notify_method_capability ..............................3
71 2.3. Notify Tag ":from" .........................................4
72 2.4. Notify Tag ":importance" ...................................4
73 2.5. Notify Tag ":message" ......................................4
74 2.6. Notify Tag ":options" ......................................4
75 2.7. XMPP Syntax ................................................4
76 3. Examples ........................................................6
77 3.1. Basic Action ...............................................6
78 3.2. Action with "body" .........................................7
79 3.3. Action with "body", ":importance", ":message", and
80 "subject" ..................................................7
81 3.4. Action with ":from", ":message", ":importance",
82 "body", and "subject" ......................................8
83 4. Requirements Conformance ........................................9
84 5. Internationalization Considerations ............................10
85 6. Security Considerations ........................................11
86 7. IANA Considerations ............................................12
87 8. References .....................................................12
88 8.1. Normative References ......................................12
89 8.2. Informative References ....................................13
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114 Saint-Andre & Melnikov Standards Track [Page 2]
115
116 RFC 5437 Sieve Notify Method: XMPP January 2009
117
118
119 1. Introduction
120
121 1.1. Overview
122
123 The [NOTIFY] extension to the [SIEVE] mail filtering language is a
124 framework for providing notifications by employing URIs to specify
125 the notification mechanism. This document defines how xmpp URIs (see
126 [XMPP-URI]) are used to generate notifications via the Extensible
127 Messaging and Presence Protocol [XMPP], which is widely implemented
128 in Jabber instant messaging technologies.
129
130 1.2. Terminology
131
132 This document inherits terminology from [NOTIFY], [SIEVE], and
133 [XMPP]. In particular, the terms "parameter" and "tag" are used as
134 described in [NOTIFY] to refer to aspects of Sieve scripts, and the
135 term "key" is used as described in [XMPP-URI] to refer to aspects of
136 an XMPP URI.
137
138 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
139 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
140 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
141 interpreted as described in [TERMS].
142
143 2. Definition
144
145 2.1. Notify Parameter "method"
146
147 The "method" parameter MUST be a URI that conforms to the xmpp URI
148 scheme (as specified in [XMPP-URI]) and that identifies an XMPP
149 account associated with the email inbox. The URI MAY include the
150 resource identifier of an XMPP address and/or the query component
151 portion of an XMPP URI, but SHOULD NOT include an authority component
152 or fragment identifier component. The processing application MUST
153 extract an XMPP address from the URI in accordance with the
154 processing rules specified in [XMPP-URI]. The resulting XMPP address
155 MUST be encapsulated in XMPP syntax as the value of the XMPP 'to'
156 attribute.
157
158 2.2. Test notify_method_capability
159
160 In response to a notify_method_capability test for the "online"
161 notification-capability, an implementation SHOULD return a value of
162 "yes" if it has knowledge of an active presence session (see
163 [XMPP-IM]) for the specified XMPP notification-uri; otherwise, it
164 SHOULD return a value of "maybe" (since typical XMPP systems may not
165 allow a Sieve engine to gain knowledge about the presence of XMPP
166 entities).
167
168
169
170 Saint-Andre & Melnikov Standards Track [Page 3]
171
172 RFC 5437 Sieve Notify Method: XMPP January 2009
173
174
175 2.3. Notify Tag ":from"
176
177 If included, the ":from" tag MUST be an electronic address that
178 conforms to the "Mailbox" rule defined in [RFC5321]. The value of
179 the ":from" tag MAY be included in the human-readable XML character
180 data of the XMPP notification; alternatively or in addition, it MAY
181 be transformed into formal XMPP syntax, in which case it MUST be
182 encapsulated as the value of an XMPP SHIM (Stanza Headers and
183 Internet Metadata) [SHIM] header named "Resent-From".
184
185 2.4. Notify Tag ":importance"
186
187 The ":importance" tag has no special meaning for this notification
188 mechanism, and this specification puts no restriction on its use.
189 The value of the ":importance" tag MAY be transformed into XMPP
190 syntax (in addition to or instead of including appropriate text in
191 the XML character data of the XMPP <body/> element); if so, it SHOULD
192 be encapsulated as the value of an XMPP SHIM (Stanza Headers and
193 Internet Metadata) [SHIM] header named "Urgency", where the XML
194 character of that header is "high" if the value of the ":importance"
195 tag is "1", "medium" if the value of the ":importance" tag is "2",
196 and "low" if the value of the ":importance" tag is "3".
197
198 2.5. Notify Tag ":message"
199
200 If the ":message" tag is included, that string MUST be transformed
201 into the XML character data of an XMPP <body/> element (where the
202 string is generated according to the guidelines specified in Section
203 3.6 of [NOTIFY]).
204
205 2.6. Notify Tag ":options"
206
207 The ":options" tag has no special meaning for this notification
208 mechanism. Any handling of this tag is the responsibility of an
209 implementation.
210
211 2.7. XMPP Syntax
212
213 The xmpp mechanism results in the sending of an XMPP message to
214 notify a recipient about an email message. The general XMPP syntax
215 is as follows:
216
217 o The notification MUST be an XMPP <message/> stanza.
218
219
220
221
222
223
224
225
226 Saint-Andre & Melnikov Standards Track [Page 4]
227
228 RFC 5437 Sieve Notify Method: XMPP January 2009
229
230
231 o The value of the XMPP 'from' attribute SHOULD be the XMPP address
232 of the notification service associated with the Sieve engine or
233 the XMPP address of the entity to be notified. The value of the
234 XMPP 'from' attribute MUST NOT be generated from the Sieve ":from"
235 tag.
236
237 o The value of the XMPP 'to' attribute MUST be the XMPP address
238 specified in the XMPP URI contained in the "method" notify
239 parameter.
240
241 o The value of the XMPP 'type' attribute MUST be 'headline' or
242 'normal'.
243
244 o The XMPP <message/> stanza MUST include a <body/> child element.
245 If the ":message" tag is included in the Sieve script, that string
246 MUST be used as the XML character data of the <body/> element. If
247 not and if the XMPP URI contained in the "method" notify parameter
248 specified a "body" key in the query component, that value SHOULD
249 be used. Otherwise, the XML character data SHOULD be some
250 configurable text indicating that the message is a Sieve
251 notification.
252
253 o The XMPP <message/> stanza MAY include a <subject/> child element.
254 If the XMPP URI contained in the "method" notify parameter
255 specified a "subject" key in the query component, that value
256 SHOULD be used as the XML character data of the <subject/>
257 element. Otherwise, the XML character data SHOULD be some
258 configurable text indicating that the message is a Sieve
259 notification.
260
261 o The XMPP <message/> stanza SHOULD include a URI, for the recipient
262 to use as a hint in locating the message, encapsulated as the XML
263 character data of a <url/> child element of an <x/> element
264 qualified by the 'jabber:x:oob' namespace, as specified in [OOB].
265 If included, the URI SHOULD be an Internet Message Access Protocol
266 [IMAP] URL that specifies the location of the message, as defined
267 in [IMAP-URL], but MAY be another URI type that can specify or
268 hint at the location of an email message, such as a URI for an
269 HTTP resource [HTTP] or a Post Office Protocol Version 3 (POP3)
270 mailbox [POP-URL] at which the message can be accessed. It is not
271 expected that an XMPP user agent shall directly handle such a URI,
272 but instead that it shall invoke an appropriate helper application
273 to handle the URI.
274
275 o The XMPP <message/> stanza MAY include an XMPP SHIM (Stanza
276 Headers and Internet Metadata) [SHIM] header named "Resent-From".
277 If the Sieve script included a ":from" tag, the "Resent-From"
278
279
280
281
282 Saint-Andre & Melnikov Standards Track [Page 5]
283
284 RFC 5437 Sieve Notify Method: XMPP January 2009
285
286
287 value MUST be the value of the ":from" tag; otherwise, the
288 "Resent-From" value SHOULD be the envelope recipient address of
289 the original email message that triggered the notification.
290
291 3. Examples
292
293 In the following examples, the sender of the email has an address of
294 <mailto:juliet@example.org>, the entity to be notified has an email
295 address of <mailto:romeo@example.com> and an XMPP address of
296 romeo@im.example.com (resulting in an XMPP URI of
297 <xmpp:romeo@im.example.com>), and the notification service associated
298 with the Sieve engine has an XMPP address of notify.example.com.
299
300 Note: In the following examples, line breaks are included in XMPP
301 URIs solely for the purpose of readability.
302
303 3.1. Basic Action
304
305 The following is a basic Sieve notify action with only a method. The
306 XML character data of the XMPP <body/> and <subject/> elements are
307 therefore generated by the Sieve engine based on configuration. In
308 addition, the Sieve engine includes a URI pointing to the message.
309
310 Basic action (Sieve syntax)
311
312 notify "xmpp:romeo@im.example.com"
313
314 The resulting XMPP <message/> stanza might be as follows:
315
316 Basic action (XMPP syntax)
317
318 <message from='notify.example.com'
319 to='romeo@im.example.com'
320 type='headline'
321 xml:lang='en'>
322 <subject>SIEVE</subject>
323 <body><juliet@example.com> You got mail.</body>
324 <x xmlns='jabber:x:oob'>
325 <url>
326 imap://romeo@example.com/INBOX;UIDVALIDITY=385759043/;UID=18
327 </url>
328 </x>
329 </message>
330
331
332
333
334
335
336
337
338 Saint-Andre & Melnikov Standards Track [Page 6]
339
340 RFC 5437 Sieve Notify Method: XMPP January 2009
341
342
343 3.2. Action with "body"
344
345 The following action contains a "body" key in the query component of
346 the XMPP URI but no ":message" tag in the Sieve script. As a result,
347 the XML character data of the XMPP <body/> element in the XMPP
348 notification is taken from the XMPP URI. In addition, the Sieve
349 engine includes a URI pointing to the message.
350
351 Action with "body" (Sieve syntax)
352
353 notify "xmpp:romeo@im.example.com?message
354 ;body=Wherefore%20art%20thou%3F"
355
356 The resulting XMPP <message/> stanza might be as follows.
357
358 Action with "body" (XMPP syntax)
359
360 <message from='notify.example.com'
361 to='romeo@im.example.com'
362 type='headline'
363 xml:lang='en'>
364 <subject>SIEVE</subject>
365 <body>Wherefore art thou?</body>
366 <x xmlns='jabber:x:oob'>
367 <url>
368 imap://romeo@example.com/INBOX;UIDVALIDITY=385759044/;UID=19
369 </url>
370 </x>
371 </message>
372
373 3.3. Action with "body", ":importance", ":message", and "subject"
374
375 The following action specifies an ":importance" tag and a ":message"
376 tag in the Sieve script, as well as a "body" key and a "subject" key
377 in the query component of the XMPP URI. As a result, the ":message"
378 tag from the Sieve script overrides the "body" key from the XMPP URI
379 when generating the XML character data of the XMPP <body/> element.
380 In addition, the Sieve engine includes a URI pointing to the message.
381
382 Action with "body", ":importance", ":message", and "subject" (Sieve
383 syntax)
384
385 notify :importance "1"
386 :message "Contact Juliet immediately!"
387 "xmpp:romeo@im.example.com?message
388 ;body=You%27re%20in%20trouble
389 ;subject=ALERT%21"
390
391
392
393
394 Saint-Andre & Melnikov Standards Track [Page 7]
395
396 RFC 5437 Sieve Notify Method: XMPP January 2009
397
398
399 The resulting XMPP <message/> stanza might be as follows.
400
401 Action with "body", ":importance", ":message", and "subject" (XMPP
402 syntax)
403
404 <message from='notify.example.com'
405 to='romeo@im.example.com'
406 type='headline'
407 xml:lang='en'>
408 <subject>ALERT!</subject>
409 <body>Contact Juliet immediately!</body>
410 <headers xmlns='http://jabber.org/protocol/shim'>
411 <header name='Urgency'>high</header>
412 </headers>
413 <x xmlns='jabber:x:oob'>
414 <url>
415 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20
416 </url>
417 </x>
418 </message>
419
420 3.4. Action with ":from", ":message", ":importance", "body", and
421 "subject"
422
423 The following action specifies a ":from" tag, an ":importance" tag,
424 and a ":message" tag in the Sieve script, as well as a "body" key and
425 a "subject" key in the query component of the XMPP URI. As a result,
426 the ":message" tag from the Sieve script overrides the "body" key
427 from the XMPP URI when generating the XML character data of the XMPP
428 <body/> element. In addition, the Sieve engine includes a URI
429 pointing to the message, as well as an XMPP SHIM (Stanza Headers and
430 Internet Metadata) [SHIM] header named "Resent-From" (which
431 encapsulates the value of the ":from" tag).
432
433 Action with ":from", ":importance", ":message", "body", and "subject"
434 (Sieve syntax)
435
436 notify :from "romeo.my.romeo@example.com"
437 :importance "1"
438 :message "Contact Juliet immediately!"
439 "xmpp:romeo@im.example.com?message
440 ;body=You%27re%20in%20trouble
441 ;subject=ALERT%21"
442
443 The resulting XMPP <message/> stanza might be as follows.
444
445
446
447
448
449
450 Saint-Andre & Melnikov Standards Track [Page 8]
451
452 RFC 5437 Sieve Notify Method: XMPP January 2009
453
454
455 Action with ":from", ":importance", ":message", "body", and "subject"
456 (XMPP syntax)
457
458 <message from='notify.example.com'
459 to='romeo@im.example.com'
460 type='headline'
461 xml:lang='en'>
462 <subject>ALERT!</subject>
463 <body>Contact Juliet immediately!</body>
464 <headers xmlns='http://jabber.org/protocol/shim'>
465 <header name='Resent-From'>romeo.my.romeo@example.com</header>
466 <header name='Urgency'>high</header>
467 </headers>
468 <x xmlns='jabber:x:oob'>
469 <url>
470 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=21
471 </url>
472 </x>
473 </message>
474
475 4. Requirements Conformance
476
477 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve
478 notification methods. The conformance of the xmpp notification
479 mechanism is provided here.
480
481 1. An implementation of the xmpp notification method SHOULD NOT
482 modify the final notification text (e.g., to limit the length);
483 however, a given deployment MAY do so (e.g., if recipients pay
484 per character or byte for XMPP messages). Modification of
485 characters themselves should not be necessary, since XMPP
486 character data is encoded in [UTF-8].
487
488 2. An implementation MAY ignore parameters specified in the
489 ":from", ":importance", and ":options" tags.
490
491 3. There is no recommended default message for an implementation to
492 include if the ":message" tag is not specified.
493
494 4. A notification sent via the xmpp notification method MAY include
495 a timestamp in the textual message.
496
497 5. The value of the XMPP 'from' attribute MUST be the XMPP address
498 of the notification service associated with the Sieve engine.
499 The value of the Sieve ":from" tag MAY be transformed into the
500 value of an XMPP SHIM (Stanza Headers and Internet Metadata)
501 [SHIM] header named "Resent-From".
502
503
504
505
506 Saint-Andre & Melnikov Standards Track [Page 9]
507
508 RFC 5437 Sieve Notify Method: XMPP January 2009
509
510
511 6. The value of the XMPP 'to' attribute MUST be the XMPP address
512 specified in the XMPP URI contained in the "method" parameter.
513
514 7. In accordance with [XMPP-URI], an implementation MUST ignore any
515 URI action or key it does not understand (i.e., the URI MUST be
516 processed as if the action or key were not present). It is
517 RECOMMENDED to support the XMPP "message" query type (see
518 [QUERIES]) and the associated "body" and "subject" keys, which
519 SHOULD be mapped to the XMPP <body/> and <subject/> child
520 elements of the XMPP <message/> stanza, respectively. However,
521 if included, then the Sieve notify ":message" tag MUST be mapped
522 to the XMPP <body/> element, overriding the "body" key (if any)
523 included in the XMPP URI.
524
525 8. An implementation MUST NOT include any other extraneous
526 information not specified in parameters to the notify action.
527
528 9. In response to a notify_method_capability test for the "online"
529 notification-capability, an implementation SHOULD return a value
530 of "yes" if it has knowledge of an active presence session (see
531 [XMPP-IM]) for the specified XMPP notification-uri, but only if
532 the entity that requested the test is authorized to know the
533 presence of the associated XMPP entity (e.g., via explicit
534 presence subscription as specified in [XMPP-IM]); otherwise, it
535 SHOULD return a value of "maybe" (since typical XMPP systems may
536 not allow a Sieve engine to gain knowledge about the presence of
537 XMPP entities).
538
539 10. An implementation SHOULD NOT attempt to retry delivery of a
540 notification if it receives an XMPP error of type "auth" or
541 "cancel", MAY attempt to retry delivery if it receives an XMPP
542 error of type "wait", and MAY attempt to retry delivery if it
543 receives an XMPP error of "modify", but only if it makes
544 appropriate modifications to the notification (see [XMPP]); in
545 any case, the number of retries SHOULD be limited to a
546 configurable number no less than 3 and no more than 10. An
547 implementation MAY throttle notifications if the number of
548 notifications within a given time period becomes excessive
549 according to local service policy. Duplicate suppression (if
550 any) is a matter of implementation and is not specified herein.
551
552 5. Internationalization Considerations
553
554 Although an XMPP address may contain nearly any [UNICODE] character,
555 the value of the "method" parameter MUST be a Uniform Resource
556 Identifier (see [URI]) rather than an Internationalized Resource
557 Identifier (see [IRI]). The rules specified in [XMPP-URI] MUST be
558 followed when generating XMPP URIs.
559
560
561
562 Saint-Andre & Melnikov Standards Track [Page 10]
563
564 RFC 5437 Sieve Notify Method: XMPP January 2009
565
566
567 In accordance with Section 13 of RFC 3920, all data sent over XMPP
568 MUST be encoded in [UTF-8].
569
570 6. Security Considerations
571
572 Depending on the information included, sending a notification can be
573 comparable to forwarding mail to the notification recipient. Care
574 must be taken when forwarding mail automatically, to ensure that
575 confidential information is not sent into an insecure environment.
576 In particular, implementations MUST conform to the security
577 considerations given in [NOTIFY], [SIEVE], and [XMPP].
578
579 [NOTIFY] specifies that a notification method MUST provide mechanisms
580 for avoiding notification loops. One type of notification loop can
581 be caused by message forwarding; however, such loops are prevented
582 because XMPP does not support the forwarding of messages from one
583 XMPP address to another. Another type of notification loop can be
584 caused by auto-replies to XMPP messages received by the XMPP
585 notification service associated with the Sieve engine; therefore,
586 such a service MUST NOT auto-reply to XMPP messages it receives.
587
588 A common use case might be for a user to create a script that enables
589 the Sieve engine to act differently if the user is currently
590 available at a particular type of service (e.g., send notifications
591 to the user's XMPP address if the user has an active session at an
592 XMPP service). Whether the user is currently available can be
593 determined by means of a notify_method_capability test for the
594 "online" notification-capability. In XMPP, information about current
595 network availability is called "presence" (see also [MODEL]). Since
596 [XMPP-IM] requires that a user must approve a presence subscription
597 before an entity can gain access to the user's presence information,
598 a limited but reasonably safe implementation might be for the Sieve
599 engine to request a subscription to the user's presence. The user
600 would then need to approve that subscription request so that the
601 Sieve engine can act appropriately depending on whether the user is
602 online or offline. However, the Sieve engine MUST NOT use the user's
603 presence information when processing scripts on behalf of a script
604 owner other than the user, unless the Sieve engine has explicit
605 knowledge (e.g., via integration with an XMPP server's presence
606 authorization rules) that the script owner is authorized to know the
607 user's presence. While it would be possible to design a more
608 advanced approach to the delegation of presence authorization, any
609 such approach is left to future standards work.
610
611
612
613
614
615
616
617
618 Saint-Andre & Melnikov Standards Track [Page 11]
619
620 RFC 5437 Sieve Notify Method: XMPP January 2009
621
622
623 7. IANA Considerations
624
625 The following template provides the IANA registration of the Sieve
626 notification mechanism specified in this document:
627
628 To: iana@iana.org
629 Subject: Registration of new Sieve notification mechanism
630 Mechanism name: xmpp
631 Mechanism URI: RFC 5122 [XMPP-URI]
632 Mechanism-specific options: none
633 Permanent and readily available reference: RFC 5437
634 Person and email address to contact for further information:
635 Peter Saint-Andre <registrar@xmpp.org>
636
637 This information has been added to the list of Sieve notification
638 mechanisms maintained at <http://www.iana.org>.
639
640 8. References
641
642 8.1. Normative References
643
644 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
645 Martin, "Sieve Email Filtering: Extension for
646 Notifications", RFC 5435, January 2009.
647
648 [OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066,
649 August 2006.
650
651 [QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF
652 XEP 0147, September 2006.
653
654 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
655 October 2008.
656
657 [SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and
658 Internet Metadata", XSF XEP 0131, July 2006.
659
660 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
661 Filtering Language", RFC 5228, January 2008.
662
663 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
664 Requirement Levels", BCP 14, RFC 2119, March 1997.
665
666 [XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers
667 (IRIs) and Uniform Resource Identifiers (URIs) for the
668 Extensible Messaging and Presence Protocol (XMPP)",
669 RFC 5122, February 2008.
670
671
672
673
674 Saint-Andre & Melnikov Standards Track [Page 12]
675
676 RFC 5437 Sieve Notify Method: XMPP January 2009
677
678
679 8.2. Informative References
680
681 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
682 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
683 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
684
685 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
686 4rev1", RFC 3501, March 2003.
687
688 [IMAP-URL] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092,
689 November 2007.
690
691 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
692 Identifiers (IRIs)", RFC 3987, January 2005.
693
694 [MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
695 Presence and Instant Messaging", RFC 2778, February 2000.
696
697 [POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
698
699 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
700 3.2.0", 2000.
701
702 The Unicode Standard, Version 3.2.0 is defined by The
703 Unicode Standard, Version 3.0 (Reading, MA, Addison-
704 Wesley, 2000. ISBN 0-201-61633-5), as amended by the
705 Unicode Standard Annex #27: Unicode 3.1
706 (http://www.unicode.org/reports/tr27/) and by the Unicode
707 Standard Annex #28: Unicode 3.2
708 (http://www.unicode.org/reports/tr28/).
709
710 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
711 Resource Identifier (URI): Generic Syntax", STD 66,
712 RFC 3986, January 2005.
713
714 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
715 10646", STD 63, RFC 3629, November 2003.
716
717 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
718 Protocol (XMPP): Core", RFC 3920, October 2004.
719
720 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
721 Protocol (XMPP): Instant Messaging and Presence",
722 RFC 3921, October 2004.
723
724
725
726
727
728
729
730 Saint-Andre & Melnikov Standards Track [Page 13]
731
732 RFC 5437 Sieve Notify Method: XMPP January 2009
733
734
735 Authors' Addresses
736
737 Peter Saint-Andre
738 Cisco
739
740 EMail: psaintan@cisco.com
741
742
743 Alexey Melnikov
744 Isode Limited
745
746 EMail: Alexey.Melnikov@isode.com
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786 Saint-Andre & Melnikov Standards Track [Page 14]
787