idnits 2.17.1 draft-ietf-sieve-notify-xmpp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 625. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2008) is 5904 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OOB' -- Possible downref: Non-RFC (?) normative reference: ref. 'QUERIES' ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHIM' -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group P. Saint-Andre 3 Internet-Draft XMPP Standards Foundation 4 Intended status: Standards Track A. Melnikov 5 Expires: August 22, 2008 Isode Limited 6 February 19, 2008 8 Sieve Notification Mechanism: xmpp 9 draft-ietf-sieve-notify-xmpp-09 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 22, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes a profile of the Sieve extension for 43 notifications, to allow notifications to be sent over the Extensible 44 Messaging and Presence Protocol (XMPP), also known as Jabber. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . 3 53 2.2. Test notify_method_capability . . . . . . . . . . . . . . 3 54 2.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 4 55 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . 4 56 2.5. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4 57 2.6. Notify tag ":options" . . . . . . . . . . . . . . . . . . 4 58 2.7. XMPP syntax . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Basic action . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Action with body . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. Action with body, importance, message, and subject . . . . 7 63 3.4. Action with from, message, importance, body, and 64 subject . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Requirements Conformance . . . . . . . . . . . . . . . . . . . 9 66 5. Internationalization Considerations . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 15 75 1. Introduction 77 1.1. Overview 79 The [NOTIFY] extension to the [SIEVE] mail filtering language is a 80 framework for providing notifications by employing URIs to specify 81 the notification mechanism. This document defines how xmpp URIs (see 82 [XMPP-URI]) are used to generate notifications via the Extensible 83 Messaging and Presence Protocol [XMPP], which is widely implemented 84 in Jabber instant messaging technologies. 86 1.2. Terminology 88 This document inherits terminology from [NOTIFY], [SIEVE], and 89 [XMPP]. 91 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 92 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 93 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 94 interpreted as described in [TERMS]. 96 2. Definition 98 2.1. Notify parameter "method" 100 The "method" parameter MUST be a URI that conforms to the xmpp URI 101 scheme (as specified in [XMPP-URI]) and that identifies an XMPP 102 account associated with the email inbox. The URI MAY include the 103 resource identifier of an XMPP address and/or the query component 104 portion of an XMPP URI, but SHOULD NOT include an authority component 105 or fragment identifier component. The processing application MUST 106 extract an XMPP address from the URI in accordance with the 107 processing rules specified in [XMPP-URI]. The resulting XMPP address 108 MUST be encapsulated in XMPP syntax as the value of the XMPP 'to' 109 attribute. 111 2.2. Test notify_method_capability 113 In response to a notify_method_capability test for the "online" 114 notification-capability, an implementation SHOULD return a value of 115 "yes" if it has knowledge of an active presence session (see 116 [XMPP-IM]) for the specified XMPP notification-uri; otherwise it 117 SHOULD return a value of "maybe" (since typical XMPP systems may not 118 allow a Sieve engine to gain knowledge about the presence of XMPP 119 entities). 121 2.3. Notify tag ":from" 123 If included, the ":from" tag MUST be an electronic address that 124 conforms to the "Mailbox" rule defined in [RFC2821]. The value of 125 the ":from" tag MAY be included in the human-readable XML character 126 data of the XMPP notification; alternatively or in addition, it MAY 127 be transformed into formal XMPP syntax, in which case it MUST be 128 encapsulated as the value of an XMPP Stanza Headers and Internet 129 Metadata [SHIM] header named "Resent-From". 131 2.4. Notify tag ":importance" 133 The ":importance" tag has no special meaning for this notification 134 mechanism, and this specification puts no restriction on its use. 135 The value of the ":importance" tag MAY be transformed into XMPP 136 syntax (in addition to or instead of including appropriate text in 137 the XML character data of the XMPP element); if so, it SHOULD 138 be encapsulated as the value of an XMPP Stanza Headers and Internet 139 Metadata [SHIM] header named "Urgency", where the XML character of 140 that header is "high" if the value of the ":importance" tag is "1", 141 "medium" if the value of the ":importance" tag is "2", and "low" if 142 the value of the ":importance" tag is "3". 144 2.5. Notify tag ":message" 146 If the ":message" tag is included, that string MUST be transformed 147 into the XML character data of an XMPP element (where the 148 string is generated according to the guidelines specified in Section 149 3.6 of [NOTIFY]). 151 2.6. Notify tag ":options" 153 The ":options" tag has no special meaning for this notification 154 mechanism. Any handling of this tag is the responsibility of an 155 implementation. 157 2.7. XMPP syntax 159 The xmpp mechanism results in the sending of an XMPP message to 160 notify a recipient about an email message. The general XMPP syntax 161 is as follows: 163 o The notification MUST be an XMPP stanza. 164 o The value of the XMPP 'from' attribute SHOULD be the XMPP address 165 of the notification service associated with the Sieve engine or 166 the XMPP address of the entity to be notified. The value of the 167 XMPP 'from' attribute MUST NOT be generated from the Sieve ":from" 168 tag. 170 o The value of the XMPP 'to' attribute MUST be the XMPP address 171 specified in the XMPP URI contained in the "method" notify 172 parameter. 173 o The value of the XMPP 'type' attribute MUST be 'headline' or 174 'normal'. 175 o The XMPP stanza MUST include a child element. 176 If the ":message" tag is included in the Sieve script, that string 177 MUST be used as the XML character data of the element. If 178 not and if the XMPP URI contained in the "method" notify parameter 179 specified a "body" parameter in the query component, that value 180 SHOULD be used. Otherwise the XML character data SHOULD be some 181 configurable text indicating that the message is a Sieve 182 notification. 183 o The XMPP stanza MAY include a child element. 184 If the XMPP URI contained in the "method" notify parameter 185 specified a "subject" parameter in the query component, that value 186 SHOULD be used as the XML character data of the 187 element. Otherwise the XML character data SHOULD be some 188 configurable text indicating that the message is a Sieve 189 notification. 190 o The XMPP stanza SHOULD include a URI for the recipient 191 to use as a hint in locating the message, encapsulated as the XML 192 character data of a child element of an element 193 qualified by the 'jabber:x:oob' namespace as specified in [OOB]. 194 If included, the URI SHOULD be an Internet Message Access Protocol 195 [IMAP] URL that specifies the location of the message as defined 196 in [IMAP-URL], but MAY be another URI type that can specify or 197 hint at the location of an email message, such as a URI for an 198 HTTP resource [HTTP] or a POP3 mailbox [POP-URL] at which the 199 message can be accessed. It is not expected that an XMPP user 200 agent shall directly handle such a URI, but instead that it shall 201 invoke an appropriate helper application to handle the URI. 202 o The XMPP stanza MAY include an XMPP Stanza Headers and 203 Internet Metadata [SHIM] header named "Resent-From". If the Sieve 204 script included a ":from" tag, the "Resent-From" value MUST be the 205 value of the ":from" tag; otherwise the "Resent-From" value SHOULD 206 be the envelope recipient address of the original email message 207 that triggered the notification. 209 3. Examples 211 In the following examples, the sender of the email has an address of 212 , the entity to be notified has an email 213 address of and an XMPP address of 214 romeo@im.example.com (resulting in an XMPP URI of 215 ), and the notification service associated 216 with the Sieve engine has an XMPP address of notify.example.com. 218 Note: In the following examples, line breaks are included in XMPP 219 URIs solely for the purpose of readability. 221 3.1. Basic action 223 The following is a basic Sieve notify action with only a method. The 224 XML character data of the XMPP and elements are 225 therefore generated by the Sieve engine based on configuration. In 226 addition, the Sieve engine includes a URI pointing to the message. 228 Basic action (Sieve syntax) 230 notify "xmpp:romeo@im.example.com" 232 The resulting XMPP stanza might be as follows. 234 Basic action (XMPP syntax) 236 240 SIEVE 241 <juliet@example.com> You got mail. 242 243 244 imap://romeo@example.com/INBOX;UIDVALIDITY=385759043/;UID=18 245 246 247 249 3.2. Action with body 251 The following action contains a "body" parameter in the query 252 component of the XMPP URI but no ":message" tag in the Sieve script. 253 As a result, the XML character data of the XMPP element in 254 the XMPP notification is taken from the XMPP URI. In addition, the 255 Sieve engine includes a URI pointing to the message. 257 Action with body (Sieve syntax) 259 notify "xmpp:romeo@im.example.com?message 260 ;body=Wherefore%20art%20thou%3F" 262 The resulting XMPP stanza might be as follows. 264 Action with body (XMPP syntax) 266 270 SIEVE 271 Wherefore art thou? 272 273 274 imap://romeo@example.com/INBOX;UIDVALIDITY=385759044/;UID=19 275 276 277 279 3.3. Action with body, importance, message, and subject 281 The following action specifies an ":importance" tag and a ":message" 282 tag in the Sieve script, as well as a "body" parameter and a 283 "subject" parameter in the query component of the XMPP URI. As a 284 result, the ":message" tag from the Sieve script overrides the "body" 285 parameter from the XMPP URI when generating the XML character data of 286 the XMPP element. In addition, the Sieve engine includes a 287 URI pointing to the message. 289 Action with body, importance, message, and subject (Sieve syntax) 291 notify :importance "1" 292 :message "Contact Juliet immediately!" 293 "xmpp:romeo@im.example.com?message 294 ;body=You%27re%20in%20trouble 295 ;subject=ALERT%21" 297 The resulting XMPP stanza might be as follows. 299 Action with body, importance, message, and subject (XMPP syntax) 301 305 ALERT! 306 Contact Juliet immediately! 307 308
high
309 310 311 312 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20 313 314 315 317 3.4. Action with from, message, importance, body, and subject 319 The following action specifies a ":from" tag, an ":importance" tag, 320 and a ":message" tag in the Sieve script, as well as a "body" 321 parameter and a "subject" parameter in the query component of the 322 XMPP URI. As a result, the ":message" tag from the Sieve script 323 overrides the "body" parameter from the XMPP URI when generating the 324 XML character data of the XMPP element. In addition, the 325 Sieve engine includes a URI pointing to the message, as well as an 326 XMPP Stanza Headers and Internet Metadata [SHIM] header named 327 "Resent-From" (which encapsulates the value of the ":from" tag). 329 Action with body, from, importance, message, and subject (Sieve 330 syntax) 332 notify :from "romeo.my.romeo@example.com" 333 :importance "1" 334 :message "Contact Juliet immediately!" 335 "xmpp:romeo@im.example.com?message 336 ;body=You%27re%20in%20trouble 337 ;subject=ALERT%21" 339 The resulting XMPP stanza might be as follows. 341 Action with body, from, importance, message, and subject (XMPP 342 syntax) 344 348 ALERT! 349 Contact Juliet immediately! 350 351
romeo.my.romeo@example.com
352
high
353 354 355 356 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=21 357 358 359 361 4. Requirements Conformance 363 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve 364 notification methods. The conformance of the xmpp notification 365 mechanism is provided here. 367 1. An implementation of the xmpp notification method SHOULD NOT 368 modify the final notification text (e.g., to limit the length); 369 however, a given deployment MAY do so (e.g., if recipients pay 370 per character or byte for XMPP messages). Modification of 371 characters themselves should not be necessary, since XMPP 372 character data is encoded in [UTF-8]. 373 2. An implementation MAY ignore parameters specified in the 374 ":from", ":importance", and ":options" tags. 375 3. There is no recommended default message for an implementation to 376 include if the ":message" argument is not specified. 377 4. A notification sent via the xmpp notification method MAY include 378 a timestamp in the textual message. 379 5. The value of the XMPP 'from' attribute MUST be the XMPP address 380 of the notification service associated with the Sieve engine. 381 The value of the Sieve ":from" tag MAY be transformed into the 382 value of an XMPP Stanza Headers and Internet Metadata [SHIM] 383 header named "Reply-To". 384 6. The value of the XMPP 'to' attribute MUST be the XMPP address 385 specified in the XMPP URI contained in the "method" parameter. 387 7. In accordance with [XMPP-URI], an implementation MUST ignore any 388 URI action or parameter it does not understand (i.e., the URI 389 MUST be processed as if the action or parameter were not 390 present). It is RECOMMENDED to support the XMPP "message" query 391 type (see [QUERIES]) and the associated "body" and "subject" 392 parameters, which parameters SHOULD be mapped to the XMPP 393 and child elements of the XMPP 394 stanza, respectively. However, if included then the Sieve 395 notify ":message" parameter MUST be mapped to the XMPP 396 element, overriding the "body" parameter (if any) included in 397 the XMPP URI. 398 8. An implementation MUST NOT include any other extraneous 399 information not specified in parameters to the notify action. 400 9. In response to a notify_method_capability test for the "online" 401 notification-capability, an implementation SHOULD return a value 402 of "yes" if it has knowledge of an active presence session (see 403 [XMPP-IM]) for the specified XMPP notification-uri but only if 404 the entity that requested the test is authorized to know the 405 presence of the associated XMPP entity (e.g., via explicit 406 presence subscription as specified in [XMPP-IM]); otherwise it 407 SHOULD return a value of "maybe" (since typical XMPP systems may 408 not allow a Sieve engine to gain knowledge about the presence of 409 XMPP entities). 410 10. An implementation SHOULD NOT attempt to retry delivery of a 411 notification if it receives an XMPP error of type "auth" or 412 "cancel", MAY attempt to retry delivery if it receives an XMPP 413 error of type "wait", and MAY attempt to retry delivery if it 414 receives an XMPP error of "modify" but only if it makes 415 appropriate modifications to the notification (see [XMPP]); in 416 any case the number of retries SHOULD be limited to a 417 configurable number no less than 3 and no more than 10. An 418 implementation MAY throttle notifications if the number of 419 notifications within a given time period becomes excessive 420 according to local service policy. Duplicate suppression (if 421 any) is a matter of implementation and is not specified herein. 423 5. Internationalization Considerations 425 Although an XMPP address may contain nearly any [UNICODE] character, 426 the value of the "method" parameter MUST be a Uniform Resource 427 Identifier (see [URI]) rather than an Internationalized Resource 428 Identifier (see [IRI]). The rules specified in [XMPP-URI] MUST be 429 followed when generating XMPP URIs. 431 In accordance with Section 13 of RFC 3920, all data sent over XMPP 432 MUST be encoded in [UTF-8]. 434 6. Security Considerations 436 Depending on the information included, sending a notification can be 437 comparable to forwarding mail to the notification recipient. Care 438 must be taken when forwarding mail automatically, to ensure that 439 confidential information is not sent into an insecure environment. 440 In particular, implementations MUST conform to the security 441 considerations given in [NOTIFY], [SIEVE], and [XMPP]. 443 [NOTIFY] specifies that a notification method MUST provide mechanisms 444 for avoiding notification loops. One type of notification loop can 445 be caused by message forwarding; however, such loops are prevented 446 because XMPP does not support forwarding of messages from one XMPP 447 address to another. Another type of notification loop can be caused 448 by auto-replies to XMPP messages received by the XMPP notification 449 service associated with the Sieve engine; therefore such a service 450 MUST NOT auto-reply to XMPP messages it receives. 452 A common use case might be for a user to create a script that enables 453 the Sieve engine to act differently if the user is currently 454 available at a particular type of service (e.g., send notifications 455 to the user's XMPP address if the user has an active session at an 456 XMPP service). Whether the user is currently available can be 457 determined by means of a notify_method_capability test for the 458 "online" notification-capability. In XMPP, information about current 459 network availability is called "presence" (see also [MODEL]). Since 460 [XMPP-IM] requires that a user must approve a presence subscription 461 before an entity can gain access to the user's presence information, 462 a limited but reasonably safe implementation might be for the Sieve 463 engine to request a subscription to the user's presence. The user 464 would then need to approve that subscription request so that the 465 Sieve engine can act appropriately depending on whether the user is 466 online or offline. However, the Sieve engine MUST NOT use the user's 467 presence information when processing scripts on behalf of a script 468 owner other than the user, unless the Sieve engine has explicit 469 knowledge (e.g., via integration with an XMPP server's presence 470 authorization rules) that the script owner is authorized to know the 471 user's presence. While it would be possible to design a more 472 advanced approach to delegation of presence authorization, any such 473 approach is left to future standards work. 475 7. IANA Considerations 477 The following template provides the IANA registration of the Sieve 478 notification mechanism specified in this document: 480 To: iana@iana.org 481 Subject: Registration of new Sieve notification mechanism 482 Mechanism name: xmpp 483 Mechanism URI: draft-saintandre-rfc4622bis 484 Mechanism-specific options: none 485 Standards Track/IESG-approved experimental RFC number: this RFC 486 Person and email address to contact for further information: 487 Peter Saint-Andre 489 This information should be added to the list of Sieve notification 490 mechanisms maintained at 491 . 493 8. References 495 8.1. Normative References 497 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 498 "Sieve Email Filtering: Notifications", 499 draft-ietf-sieve-notify-12 (work in progress), 500 December 2007. 502 [OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066, 503 August 2006. 505 [QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF 506 XEP 0147, September 2006. 508 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 509 April 2001. 511 [SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 512 Internet Metadata", XSF XEP 0131, July 2006. 514 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 515 Language", draft-ietf-sieve-3028bis-13 (work in progress), 516 October 2007. 518 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [XMPP-URI] 522 Saint-Andre, P., "Internationalized Resource Identifiers 523 (IRIs) and Uniform Resource Identifiers (URIs) for the 524 Extensible Messaging and Presence Protocol (XMPP)", 525 draft-saintandre-rfc4622bis-01 (work in progress), 526 June 2007. 528 8.2. Informative References 530 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 531 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 532 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 534 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 535 4rev1", RFC 3501, March 2003. 537 [IMAP-URL] 538 Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 539 November 2007. 541 [MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for 542 Presence and Instant Messaging", RFC 2778, February 2000. 544 [POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. 546 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 547 Identifiers (IRIs)", RFC 3987, January 2005. 549 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 550 3.2.0", 2000. 552 The Unicode Standard, Version 3.2.0 is defined by The 553 Unicode Standard, Version 3.0 (Reading, MA, Addison- 554 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 555 Unicode Standard Annex #27: Unicode 3.1 556 (http://www.unicode.org/reports/tr27/) and by the Unicode 557 Standard Annex #28: Unicode 3.2 558 (http://www.unicode.org/reports/tr28/). 560 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 561 Resource Identifier (URI): Generic Syntax", STD 66, 562 RFC 3986, January 2005. 564 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 565 10646", STD 63, RFC 3629, November 2003. 567 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 568 Protocol (XMPP): Core", RFC 3920, October 2004. 570 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 571 Protocol (XMPP): Instant Messaging and Presence", 572 RFC 3921, October 2004. 574 Authors' Addresses 576 Peter Saint-Andre 577 XMPP Standards Foundation 579 Email: stpeter@jabber.org 580 URI: https://stpeter.im/ 582 Alexey Melnikov 583 Isode Limited 585 Email: Alexey.Melnikov@isode.com 587 Full Copyright Statement 589 Copyright (C) The IETF Trust (2008). 591 This document is subject to the rights, licenses and restrictions 592 contained in BCP 78, and except as set forth therein, the authors 593 retain all their rights. 595 This document and the information contained herein are provided on an 596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 598 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 599 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 600 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 601 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 603 Intellectual Property 605 The IETF takes no position regarding the validity or scope of any 606 Intellectual Property Rights or other rights that might be claimed to 607 pertain to the implementation or use of the technology described in 608 this document or the extent to which any license under such rights 609 might or might not be available; nor does it represent that it has 610 made any independent effort to identify any such rights. Information 611 on the procedures with respect to rights in RFC documents can be 612 found in BCP 78 and BCP 79. 614 Copies of IPR disclosures made to the IETF Secretariat and any 615 assurances of licenses to be made available, or the result of an 616 attempt made to obtain a general license or permission for the use of 617 such proprietary rights by implementers or users of this 618 specification can be obtained from the IETF on-line IPR repository at 619 http://www.ietf.org/ipr. 621 The IETF invites any interested party to bring to its attention any 622 copyrights, patents or patent applications, or other proprietary 623 rights that may cover technology that may be required to implement 624 this standard. Please address the information to the IETF at 625 ietf-ipr@ietf.org. 627 Acknowledgment 629 Funding for the RFC Editor function is provided by the IETF 630 Administrative Support Activity (IASA).