idnits 2.17.1 draft-ietf-lemonade-architecture-03.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 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 603. 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 (July 9, 2008) is 5769 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-09 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-10 == Outdated reference: A later version (-12) exists of draft-martin-managesieve-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 11 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: January 10, 2009 Nortel Networks 6 July 9, 2008 8 LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet 9 Mail 10 draft-ietf-lemonade-architecture-03.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 January 10, 2009. 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, 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, and 148 * Billing, charging, and so on. 150 OMA identifies different interfaces: 151 o ME-1: MEM client interface to interact via the MEM protocol with 152 the MEM server 153 o ME-2: Corresponding interface of the MEM server 154 o ME-3: Out-of-band MEM server interfaces, for example to support 155 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 the 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 203 o MEM client, other enabler and MEM server are in the mobile 204 operator domain and email server is in the domain of the email 205 service provider 206 o MEM client and other enablers are in the mobile operator domain, 207 MEM server is in a third party service provider domain and the 208 email server is in the domain of the email service provider 210 The e-mail service provider can be either a third-party service 211 provider, a network service provider, or an enterprise e-mail 212 service. 214 2.3. OMA MEM Technical Specification 216 The OMA MEM activity will conclude with a specification for a mobile 217 email enabler (MEM). The ongoing work is in OMA MEM Technical 218 Specification [MEM-ts]. LEMONADE is a basis for the mechanism. 219 However, some additional details that are outside the scope of IETF 220 will also be included. 222 OMA provides ways to perform provisioning via OMA client provisioning 223 and device management. Other provisioning specifications are 224 available (e.g., SMS based). 226 OMA provides enablers to support out-of-band notification mechanisms, 227 as well as filter specifications (such as XDM), remote device 228 deactivation, and other, non-Internet activities. 230 3. IETF LEMONADE Architecture 232 This section introduces the LEMONADE Architecture. 234 The IETF LEMONADE activity has derived a LEMONADE profile 235 [PROFILE-bis] with the logical architecture represented in Figure 2, 236 where arrows indicate content flows. 238 ______________ 239 | | 240 _________| Notification | 241 | | Mechanism | 242 | |______________| 243 |Notif. ^ 244 |Protocol | 245 | ___|______ 246 | | | _____ 247 __v__ IMAP | LEMONADE | ESMTP | | 248 | |<----------->| IMAP |<---------------| MTA | 249 | MUA |- | Store | |_____| 250 |_____| \ |__________| 251 \ | 252 \ |URLAUTH 253 \SUBMIT | 254 \ ____v_____ 255 \ | | _____ 256 \ | LEMONADE | ESMTP | | 257 ---->| Submit |--------------->| MTA | 258 | Server | |_____| 259 |__________| 261 Figure 2: LEMONADE logical architecture 263 The LEMONADE profile [PROFILE] assumes: 264 o IMAP protocol [RFC3501] including LEMONADE profile extensions 265 [PROFILE] 266 o SUBMIT protocol [RFC4409], including LEMONADE profile extensions 267 o LEMONADE profile compliant IMAP store connected to MTA (Mail 268 Transfer Agent) via ESMTP [RFC2821] 269 o LEMONADE profile compliant Submit server connected to an MTA, 270 often via ESMTP 271 o Out-of-band server to client notifications relying on external 272 notification mechanisms (and notification protocols) that may be 273 out of scope of the LEMONADE profile. 274 o A LEMONADE aware MUA (Mail User Agent). While use of out-of-band 275 notification is described in the LEMONADE profile, support for the 276 underlying notifications mechanisms/protocols is out of scope of 277 the LEMONADE specifications. 279 Further details on the IETF email protocol stack and architecture can 280 be found in [MAIL] 282 3.1. Relationship between the OMA MEM and LEMONADE logical 283 architectures 285 Figure 3 illustrates the mapping of the IETF LEMONADE logical 286 architecture on the OMA MEM logical architecture. 287 _____________________ 288 | Other_Mob. Enablers | 289 | |--------------| | 290 _________| Notification | | 291 | | | Mechanism | | 292 | | |______________| | 293 |Notif. |____________^________| 294 |Protocol ______|__________ 295 ME-4 | | ___|_ME-3_ | 296 ___|____ | | | | _____ 297 | __v__ | IMAP | | LEMONADE | | ESMTP | | 298 || |<----------->| IMAP |<-----------| MTA | 299 || MUA || ME-2a | | Store | | |_____| 300 ||_____||\ME-1 | |__________| | 301 | MEM | \ | | | 302 | Client| \ | |URLAUTH | 303 |_______| \SUBMIT | | 304 \ | ____v_____ | 305 \ | | | | _____ 306 \ | | LEMONADE | | ESMTP | | 307 ---->| Submit |----------->| MTA | 308 ME-2b | | Server | | |_____| 309 | |__________| | 310 |MEM Email | 311 |Server Server| 312 |_________________| 313 ^ 314 |ME-5 315 | 317 Figure 3: Mapping of LEMONADE logical architecture onto the OMA MEM 318 logical architecture 320 As described in Section 3, the LEMONADE profile assumes LEMONADE 321 profile compliant IMAP stores and Submit servers. Because the 322 LEMONADE profile extends the IMAP store and the submit server, the 323 mobile enablement of email provided by the LEMONADE profile is 324 directly provided in these servers. Mapping to the OMA MEM logical 325 architecture, for the case considered and specified by the LEMONADE 326 profile, we logically combine the MEM server and email server. 327 However, in lemonade we split them logically into a distinct LEMONADE 328 message store and a LEMONADE submit server. ME-2 consists of two 329 interfaces. ME-2a is IMAP extended according to the LEMONADE 330 profile. ME-2b is SUBMIT extended according to the LEMONADE profile. 332 The MUA is part of the MEM client. 334 The external notifications mechanism is part of OMA enablers 335 specified by the OMA. 337 3.2. LEMONADE realization of OMA MEM with non-LEMONADE compliant 338 servers 340 The OMA MEM activity is not limited to enabling Lemonade compliant 341 servers. It explicitly identifies the need to support other back- 342 ends. This is, of course, outside the scope of the IETF Lemonade 343 activity. 345 3.2.1. LEMONADE realization of OMA MEM with non-LEMONADE IMAP servers 347 Figure 4 illustrates the case of IMAP servers that are not LEMONADE 348 compliant. In such case, the I2 interface between the MEM server 349 components and the IMAP store and submit server are IMAP and SUBMIT 350 without Lemonade extensions. 351 ______________ 352 | | 353 _________| Notification | 354 | | Mechanism | 355 | |______________| 356 |Notif. ^ 357 |Protocol | 358 | ___|______ _____________ 359 | | LEMONADE | | | _____ 360 __v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | | 361 | |<--------->|Enabler |<------>|IMAP |<----->| MTA | 362 | MUA |\ ME-2a | Server | |Store | |_____| 363 |_____| \ |__________| |_____________| 364 \ | 365 \ |URLAUTH 366 \SUBMIT | 367 \ ____v_____ _____________ 368 \ | | | | _____ 369 \ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | | 370 -->| MEM | |Submit | | | 371 | Enabler |------->|Server |------>| MTA | 372 ME-2b | Server | | | |_____| 373 |__________| |_____________| 375 Figure 4: Architecture to support non-LEMONADE IMAP servers with a 376 LEMONADE realization of an OMA MEM enabler 378 3.2.2. LEMONADE realization of OMA MEM with non-IMAP servers 380 Figure 5 illustrates the cases where the message store and submit 381 servers are not IMAP store or submit servers. They may be POP3 382 servers or other proprietary message stores. 383 ______________ 384 | | 385 _________| Notification | 386 | | Mechanism | 387 | |______________| 388 |Notif. ^ 389 |Protocol | 390 | ___|______ _____________ 391 | | LEMONADE | | | _____ 392 __v__ IMAP | MEM | I2 |Proprietary | ESMTP | | 393 | |<--------->|Enabler |<------>|Message |<----->| MTA | 394 | MUA |\ ME-2a | Server | |Store | |_____| 395 |_____| \ |__________| |_____________| 396 \ | 397 \ |URLAUTH 398 \SUBMIT | 399 \ ____v_____ _____________ 400 \ | | | | _____ 401 \ | LEMONADE | I2 |Proprietary | ESMTP | | 402 -->| MEM | |Submit | | | 403 | Enabler |------->|Server |------>| MTA | 404 ME-2b | Server | | | |_____| 405 |__________| |_____________| 407 Figure 5: Architecture to support non-IMAP servers with a LEMONADE 408 realization of OMA MEM enabler. 410 I2 designates proprietary adapters to the back-ends. 412 4. Filters and server to client notifications and LEMONADE 414 OMA MEM RD [MEM-req] and AD [MEM-arch] emphasize the need to provide 415 mechanisms for server to client notifications of email events and 416 filtering. Figure 6 illustrates how notification and filtering works 417 in the LEMONADE profile [PROFILE]. 419 ______________ 420 | | 421 _________| Notification | 422 | | Mechanism | 423 | |______________| 424 |Notif. ^ 425 |Protocol -------\ _|__ 426 | ______| ___\>|NF|____ 427 | | | ---- | _____ 428 __v__| IMAP |__ LEMONADE |___ ESMTP __| | 429 | |<-------->|VF| IMAP |DF |<--------|AF| MTA | 430 | MUA |\ ME-2a |-- Store |--- --|_____| 431 |_____| \ |_____________| ^ 432 \_\_______________|_______| 433 \ |URLAUTH 434 \SUBMIT | 435 \ ____v_____ 436 \ | | _____ 437 \ | LEMONADE | ESMTP | | 438 ---->| Submit |--------------->| MTA | 439 ME-2b | Server | |_____| 440 |__________| 442 Figure 6: Filtering mechanism defined in LEMONADE architecture 444 In Figure 6, we define four categories of filters: 445 o AF: Administrative Filters - The e-mail service provider usually 446 sets administrative filters. The user typically does not 447 configure AF. AF applies policies covering content filtering, 448 virus protection, spam filtering, etc. 449 o DF: Deposit Filters - Filters that are executed on deposit of new 450 emails. They can be defined as SIEVE filters [SIEVE]. They can 451 include vacation notices [RFC5230]. 452 o VF: View Filters - Filters that define which emails are visible to 453 the MUA. View filters can be performed via IMAP using the 454 facilities described in [NOTIFICATIONS]. 455 o NF: Notification Filters - Filters that define for what email 456 server event an out-of-band notification is sent to the client, as 457 described in [NOTIFICATIONS]. 459 The MUA can manage the NF and DF filters using the SIEVE management 460 protocol [MANAGESIEVE]. 462 5. Security Considerations 464 We note there are security risks associated with: 466 o Out-of-band notifications 467 o Server configuration by client 468 o Client configuration by server 469 o Presence of MEM proxy servers 470 o Presence of MEM servers as intermediaries 471 o Measures to address the need to traverse firewalls 473 We refer the reader to the relevant Internet Mail, IMAP, SUBMIT, and 474 Lemonade documents for how we address these issues. 476 6. IANA considerations 478 None. 480 7. Acknowledgements 482 The authors acknowledge and appreciate the work and comments of the 483 IETF LEMONADE working group and the OMA MEM working group. We 484 extracted the contents of this document from sections of 485 draft-ietf-lemonade-profile-bis-05.txt by Stephane Maes, Alexey 486 Melnikov and Dave Cridland, as well as sections of 487 draft-ietf-lemonade-notifications-04.txt by Stephane Maes and Ray 488 Cromwell. 490 8. Informative References 492 [MEM-arch] 493 Open Mobile Alliance, "Mobile Email Architecture 494 Document", June 2007, . 499 [MEM-req] Open Mobile Alliance, "Mobile Email Requirements 500 Document", OMA http://www.openmobilealliance.org/, 501 Oct 2005. 503 [MEM-ts] Open Mobile Alliance, "Mobile Email Technical 504 Specification", OMA (Work in Progress), 505 http://www.openmobilealliance.org/, Oct 2007. 507 [PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support 508 Diverse Service Environments (Lemonade) Profile", 509 RFC 4550, June 2006. 511 [PROFILE-bis] 512 Cridland, D., Melnikov, A., and S. Maes, "The Lemonade 513 Profile", draft-ietf-lemonade-profile-bis-09 (work in 514 progress), June 2008. 516 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 517 4rev1", RFC 3501, March 2003. 519 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 520 April 2001. 522 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 523 RFC 4409, April 2006. 525 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 526 Vacation Extension", RFC 5230, January 2008. 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-10 (work 535 in progress), July 2008. 537 [MAIL] Crocker, D., "Internet Mail Architecture", 538 draft-crocker-email-arch-10 (work in progress), 539 February 2008. 541 [MANAGESIEVE] 542 Melnikov, A. and T. Martin, "A Protocol for Remotely 543 Managing Sieve Scripts", draft-martin-managesieve-10 (work 544 in progress), June 2008. 546 Authors' Addresses 548 Eric W. Burger 549 New Hampshire 550 USA 552 Phone: 553 Fax: +1 530-267-7447 554 Email: eburger@standardstrack.com 555 URI: http://www.standardstrack.com 556 Glenn Parsons 557 Nortel Networks 558 3500 Carling Avenue 559 Ottawa, ON K2H 8E9 560 Canada 562 Phone: +1 613 763 7582 563 Email: gparsons@nortel.com 565 Full Copyright Statement 567 Copyright (C) The IETF Trust (2008). 569 This document is subject to the rights, licenses and restrictions 570 contained in BCP 78, and except as set forth therein, the authors 571 retain all their rights. 573 This document and the information contained herein are provided on an 574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 575 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 576 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 577 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 578 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 581 Intellectual Property 583 The IETF takes no position regarding the validity or scope of any 584 Intellectual Property Rights or other rights that might be claimed to 585 pertain to the implementation or use of the technology described in 586 this document or the extent to which any license under such rights 587 might or might not be available; nor does it represent that it has 588 made any independent effort to identify any such rights. Information 589 on the procedures with respect to rights in RFC documents can be 590 found in BCP 78 and BCP 79. 592 Copies of IPR disclosures made to the IETF Secretariat and any 593 assurances of licenses to be made available, or the result of an 594 attempt made to obtain a general license or permission for the use of 595 such proprietary rights by implementers or users of this 596 specification can be obtained from the IETF on-line IPR repository at 597 http://www.ietf.org/ipr. 599 The IETF invites any interested party to bring to its attention any 600 copyrights, patents or patent applications, or other proprietary 601 rights that may cover technology that may be required to implement 602 this standard. Please address the information to the IETF at 603 ietf-ipr@ietf.org.