idnits 2.17.1 draft-ietf-sieve-notify-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 662. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (November 29, 2006) is 6358 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MODIFIER' is mentioned on line 425, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Limited 4 Intended status: Standards Track B. Leiba, Ed. 5 Expires: June 2, 2007 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 BeThereBeSquare Inc. 9 November 29, 2006 11 Sieve Extension: Notifications 12 draft-ietf-sieve-notify-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 2, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 Users go to great lengths to be notified as quickly as possible that 46 they have received new mail. Most of these methods involve polling 47 to check for new messages periodically. A push method handled by the 48 final delivery agent gives users quicker notifications and saves 49 server resources. This document does not specify the notification 50 method but is expected that using existing instant messaging 51 infrastructure such as Zephyr, Jabber, or SMS messages will be 52 popular. This draft describes an extension to the Sieve mail 53 filtering language that allows users to give specific rules for how 54 and when notifications should be sent. 56 Changes since draft-ietf-sieve-notify-04 58 o Made notification method required. 60 o Defined "mailto" as a mandatory-to-implement method. 62 o Added normative reference to mailto. 64 o Clarified that :importance may be treated as a transport 65 indicator. 67 o Clarified that :importance value can be included in the default 68 :message, if one is not specified. 70 o Made the default :message implementation specific. 72 o Renamed the capability name from "notify" to "enotify" 74 o Updated IANA registration. 76 o Moved text about ManageSieve capability to the ManageSieve 77 document itself. 79 o Removed reference to IANA registry for options. 81 o Some miscellaneous text cleanup and clarification. 83 Changes since draft-ietf-sieve-notify-03 85 o Added a warning that "notify" must not be used as a crappy form of 86 "redirect". 88 o Added a warning about using "notify" to forward confidential 89 information in order to bypass organization's policy. 91 o Fixed syntax of the :options argument - it is a string list, each 92 string containing "=" 94 o Renamed :priority to :importance 95 o Cleaned up section about requirements on methods. 97 Changes since draft-ietf-sieve-notify-02 99 o Added :from tagged argument. 101 o Added Extract_text action, which allows to extract content of the 102 first text/* part. 104 o Added back the ":options" parameter to the notify action. 106 o Added new section talking about requirements on notification 107 method specs. 109 o Added more examples. 111 Changes since draft-ietf-sieve-notify-00 113 o Updated references, etc. 115 o Added IANA considerations section. 117 o Removed denotify action. 119 o Updated examples to use the variables extension. 121 o Replaced notification method with URI. 123 o Removed text suggesting that this extension can be used to track 124 all Sieve actions taken. 126 o Changed priority to be a string. 128 o Added text about URI verification. 130 o Clarified that a notification method is allowed to perform 131 adaptation of notification context (e.g. truncation, charset 132 conversion, etc.). These adaptations must be documented in a 133 document describing the notification method. 135 o Clarified that notify is compatible with all existing actions. 137 o Removed the :id parameter to the notify action. 139 o Added valid_notif_method test that allows to test if an 140 notification method (URI) is supported. 142 o Added a new capability response to ManageSieve that allows to 143 report supported notification types. 145 Table of Contents 147 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 148 1.1. Conventions used in this document . . . . . . . . . . . . . 5 150 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 5 152 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 5 153 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 5 154 3.2. Notify tag ":method" . . . . . . . . . . . . . . . . . . . . 5 155 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 6 156 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 6 157 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 7 158 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 7 159 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 160 3.8. Requirements on notification methods specifications . . . . 10 162 4. Extract_text Action . . . . . . . . . . . . . . . . . . . . 11 164 5. Test valid_notif_method . . . . . . . . . . . . . . . . . . 12 166 6. Interactions with Other Sieve Actions . . . . . . . . . . . 13 168 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 170 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 172 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 174 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 175 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 14 176 10.2. Informative References . . . . . . . . . . . . . . . . . . . 14 178 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 179 Intellectual Property and Copyright Statements . . . . . . . 17 181 1. Introduction 183 This is an extension to the Sieve language defined by [Sieve] for 184 providing instant notifications. It defines the new action "notify". 186 This document does not specify the notification methods. Examples of 187 possible notification methods are email and xmpp. To allow a 188 mechanism for portability of scripts that use notifications, 189 implementation of the [MailTo] method is mandatory. Other available 190 methods shall depend upon the implementation and configuration of the 191 system. 193 1.1. Conventions used in this document 195 Conventions for notations are as in [Sieve] section 1.1, including 196 the use of [ABNF]. 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [Kwds]. 202 2. Capability Identifier 204 The capability string associated with the extension defined in this 205 document is "enotify". 207 3. Notify Action 209 3.1. Notify Action Syntax and Semantics 211 Usage: notify ":method" string 212 [":from" string] 213 [":importance" <"1" / "2" / "3">] 214 [":options" string-list] 215 [":message" string] 217 The Notify action specifies that a notification should be sent to the 218 user. The format of the notification is implementation-defined and 219 is also affected by the notification method used (see Section 3.2). 220 However, all content specified in the :message parameter SHOULD be 221 included. 223 3.2. Notify tag ":method" 225 The :method tag identifies the notification method that will be used; 226 it is a URI [URI], and this tag and the URI MUST be present. For 227 example, the notification method can be an SMS URI [SMS-URI] 228 containing a phone number, or an XMPP [XMPP] URI containing a Jabber 229 identifier [XMPP-URI]. 231 The supported URI values will be site-specific, but support for the 232 [MailTo] method is REQUIRED. If a URI schema is specified that the 233 implementation does not support, the notification MUST cause an error 234 condition. Sieve scripts can check the supported methods using the 235 "valid_notif_method" test to be sure that they only use supported 236 ones, to avoid such error conditions. 238 If the :method tag contains a supported URI schema, then the URI MUST 239 be checked for syntactic validity. An invalid URI syntax or an 240 unsupported URI extension MUST cause an error. An implementation MAY 241 enforce other semantic restrictions on URIs -- for example an SMS URI 242 can only contain phone numbers in a particular geographical region -- 243 and will treat violations of such semantic restrictions as errors. 245 3.3. Notify tag ":from" 247 A ":from" parameter may be used to specify an author of the 248 notification. The syntax of this parameter's value is method- 249 specific. Implementations SHOULD check the syntax according to the 250 notification method specification and generate an error when a 251 syntactically invalid ":from" parameter is specified. 253 3.4. Notify tag ":importance" 255 The :importance tag specifies the importance of the delivery of the 256 notification. The :importance tag is followed by a numeric value 257 represented as a string: "1" (high importance), "2" (normal 258 importance), and "3" (low importance). If no importance is given, 259 the default value "2" SHOULD be assumed. A notification method can 260 treat the importance value as a transport indicator. For example, it 261 might deliver notifications of high importance quicker than 262 notifications of normal or low importance. Some notification methods 263 allow users to specify their state of activity (for example "busy" or 264 "away from keyboard"). If the notification method provides this 265 information it SHOULD be used to selectively send notifications. If, 266 for example, the user marks herself as "busy", a notification method 267 can require that a notification with importance of "3" is not to be 268 sent, however the user should be notified of a notification with 269 higher importance. 271 If the notification method allows users to filter messages based upon 272 certain parameters in the message, users SHOULD be able to filter 273 based upon importance. If the notification method does not support 274 importance, then this parameter MUST be ignored, however an 275 implementation MAY include the importance value in the default 276 message Section 3.6, if one is not provided. 278 3.5. Notify tag ":options" 280 The :options tag is used to send additional parameters to the 281 notification method. Interpretation of the parameters is method- 282 specific. This document doesn't specify any such additional 283 parameter. 285 Each string in the options string list has the following syntax: 286 "=" [[Alexey 3: Should we say something about 287 implementation prefix for implementation specific options? Something 288 like "x-Vendor-zzz". If we don't say it now, it might be too late to 289 say it later.]] 291 3.6. Notify tag ":message" 293 The :message tag specifies the message data to be included in the 294 notification. The entirety of the string SHOULD be sent but 295 implementations MAY shorten the message for technical or aesthetic 296 reasons. If the message parameter is absent, a default 297 implementation-specific message is used. Unless specified otherwise 298 by a particular notification mechanism, an implementation default 299 containing at least the value of the "From" header field and the 300 value of the "Subject" header field is RECOMMENDED. 302 In order to construct more complex messages the notify extension can 303 be used together with the Sieve variables extension [Variables], as 304 shown in the examples below. 306 3.7. Examples 307 Example 1: 308 require ["enotify", "fileinto", "variables"]; 310 if header :contains "from" "boss@example.org" { 311 notify :method "mailto:alm@example.com" 312 :importance "1" 313 :message "This is probably very important"; 314 # Don't send any further notifications 315 stop; 316 } 318 if header :contains "to" "sievemailinglist@example.org" { 319 # :matches is used to get the value of the Subject header 320 if header :matches "Subject" "*" { 321 set "subject" "${1}"; 322 } 324 # :matches is used to get the value of the From header 325 if header :matches "From" "*" { 326 set "from" "${1}"; 327 } 329 notify :importance "3" 330 :method "mailto:alm@example.com" 331 :message "[SIEVE] ${from}: ${subject}"; 332 fileinto "INBOX.sieve"; 333 } 335 Example 2: 336 require ["enotify", "fileinto", "variables", "envelope"]; 338 if header :matches "from" "*@*.example.org" { 339 # :matches is used to get the MAIL FROM address 340 if envelope :all :matches "from" "*" { 341 set "env_from" " [really: ${1}]"; 342 } 344 # :matches is used to get the value of the Subject header 345 if header :matches "Subject" "*" { 346 set "subject" "${1}"; 347 } 349 # :matches is used to get the address from the From header 350 if address :matches :all "from" "*" { 351 set "from_addr" "${1}"; 352 } 354 notify :method "mailto:alm@example.com" 355 :message "${from_addr}${env_from}: ${subject}"; 356 } 358 Example 3: 359 require ["enotify", "variables"]; 361 set "notif_method" 362 "xmpp:tim@example.com?You%20got%20mail&subject=SIEVE"; 364 if header :contains "subject" "Your dog" { 365 set "notif_method" "sms:+14085551212"; 366 } 368 if header :contains "to" "sievemailinglist@example.org" { 369 set "notif_method" ""; 370 } 372 if not string :is "${notif_method}" "" { 373 notify :method "${notif_method}"; 374 } 376 if header :contains "from" "boss@example.org" { 377 # :matches is used to get the value of the Subject header 378 if header :matches "Subject" "*" { 379 set "subject" "${1}"; 380 } 382 # don't need high importance notification for 383 # a 'for your information' 384 if not header :contains "subject" "FYI:" { 385 notify :method "sms:+14085551212" 386 :importance "1" :message "BOSS: ${subject}"; 387 } 388 } 390 [[anchor2: Make sure that the XMPP notification syntax is correct.]] 392 3.8. Requirements on notification methods specifications 394 This section describes requirements for documents that define 395 specific Sieve notification methods. 397 A notification method MAY allow modification of the final 398 notification text -- for example, truncating it if it exceeds a 399 length limit, or modifying characters that can not be represented in 400 the target character set. Characters in the notification text which 401 can't be represented by the notification method SHOULD be replaced 402 with a symbol indicating an unknown character. Allowed modifications 403 MUST be documented in the document describing the notification 404 method. 406 A notification method MAY ignore parameters specified in the Notify 407 action. 409 A notification method MAY recommend the default message value to be 410 used if the :message argument is not specified. 412 It is RECOMMENDED that a timestamp be included in the notification. 414 Methods SHOULD NOT include extraneous information not specified in 415 parameters to the notify action. 417 If there are errors sending the notification, the Sieve interpreter 418 SHOULD ignore the notification and not retry indefinitely. Documents 419 describing notification methods SHOULD describe how retries, 420 duplicate suppression (if any), etc. are to be handled by 421 implementations. 423 4. Extract_text Action 425 Usage: extract_text [MODIFIER] [":first" number] 426 428 The Extract_text action stores at most :first bytes of the first 429 text/* part in the variable identified by varname. If the :first 430 parameter is not present, the whole content of the first text/* part 431 is stored. If the message being processed doesn't contain any text/* 432 part, the action will set the variable identified by varname to the 433 empty string. [[Alexey 5: Do we need to be more specific about what 434 "the first text part" means?]] 436 Modifiers are applied on the extracted text before it is stored in 437 the variable. See [Variables] for details. 439 Note that this action is only available when the Sieve script 440 specifies both "variables" [Variables] and "enotify" capabilities in 441 the require statements. 443 Example 4: 444 require ["enotify", "variables"]; 446 if header :contains "from" "boss@example.org" { 447 # :matches is used to get the value of the Subject header 448 if header :matches "Subject" "*" { 449 set "subject" "${1}"; 450 } 452 # extract the first 100 bytes of the first text/* part 453 extract_text :first 100 "msgcontent"; 455 # don't need high importance notification for 456 # a 'for your information' 457 if not header :contains "subject" "FYI:" { 458 notify :method "sms:+14085551212" 459 :importance "1" 460 :message "BOSS: ${subject}; ${msgcontent}"; 461 } 462 } 464 5. Test valid_notif_method 466 Usage: valid_notif_method 468 The "valid_notif_method" test is true if the notification methods 469 listed in the notification-uris argument are supported and they are 470 syntactically and semantically (including implementation-specific 471 semantic restrictions) valid. This test MUST perform exactly the 472 same validation as would be performed on the ":method" parameter of 473 the "notify" action. 475 The test is true only if ALL of the listed notification methods are 476 supported and valid. 478 Example 5: 479 if not valid_notif_method ["mailto:", 480 "http://gw.example.net/notify?test"] { 481 stop; 482 } 484 6. Interactions with Other Sieve Actions 486 The notify action is compatible with all other actions, and does not 487 affect the operation of other actions. In particular, the notify 488 action MUST NOT cancel the implicit keep. 490 Multiple executed notify actions are allowed. Specific notification 491 methods MAY allow multiple notifications from the same script to be 492 collapsed into one. 494 7. Security Considerations 496 Security considerations are discussed in [Sieve]. Additionally, 497 implementations must be careful to follow the security considerations 498 of the specific notification methods. 500 The notify action is potentially very dangerous. The path the 501 notification takes through the network may not be secure. An error 502 in the options string may cause the message to be transmitted to 503 someone it was not intended for, or may expose information to 504 eavesdroppers. 506 Just because a notification is received doesn't mean that it was sent 507 by the Sieve implementation. It might be possible to forge 508 notifications with some notification methods. 510 An organization may have a policy about the forwarding of classified 511 information to unclassified networks. Unless the policy is also 512 enforced in the module responsible for generating (or sending) of 513 notifications, users can use the extension defined in this document 514 to extract classified information and bypass the policy. 516 Notifications can result in loops and bounces. In particular, a 517 notification to an email address will not contain necessary Received 518 header fields that might be otherwise used to prevent mail loops. 519 All notification methods must take care to provide mechanisms for 520 avoiding notification loops. 522 8. IANA Considerations 524 The following template specifies the IANA registration of the notify 525 Sieve extension specified in this document: 527 To: iana@iana.org 528 Subject: Registration of new Sieve extension 529 Capability name: enotify 530 Description: adds the 'notify' action for notifying user about the 531 received message; also adds the 'extract_text' action for extracting 532 a part of the first textual bodypart. 533 RFC number: this RFC 534 Contact address: 535 The Sieve discussion list 537 This information should be added to the list of sieve extensions 538 given on http://www.iana.org/assignments/sieve-extensions. 540 9. Acknowledgements 542 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 543 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 544 Mallett and Ned Freed for help with this document. 546 10. References 548 10.1. Normative References 550 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 551 Specifications: ABNF", RFC 4234, October 2005. 553 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", RFC 2119, March 1997. 556 [MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 557 mailto", work in progress, draft-ietf-sieve-notify-mailto, 558 October 2006. 560 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 561 Language", work in progress, draft-ietf-sieve-3028bis, 562 August 2006. 564 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 565 Resource Identifier (URI): Generic Syntax", STD 66, 566 RFC 3986, January 2005. 568 [Variables] 569 Homme, K., "Sieve Extension: Variables", work in 570 progress, draft-ietf-sieve-variables, December 2005. 572 10.2. Informative References 574 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 575 Message Service", work in progress, draft-wilde-sms-uri, 576 August 2005. 578 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 579 Protocol (XMPP): Core", RFC 3920, October 2004. 581 [XMPP-URI] 582 Saint-Andre, P., "Internationalized Resource Identifiers 583 (IRIs) and Uniform Resource Identifiers (URIs) for the 584 Extensible Messaging and Presence Protocol (XMPP)", work 585 in progress, draft-saintandre-xmpp-iri, September 2005. 587 Authors' Addresses 589 Alexey Melnikov (editor) 590 Isode Limited 591 5 Castle Business Village 592 36 Station Road 593 Hampton, Middlesex TW12 2BX 594 UK 596 Email: Alexey.Melnikov@isode.com 598 Barry Leiba (editor) 599 IBM T.J. Watson Research Center 600 19 Skyline Drive 601 Hawthorne, NY 10532 602 US 604 Phone: +1 914 784 7941 605 Email: leiba@watson.ibm.com 607 Wolfgang Segmuller 608 IBM T.J. Watson Research Center 609 19 Skyline Drive 610 Hawthorne, NY 10532 611 US 613 Phone: +1 914 784 7408 614 Email: werewolf@us.ibm.com 615 Tim Martin 616 BeThereBeSquare Inc. 617 672 Haight st. 618 San Francisco, CA 94117 619 US 621 Phone: +1 510 260-4175 622 Email: timmartin@alumni.cmu.edu 624 Full Copyright Statement 626 Copyright (C) The Internet Society (2006). 628 This document is subject to the rights, licenses and restrictions 629 contained in BCP 78, and except as set forth therein, the authors 630 retain all their rights. 632 This document and the information contained herein are provided on an 633 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 634 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 635 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 636 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 637 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 640 Intellectual Property 642 The IETF takes no position regarding the validity or scope of any 643 Intellectual Property Rights or other rights that might be claimed to 644 pertain to the implementation or use of the technology described in 645 this document or the extent to which any license under such rights 646 might or might not be available; nor does it represent that it has 647 made any independent effort to identify any such rights. Information 648 on the procedures with respect to rights in RFC documents can be 649 found in BCP 78 and BCP 79. 651 Copies of IPR disclosures made to the IETF Secretariat and any 652 assurances of licenses to be made available, or the result of an 653 attempt made to obtain a general license or permission for the use of 654 such proprietary rights by implementers or users of this 655 specification can be obtained from the IETF on-line IPR repository at 656 http://www.ietf.org/ipr. 658 The IETF invites any interested party to bring to its attention any 659 copyrights, patents or patent applications, or other proprietary 660 rights that may cover technology that may be required to implement 661 this standard. Please address the information to the IETF at 662 ietf-ipr@ietf.org. 664 Acknowledgment 666 Funding for the RFC Editor function is provided by the IETF 667 Administrative Support Activity (IASA).