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