idnits 2.17.1 draft-ietf-sieve-notify-04.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 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 645. ** 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 (October 19, 2006) is 6389 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 400, 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: April 22, 2007 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 BeThereBeSquare Inc. 9 October 19, 2006 11 Sieve Extension: Notifications 12 draft-ietf-sieve-notify-04 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 April 22, 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 ToDo 58 o Change tagged :method to the positional parameter? 60 Changes since draft-ietf-sieve-notify-03 62 o Added a warning that "notify" must not be used as a crappy form of 63 "redirect". 65 o Added a warning about using "notify" to forward confidential 66 information in order to bypass organization's policy. 68 o Fixed syntax of the :options argument - it is a string list, each 69 string containing "=" 71 o Renamed :priority to :importance 73 o Cleaned up section about requirements on methods. 75 Changes since draft-ietf-sieve-notify-02 77 o Added :from tagged argument. 79 o Added Extract_text action, which allows to extract content of the 80 first text/* part. 82 o Added back the ":options" parameter to the notify action. 84 o Added new section talking about requirements on notification 85 method specs. 87 o Added more examples. 89 Changes since draft-ietf-sieve-notify-00 91 o Updated references, etc. 93 o Added IANA considerations section. 95 o Removed denotify action. 97 o Updated examples to use the variables extension. 99 o Replaced notification method with URI. 101 o Removed text suggesting that this extension can be used to track 102 all Sieve actions taken. 104 o Changed priority to be a string. 106 o Added text about URI verification. 108 o Clarified that a notification method is allowed to perform 109 adaptation of notification context (e.g. truncation, charset 110 conversion, etc.). These adaptations must be documented in a 111 document describing the notification method. 113 o Clarified that notify is compatible with all existing actions. 115 o Removed the :id parameter to the notify action. 117 o Added valid_notif_method test that allows to test if an 118 notification method (URI) is supported. 120 o Added a new capability response to ManageSieve that allows to 121 report supported notification types. 123 Table of Contents 125 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 126 1.1. Conventions used in this document . . . . . . . . . . . . . 5 128 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 5 130 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 5 131 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 5 132 3.2. Notify tag ":method" . . . . . . . . . . . . . . . . . . . . 5 133 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 6 134 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 6 135 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 7 136 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 7 137 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 138 3.8. Requirements on notification methods specifications . . . . 9 140 4. Extract_text Action . . . . . . . . . . . . . . . . . . . . 10 142 5. Test valid_notif_method . . . . . . . . . . . . . . . . . . 11 144 6. Interactions with Other Sieve Actions . . . . . . . . . . . 12 146 7. Security Considerations . . . . . . . . . . . . . . . . . . 12 148 8. Extensions to ManageSieve protocol . . . . . . . . . . . . . 12 150 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 152 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 154 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 155 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 13 156 11.2. Informative References . . . . . . . . . . . . . . . . . . . 14 158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 159 Intellectual Property and Copyright Statements . . . . . . . 16 161 1. Introduction 163 This is an extension to the Sieve language defined by [Sieve] for 164 providing instant notifications. It defines the new action "notify". 166 This document does not dictate the notification method used. 167 Examples of possible notification methods are Zephyr and Jabber. The 168 available methods shall be site-defined. 170 1.1. Conventions used in this document 172 Conventions for notations are as in [Sieve] section 1.1, including 173 the use of [ABNF]. 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [Kwds]. 179 2. Capability Identifier 181 The capability string associated with the extension defined in this 182 document is "notify". 184 3. Notify Action 186 3.1. Notify Action Syntax and Semantics 188 Usage: notify [":method" string] 189 [":from" string] 190 [":importance" <"1" / "2" / "3">] 191 [":options" string-list] 192 [":message" string] 194 The Notify action specifies that a notification should be sent to the 195 user. The format of the notification is implementation-defined and 196 is also affected by the notification method used (see Section 3.2). 197 However, all content specified in the :message parameter SHOULD be 198 included. 200 3.2. Notify tag ":method" 202 The :method tag identifies the notification method that will be used; 203 it is a URI [URI]. For example, the notification method can be an 204 SMS URI [SMS-URI] containing a phone number, or an XMPP [XMPP] URI 205 containing a Jabber identifier [XMPP-URI]. If the :method tag is not 206 specified, a default implementation-defined notification method is 207 used, and if there is no default method defined, the notification is 208 ignored. Implementations MUST NOT generate an error condition for 209 lack of a default notification method, and execution of the script 210 MUST continue. 212 The supported URI values will be site-specific. If an URI schema is 213 specified that the implementation does not support, the notification 214 MUST cause an error condition. Sieve scripts can check the supported 215 methods using the "valid_notif_method" test to be sure that they only 216 use supported ones, to avoid such error conditions. If the :method 217 tag contains a supported URI schema, then the URI MUST be checked for 218 syntactic validity. An invalid URI syntax or an unsupported URI 219 extension MUST cause an error. An implementation MAY enforce other 220 semantic restrictions on URIs -- for example an SMS URI can only 221 contain phone numbers in a particular geographical region. Violation 222 of such semantic restrictions MUST be treated as an error. 223 [[Barry 1: "MUST" seems silly here, since the whole sentence is a 224 "MAY".]] 226 3.3. Notify tag ":from" 228 A ":from" parameter may be used to specify a notification method 229 specific author of the notification. Implementations SHOULD check 230 the syntax according to the notification method specification and 231 generate an error when a syntactically invalid ":from" parameter is 232 specified. 234 3.4. Notify tag ":importance" 236 The :importance tag specifies the importance of the notification. 237 The :importance tag is followed by a numeric value represented as a 238 string: "1" (high importance), "2" (normal importance), and "3" (low 239 importance). If no importance is given, the default value "2" SHOULD 240 be assumed. Some notification methods allow users to specify their 241 state of activity (for example "busy" or "away from keyboard"). If 242 the notification method provides this information it SHOULD be used 243 to selectively send notifications. If, for example, the user marks 244 herself as "busy", a notification method can require that a 245 notification with importance of "3" is not to be sent, however the 246 user should be notified of a notification with higher importance. 247 [[Alexey 1: Clarify that this is a transport indicator, not content]] 249 If the notification method allows users to filter messages based upon 250 certain parameters in the message, users SHOULD be able to filter 251 based upon importance. If the notification method does not support 252 importance, then this parameter MUST be ignored. [[Alexey 2: Does 253 the MUST prohibit inclusion of the field into :message content?]] 255 3.5. Notify tag ":options" 257 The :options tag is used to send additional parameters to the 258 notification method. Interpretation of the parameters is method- 259 specific. 261 Each string in the options string list has the following value: 262 "=" [[Alexey 3: Do we need IANA registry for 263 ?]] 265 3.6. Notify tag ":message" 267 The :message tag specifies the message data to be included in the 268 notification. The entirety of the string SHOULD be sent but 269 implementations MAY shorten the message for technical or aesthetic 270 reasons. If the message parameter is absent, a default message 271 containing the value of the From header field and the value of the 272 Subject header field will be used. Note that the notification method 273 (the ":method" tag) may affect how this information is formatted. 275 The implementation of a notification method MAY modify the final 276 notification text -- for example, truncating it if it exceeds a 277 length limit, or modifying characters that can not be represented in 278 the target character set. Allowed modifications should be documented 279 in a standards-track, experimental or informational document. 281 In order to construct more complex messages the notify extension can 282 be used together with the Sieve variables extension [Variables], as 283 shown in the examples below. 285 3.7. Examples 286 Example 1: 287 require ["notify", "fileinto", "variables"]; 289 if header :contains "from" "boss@example.org" { 290 notify :importance "1" 291 :message "This is probably very important"; 292 # Don't send any further notifications 293 stop; 294 } 296 if header :contains "to" "sievemailinglist@example.org" { 297 # :matches is used to get the value of the Subject header 298 if header :matches "Subject" "*" { 299 set "subject" "${1}"; 300 } 302 # :matches is used to get the value of the From header 303 if header :matches "From" "*" { 304 set "from" "${1}"; 305 } 307 notify :importance "3" 308 :message "[SIEVE] ${from}: ${subject}"; 309 fileinto "INBOX.sieve"; 310 } 312 Example 2: 313 require ["notify", "fileinto", "variables", "envelope"]; 315 if header :matches "from" "*@*.example.org" { 316 # :matches is used to get the MAIL FROM address 317 if envelope :all :matches "from" "*" { 318 set "env_from" " [really: ${1}]"; 319 } 321 # :matches is used to get the value of the Subject header 322 if header :matches "Subject" "*" { 323 set "subject" "${1}"; 324 } 326 # :matches is used to get the address from the From header 327 if address :matches :all "from" "*" { 328 set "from_addr" "${1}"; 329 } 331 notify :message "${from_addr}${env_from}: ${subject}"; 332 } 334 Example 3: 335 require ["notify", "variables"]; 337 set "notif_method" 338 "xmpp:tim@example.com?You%20got%20mail&subject=SIEVE"; 340 if header :contains "subject" "Your dog" { 341 set "notif_method" "sms:+14085551212"; 342 } 344 if header :contains "to" "sievemailinglist@example.org" { 345 set "notif_method" ""; 346 } 348 if not string :is "${notif_method}" "" { 349 notify :method "${notif_method}"; 350 } 352 if header :contains "from" "boss@example.org" { 353 # :matches is used to get the value of the Subject header 354 if header :matches "Subject" "*" { 355 set "subject" "${1}"; 356 } 358 # don't need high importance notification for 359 # a 'for your information' 360 if not header :contains "subject" "FYI:" { 361 notify :method "sms:+14085551212" 362 :importance "1" :message "BOSS: ${subject}"; 363 } 364 } 366 [[anchor2: Make sure that the XMPP notification syntax is correct.]] 368 3.8. Requirements on notification methods specifications 370 This section describes requirements on a document describing a Sieve 371 notification method. 373 A notification method MAY allow modification of the final 374 notification text -- for example, truncating it if it exceeds a 375 length limit, or modifying characters that can not be represented in 376 the target character set. Characters in the notification text which 377 can't be represented by the notification method SHOULD be replaced 378 with a symbol indicating an unknown character. Allowed modifications 379 MUST be documented in the document describing the notification 380 method. 382 A notification method MAY ignore parameters specified in the Notify 383 action. [[Alexey 4: Does this apply to :message? I.e., do we want 384 to allow for notifications that can only transport "you got mail" 385 indicator?]] 387 It is RECOMMENDED that a timestamp be included in the notification. 389 Implementations SHOULD NOT include extraneous information not 390 specified in parameters to the notify action. 392 If there are errors sending the notification, the Sieve interpreter 393 SHOULD ignore the notification and not retry indefinitely. Document 394 describing a notification method SHOULD describe how retries, 395 duplicate suppression (if any), etc. are to be handled by 396 implementations. 398 4. Extract_text Action 400 Usage: extract_text [MODIFIER] [":first" number] 401 403 The Extract_text action stores at most :first bytes of the first 404 text/* part in the variable identified by varname. If the :first 405 parameter is not present, the whole content of the first text/* part 406 is stored. If the message being processed doesn't contain any text/* 407 part, the action will set the variable identified by varname to empty 408 string. [[Alexey 5: Do we need to be more specific about what "the 409 first text part" means?]] 411 Modifiers are applied on the extracted text before it is stored in 412 the variable. See [Variables] for details. 414 Note that this action is only available when the Sieve script 415 specifies both "variables" [Variables] and "notify" capabilities in 416 the require statements. 418 Example 4: 419 require ["notify", "variables"]; 421 if header :contains "from" "boss@example.org" { 422 # :matches is used to get the value of the Subject header 423 if header :matches "Subject" "*" { 424 set "subject" "${1}"; 425 } 427 # extract the first 100 bytes of the first text/* part 428 extract_text :first 100 "msgcontent"; 430 # don't need high importance notification for 431 # a 'for your information' 432 if not header :contains "subject" "FYI:" { 433 notify :method "sms:+14085551212" 434 :importance "1" :message 435 "BOSS: ${subject}; ${msgcontent}"; 436 } 437 } 439 5. Test valid_notif_method 441 Usage: valid_notif_method 443 The "valid_notif_method" test is true if the notification methods 444 listed in the notification-uris argument are supported and they are 445 syntactically and semantically (including implementation-specific 446 semantic restrictions) valid. This test MUST perform exactly the 447 same validation as would be performed on the ":method" parameter of 448 the "notify" action. 450 All of the listed notification methods must be supported and valid or 451 the test is false. 453 Example 5: 454 if not valid_notif_method ["mailto:", 455 "http://gw.example.net/notify?test"] { 456 stop; 457 } 459 6. Interactions with Other Sieve Actions 461 The notify action is compatible with all other actions, and does not 462 affect the operation of other actions. In particular, the notify 463 action MUST NOT cancel the implicit keep. 465 Multiple executed notify actions are allowed. 467 7. Security Considerations 469 Security considerations are discussed in [Sieve]. Additionally, 470 implementations must be careful to follow the security considerations 471 of the specific notification methods. 473 The notify action is potentially very dangerous. The path the 474 notification takes through the network may not be secure. An error 475 in the options string may cause the message to be transmitted to 476 someone it was not intended for, or may expose information to 477 eavesdroppers. 479 Just because a notification is received doesn't mean that it was sent 480 by the Sieve implementation. It might be possible to forge 481 notifications with some notification methods. 483 An organization may have a policy about forwarding of any classified 484 information to unclassified networks. Unless the policy is also 485 enforced in the module responsible for generating (or sending) of 486 notifications, users can use the extension defined in this document 487 to extract classified information and bypass the policy. 489 [[Alexey 6: The following might be too specific to mailto:]] Users 490 must not use notifications as poor's man "redirect" facility, as this 491 can result in mail loops and bounces. In particular, a notification 492 to an email address will not contain necessary Received header fields 493 that might be otherwise used to prevent mail loops. 495 8. Extensions to ManageSieve protocol 497 A ManageSieve [ManageSieve] server that supports the "notify" 498 extension MUST advertise the NOTIFY capability, that has a single 499 mandatory parameter. The parameter is a string containing space 500 separated list of URI schema parts for supported nofication methods. 502 Example: 503 S: "NOTIFY" "xmpp mailto" 505 9. IANA Considerations 507 The following template specifies the IANA registration of the notify 508 Sieve extension specified in this document: 510 To: iana@iana.org 511 Subject: Registration of new Sieve extension 512 Capability name: notify 513 Capability keyword: notify 514 Capability arguments: N/A 515 Standards Track/IESG-approved experimental RFC number: this RFC 516 Person and email address to contact for further information: 517 Alexey Melnikov 519 This information should be added to the list of sieve extensions 520 given on http://www.iana.org/assignments/sieve-extensions. 522 10. Acknowledgements 524 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 525 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 526 Mallett and Ned Freed for help with this document. 528 11. References 530 11.1. Normative References 532 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 533 Specifications: ABNF", RFC 4234, October 2005. 535 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", RFC 2119, March 1997. 538 [ManageSieve] 539 Martin, T. and A. Melnikov, "A Protocol for Remotely 540 Managing Sieve Scripts", work in 541 progress, draft-martin-managesieve, February 2006. 543 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 544 Language", work in progress, draft-ietf-sieve-3028bis, 545 July 2005. 547 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 548 Resource Identifier (URI): Generic Syntax", STD 66, 549 RFC 3986, January 2005. 551 [Variables] 552 Homme, K., "Sieve Extension: Variables", work in 553 progress, draft-ietf-sieve-variables, October 2005. 555 11.2. Informative References 557 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 558 Message Service", work in progress, draft-wilde-sms-uri, 559 August 2005. 561 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 562 Protocol (XMPP): Core", RFC 3920, October 2004. 564 [XMPP-URI] 565 Saint-Andre, P., "Internationalized Resource Identifiers 566 (IRIs) and Uniform Resource Identifiers (URIs) for the 567 Extensible Messaging and Presence Protocol (XMPP)", work 568 in progress, draft-saintandre-xmpp-iri, September 2005. 570 Authors' Addresses 572 Alexey Melnikov (editor) 573 Isode Limited 574 5 Castle Business Village 575 36 Station Road 576 Hampton, Middlesex TW12 2BX 577 UK 579 Email: Alexey.Melnikov@isode.com 581 Barry Leiba (editor) 582 IBM T.J. Watson Research Center 583 19 Skyline Drive 584 Hawthorne, NY 10532 585 US 587 Phone: +1 914 784 7941 588 Email: leiba@watson.ibm.com 589 Wolfgang Segmuller 590 IBM T.J. Watson Research Center 591 19 Skyline Drive 592 Hawthorne, NY 10532 593 US 595 Phone: +1 914 784 7408 596 Email: werewolf@us.ibm.com 598 Tim Martin 599 BeThereBeSquare Inc. 600 672 Haight st. 601 San Francisco, CA 94117 602 US 604 Phone: +1 510 260-4175 605 Email: timmartin@alumni.cmu.edu 607 Full Copyright Statement 609 Copyright (C) The Internet Society (2006). 611 This document is subject to the rights, licenses and restrictions 612 contained in BCP 78, and except as set forth therein, the authors 613 retain all their rights. 615 This document and the information contained herein are provided on an 616 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 617 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 618 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 619 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 620 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 621 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 623 Intellectual Property 625 The IETF takes no position regarding the validity or scope of any 626 Intellectual Property Rights or other rights that might be claimed to 627 pertain to the implementation or use of the technology described in 628 this document or the extent to which any license under such rights 629 might or might not be available; nor does it represent that it has 630 made any independent effort to identify any such rights. Information 631 on the procedures with respect to rights in RFC documents can be 632 found in BCP 78 and BCP 79. 634 Copies of IPR disclosures made to the IETF Secretariat and any 635 assurances of licenses to be made available, or the result of an 636 attempt made to obtain a general license or permission for the use of 637 such proprietary rights by implementers or users of this 638 specification can be obtained from the IETF on-line IPR repository at 639 http://www.ietf.org/ipr. 641 The IETF invites any interested party to bring to its attention any 642 copyrights, patents or patent applications, or other proprietary 643 rights that may cover technology that may be required to implement 644 this standard. Please address the information to the IETF at 645 ietf-ipr@ietf.org. 647 Acknowledgment 649 Funding for the RFC Editor function is provided by the IETF 650 Administrative Support Activity (IASA).