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