idnits 2.17.1 draft-mahy-sieve-notify-sip-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 622. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (July 1, 2007) is 6141 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 (-13) exists of draft-ietf-sieve-3028bis-12 == Outdated reference: A later version (-12) exists of draft-ietf-sieve-notify-07 ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4234 (ref. '6') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4474 (ref. '8') (Obsoleted by RFC 8224) == Outdated reference: A later version (-10) exists of draft-ietf-sieve-notify-mailto-02 == Outdated reference: A later version (-09) exists of draft-ietf-sieve-notify-xmpp-04 == Outdated reference: A later version (-07) exists of draft-ietf-lemonade-msgevent-02 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve WG R. Mahy 3 Internet-Draft Plantronics 4 Expires: January 2, 2008 July 1, 2007 6 Sieve Notification Using the Session Initiation Protocol (SIP) Message 7 Summary and Message Waiting Indication Event Package 8 draft-mahy-sieve-notify-sip-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 2, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes using the existing SIP message-summary event 42 package to carry notifications generated from Sieve filter rules. 44 Table of Contents 46 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Use of Sieve filters in a message-summary subscription . . . . 4 49 4. New MIME Type for notification bodies . . . . . . . . . . . . 5 50 5. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 5 51 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 54 8.1. MIME Registration for 55 application/sieve-notification+xml . . . . . . . . . . . . 12 56 9. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 13 57 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 59 10.2. Informational References . . . . . . . . . . . . . . . . . 14 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 Intellectual Property and Copyright Statements . . . . . . . . . . 15 63 1. Conventions 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC-2119 [5]. 69 2. Background 71 Sieve [1] is an email filtering language. Individual rules in this 72 language check for specific conditions, and then execute specific 73 actions. One supported action sends a Sieve notification [2], for 74 example using email [9] or XMPP [10] (Extensible Messaging and 75 Presence Protocol). 77 SIP [3] is a protocol used for rendezvous, management of multimedia 78 sessions, and relevant event notifications [4]. Messaging Waiting 79 Indication is a common feature of telephone networks. It typically 80 involves an audible or visible indication that messages are waiting, 81 such as playing a special dial tone, lighting a light or indicator on 82 the phone, displaying icons or text, or some combination. RFC 3842 83 [7] defines a SIP event package to alert the subscriber when the 84 types of messages available have changed. 86 Using SIP-Specific Event Notification, A Subscriber User Agent 87 (typically an IP phone or SIP software User Agent) subscribes to the 88 status of their messages. A SIP User Agent acting on behalf of the 89 user's messaging system then notifies the Subscriber whenever the 90 messaging account's messages have changed. (This Notifier could be 91 composed with a User Agent that provides a real-time media interface 92 to send or receive messages, or it could be a standalone entitiy.) 93 The Notifier sends a message summary in the body of a NOTIFY, encoded 94 in a new MIME type defined later in this document. A User Agent can 95 also explicitly fetch the current status. 97 This document describes how to use the existing SIP message-summary 98 event package to convey only notifications specified by the Sieve 99 filtering language. Sieve notifications in the context of this event 100 package are always explicitly authorized. This avoids delivering 101 notifications about possibly unwanted unsolicited events. 103 The Email System Event Notification Model [12] describes sending 104 notifications about several kinds of events which are relevant to 105 email systems [11], and describes a model to convey those 106 notifications. This document is largely orthogonal in that it 107 provides access to almost none of the mailbox events, and it 108 explicitly defines a mechanism to dynamically setup a sieve filter 109 and solicit notifications indirectly triggered by new incoming 110 messages (which the model does not address). The notifier for this 111 package could be collocated with the "Publisher Notifications 112 Aggregator (PNA)" role described in the model document. 114 3. Use of Sieve filters in a message-summary subscription 116 SIP event notification is designed to present consistent, reliable, 117 synchronized state even when SIP user agents temporarily lose and re- 118 establish network connectivity. Because of this design requirement, 119 a new subscription always contains an explicit initial state. In the 120 context of Sieve notifications, this initial state can contain 121 notifications that the subscriber has not seen yet, even if those 122 notifications where already sent using other notification methods or 123 received by other SIP subscribers. Since multiple Sieve 124 notifications could be received in a single NOTIFY request, the 125 notifications are enclosed in a simple container using XML, as 126 described in the next section. 128 To explicitly indicate the begining of time to use for notifications, 129 the subscriber can include a new optional SIP Event header parameter 130 'notify-counter'. If this parameter is included, the notifier can 131 provide notifications consistent with this "version" of the notify- 132 counter. If the notification contains the same notify-counter as the 133 corresponding subscription, the subscriber knows that it did not miss 134 any notifications. 136 When a MIME body is included in a SIP SUBSCRIBE request, this body is 137 treated as an event filter. In this application, the filter is an 138 "application/sieve" document, with a few specific requirements 139 described below. 141 The filter document used for filtering SHOULD NOT include Actions 142 other than "notify", for example: keep, delete, or fileto. The Sieve 143 notify tag ":method" MUST NOT be included, and MUST be ignored if it 144 present. The notification method and URI are already specified more 145 formally in the SIP SUBSCRIBE request. Likewise the notify tag 146 ":from" MUST be ignored. The From header of the notification is 147 already set in the SIP dialog used for the subscription. 149 The ":message" notify tag is used to construct a (probably human- 150 readable) string that appears in the 'message' element of the 151 notification. This document also defines a new notify option 152 "headerlist" (used with the ":options" notify tag). The value of the 153 "headerlist" option is a comma-separated list of email headers, each 154 of which will be included in its own 'header' element in the 155 notification. The usage of the headerlist is completely optional. 157 4. New MIME Type for notification bodies 159 This section defines a new MIME type "application/ 160 sieve-notification+xml". This document format contains a top-level 161 'sieve-notifications' element, which has a mandatory 'notify-counter' 162 attribute. This counter is an unsigned integer. This element 163 contains zero or more 'notification' elements. Each 'notification' 164 element contains exactly one 'message' element with the populated 165 contents of the ":message" notify tag. Each 'notification' element 166 can also contain zero or more 'header' elements. Each 'header' 167 element has a mandatory 'name' attribute with the name of a header 168 from the 'headerlist' ":options" notify tag. The contents of the 169 'header' element is the value of the named header. 171 A relax NG schema for this body type is included in the Appendix. 172 Below is a Sieve filter in a SUBSCRIBE body, and the corresponding 173 notification body. A full example is given in the next section. 175 === SUBSCRIBE Body === 176 require ["enotify"]; 178 if header :contains "from" "example.com" { 179 notify :message "Reminder to call about project foobar" 180 :options "headerlist" "From,Subject"; 181 } 183 === NOTIFY Body === 184 185 186 187
alice@example.com
188
Foobar status report
189 Reminder to call about project foobar 190 191 193 5. Example Message Flow 195 The examples shown below are for informational purposes only. 197 In the example call flow below, Alice's IP phone subscribes to the 198 status of Alice's messages. Via headers are omitted for clarity. 200 Subscriber Notifier 201 | | 202 | A1: SUBSCRIBE (new) | 203 |---------------------->| 204 | A2: 200 OK | 205 |<----------------------| 206 | | 207 | A3: NOTIFY (sync) | 208 |<----------------------| 209 | A4: 200 OK | 210 |---------------------->| 211 | | 212 | |<--- email arrives 213 | A5: NOTIFY (change) | 214 |<----------------------| 215 | A6: 200 OK | 216 |---------------------->| 217 | | 218 | | 219 | A7: (re)SUBSCRIBE | 220 |---------------------->| 221 | A8: 200 OK | 222 |<----------------------| 223 | | 224 | A9: NOTIFY (sync) | 225 |<----------------------| 226 | A10: 200 OK | 227 |---------------------->| 228 | | 229 | | 230 | A11: (un)SUBSCRIBE | 231 |---------------------->| 232 | A12: 200 OK | 233 |<----------------------| 234 | | 235 | A13: NOTIFY (sync) | 236 |<----------------------| 237 | A14: 200 OK | 238 |---------------------->| 240 A1: Subscriber (Alice's phone) -> 241 Notifier (Alice's voicemail gateway) 242 Subscribe to Alice's message summary status for 1 hour. 244 SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 245 To: 246 From: ;tag=78923 247 Date: Mon, 10 Jul 2000 03:55:06 GMT 248 Call-Id: 1349882@alice-phone.example.com 249 CSeq: 4 SUBSCRIBE 250 Contact: 251 Event: message-summary 252 Expires: 3600 253 Accept: application/sieve-notification+xml 254 Content-Type: application/sieve 255 Content-Length: 85 257 require ["enotify"]; 259 if header :contains "from" "example.com" { 260 notify :message "Reminder to call about project foobar" 261 :options "headerlist" "From,Subject"; 262 } 264 A2: Notifier -> Subscriber 266 SIP/2.0 200 OK 267 To: ;tag=4442 268 From: ;tag=78923 269 Date: Mon, 10 Jul 2000 03:55:07 GMT 270 Call-Id: 1349882@alice-phone.example.com 271 CSeq: 4 SUBSCRIBE 272 Expires: 86400 273 Content-Length: 0 275 A3: Notifier -> Subscriber 276 (immediate synchronization of current state: 277 no notifications to report) 279 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 280 To: ;tag=78923 281 From: ;tag=4442 282 Date: Mon, 10 Jul 2000 03:55:07 GMT 283 Call-Id: 1349882@alice-phone.example.com 284 CSeq: 20 NOTIFY 285 Contact: 286 Event: message-summary 287 Subscription-State: active;expires=3600 288 Content-Type: application/sieve-notification+xml 289 Content-Length: 79 291 292 294 A4: Subscriber -> Notifier 296 SIP/2.0 200 OK 297 To: ;tag=78923 298 From: ;tag=4442 299 Date: Mon, 10 Jul 2000 03:55:08 GMT 300 Call-Id: 1349882@alice-phone.example.com 301 CSeq: 20 NOTIFY 302 Content-Length: 0 304 A5: Notifier -> Subscriber 305 This is a notification of a new message. 307 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 308 To: ;tag=78923 309 From: ;tag=4442 310 Date: Mon, 10 Jul 2000 04:28:53 GMT 311 Contact: 312 Call-ID: 1349882@alice-phone.example.com 313 CSeq: 31 NOTIFY 314 Event: message-summary 315 Subscription-State: active;expires=1665 316 Content-Type: application/sieve-notification+xml 317 Content-Length: 319 320 321 322
alice@example.com
323
Foobar status report
324 Reminder to call about project foobar 325 326 328 A6: Subscriber -> Notifier 330 SIP/2.0 200 OK 331 To: ;tag=78923 332 From: ;tag=4442 333 Date: Mon, 10 Jul 2000 04:28:53 GMT 334 Call-ID: 1349882@alice-phone.example.com 335 CSeq: 31 NOTIFY 336 Content-Length: 0 338 A7: Subscriber -> Notifier 339 Refresh subscription. 341 SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 342 To: ;tag=4442 343 From: ;tag=78923 344 Date: Mon, 10 Jul 2000 04:55:06 GMT 345 Call-Id: 1349882@alice-phone.example.com 346 CSeq: 8 SUBSCRIBE 347 Contact: 348 Event: message-summary;notify-counter=4589 349 Expires: 3600 350 Accept: application/sieve-notification+xml 351 Content-Length: 0 353 A8: Notifier -> Subscriber 355 SIP/2.0 200 OK 356 To: ;tag=4442 357 From: ;tag=78923 358 Date: Mon, 10 Jul 2000 04:55:07 GMT 359 Call-Id: 1349882@alice-phone.example.com 360 CSeq: 8 SUBSCRIBE 361 Contact: 362 Expires: 86400 363 Content-Length: 0 365 A9: Notifier -> Subscriber 366 (immediate synchronization of current state) 368 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 369 To: ;tag=78923 370 From: ;tag=4442 371 Date: Mon, 10 Jul 2000 04:55:07 GMT 372 Call-Id: 1349882@alice-phone.example.com 373 CSeq: 47 NOTIFY 374 Contact: 375 Event: message-summary 376 Subscription-State: active;expires=3600 377 Content-Type: application/sieve-notification+xml 378 Content-Length: 79 380 381 383 A10: Subscriber -> Notifier 385 SIP/2.0 200 OK 386 To: ;tag=78923 387 From: ;tag=4442 388 Date: Mon, 10 Jul 2000 04:55:08 GMT 389 Call-Id: 1349882@alice-phone.example.com 390 CSeq: 47 NOTIFY 391 Contact: 393 A11: Subscriber -> Notifier 394 Un-subscribe after "alice" logs out. 396 SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 397 To: ;tag=4442 398 From: ;tag=78923 399 Date: Mon, 10 Jul 2000 05:35:06 GMT 400 Call-Id: 1349882@alice-phone.example.com 401 CSeq: 17 SUBSCRIBE 402 Contact: 403 Event: message-summary 404 Expires: 0 405 Content-Length: 0 407 A12: Notifier -> Subscriber 409 SIP/2.0 200 OK 410 To: ;tag=4442 411 From: ;tag=78923 412 Date: Mon, 10 Jul 2000 05:35:07 GMT 413 Call-Id: 1349882@alice-phone.example.com 414 CSeq: 17 SUBSCRIBE 415 Contact: 416 Content-Length: 0 418 A13: Notifier -> Subscriber 419 (immediate synchronization of current state, 420 which the subscriber can now ignore) 422 NOTIFY sip:alice@alice-phone.example.com SIP/2.0 423 To: ;tag=78923 424 From: ;tag=4442 425 Date: Mon, 10 Jul 2000 05:35:07 GMT 426 Call-Id: 1349882@alice-phone.example.com 427 CSeq: 56 NOTIFY 428 Contact: 429 Event: message-summary 430 Subscription-State: terminated;reason=timeout 431 Content-Type: application/sieve-notification+xml 432 Content-Length: 79 434 435 437 A14: Subscriber -> Notifier 439 SIP/2.0 200 OK 440 To: ;tag=78923 441 From: ;tag=4442 442 Date: Mon, 10 Jul 2000 05:35:08 GMT 443 Call-Id: 1349882@alice-phone.example.com 444 CSeq: 56 NOTIFY 445 Event: message-summary 446 Content-Length: 0 448 6. Formal Syntax 450 The following syntax specification uses the augmented Backus-Naur 451 Form (BNF) as described in RFC 4234 [6]. This document defines a new 452 Event header parameter with the name 'notify-counter'. Its formal 453 syntax is described below: 455 notify-counter = "notify-counter" EQUAL 1*DIGIT 456 ; MUST NOT exceed 2^32-1 458 7. Security Considerations 460 The bulk of the relevant privacy and security considerations are 461 discussed in Sieve [1] and Sieve notifications [2]. In addition, SIP 462 [3] subscriptions SHOULD be authenticated and authorized to fetch 463 notifications for the target SIP resource / mailbox. (Digest 464 authentication is mandatory to implement in all SIP nodes.) In 465 addition, the SIP Identity header [8] can be used to insure that 466 notifications were not forged and were not modified in transit. To 467 prevent eavesdropping, the SIP subscriber could insist on using the 468 sips: scheme which insures that SIP messages are only sent over TLS 469 protected channels. Finally, a truly paranoid user can use the SIP 470 S/MIME mechanism for end-to-end encryption, authentication, and 471 message integrity. 473 8. IANA Considerations 474 8.1. MIME Registration for application/sieve-notification+xml 476 MIME media type name: application 478 MIME subtype name: sieve-notification+xml 480 Required parameters: none. 482 Optional parameters: none. 484 Encoding considerations: Usual XML stuff here. 486 Security considerations: See the "Security Considerations" 487 section in this document. 489 Interoperability considerations: none 491 Published specification: This document. 493 Applications which use this media: The sieve-notification application 494 subtype supports the exchange of sieve email notification information 495 in SIP networks. 497 Additional information: 499 1. Magic number(s): N/A 501 2. File extension(s): N/A 503 3. Macintosh file type code: N/A 505 9. Relax NG Schema 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 525 10. References 527 10.1. Normative References 529 [1] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 530 Language", draft-ietf-sieve-3028bis-12 (work in progress), 531 February 2007. 533 [2] Melnikov, A., "Sieve Extension: Notifications", 534 draft-ietf-sieve-notify-07 (work in progress), February 2007. 536 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 537 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 538 Session Initiation Protocol", RFC 3261, June 2002. 540 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 541 Notification", RFC 3265, June 2002. 543 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 544 Levels", BCP 14, RFC 2119, March 1997. 546 [6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 547 Specifications: ABNF", RFC 4234, October 2005. 549 [7] Mahy, R., "A Message Summary and Message Waiting Indication 550 Event Package for the Session Initiation Protocol (SIP)", 551 RFC 3842, August 2004. 553 [8] Peterson, J. and C. Jennings, "Enhancements for Authenticated 554 Identity Management in the Session Initiation Protocol (SIP)", 555 RFC 4474, August 2006. 557 10.2. Informational References 559 [9] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 560 mailto", draft-ietf-sieve-notify-mailto-02 (work in progress), 561 March 2007. 563 [10] Saint-Andre, P. and A. Melnikov, "Sieve Notification Mechanism: 564 xmpp", draft-ietf-sieve-notify-xmpp-04 (work in progress), 565 March 2007. 567 [11] Gellens, R. and C. Newman, "Internet Message Store Events", 568 draft-ietf-lemonade-msgevent-02 (work in progress), May 2007. 570 [12] Dusseault, L., "Email System Event Notification Model", 571 draft-dusseault-email-notif-model-00 (work in progress), 572 June 2007. 574 Author's Address 576 Rohan Mahy 577 Plantronics 578 345 Encinal St 579 Santa Cruz, CA 95060 580 USA 582 Email: rohan@ekabal.com 584 Full Copyright Statement 586 Copyright (C) The IETF Trust (2007). 588 This document is subject to the rights, licenses and restrictions 589 contained in BCP 78, and except as set forth therein, the authors 590 retain all their rights. 592 This document and the information contained herein are provided on an 593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 594 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 595 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 596 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 597 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 600 Intellectual Property 602 The IETF takes no position regarding the validity or scope of any 603 Intellectual Property Rights or other rights that might be claimed to 604 pertain to the implementation or use of the technology described in 605 this document or the extent to which any license under such rights 606 might or might not be available; nor does it represent that it has 607 made any independent effort to identify any such rights. Information 608 on the procedures with respect to rights in RFC documents can be 609 found in BCP 78 and BCP 79. 611 Copies of IPR disclosures made to the IETF Secretariat and any 612 assurances of licenses to be made available, or the result of an 613 attempt made to obtain a general license or permission for the use of 614 such proprietary rights by implementers or users of this 615 specification can be obtained from the IETF on-line IPR repository at 616 http://www.ietf.org/ipr. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights that may cover technology that may be required to implement 621 this standard. Please address the information to the IETF at 622 ietf-ipr@ietf.org. 624 Acknowledgment 626 Funding for the RFC Editor function is provided by the IETF 627 Administrative Support Activity (IASA).