idnits 2.17.1 draft-ietf-lemonade-architecture-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. 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 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 29, 2007) is 5961 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4550 (ref. '4') (Obsoleted by RFC 5550) == Outdated reference: A later version (-12) exists of draft-ietf-lemonade-profile-bis-07 -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. '6') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4409 (ref. '8') (Obsoleted by RFC 6409) == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-09 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LEMONADE Working Group E. Burger 3 Internet-Draft BEA Systems, Inc. 4 Intended status: Informational G. Parsons 5 Expires: July 1, 2008 Nortel Networks 6 December 29, 2007 8 LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet 9 Mail 10 draft-ietf-lemonade-architecture-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 1, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies the architecture for mobile email, as 44 described by the OMA, using Internet Mail protocols. This 45 architecture is the basis of the work of the LEMONADE WG and is a 46 guideline for the LEMONADE Profile. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. OMA Mobile Email (MEM) . . . . . . . . . . . . . . . . . . . . 3 52 2.1. OMA MEM Requirements . . . . . . . . . . . . . . . . . . . 3 53 2.2. OMA MEM Architecture . . . . . . . . . . . . . . . . . . . 3 54 2.2.1. OMA MEM logical Architecture . . . . . . . . . . . . . 3 55 2.2.2. OMA MEM Deployment Issues . . . . . . . . . . . . . . 5 56 2.3. OMA MEM Technical Specification . . . . . . . . . . . . . 6 57 3. IETF LEMONADE Architecture . . . . . . . . . . . . . . . . . . 6 58 3.1. Relationship between the OMA MEM and LEMONADE logical 59 architectures . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2. LEMONADE realization of OMA MEM with non-LEMONADE 61 compliant servers . . . . . . . . . . . . . . . . . . . . 9 62 3.2.1. LEMONADE realization of OMA MEM with non-LEMONADE 63 IMAP servers . . . . . . . . . . . . . . . . . . . . . 9 64 3.2.2. LEMONADE realization of OMA MEM with non-IMAP 65 servers . . . . . . . . . . . . . . . . . . . . . . . 10 66 4. Filters and server to client notifications and LEMONADE . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. Informative References . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . . . . 14 74 1. Introduction 76 This document describes the architecture of OMA mobile email (MEM) 77 using Internet Mail protocols defined by the IETF. The LEMONADE work 78 group has enhanced many of these protocols for use in the mobile 79 environment and are summarized in the LEMONADE profile [4] and its 80 revision LEMONADE profile bis [5]. This document shows how the OMA 81 MEM Requirement document [2], OMA MEM Architecture [1], and OMA MEM 82 Technical Specification [3] relate to the work of LEMONADE. 84 2. OMA Mobile Email (MEM) 86 The OMA Mobile Email (MEM) sub-working group has spent some time 87 studying the requirements and architecture of mobile email. IETF 88 LEMONADE has been liaising with them and has based much of our 89 Internet Mail enhancements based on their input. This section 90 summarizes the output of the OMA. 92 2.1. OMA MEM Requirements 94 The OMA MEM activity collected a set of use cases and derived 95 requirements for a mobile email enabler (MEM). The OMA MEM 96 Requirements [2] summarizes this work. Some requirements relates to 97 email protocols, some involve other OMA technologies outside the 98 scope of IETF and some relate to implementations and normative 99 interoperability statements for clients and servers. 101 2.2. OMA MEM Architecture 103 This section introduces the OMA MEM Architecture. 105 2.2.1. OMA MEM logical Architecture 107 The OMA MEM activity has derived a logical architecture from the 108 requirements and use cases described in [2]. A simplification for 109 illustrative purposes is shown in Figure 1, where arrows indicate 110 content flows. 112 __________ 113 | Other | 114 +---| Mobile |<--+ 115 | | Enablers | | 116 | |__________| | 117 |ME-4 |ME-3 118 _v____ ___v____ ________ 119 | |ME-1 | | | | 120 | MEM |-------->| MEM | I2 | Email | 121 |Client| ME-2| Server |<---->| Server | 122 |______|<--------|________| |________| 123 ^ 124 |ME-5 125 | 127 Figure 1: Basic OMA MEM logical architecture 129 Figure 1 identifies the following elements: 130 o The MEM client that implements the client-side functionality of 131 the OMA Mobile Email Enabler. It is also responsible for 132 providing the mobile email user experience and interface to the 133 user and storing the email and data to be sent to the MEM server 134 when not connected. 135 o The MEM server that implements the server-side functionality of 136 the OMA Mobile Email Enabler (MEM). 137 o The MEM protocol between the MEM Client and MEM Server. It is 138 responsible for all the in-band data exchanges that take place 139 between the MEM client and server in order to update the MEM 140 client with email server changes, the email server with changes in 141 the MEM client and to send new email from the email server. 142 o Other OMA enablers are needed to directly support the mobile email 143 enabler. They are out of scope of IETF but they may include 144 support for: 145 * Client provisioning and management for over the air 146 installation of the MEM client on the device, provisioning of 147 its settings and revocation, and 148 * Messaging enablers for out-of-band notification, where out-of- 149 band notifications that are server to client event exchanges 150 not transported by the MEM protocol but via other channels. 152 OMA identifies different interfaces: 153 o ME-1: MEM client interface to interact via the MEM protocol with 154 the MEM server 155 o ME-2: Corresponding interface of the MEM server 156 o ME-3: Out-of-band MEM server interfaces, for example to support 157 generation of server to client notifications. 159 o ME-4: Out-of-band MEM client interfaces (e.g. to receive server to 160 client notifications). 161 o ME-5: Interface for management of MEM enabler server settings, 162 user preferences, and filters, globally and per account. 164 The MEM server enables an email server. In a particular 165 implementation, the email server may be packaged with (internal to 166 it) the MEM server or be a separate component. In such cases, 167 interfaces to the email server are out of scope of the OMA MEM 168 specifications. In the present document, we focus on the case where 169 the backend consists of IETF IMAP and Submit servers. However, we 170 also discuss the relationship to other cases. The I2 interface is an 171 OMA notation to designate protocol / interfaces that are not 172 specified by the MEM enabler but may be standardized elsewhere. 174 2.2.2. OMA MEM Deployment Issues 176 The OMA MEM Architecture document [1] further identifies deployment 177 models. 179 2.2.2.1. OMA MEM proxy 181 The OMA MEM Architecture document [1] identifies OMA MEM server 182 proxies as server components that may be deployed ahead of firewalls 183 to facilitate firewall traversal. 185 2.2.2.2. OMA MEM deployment cases 187 OMA MEM identifies that each component (MEM client, MEM servers, 188 other enablers, and the email server) may be deployed in different 189 domains, possibly separated by firewalls and other network 190 intermediaries. MEM proxies may be involved in front of firewall 191 that protects the MEM server domain. 193 OMA MEM targets support of configurations where: 194 o All components are within a same domain, such as in a mobile 195 operator 196 o MEM client and other enablers are in the mobile operator domain, 197 there is a MEM proxy, and the MEM server and email server are in 198 the domain of the email service provider 199 o MEM client and other enablers as well as a MEM proxy are in the 200 mobile operator domain, MEM server and email server are in the 201 domain of the email service provider 202 o MEM client and other enablers are in the mobile operator domain, a 203 MEM proxy is in a third party service provider domain and MEM 204 server and email server are in the domain of the email service 205 provider 207 o MEM client, other enabler and MEM server are in the mobile 208 operator domain and email server is in the domain of the email 209 service provider 210 o MEM client and other enablers are in the mobile operator domain, 211 MEM server is in a third party service provider domain and the 212 email server is in the domain of the email service provider 214 The e-mail service provider can be either a third-party service 215 provider, a network service provider, or an enterprise e-mail 216 service. 218 2.3. OMA MEM Technical Specification 220 The OMA MEM activity will conclude with a specification for a mobile 221 email enabler (MEM). The ongoing work is in OMA MEM Technical 222 Specification [3]. LEMONADE is a basis for the mechanism. However, 223 some additional details that are outside the scope of IETF will also 224 be included. 226 OMA provides ways to perform provisioning via OMA client provisioning 227 and device management. Other provisioning specifications are 228 available (e.g., SMS based). 230 OMA provides enablers to support out-of-band notification mechanisms, 231 as well as filter specifications (such as XDM), remote device 232 deactivation, and other, non-Internet activities. 234 3. IETF LEMONADE Architecture 236 This section introduces the LEMONADE Architecture. 238 The IETF LEMONADE activity has derived a LEMONADE profile [4] with 239 the logical architecture represented in Figure 2, where arrows 240 indicate content flows. 242 ______________ 243 | | 244 _________| Notification | 245 | | Mechanism | 246 | |______________| 247 |Notif. ^ 248 |Protocol | 249 | ___|______ 250 | | | _____ 251 __v__ IMAP | LEMONADE | ESMTP | | 252 | |<----------->| IMAP |<---------------| MTA | 253 | MUA |- | Store | |_____| 254 |_____| \ |__________| 255 \ | 256 \ |URLAUTH 257 \SUBMIT | 258 \ ____v_____ 259 \ | | _____ 260 \ | LEMONADE | ESMTP | | 261 ---->| Submit |--------------->| MTA | 262 | Server | |_____| 263 |__________| 265 Figure 2: LEMONADE logical architecture 267 The LEMONADE profile [4] assumes: 268 o IMAP protocol [6] including LEMONADE profile extensions [4] 269 o SUBMIT protocol [8], including LEMONADE profile extensions 270 o LEMONADE profile compliant IMAP store connected to MTA (Mail 271 Transfer Agent) via ESMTP [7] 272 o LEMONADE profile compliant Submit server connected to MTA via 273 ESMTP 274 o Lemonade profile message store / submit server protocols (URLAUTH, 275 BURL, CATENATE) (see lemonade Profile [4]). 276 o Out-of-band server to client notifications relying on external 277 notification mechanisms (and notification protocols) that may be 278 out of scope of the LEMONADE profile. 279 o A LEMONADE aware MUA (Mail User Agent). While use of out-of-band 280 notification is described in the LEMONADE profile, support for the 281 underlying notifications mechanisms/protocols is out of scope of 282 the LEMONADE specifications. 284 Further details on the IETF email protocol stack and architecture can 285 be found in [10] 287 3.1. Relationship between the OMA MEM and LEMONADE logical 288 architectures 290 Figure 3 illustrates the mapping of the IETF LEMONADE logical 291 architecture on the OMA MEM logical architecture. 292 _____________________ 293 | Other_Mob. Enablers | 294 | |--------------| | 295 _________| Notification | | 296 | | | Mechanism | | 297 | | |______________| | 298 |Notif. |____________^________| 299 |Protocol ______|__________ 300 ME-4 | | ___|_ME-3_ | 301 ___|____ | | | | _____ 302 | __v__ | IMAP | | LEMONADE | | ESMTP | | 303 || |<----------->| IMAP |<-----------| MTA | 304 || MUA || ME-2a | | Store | | |_____| 305 ||_____||\ME-1 | |__________| | 306 | MEM | \ | | | 307 | Client| \ | |URLAUTH | 308 |_______| \SUBMIT | | 309 \ | ____v_____ | 310 \ | | | | _____ 311 \ | | LEMONADE | | ESMTP | | 312 ---->| Submit |----------->| MTA | 313 ME-2b | | Server | | |_____| 314 | |__________| | 315 |MEM Email | 316 |Server Server| 317 |_________________| 318 ^ 319 |ME-5 320 | 322 Figure 3: Mapping of LEMONADE logical architecture onto the OMA MEM 323 logical architecture 325 As described in Section 3, the LEMONADE profile assumes LEMONADE 326 profile compliant IMAP stores and Submit servers. Because the 327 LEMONADE profile extends the IMAP store and the submit server, the 328 mobile enablement of email provided by the LEMONADE profile is 329 directly provided in these servers. Mapping to the OMA MEM logical 330 architecture, for the case considered and specified by the LEMONADE 331 profile, we logically combine the MEM server and email server. 332 However, in lemonade we split them logically into a distinct LEMONADE 333 message store and a LEMONADE submit server. ME-2 consists of two 334 interfaces. ME-2a is IMAP extended according to the LEMONADE 335 profile. ME-2b is SUBMIT extended according to the LEMONADE profile. 337 The MUA is part of the MEM client. 339 The external notifications mechanism is part of OMA enablers 340 specified by the OMA. 342 3.2. LEMONADE realization of OMA MEM with non-LEMONADE compliant 343 servers 345 The OMA MEM activity is not limited to enabling Lemonade compliant 346 servers. It explicitly identifies the need to support other back- 347 ends. This is, of course, outside the scope of the IETF Lemonade 348 activity. 350 3.2.1. LEMONADE realization of OMA MEM with non-LEMONADE IMAP servers 352 Figure 4 illustrates the case of IMAP servers that are not LEMONADE 353 compliant. In such case, the I2 interface between the MEM server 354 components and the IMAP store and submit server are IMAP and SUBMIT 355 without Lemonade extensions. 356 ______________ 357 | | 358 _________| Notification | 359 | | Mechanism | 360 | |______________| 361 |Notif. ^ 362 |Protocol | 363 | ___|______ _____________ 364 | | LEMONADE | | | _____ 365 __v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | | 366 | |<--------->|Enabler |<------>|IMAP |<----->| MTA | 367 | MUA |\ ME-2a | Server | |Store | |_____| 368 |_____| \ |__________| |_____________| 369 \ | 370 \ |URLAUTH 371 \SUBMIT | 372 \ ____v_____ _____________ 373 \ | | | | _____ 374 \ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | | 375 -->| MEM | |Submit | | | 376 | Enabler |------->|Server |------>| MTA | 377 ME-2b | Server | | | |_____| 378 |__________| |_____________| 380 Figure 4: Architecture to support non-LEMONADE IMAP servers with a 381 LEMONADE realization of an OMA MEM enabler 383 3.2.2. LEMONADE realization of OMA MEM with non-IMAP servers 385 Figure 5 illustrates the cases where the message store and submit 386 servers are not IMAP store or submit servers. They may be POP3 387 servers or other proprietary message stores. 388 ______________ 389 | | 390 _________| Notification | 391 | | Mechanism | 392 | |______________| 393 |Notif. ^ 394 |Protocol | 395 | ___|______ _____________ 396 | | LEMONADE | | | _____ 397 __v__ IMAP | MEM | I2 |Proprietary | ESMTP | | 398 | |<--------->|Enabler |<------>|Message |<----->| MTA | 399 | MUA |\ ME-2a | Server | |Store | |_____| 400 |_____| \ |__________| |_____________| 401 \ | 402 \ |URLAUTH 403 \SUBMIT | 404 \ ____v_____ _____________ 405 \ | | | | _____ 406 \ | LEMONADE | I2 |Proprietary | ESMTP | | 407 -->| MEM | |Submit | | | 408 | Enabler |------->|Server |------>| MTA | 409 ME-2b | Server | | | |_____| 410 |__________| |_____________| 412 Figure 5: Architecture to support non-IMAP servers with a LEMONADE 413 realization of OMA MEM enabler. 415 I2 designates proprietary adapters to the back-ends. 417 4. Filters and server to client notifications and LEMONADE 419 OMA MEM RD [2] and AD [1] emphasize the need to provide mechanisms 420 for server to client notifications of email events and filtering. 421 Figure 6 illustrates how notification and filtering works in the 422 LEMONADE profile [4]. 424 ______________ 425 | | 426 _________| Notification | 427 | | Mechanism | 428 | |______________| 429 |Notif. ^ 430 |Protocol -------\ _|__ 431 | ______| ___\>|NF|____ 432 | | | ---- | _____ 433 __v__| IMAP |__ LEMONADE |___ ESMTP __| | 434 | |<-------->|VF| IMAP |DF |<--------|AF| MTA | 435 | MUA |\ ME-2a |-- Store |--- --|_____| 436 |_____| \ |_____________| ^ 437 \_\_______________|_______| 438 \ |URLAUTH 439 \SUBMIT | 440 \ ____v_____ 441 \ | | _____ 442 \ | LEMONADE | ESMTP | | 443 ---->| Submit |--------------->| MTA | 444 ME-2b | Server | |_____| 445 |__________| 447 Figure 6: Filtering mechanism defined in LEMONADE architecture 449 In Figure 6, we define four categories of filters: 450 o AF: Administrative Filters - The e-mail service provider usually 451 sets administrative filters. The user typically does not 452 configure AF. AF applies policies covering content filtering, 453 virus protection, spam filtering, etc. 454 o DF: Deposit Filters - Filters that are executed on deposit of new 455 emails. They can be defined as SIEVE filters [9]. They can 456 include vacation notices. 457 o VF: View Filters - Filters that define which emails are visible to 458 the MUA. View filters can be performed via IMAP using the 459 facilities described in [5]. 460 o NF: Notification Filters - Filters that define for what email 461 server event an out-of-band notification is sent to the client, as 462 described in [5]. 464 The MUA can manage the NF and DF filters using the SIEVE management 465 protocol. 467 5. Security Considerations 469 We note there are security risks associated with: 471 o Out-of-band notifications 472 o Server configuration by client 473 o Client configuration by server 474 o Presence of MEM proxy servers 475 o Presence of MEM servers as intermediaries 476 o Measures to address the need to traverse firewalls 478 We refer the reader to the relevant Internet Mail, IMAP, SUBMIT, and 479 Lemonade documents for how we address these issues. 481 6. IANA considerations 483 None. 485 7. Acknowledgements 487 The authors acknowledge and appreciate the work and comments of the 488 IETF LEMONADE working group and the OMA MEM working group. We 489 extracted the contents of this document from sections of 490 draft-ietf-lemonade-profile-bis-05.txt and 491 draft-ietf-lemonade-notifications-04.txt. 493 8. Informative References 495 [1] Open Mobile Alliance, "Mobile Email Architecture Document", 496 June 2007, . 500 [2] Open Mobile Alliance, "Mobile Email RequirementS Document", 501 OMA http://www.openmobilealliance.org/, Oct 2005. 503 [3] Open Mobile Alliance, "Mobile Email Technical Specification", 504 OMA (Work in Progress), http://www.openmobilealliance.org/, 505 Oct 2007. 507 [4] Maes, S. and A. Melnikov, "Internet Email to Support Diverse 508 Service Environments (Lemonade) Profile", RFC 4550, June 2006. 510 [5] Cridland, D., Melnikov, A., and S. Maes, "The Lemonade 511 Profile", draft-ietf-lemonade-profile-bis-07 (work in 512 progress), November 2007. 514 [6] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 515 4rev1", RFC 3501, March 2003. 517 [7] Gwinn, R., "Simple Network Paging Protocol - Version 3 -Two-Way 518 Enhanced", RFC 1861, October 1995. 520 [8] Gellens, R. and J. Klensin, "Message Submission for Mail", 521 RFC 4409, April 2006. 523 [9] Guenther, P. and T. Showalter, "Seive: An Email Filtering 524 Language", October 2007, . 527 [10] Crocker, D., "Internet Mail Architecture", 528 draft-crocker-email-arch-09 (work in progress), May 2007. 530 Authors' Addresses 532 Eric W. Burger 533 BEA Systems, Inc. 534 4 Van de Graaf Dr. 535 Burlington, MA 01803 536 USA 538 Phone: +1 781 993 7437 539 Fax: 540 Email: eric.burger@bea.com 541 URI: http://www.standardstrack.com 543 Glenn Parsons 544 Nortel Networks 545 3500 Carling Avenue 546 Ottawa, ON K2H 8E9 547 Canada 549 Phone: +1 613 763 7582 550 Email: gparsons@nortel.com 552 Full Copyright Statement 554 Copyright (C) The IETF Trust (2007). 556 This document is subject to the rights, licenses and restrictions 557 contained in BCP 78, and except as set forth therein, the authors 558 retain all their rights. 560 This document and the information contained herein are provided on an 561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 563 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 564 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 565 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Intellectual Property 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Acknowledgment 594 Funding for the RFC Editor function is provided by the IETF 595 Administrative Support Activity (IASA).