idnits 2.17.1 draft-ietf-sieve-notify-xmpp-07.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 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. 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 (December 5, 2007) is 5979 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) == Outdated reference: A later version (-12) exists of draft-ietf-sieve-notify-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'OOB' -- Possible downref: Non-RFC (?) normative reference: ref. 'QUERIES' -- 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: 1 error (**), 0 flaws (~~), 3 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: June 7, 2008 Isode Limited 6 December 5, 2007 8 Sieve Notification Mechanism: xmpp 9 draft-ietf-sieve-notify-xmpp-07 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 June 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Intellectual Property and Copyright Statements . . . . . . . . . . 14 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 The ":from" tag has no special meaning for this notification 124 mechanism, and this specification puts no restriction on its use. 125 The value of the ":from" tag MAY be transformed into XMPP syntax; if 126 so, it SHOULD be encapsulated as the value of an XMPP Stanza Headers 127 and Internet Metadata [SHIM] header named "Reply-To". 129 2.4. Notify tag ":importance" 131 The ":importance" tag has no special meaning for this notification 132 mechanism, and this specification puts no restriction on its use. 133 The value of the ":importance" tag MAY be transformed into XMPP 134 syntax (in addition to or instead of including appropriate text in 135 the XML character data of the XMPP element); if so, it SHOULD 136 be encapsulated as the value of an XMPP Stanza Headers and Internet 137 Metadata [SHIM] header named "Urgency", where the XML character of 138 that header is "high" if the value of the ":importance" tag is "1", 139 "medium" if the value of the ":importance" tag is "2", and "low" if 140 the value of the ":importance" tag is "3". 142 2.5. Notify tag ":message" 144 If the ":message" tag is included, that string MUST be transformed 145 into the XML character data of an XMPP element (where the 146 string is generated according to the guidelines specified in Section 147 3.6 of [NOTIFY]). 149 2.6. Notify tag ":options" 151 The ":options" tag has no special meaning for this notification 152 mechanism. Any handling of this tag is the responsibility of an 153 implementation. 155 2.7. XMPP syntax 157 The xmpp mechanism results in the sending of an XMPP message to 158 notify a recipient about an email message. The general XMPP syntax 159 is as follows: 161 o The notification MUST be an XMPP stanza. 162 o The value of the XMPP 'from' attribute MUST be the XMPP address of 163 the notification service associated with the SIEVE engine. 164 o The value of the XMPP 'to' attribute MUST be the XMPP address 165 specified in the XMPP URI contained in the "method" notify 166 parameter. 168 o The value of the XMPP 'type' attribute MUST be 'headline' or 169 'normal'. 170 o The XMPP stanza MUST include a child element. 171 If the ":message" tag is included in the Sieve script, that string 172 MUST be used as the XML character data of the element. If 173 not and if the XMPP URI contained in the "method" notify parameter 174 specified a "body" parameter in the query component, that value 175 SHOULD be used. Otherwise the XML character data SHOULD be some 176 configurable text indicating that the message is a Sieve 177 notification. 178 o The XMPP stanza MAY include a child element. 179 If the XMPP URI contained in the "method" notify parameter 180 specified a "subject" parameter in the query component, that value 181 SHOULD be used as the XML character data of the 182 element. Otherwise the XML character data SHOULD be some 183 configurable text indicating that the message is a Sieve 184 notification. 185 o The XMPP stanza SHOULD include a URI for the recipient 186 to use as a hint in locating the message, encapsulated as the XML 187 character data of a child element of an element 188 qualified by the 'jabber:x:oob' namespace as specified in [OOB]. 189 If included, the URI SHOULD be an Internet Message Access Protocol 190 [IMAP] URL that specifies the location of the message as defined 191 in [IMAP-URL], but MAY be another URI type that can specify or 192 hint at the location of an email message, such as a URI for an 193 HTTP resource [HTTP] or a POP3 mailbox [POP-URL] at which the 194 message can be accessed. It is not expected that an XMPP user 195 agent shall directly handle such a URI, but instead that it shall 196 invoke an appropriate helper application to handle the URI. 197 o The XMPP stanza MAY include an XMPP Stanza Headers and 198 Internet Metadata [SHIM] header named "Reply-To", which 199 encapsulates the value of the ":from" tag. 200 o The XMPP stanza MAY include an XMPP Stanza Headers and 201 Internet Metadata [SHIM] header named "Resent-From", which 202 encapsulates the value of the envelope recipient address of the 203 original email message that triggered the notification. 205 3. Examples 207 In the following examples, the sender of the email has an address of 208 , the entity to be notified has an email 209 address of and an XMPP address of 210 romeo@im.example.com (resulting in an XMPP URI of 211 ), and the notification service associated 212 with the SIEVE engine has an XMPP address of notify.example.com. 214 Note: In the following examples, line breaks are included in XMPP 215 URIs solely for the purpose of readability. 217 3.1. Basic action 219 The following is a basic Sieve notify action with only a method. The 220 XML character data of the XMPP and elements are 221 therefore generated by the Sieve engine based on configuration. In 222 addition, the Sieve engine includes a URI pointing to the message. 224 Basic action (Sieve syntax) 226 notify "xmpp:romeo@im.example.com" 228 The resulting XMPP stanza might be as follows. 230 Basic action (XMPP syntax) 232 236 SIEVE 237 <juliet@example.com> You got mail. 238 239 240 imap://romeo@example.com/INBOX;UIDVALIDITY=385759043/;UID=18 241 242 243 245 3.2. Action with body 247 The following action contains a "body" parameter in the query 248 component of the XMPP URI but no ":message" tag in the Sieve script. 249 As a result, the XML character data of the XMPP element in 250 the XMPP notification is taken from the XMPP URI. In addition, the 251 Sieve engine includes a URI pointing to the message. 253 Action with body (Sieve syntax) 255 notify "xmpp:romeo@im.example.com?message 256 ;body=Wherefore%20art%20thou%3F" 258 The resulting XMPP stanza might be as follows. 260 Action with body (XMPP syntax) 262 266 SIEVE 267 Wherefore art thou? 268 269 270 imap://romeo@example.com/INBOX;UIDVALIDITY=385759044/;UID=19 271 272 273 275 3.3. Action with body, importance, message, and subject 277 The following action specifies an ":importance" tag and a ":message" 278 tag in the Sieve script, as well as a "body" parameter and a 279 "subject" parameter in the query component of the XMPP URI. As a 280 result, the ":message" tag from the Sieve script overrides the "body" 281 parameter from the XMPP URI when generating the XML character data of 282 the XMPP element. In addition, the Sieve engine includes a 283 URI pointing to the message. 285 Action with body, importance, message, and subject (Sieve syntax) 287 notify :importance "1" 288 :message "Contact Juliet immediately!" 289 "xmpp:romeo@im.example.com?message 290 ;body=You%27re%20in%20trouble 291 ;subject=ALERT%21" 293 The resulting XMPP stanza might be as follows. 295 Action with body, importance, message, and subject (XMPP syntax) 297 301 ALERT! 302 Contact Juliet immediately! 303 304
high
305 306 307 308 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20 309 310 311 313 3.4. Action with from, message, importance, body, and subject 315 The following action specifies a ":from" tag, an ":importance" tag, 316 and a ":message" tag in the Sieve script, as well as a "body" 317 parameter and a "subject" parameter in the query component of the 318 XMPP URI. As a result, the ":message" tag from the Sieve script 319 overrides the "body" parameter from the XMPP URI when generating the 320 XML character data of the XMPP element. In addition, the 321 Sieve engine includes a URI pointing to the message, as well as an 322 XMPP Stanza Headers and Internet Metadata [SHIM] header named 323 "Reply-To" (which encapsulates the value of the ":from" tag) and a 324 SHIM header named "Resent-From" (which encapsulates the value of the 325 original email message that triggered the notification). 327 Action with body, from, importance, message, and subject (Sieve 328 syntax) 330 notify :from "bill.shakespeare@example.com" 331 :importance "1" 332 :message "Contact Juliet immediately!" 333 "xmpp:romeo@im.example.com?message 334 ;body=You%27re%20in%20trouble 335 ;subject=ALERT%21" 337 The resulting XMPP stanza might be as follows. 339 Action with body, from, importance, message, and subject (XMPP 340 syntax) 342 346 ALERT! 347 Contact Juliet immediately! 348 349
bill.shakespeare@example.net
350
romeo@example.com
351
high
352 353 354 355 imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=21 356 357 358 360 4. Requirements Conformance 362 Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve 363 notification methods. The conformance of the xmpp notification 364 mechanism is provided here. 366 1. An implementation of the xmpp notification method SHOULD NOT 367 modify the final notification text (e.g., to limit the length); 368 however, a given deployment MAY do so (e.g., if recipients pay 369 per character or byte for XMPP messages). Modification of 370 characters themselves should not be necessary, since XMPP 371 character data is encoded in [UTF-8]. 372 2. An implementation MAY ignore parameters specified in the 373 ":from", ":importance", and ":options" tags. 374 3. There is no recommended default message for an implementation to 375 include if the ":message" argument is not specified. 376 4. A notification sent via the xmpp notification method MAY include 377 a timestamp in the textual message. 378 5. The value of the XMPP 'from' attribute MUST be the XMPP address 379 of the notification service associated with the SIEVE engine. 380 The value of the Sieve ":from" tag MAY be transformed into the 381 value of an XMPP Stanza Headers and Internet Metadata [SHIM] 382 header named "Reply-To". 383 6. The value of the XMPP 'to' attribute MUST be the XMPP address 384 specified in the XMPP URI contained in the "method" parameter. 386 7. In accordance with [XMPP-URI], an implementation MUST ignore any 387 URI action or parameter it does not understand (i.e., the URI 388 MUST be processed as if the action or parameter were not 389 present). It is RECOMMENDED to support the XMPP "message" query 390 type (see [QUERIES]) and the associated "body" and "subject" 391 parameters, which parameters SHOULD be mapped to the XMPP 392 and child elements of the XMPP 393 stanza, respectively. However, if included then the Sieve 394 notify ":message" parameter MUST be mapped to the XMPP 395 element, overriding the "body" parameter (if any) included in 396 the XMPP URI. 397 8. An implementation MUST NOT include any other extraneous 398 information not specified in parameters to the notify action. 399 9. In response to a notify_method_capability test for the "online" 400 notification-capability, an implementation SHOULD return a value 401 of "yes" if it has knowledge of an active presence session (see 402 [XMPP-IM]) for the specified XMPP notification-uri; otherwise it 403 SHOULD return a value of "maybe" (since typical XMPP systems may 404 not allow a SIEVE engine to gain knowledge about the presence of 405 XMPP entities). 406 10. An implementation SHOULD NOT attempt to retry delivery of a 407 notification if it receives an XMPP error of type "auth" or 408 "cancel", MAY attempt to retry delivery if it receives an XMPP 409 error of type "wait", and MAY attempt to retry delivery if it 410 receives an XMPP error of "modify" but only if it makes 411 appropriate modifications to the notification (see [XMPP]); in 412 any case the number of retries SHOULD be limited to a 413 configurable number no less than 3 and no more than 10. An 414 implementation MAY throttle notifications if the number of 415 notifications within a given time period becomes excessive 416 according to local service policy. Duplicate suppression (if 417 any) is a matter of implementation and is not specified herein. 419 5. Internationalization Considerations 421 Although an XMPP address may contain nearly any [UNICODE] character, 422 the value of the "method" parameter MUST be a Uniform Resource 423 Identifier (see [URI]) rather than an Internationalized Resource 424 Identifier (see [IRI]). The rules specified in [XMPP-URI] MUST be 425 followed when generating XMPP URIs. 427 In accordance with Section 13 of RFC 3920, all data sent over XMPP 428 MUST be encoded in [UTF-8]. 430 6. Security Considerations 432 Depending on the information included, sending a notification can be 433 comparable to forwarding mail to the notification recipient. Care 434 must be taken when forwarding mail automatically, to ensure that 435 confidential information is not sent into an insecure environment. 436 In particular, implementations MUST conform to the security 437 considerations given in [NOTIFY], [SIEVE], and [XMPP]. 439 7. IANA Considerations 441 The following template provides the IANA registration of the Sieve 442 notification mechanism specified in this document: 444 To: iana@iana.org 445 Subject: Registration of new Sieve notification mechanism 446 Mechanism name: xmpp 447 Mechanism URI: draft-saintandre-rfc4622bis 448 Mechanism-specific options: none 449 Standards Track/IESG-approved experimental RFC number: this RFC 450 Person and email address to contact for further information: 451 Peter Saint-Andre 453 This information should be added to the list of Sieve notification 454 mechanisms maintained at 455 . 457 8. References 459 8.1. Normative References 461 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 462 "SIEVE Email Filtering: Notifications", 463 draft-ietf-sieve-notify-10 (work in progress), 464 November 2007. 466 [OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066, 467 August 2006. 469 [QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF 470 XEP 0147, September 2006. 472 [SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 473 Internet Metadata", XSF XEP 0131, July 2006. 475 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 476 Language", draft-ietf-sieve-3028bis-13 (work in progress), 477 October 2007. 479 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [XMPP-URI] 483 Saint-Andre, P., "Internationalized Resource Identifiers 484 (IRIs) and Uniform Resource Identifiers (URIs) for the 485 Extensible Messaging and Presence Protocol (XMPP)", 486 draft-saintandre-rfc4622bis-01 (work in progress), 487 June 2007. 489 8.2. Informative References 491 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 492 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 493 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 495 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 496 4rev1", RFC 3501, March 2003. 498 [IMAP-URL] 499 Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 500 November 2007. 502 [POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. 504 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 505 Identifiers (IRIs)", RFC 3987, January 2005. 507 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 508 3.2.0", 2000. 510 The Unicode Standard, Version 3.2.0 is defined by The 511 Unicode Standard, Version 3.0 (Reading, MA, Addison- 512 Wesley, 2000. ISBN 0-201-61633-5), as amended by the 513 Unicode Standard Annex #27: Unicode 3.1 514 (http://www.unicode.org/reports/tr27/) and by the Unicode 515 Standard Annex #28: Unicode 3.2 516 (http://www.unicode.org/reports/tr28/). 518 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 519 Resource Identifier (URI): Generic Syntax", STD 66, 520 RFC 3986, January 2005. 522 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 523 10646", STD 63, RFC 3629, November 2003. 525 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 526 Protocol (XMPP): Core", RFC 3920, October 2004. 528 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 529 Protocol (XMPP): Instant Messaging and Presence", 530 RFC 3921, October 2004. 532 Authors' Addresses 534 Peter Saint-Andre 535 XMPP Standards Foundation 537 Email: stpeter@jabber.org 538 URI: https://stpeter.im/ 540 Alexey Melnikov 541 Isode Limited 543 Email: Alexey.Melnikov@isode.com 545 Full Copyright Statement 547 Copyright (C) The IETF Trust (2007). 549 This document is subject to the rights, licenses and restrictions 550 contained in BCP 78, and except as set forth therein, the authors 551 retain all their rights. 553 This document and the information contained herein are provided on an 554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 556 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 557 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 558 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 Intellectual Property 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; nor does it represent that it has 568 made any independent effort to identify any such rights. Information 569 on the procedures with respect to rights in RFC documents can be 570 found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use of 575 such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository at 577 http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at 583 ietf-ipr@ietf.org. 585 Acknowledgment 587 Funding for the RFC Editor function is provided by the IETF 588 Administrative Support Activity (IASA).