idnits 2.17.1 draft-ietf-lemonade-architecture-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. 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 (November 3, 2008) is 5652 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-11 -- 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 (-14) exists of draft-crocker-email-arch-11 == Outdated reference: A later version (-09) exists of draft-ietf-sieve-managesieve-01 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 This Space for Sale 4 Intended status: Informational G. Parsons 5 Expires: May 7, 2009 Nortel Networks 6 November 3, 2008 8 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile 9 Email (MEM) using Internet Mail 10 draft-ietf-lemonade-architecture-04 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 May 7, 2009. 37 Abstract 39 This document specifies the architecture for mobile email, as 40 described by the Open Mobile Alliance (OMA), using Internet Mail 41 protocols. This architecture was an important consideration for much 42 of the work of the LEMONADE (Enhancements to Internet email to 43 Support Diverse Service Environments) work group in the IETF. This 44 document also describes how the LEMONADE architecture meets the OMA's 45 requirements for their Mobile Email (MEM) service. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. OMA Mobile Email (MEM) . . . . . . . . . . . . . . . . . . . . 3 51 2.1. OMA MEM Requirements . . . . . . . . . . . . . . . . . . . 3 52 2.2. OMA MEM Architecture . . . . . . . . . . . . . . . . . . . 3 53 2.2.1. OMA MEM logical Architecture . . . . . . . . . . . . . 3 54 2.2.2. OMA MEM Deployment Issues . . . . . . . . . . . . . . 5 55 2.3. OMA MEM Technical Specification . . . . . . . . . . . . . 6 56 3. IETF LEMONADE Architecture . . . . . . . . . . . . . . . . . . 6 57 3.1. Relationship between the OMA MEM and LEMONADE logical 58 architectures . . . . . . . . . . . . . . . . . . . . . . 8 59 3.2. LEMONADE realization of OMA MEM with non-LEMONADE 60 compliant servers . . . . . . . . . . . . . . . . . . . . 9 61 3.2.1. LEMONADE realization of OMA MEM with non-LEMONADE 62 IMAP servers . . . . . . . . . . . . . . . . . . . . . 9 63 3.2.2. LEMONADE realization of OMA MEM with non-IMAP 64 servers . . . . . . . . . . . . . . . . . . . . . . . 10 65 4. Filters and server to client notifications and LEMONADE . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. Informative References . . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Introduction 75 This document describes the architecture of OMA mobile email (MEM) 76 using Internet Mail protocols defined by the IETF. The LEMONADE work 77 group has enhanced many of these protocols for use in the mobile 78 environment. The LEMONADE profile [PROFILE] and its revision 79 LEMONADE profile bis [PROFILE-bis] summarize such protocols and 80 protocol use. This document shows how the OMA MEM Requirement 81 document [MEM-req], OMA MEM Architecture [MEM-arch], and OMA MEM 82 Technical Specification [MEM-ts] relate to the work of LEMONADE in 83 the IETF. 85 2. OMA Mobile Email (MEM) 87 The OMA Mobile Email (MEM) sub-working group has spent some time 88 studying the requirements and architecture of mobile email. IETF 89 LEMONADE has been liaising with them and has based much of our 90 Internet Mail enhancements based on their input. This section 91 summarizes the output of the OMA. 93 2.1. OMA MEM Requirements 95 The OMA MEM activity collected a set of use cases and derived 96 requirements for a mobile email enabler (MEM). The OMA MEM 97 Requirements [MEM-req] summarizes this work. Some requirements 98 relates to email protocols, some involve other OMA technologies 99 outside the scope of IETF and some relate to implementations and 100 normative interoperability statements for clients and servers. 102 2.2. OMA MEM Architecture 104 This section introduces the OMA MEM Architecture. 106 2.2.1. OMA MEM logical Architecture 108 The OMA MEM activity has derived a logical architecture from the 109 requirements and use cases described in [MEM-req]. A simplification 110 for illustrative purposes is shown in Figure 1, where arrows indicate 111 content flows. 113 __________ 114 | Other | 115 +---| Mobile |<--+ 116 | | Enablers | | 117 | |__________| | 118 |ME-4 |ME-3 119 _v____ ___v____ ________ 120 | |ME-1 | | | | 121 | MEM |-------->| MEM | I2 | Email | 122 |Client| ME-2| Server |<---->| Server | 123 |______|<--------|________| |________| 124 ^ 125 |ME-5 126 | 128 Figure 1: Basic OMA MEM logical architecture 130 Figure 1 identifies the following elements: 131 o The MEM client that implements the client-side functionality of 132 the OMA Mobile Email Enabler. It is also responsible for 133 providing the mobile email user experience and interface to the 134 user and storing the email and data to be sent to the MEM server 135 when not connected. 136 o The MEM server that implements the server-side functionality of 137 the OMA Mobile Email Enabler (MEM). 138 o The MEM protocol between the MEM Client and MEM Server. It is 139 responsible for all the in-band data exchanges that take place 140 between the MEM client and server in order to update the MEM 141 client with email server changes, the email server with changes in 142 the MEM client and to send new email from the email server. 143 o Other OMA enablers are needed to directly support the mobile email 144 enabler. They are out of scope of IETF but they may include 145 support for: 146 * Client provisioning and management for over the air 147 installation of the MEM client on the device, provisioning of 148 its settings and revocation, 149 * Messaging enablers for out-of-band notification, where out-of- 150 band notifications that are server to client event exchanges 151 not transported by the MEM protocol but via other channels, and 152 * Billing, charging, and so on. 154 OMA identifies different interfaces: 155 o ME-1: MEM client interface to interact via the MEM protocol with 156 the MEM server 157 o ME-2: Corresponding interface of the MEM server 158 o ME-3: Out-of-band MEM server interfaces, for example to support 159 generation of server to client notifications. 160 o ME-4: Out-of-band MEM client interfaces (e.g. to receive server to 161 client notifications). 162 o ME-5: Interface for management of MEM enabler server settings, 163 user preferences, and filters, globally and per account. 165 The MEM server enables an email server. In a particular 166 implementation, the email server may be packaged with (internal to 167 it) the MEM server or be a separate component. In such cases, 168 interfaces to the email server are out of scope of the OMA MEM 169 specifications. In the present document, we focus on the case where 170 the backend consists of IETF IMAP and Submit servers. However, we 171 also discuss the relationship to other cases. The I2 interface is an 172 OMA notation to designate protocol / interfaces that are not 173 specified by the MEM enabler but may be standardized elsewhere. 175 2.2.2. OMA MEM Deployment Issues 177 The OMA MEM Architecture document [MEM-arch] further identifies 178 deployment models. 180 2.2.2.1. OMA MEM proxy 182 The OMA MEM Architecture document [MEM-arch] identifies OMA MEM 183 server proxies as server components that may be deployed ahead of 184 firewalls to facilitate firewall traversal. 186 2.2.2.2. OMA MEM deployment cases 188 OMA MEM identifies that each component (MEM client, MEM servers, 189 other enablers, and the email server) may be deployed in different 190 domains, possibly separated by firewalls and other network 191 intermediaries. MEM proxies may be involved in front of firewall 192 that protects the MEM server domain. 194 OMA MEM targets support of configurations where: 195 o All components are within the same domain, such as in a mobile 196 operator 197 o MEM client and other enablers are in the mobile operator domain, 198 there is a MEM proxy, and the MEM server and email server are in 199 the domain of the email service provider 200 o MEM client and other enablers as well as a MEM proxy are in the 201 mobile operator domain, MEM server and email server are in the 202 domain of the email service provider 203 o MEM client and other enablers are in the mobile operator domain, a 204 MEM proxy is in a third party service provider domain and MEM 205 server and email server are in the domain of the email service 206 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 a third-party service provider, a 215 network service provider, or an enterprise e-mail service. 217 2.3. OMA MEM Technical Specification 219 The OMA MEM activity will conclude with a specification for a mobile 220 email enabler (MEM). The ongoing work is in OMA MEM Technical 221 Specification [MEM-ts]. LEMONADE is a basis for the mechanism. 222 However, some additional details that are outside the scope of IETF 223 will also be included. 225 OMA provides ways to perform provisioning via OMA client provisioning 226 and device management. Other provisioning specifications are 227 available (e.g., SMS based). 229 OMA provides enablers to support out-of-band notification mechanisms, 230 as well as filter specifications (such as XDM), remote device 231 deactivation, and other, non-Internet activities. 233 3. IETF LEMONADE Architecture 235 This section introduces the LEMONADE Architecture. 237 The IETF LEMONADE activity has derived a LEMONADE profile 238 [PROFILE-bis] with the logical architecture represented in Figure 2, 239 where arrows indicate content flows. 241 ______________ 242 | | 243 _________| Notification | 244 | | Mechanism | 245 | |______________| 246 |Notif. ^ 247 |Protocol | 248 | ___|______ 249 | | | _____ 250 __v__ IMAP | LEMONADE | ESMTP | | 251 | |<----------->| IMAP |<---------------| MTA | 252 | MUA |- | Store | |_____| 253 |_____| \ |__________| 254 \ | 255 \ |URLAUTH 256 \SUBMIT | 257 \ ____v_____ 258 \ | | _____ 259 \ | LEMONADE | ESMTP | | 260 ---->| Submit |--------------->| MTA | 261 | Server | |_____| 262 |__________| 264 Figure 2: LEMONADE logical architecture 266 The LEMONADE profile [PROFILE] assumes: 267 o IMAP protocol [RFC3501] including LEMONADE profile extensions 268 [PROFILE] 269 o SUBMIT protocol [RFC4409], including LEMONADE profile extensions 270 o LEMONADE profile compliant IMAP store connected to MTA (Mail 271 Transfer Agent) via ESMTP [EMAIL] 272 o LEMONADE profile compliant Submit server connected to an MTA, 273 often via ESMTP 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. 355 It is important to note the realizations are of a schematic nature 356 and do not dictate actual implementation. For example, one could 357 envision collocating the LEMONADE MEM Enabler Server and the Submit 358 Server shown in Figure 4 in a single instantiation of the 359 implementation. Likewise, we consciously label the LEMONADE MEM 360 Enabler as neither an IMAP Proxy nor an IMAP back-to-back user agent. 361 LEMAONDE leaves the actual implementation to the developer. 363 ______________ 364 | | 365 _________| Notification | 366 | | Mechanism | 367 | |______________| 368 |Notif. ^ 369 |Protocol | 370 | ___|______ _____________ 371 | | LEMONADE | | | _____ 372 __v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | | 373 | |<--------->|Enabler |<------>|IMAP |<----->| MTA | 374 | MUA |\ ME-2a | Server | |Store | |_____| 375 |_____| \ |__________| |_____________| 376 \ | 377 \ |URLAUTH 378 \SUBMIT | 379 \ ____v_____ _____________ 380 \ | | | | _____ 381 \ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | | 382 -->| MEM | |Submit | | | 383 | Enabler |------->|Server |------>| MTA | 384 ME-2b | Server | | | |_____| 385 |__________| |_____________| 387 Figure 4: Architecture to support non-LEMONADE IMAP servers with a 388 LEMONADE realization of an OMA MEM enabler 390 3.2.2. LEMONADE realization of OMA MEM with non-IMAP servers 392 Figure 5 illustrates the cases where the message store and submit 393 servers are not IMAP store or submit servers. They may be POP3 394 servers or other proprietary message stores. 396 ______________ 397 | | 398 _________| Notification | 399 | | Mechanism | 400 | |______________| 401 |Notif. ^ 402 |Protocol | 403 | ___|______ _____________ 404 | | LEMONADE | | | _____ 405 __v__ IMAP | MEM | I2 |Proprietary | ESMTP | | 406 | |<--------->|Enabler |<------>|Message |<----->| MTA | 407 | MUA |\ ME-2a | Server | |Store | |_____| 408 |_____| \ |__________| |_____________| 409 \ | 410 \ |URLAUTH 411 \SUBMIT | 412 \ ____v_____ _____________ 413 \ | | | | _____ 414 \ | LEMONADE | I2 |Proprietary | ESMTP | | 415 -->| MEM | |Submit | | | 416 | Enabler |------->|Server |------>| MTA | 417 ME-2b | Server | | | |_____| 418 |__________| |_____________| 420 Figure 5: Architecture to support non-IMAP servers with a LEMONADE 421 realization of OMA MEM enabler. 423 I2 designates proprietary adapters to the back-ends. 425 4. Filters and server to client notifications and LEMONADE 427 OMA MEM RD [MEM-req] and AD [MEM-arch] emphasize the need to provide 428 mechanisms for server to client notifications of email events and 429 filtering. Figure 6 illustrates how notification and filtering works 430 in the LEMONADE profile [PROFILE]. 432 ______________ 433 | | 434 _________| Notification | 435 | | Mechanism | 436 | |______________| 437 |Notif. ^ 438 |Protocol -------\ _|__ 439 | ______| ___\>|NF|____ 440 | | | ---- | _____ 441 __v__| IMAP |__ LEMONADE |___ ESMTP __| | 442 | |<-------->|VF| IMAP |DF |<--------|AF| MTA | 443 | MUA |\ ME-2a |-- Store |--- --|_____| 444 |_____| \ |_____________| ^ 445 \_\_______________|_______| 446 \ |URLAUTH 447 \SUBMIT | 448 \ ____v_____ 449 \ | | _____ 450 \ | LEMONADE | ESMTP | | 451 ---->| Submit |--------------->| MTA | 452 ME-2b | Server | |_____| 453 |__________| 455 Figure 6: Filtering mechanism defined in LEMONADE architecture 457 In Figure 6, we define four categories of filters: 458 o AF: Administrative Filters - The e-mail service provider usually 459 sets administrative filters. The user typically does not 460 configure AF. AF applies policies covering content filtering, 461 virus protection, spam filtering, etc. 462 o DF: Deposit Filters - Filters that are executed on deposit of new 463 emails. They can be defined as SIEVE filters [SIEVE]. They can 464 include vacation notices [RFC5230]. As SIEVE filters, one can 465 administer them using the SIEVE management protocol [MANAGESIEVE]. 466 o VF: View Filters - Filters that define which emails are visible to 467 the MUA. View filters can be performed via IMAP using the 468 facilities described in [NOTIFICATIONS]. 469 o NF: Notification Filters - Filters that define for what email 470 server event an out-of-band notification is sent to the client, as 471 described in [NOTIFICATIONS]. 473 Refer to the aforementioned references for implementation and 474 management of the respective filters. 476 5. Security Considerations 478 We note there are security risks associated with: 479 o Out-of-band notifications 480 o Server configuration by client 481 o Client configuration by server 482 o Presence of MEM proxy servers 483 o Presence of MEM servers as intermediaries 484 o Measures to address the need to traverse firewalls 486 We refer the reader to the relevant Internet Mail, IMAP, SUBMIT, and 487 Lemonade documents for how we address these issues. 489 6. IANA considerations 491 None. 493 7. Acknowledgements 495 The authors acknowledge and appreciate the work and comments of the 496 IETF LEMONADE working group and the OMA MEM working group. We 497 extracted the contents of this document from sections of 498 draft-ietf-lemonade-profile-bis-05.txt by Stephane Maes, Alexey 499 Melnikov and Dave Cridland, as well as sections of 500 draft-ietf-lemonade-notifications-04.txt by Stephane Maes and Ray 501 Cromwell. 503 8. Informative References 505 [MEM-arch] 506 Open Mobile Alliance, "Mobile Email Architecture 507 Document", June 2007, . 512 [MEM-req] Open Mobile Alliance, "Mobile Email Requirements 513 Document", OMA http://www.openmobilealliance.org/, 514 Oct 2005. 516 [MEM-ts] Open Mobile Alliance, "Mobile Email Technical 517 Specification", OMA (Work in Progress), 518 http://www.openmobilealliance.org/, Oct 2007. 520 [PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support 521 Diverse Service Environments (Lemonade) Profile", 522 RFC 4550, June 2006. 524 [PROFILE-bis] 525 Cridland, D., Melnikov, A., and S. Maes, "The Lemonade 526 Profile", draft-ietf-lemonade-profile-bis-11 (work in 527 progress), September 2008. 529 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 530 4rev1", RFC 3501, March 2003. 532 [EMAIL] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 533 October 2008. 535 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 536 RFC 4409, April 2006. 538 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 539 Vacation Extension", RFC 5230, January 2008. 541 [SIEVE] Guenther, P. and T. Showalter, "Seive: An Email Filtering 542 Language", RFC 5528, January 2008, 543 . 545 [NOTIFICATIONS] 546 Gellens, R. and S. Maes, "Lemonade Notifications 547 Architecture", draft-ietf-lemonade-notifications-10 (work 548 in progress), July 2008. 550 [MAIL] Crocker, D., "Internet Mail Architecture", 551 draft-crocker-email-arch-11 (work in progress), 552 October 2008. 554 [MANAGESIEVE] 555 Melnikov, A. and T. Martin, "A Protocol for Remotely 556 Managing Sieve Scripts", draft-ietf-sieve-managesieve-01 557 (work in progress), November 2008. 559 Authors' Addresses 561 Eric W. Burger 562 This Space for Sale 563 New Hampshire 564 USA 566 Phone: 567 Fax: +1 530-267-7447 568 Email: eburger@standardstrack.com 569 URI: http://www.standardstrack.com 571 Glenn Parsons 572 Nortel Networks 573 3500 Carling Avenue 574 Ottawa, ON K2H 8E9 575 Canada 577 Phone: +1 613 763 7582 578 Email: gparsons@nortel.com 580 Full Copyright Statement 582 Copyright (C) The IETF Trust (2008). 584 This document is subject to the rights, licenses and restrictions 585 contained in BCP 78, and except as set forth therein, the authors 586 retain all their rights. 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 591 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 592 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 593 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Intellectual Property 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org.