idnits 2.17.1 draft-ietf-lemonade-profile-bis-10.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 1582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1606. 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 14, 2008) is 5755 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4551 (ref. 'IMAP-CONDSTORE') (Obsoleted by RFC 7162) == Outdated reference: A later version (-07) exists of draft-ietf-lemonade-imap-notify-06 ** Obsolete normative reference: RFC 5162 (ref. 'IMAP-QRESYNC') (Obsoleted by RFC 7162) == Outdated reference: A later version (-12) exists of draft-martin-managesieve-10 ** Obsolete normative reference: RFC 1652 (ref. 'SMTP-8BITMIME') (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 4409 (ref. 'SUBMIT') (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'ESMTP') (Obsoleted by RFC 5321) == Outdated reference: A later version (-08) exists of draft-melnikov-imapext-filters-05 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LEMONADE D. Cridland, Ed. 3 Internet-Draft A. Melnikov, Ed. 4 Intended status: Standards Track Isode Limited 5 Expires: January 15, 2009 S. Maes, Ed. 6 Oracle 7 July 14, 2008 9 The Lemonade Profile 10 draft-ietf-lemonade-profile-bis-10.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 15, 2009. 37 Abstract 39 This document describes a profile (a set of required extensions, 40 restrictions and usage modes) of the IMAP and mail submission 41 protocols. This profile allows clients (especially those that are 42 constrained in memory, bandwidth, processing power, or other areas) 43 to efficiently use IMAP and Submission to access and submit mail. 44 This includes the ability to forward received mail without needing to 45 download and upload the mail, to optimize submission and to 46 efficiently resynchronize in case of loss of connectivity with the 47 server. 49 The Lemonade profile relies upon several extensions to IMAP and Mail 50 Submission protocols. 52 Table of Contents 54 1. Conventions used in this document . . . . . . . . . . . . . . 4 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Summary of the required support . . . . . . . . . . . . . . . 5 57 3.1. Lemonade Submission Servers . . . . . . . . . . . . . . . 5 58 3.2. Lemonade Message Stores . . . . . . . . . . . . . . . . . 6 59 3.3. Lemonade Message Delivery Agents . . . . . . . . . . . . . 7 60 4. Lemonade Submission Servers . . . . . . . . . . . . . . . . . 8 61 4.1. Forward Without Download . . . . . . . . . . . . . . . . . 8 62 4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.3. DSN Support . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.4. Message size declaration . . . . . . . . . . . . . . . . . 8 65 4.5. Enhanced status code Support . . . . . . . . . . . . . . . 9 66 4.6. Encryption and Compression . . . . . . . . . . . . . . . . 9 67 5. Lemonade Message Stores . . . . . . . . . . . . . . . . . . . 10 68 5.1. Quick resynchronization . . . . . . . . . . . . . . . . . 10 69 5.2. Message part handling . . . . . . . . . . . . . . . . . . 10 70 5.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 11 71 5.4. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 72 5.4.1. IMAP Notifications . . . . . . . . . . . . . . . . . . 11 73 5.4.2. External Notifications . . . . . . . . . . . . . . . . 12 74 5.5. Searching and View Filters . . . . . . . . . . . . . . . . 12 75 5.6. Mailbox Handling . . . . . . . . . . . . . . . . . . . . . 13 76 5.7. Forward Without Download . . . . . . . . . . . . . . . . . 13 77 5.7.1. Support for PARTIAL in CATENATE and URLAUTH . . . . . 13 78 5.8. Additional IMAP extensions . . . . . . . . . . . . . . . . 13 79 5.9. Registration of $Forwarded IMAP keyword . . . . . . . . . 14 80 5.10. Registration of $PendingSubmission and $BeingSubmitted 81 IMAP keywords . . . . . . . . . . . . . . . . . . . . . . 14 82 5.11. Related IMAP extensions . . . . . . . . . . . . . . . . . 14 83 6. Lemonade Message Delivery Agents . . . . . . . . . . . . . . . 15 84 7. Lemonade Mail User Agents . . . . . . . . . . . . . . . . . . 15 85 8. Forward without download . . . . . . . . . . . . . . . . . . . 16 86 8.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 16 87 8.2. Message Sending Overview . . . . . . . . . . . . . . . . . 17 88 8.3. Traditional Strategy . . . . . . . . . . . . . . . . . . . 17 89 8.4. Step by step description . . . . . . . . . . . . . . . . . 18 90 8.4.1. Message assembly using IMAP CATENATE extension . . . . 19 91 8.4.2. Message assembly using SMTP CHUNKING and BURL 92 extensions . . . . . . . . . . . . . . . . . . . . . . 23 93 8.5. Security Considerations for pawn-tickets. . . . . . . . . 27 94 8.6. Copies of Sent messages: The fcc problem . . . . . . . . . 27 95 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 28 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 97 10.1. Confidentiality Protection of Submitted Messages . . . . . 28 98 10.2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 10.3. Additional extensions and deployment models . . . . . . . 29 100 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 101 12. Version history . . . . . . . . . . . . . . . . . . . . . . . 30 102 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 104 14.1. Normative References . . . . . . . . . . . . . . . . . . . 31 105 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 107 Intellectual Property and Copyright Statements . . . . . . . . . . 37 109 1. Conventions used in this document 111 In examples, "M:", "I:" and "S:" indicate lines sent by the client 112 messaging user agent, IMAP e-mail server and SMTP submit server 113 respectively. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [KEYWORDS]. 119 Other capitalised words are typically names of extensions or commands 120 - these are uppercased for clarity only, and are case-insensitive. 122 All examples in this document are optimized for Lemonade use and 123 might not represent examples of proper protocol usage for a general 124 use Submit/IMAP client. In particular examples assume that Submit 125 and IMAP servers support all Lemonade extensions described in this 126 document, so they do not demonstrate fallbacks in the absence of an 127 extension. 129 2. Introduction 131 The Lemonade Profile, or simply Lemonade, provides enhancements to 132 Internet email to support diverse service environments. Lemonade 133 Mail Servers provide both a Lemonade Submission Server and a Lemonade 134 Message Store, which are based on the existing [SUBMIT] and [IMAP] 135 protocols respectively. 137 This document describes the Lemonade profile that includes: 138 o General common enhancements to Internet Mail, described in 139 Section 5 and Section 4. 140 o "Forward without download" that describes exchanges between 141 Lemonade clients and servers to allow to submit new email messages 142 incorporating content which resides on locations external to the 143 client, described in Section 8. 144 o Quick mailbox resynchronization, described in Section 5.1. 145 o Extensions to support more precise, and broader, notifications 146 from the store in support of notifications and view filters, 147 described in Section 5.4.1 and Section 5.5. 149 It is intended that the Lemonade profile support realizations of the 150 OMA's mobile email enabler (MEM) (see [OMA-MEM-REQ] and 151 [OMA-MEM-ARCH]) using Internet Mail protocols defined by the IETF. 153 3. Summary of the required support 155 3.1. Lemonade Submission Servers 157 Lemonade Submission Servers MUST provide a service as described in 158 [SUBMIT], and MUST support the following. Note that the Lemonade 159 Profile imposes further requirements for some cases, detailed in the 160 sections cited. 162 +---------------------+--------------------+--------------+ 163 | SMTP extension | Reference | Requirements | 164 +---------------------+--------------------+--------------+ 165 | PIPELINING | [SMTP-PIPELINING] | Section 4.2 | 166 | DSN | [SMTP-DSN] | Section 4.3 | 167 | SIZE | [SMTP-SIZE] | Section 4.4 | 168 | ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 | 169 | STARTTLS | [SMTP-TLS] | Section 4.6 | 170 | BURL imap | [SMTP-BURL] | Section 8 | 171 | BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 | 172 | CHUNKING | [SMTP-BINARYMIME] | Section 4.1 | 173 | 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] | 174 | AUTH | [SMTP-AUTH] | [SUBMIT] | 175 +---------------------+--------------------+--------------+ 177 3.2. Lemonade Message Stores 179 Lemonade Message Stores MUST provide a service as described in 180 [IMAP], and MUST support the following. Note that the Lemonade 181 Profile imposes further requirements for some cases, detailed in the 182 sections cited. 184 +----------------------------+------------------+---------------+ 185 | IMAP extension | Reference | Requirements | 186 +----------------------------+------------------+---------------+ 187 | NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 | 188 | CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 | 189 | STARTTLS | [IMAP] | - | 190 | URLAUTH | [IMAP-URLAUTH] | Section 5.7 | 191 | CATENATE | [IMAP-CATENATE] | Section 5.7 | 192 | URL-PARTIAL | Section 5.7.1 | Section 5.7 | 193 | UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 | 194 | LITERAL+ | [IMAP-LITERAL+] | Section 5.8 | 195 | IDLE | [IMAP-IDLE] | Section 5.4.1 | 196 | NOTIFY | [IMAP-NOTIFY] | Section 5.4.1 | 197 | $Forwarded keyword | - | Section 5.9 | 198 | $PendingSubmission keyword | - | Section 5.10 | 199 | $BeingSubmitted keyword | - | Section 5.10 | 200 | BINARY | [IMAP-BINARY] | Section 5.2 | 201 | QRESYNC | [IMAP-QRESYNC] | Section 5.1 | 202 | ENABLE | [IMAP-ENABLE] | Section 5.1 | 203 | ESEARCH | [IMAP-ESEARCH] | Section 5.5 | 204 | CONTEXT=SEARCH | [IMAP-CONTEXT] | Section 5.5 | 205 | SORT | [IMAP-SORT] | Section 5.5 | 206 | ESORT | [IMAP-CONTEXT] | Section 5.5 | 207 | CONTEXT=SORT | [IMAP-CONTEXT] | Section 5.5 | 208 | CONVERT | [IMAP-CONVERT] | Section 5.2 | 209 | COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 | 210 | I18NLEVEL=1 | [IMAP-I18N] | Section 5.8 | 211 | SASL-IR | [IMAP-SASL-IR] | Section 5.8 | 212 +----------------------------+------------------+---------------+ 214 In addition to this list, any Lemonade Message Stores MUST send the 215 CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial 216 server greeting and after the LOGIN/AUTHENTICATE commands. 218 3.3. Lemonade Message Delivery Agents 220 Lemonade Message Delivery Agents MUST support Sieve mail filtering 221 language as described in [SIEVE], and MUST support the following 222 Sieve extensions. Lemonade Message Delivery Agents MUST also support 223 Sieve script management using the [MANAGE-SIEVE] protocol. Note that 224 the Lemonade Profile imposes further requirements for some cases, 225 detailed in the sections cited. 227 +------------------------------+--------------------+--------------+ 228 | Sieve extension | Reference | Requirements | 229 +------------------------------+--------------------+--------------+ 230 | VACATION | [SIEVE-VACATION] | Section 6 | 231 | ENOTIFY | [SIEVE-NOTIFY] | Section 6 | 232 | VARIABLES | [SIEVE-VARIABLES] | Section 6 | 233 | RELATIONAL | [SIEVE-RELATIONAL] | Section 6 | 234 | IMAP4FLAGS | [SIEVE-IMAP4FLAGS] | Section 6 | 235 | comparator-i;unicode-casemap | [UNICODE-CASEMAP] | Section 6 | 236 +------------------------------+--------------------+--------------+ 238 4. Lemonade Submission Servers 240 All Lemonade Submission Servers implement the Mail Submission 241 protocol described in [SUBMIT], which is in turn a specific profile 242 of [ESMTP]. Therefore any MUA designed to submit email via [SUBMIT] 243 or [ESMTP] will interoperate with Lemonade Submission Servers. 245 In addition, Lemonade Submission Servers implement the following set 246 of SMTP and Submission extensions to increase message submission 247 efficiency. 249 4.1. Forward Without Download 251 In order to optimize network usage for the typical case where message 252 content is copied to, or sourced from, the IMAP store, Lemonade 253 provides support for a suite of extensions collectively known as 254 Forward Without Download, discussed in detail in Section 8. 256 Lemonade Submission Servers MUST support the BURL [SMTP-BURL], 257 8BITMIME [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME] and CHUNKING 258 [SMTP-BINARYMIME]. 260 BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST 261 advertise the "imap" option following the BURL EHLO keyword (See 262 [SMTP-BURL] for more details). 264 4.2. Pipelining 266 Some clients regularly use networks with a relatively high latency, 267 such as Mobile or Satellite based networks. Avoidance of round-trips 268 within a transaction has a great advantage for the reduction in both 269 bandwidth and total transaction time. For this reason Lemonade 270 compliant mail submission servers MUST support the SMTP Service 271 Extensions for Command Pipelining [SMTP-PIPELINING]. 273 4.3. DSN Support 275 Lemonade compliant mail submission servers MUST support SMTP service 276 extensions for delivery status notifications [SMTP-DSN]. 278 4.4. Message size declaration 280 There is a distinct advantage in detecting failure cases as early as 281 possible in many cases, such as where the user is charged per-octet, 282 or where bandwidth is low. This is especially true of large message 283 sizes. 285 Lemonade Submission Servers MUST support the SMTP Service Extension 286 for Message Size Declaration [SMTP-SIZE]. 288 Lemonade Submission Servers MUST NOT consider a supplied message size 289 to be acceptable without expanding all BURL parts. 291 A Lemonade capable client SHOULD use message size declaration. In 292 particular the client MUST NOT send a message to a mail submission 293 server, if it knows that the message exceeds the maximal message size 294 advertised by the submission server. When including a message size 295 in the MAIL FROM command, the client MUST use a value that is at 296 least as large as the size of the assembled message data after 297 resolution of all BURL parts. 299 4.5. Enhanced status code Support 301 Lemonade compliant mail submission servers MUST support SMTP Service 302 Extension for Returning Enhanced Error Codes [SMTP-STATUSCODES]. 303 These allow a client to determine the precise cause of failure. 305 4.6. Encryption and Compression 307 Lemonade Compliant mail submission servers MUST support SMTP Service 308 Extension for Secure SMTP over TLS [SMTP-TLS]. 310 Support for the DEFLATE compression method, as described in 311 [TLS-COMP], is RECOMMENDED. 313 5. Lemonade Message Stores 315 All Lemonade Message Stores implement Internet Message Access 316 Protocol, as defined in [IMAP]. Therefore any MUA written to access 317 messages using the facilities described in [IMAP] will interoperate 318 with a Lemonade Message Store. 320 In addition, Lemonade Message Stores provide a set of extensions to 321 address the limitations of some clients and networks. 323 5.1. Quick resynchronization 325 Resynchronization is a costly part of an IMAP session, and mobile 326 networks are generally more prone to unintended disconnection, which 327 in turns makes this problem more acute. Therefore Lemonade Message 328 Stores provide a suite of extensions to reduce the synchronization 329 cost. 331 Lemonade Compliant IMAP servers MUST support the CONDSTORE 332 [IMAP-CONDSTORE], the QRESYNC [IMAP-QRESYNC] and the ENABLE 333 [IMAP-ENABLE] extensions. These allow a client to quickly 334 resynchronize any mailbox by asking the server to return all flag 335 changes and expunges that have occurred since a previously recorded 336 state. This can also speed up client reconnect in case the transport 337 layer is cut, whether accidentally or as part of a change in network. 339 [IMAP-SYNC-HOWTO] details how clients perform efficient mailbox 340 resynchronization. 342 5.2. Message part handling 344 The handling of message parts, especially attachments, represents a 345 set of challenges to limited devices, both in terms of the bandwidth 346 used, and the capability of the device. 348 Lemonade Compliant IMAP servers MUST support the BINARY [IMAP-BINARY] 349 extension. This moves MIME body part decoding operations from the 350 client to the server. The decoded data is always equal or less than 351 the encoded representation, so this reduces bandwidth effectively. 353 [IMAP-BINARY] allows for servers to refuse to accept uploaded 354 messages containing binary data, by not accepting the Binary content- 355 transfer-encoding; however Lemonade Compliant IMAP servers SHALL 356 always accept binary encoded MIME messages in APPEND commands for any 357 folder. 359 [IMAP-CONVERT] MUST also be supported by servers, which allows 360 clients to request conversions between media types, and allows for 361 scaling images, etc. This provides the ability to view attachments 362 (and sometimes body parts) without the facility to cope with a wide 363 range of media types, or to efficiently view attachments. 365 5.3. Compression 367 The IETF has for some time generally agreed that compression is best 368 handled at as low a level as possible, therefore Lemonade Message 369 Stores SHOULD support the Deflate compression algorithm for TLS, as 370 defined in [TLS-COMP]. 372 However, the working group acknowledges that for many endpoints, this 373 is a rarely deployed technology, and as such, Lemonade Message Stores 374 MUST provide [IMAP-COMPRESS] support for fallback application-level 375 stream compression, where TLS is not actively providing compression. 377 5.4. Notifications 379 The addition of Server-to-client notifications ransforms the LEMONADE 380 profile into an event-based synchronization protocol. Whenever an 381 event occurs that interests the MUA, a notification can be generated. 383 If the MUA is connected to the IMAP server, inband notifications are 384 generated using the facilities outlined in Section 5.4.1. 386 When the MUA is not connected, the Notification filter generates a 387 outband notification. The notification filter may be considered as 388 acting on a PUSH repository. 390 If the MUA is not connected, and outband notification is disabled, 391 the client must perform a quick-sync on reconnect to determine 392 mailbox changes, using the mechanisms outlined in Section 5.1. 394 5.4.1. IMAP Notifications 396 Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension. 397 The extension allows clients to receive unsolicited notifications 398 about changes in the selected mailbox, without needing to poll for 399 changes. The responses forming these notifications MUST be sent in a 400 timely manner when such changes happen. 402 Lemonade Message Stores also provide the NOTIFY extension described 403 in [IMAP-NOTIFY], which allows clients to request specific event 404 types to be sent immediately to the client, both for the currently 405 selected folder and others. Such event types include message 406 delivery, and mailbox renames. 408 5.4.2. External Notifications 410 Lemonade, and TCP, provide for long-lived idle connections between 411 the client and mail store, allowing the server to push notifications 412 within IMAP. Some mobile networks support dormancy, which shuts down 413 the radio traffic channel during idle periods to conserve handset and 414 network resources, while maintaining IP and TCP state. (See the 415 [LEMONADE-DEPLOYMENTS] document for more information.) 417 However, there are environments where the email client cannot remain 418 active indefinitely, or where it is not advisable (or even always 419 possible) for TCP connections to the server to remain up while idle 420 for extended periods. In these situations, a good user experience 421 requires that when "interesting" events occur in the mail store, the 422 client be informed so that it can connect and resynchronize. At an 423 absolute minimum, this requires that at least the arrival of new mail 424 generate some sort of wake-up to the email client. A number of 425 vendors have implemented various solutions to this. As examples of 426 what has been done, for many years (long pre-dating cellular 427 handsets) the technique described in [FINGER-HACK] has been 428 supported. Today, a number of email vendors include facilities to 429 send SMS or other simple non-stream messages to clients on handsets 430 when new mail arrives. OMA has published a mechanism that uses WAP 431 PUSH to send a basic message containing a URL [OMA-EMN]. The IETF is 432 investigating ways to standardize enhanced functionality in this 433 area. 435 A "push email" user experience can be achieved using any number of 436 techniques, ranging from always-on TCP connectivity to the server and 437 the NOTIFY extension described above, to OMA EMN, or even a non- 438 standard trigger message over SMS. In any technique, the client 439 learns of the existence of new mail, and decides to fetch information 440 about it, some part of it, or all of it, and then presents this to 441 the user. 443 5.5. Searching and View Filters 445 Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH] 446 extension. The extension allows clients to efficiently find the 447 first or last messages, find a count of matching messages, and obtain 448 a list of matching messages in a considerably more compact 449 representation. 451 Lemonade Message Stores also provide a mechanism for clients to avoid 452 handling an entire mailbox, instead accessing a view of the mailbox. 453 This technique, common in many desktop clients as a client-side 454 capability, is useful for constrained clients to minimize the 455 quantity of messages and notification data. 457 Lemonade Message Stores therefore MUST implement the CONTEXT=SEARCH, 458 ESORT and CONTEXT=SORT extensions defined in [IMAP-CONTEXT], as well 459 as the SORT extension defined in [IMAP-SORT]. 461 5.6. Mailbox Handling 463 Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE] 464 extension. The extension allows clients to discover shared mailboxes 465 and mailboxes belonging to other users, and provide a normalized 466 hierarchy view of the mailboxes available. 468 Lemonade Message Stores MUST support the I18NLEVEL= [IMAP-I18N] 469 extension, with having value 1 or 2. It adds support for non- 470 English (internationalized) search and sort functions. (Note that 471 I18NLEVEL=2 implies support for I18NLEVEL=1, so a Lemonade compliant 472 client that make use of this extension MUST recognize either one.) 474 5.7. Forward Without Download 476 In order to optimize network usage for the typical case where message 477 content is copied to, or sourced from, the IMAP store, Lemonade 478 provides support for a suite of extensions collectively known as 479 Forward Without Download, discussed in detail in Section 8. 481 Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE], 482 UIDPLUS [IMAP-UIDPLUS] and URLAUTH [IMAP-URLAUTH]. Lemonade Message 483 Stores MUST also support URL-PARTIAL Section 5.7.1. 485 5.7.1. Support for PARTIAL in CATENATE and URLAUTH 487 [IMAP-URL] introduced a new syntactic element for referencing a byte 488 range of a message/body part. This is done using the ;PARTIAL= 489 field. If an IMAP server supports PARTIAL in IMAP URL used in 490 CATENATE and URLAUTH extensions, then it MUST advertise the URL- 491 PARTIAL capability in the CAPABILITY response/response code. 493 5.8. Additional IMAP extensions 495 Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+] 496 extension. The extension allows clients to save a round trip each 497 time a non-synchronizing literal is sent. 499 Lemonade Message Stores MUST also implement the SASL-IR 500 [IMAP-SASL-IR] extension, which allows clients to save a round trip 501 during authentication, potentially pipelining the entire 502 authentication sequence. 504 Lemonade Compliant IMAP servers MUST support IMAP over TLS [IMAP] as 505 required by [IMAP]. As noted above in Section 5.3, servers SHOULD 506 support the deflate compression algorithm for TLS, as specified in 507 [TLS-COMP]. 509 5.9. Registration of $Forwarded IMAP keyword 511 The $Forwarded IMAP keyword is used by several IMAP clients to 512 specify that the marked message was forwarded to another email 513 address, embedded within or attached to a new message. A mail client 514 sets this keyword when it successfully forwards the message to 515 another email address. Typical usage of this keyword is to show a 516 different (or additional) icon for a message that has been forwarded. 517 Once set the flag SHOULD NOT be cleared. 519 Lemonade Message Stores MUST be able to store the $Forwarded keyword. 520 They MUST preserve it on the COPY operation. The servers MUST 521 support the SEARCH KEYWORD $Forwarded. 523 5.10. Registration of $PendingSubmission and $BeingSubmitted IMAP 524 keywords 526 The $PendingSubmission IMAP keyword designates the message as 527 awaiting to be submitted. This keyword allows to store messages 528 waiting to be submitted in the same mailbox where messages that were 529 already submitted and/or being edited are stored. A mail client sets 530 this keyword when it decides that the message needs to be sent out. 531 When a client (it might be a different client from the one that 532 decided that the message is pending submission) starts sending the 533 message, it atomically clears the $PendingSubmission keyword and sets 534 the $BeingSubmitted keyword. Once submission is successful, the 535 $BeingSubmitted keyword is cleared. The two keywords allow to 536 distinguish messages being actively submitted from messages awaiting 537 to be submitted. They also allow to find all messages that were 538 supposed to be submitted, if the client submitting them crashes or 539 quits before submitting them. 541 Lemonade Message Stores MUST be able to store the $PendingSubmission 542 and the $BeingSubmitted keyword. Lemonade Message Stores MUST 543 preserve them on the COPY operation. The servers MUST support the 544 SEARCH KEYWORD $PendingSubmission and SEARCH KEYWORD $BeingSubmitted. 546 5.11. Related IMAP extensions 548 This section is non-normative. 550 Server implementations targeting to fulfil OMA MEM requirements 551 [OMA-MEM-REQ] should consider implementing [IMAP-FILTERS], which 552 provides a way to persist definition of virtual mailboxes on the 553 server. 555 6. Lemonade Message Delivery Agents 557 Lemonade Message Delivery Agents MUST support the [SIEVE] filtering 558 language at the point of delivery, allowing the user to control which 559 messages are accepted, and where they are filed. 561 Lemonade Message Delivery Agents MUST support the Sieve Vacation 562 extension [SIEVE-VACATION], which allows the client to setup an auto- 563 responder, typically to report being on vacation (thus the name of 564 the Sieve extension). 566 Lemonade Message Delivery Agents MUST support the Sieve Enotify 567 extension [SIEVE-NOTIFY], which allows a Sieve script to generate 568 notifications (such as XMPP, SIP or email) about received messages. 570 Lemonade Message Delivery Agents MUST support the Sieve Variables 571 extension [SIEVE-VARIABLES], which adds support for variables to the 572 Sieve scripting language. This extension is typically used with 573 Sieve Enotify or Vacation to customize responses/notifications. 575 Lemonade Message Delivery Agents MUST support the Sieve Relational 576 extension [SIEVE-RELATIONAL], which adds support for relational 577 comparisons to the Sieve scripting language. This extension is 578 typically used together with Sieve Enotify. 580 Lemonade Message Delivery Agents MUST support the Sieve Imap4Flags 581 extension [SIEVE-IMAP4FLAGS], which allows a Sieve script to set IMAP 582 flags/keywords when delivering a message to a mailbox. For example 583 this can be used to automatically mark certain messages as 584 interesting, urgent, etc. 586 Lemonade Message Delivery Agents MUST support the i;unicode-casemap 587 comparator in Sieve [UNICODE-CASEMAP]. The comparator allows for 588 case-insensitive matching of Unicode characters. 590 Lemonade Message Delivery Agents MUST support Sieve script management 591 using the [MANAGE-SIEVE] protocol. They MUST also advertise in 592 [MANAGE-SIEVE] all Sieve extensions listed in this section. 594 7. Lemonade Mail User Agents 596 Although all existing IMAP MUAs are Lemonade compliant in as much as 597 all Lemonade services are based on the existing [IMAP] and [SUBMIT] 598 protocols, client implementors are encouraged to take full advantage 599 of the facilities provided by Lemonade Submission Servers and 600 Lemonade Message Stores, as described in Section 4 and Section 5 601 respectively. 603 Note that the explicit usage of [SUBMIT] means that when opening a 604 connection to the submission server, clients MUST do so using port 605 587 unless explicitly configured to use an alternate port. If the 606 TCP connection to the submission server fails to open using port 587, 607 the client MAY then immediately retry using a different port, such as 608 25. See [SUBMIT] information on why using port 25 is likely to fail 609 depending on the current location of the client, and may result in a 610 failure code during the SMTP transaction. 612 In addition, some specifications are useful to support interoperable 613 messaging with an enhanced user experience. 615 Lemonade capable clients SHOULD support the Format and DelSp 616 parameters to the text/plain media type described in [FLOWED], and 617 generate this format for messages. 619 Lemonade capable clients SHOULD support, and use, the $Forwarded 620 keyword described in Section 5.9. 622 8. Forward without download 624 8.1. Motivations 626 The advent of client/server email using the [IMAP] and [SUBMIT] 627 protocols changed what formerly were local disk operations to become 628 repetitive network data transmissions. 630 Lemonade "forward without download" makes use of the [SMTP-BURL] 631 extension to enable access to external sources during the submission 632 of a message. In combination with the [IMAP-URLAUTH] extension, 633 inclusion of message parts or even entire messages from the IMAP mail 634 store is possible with a minimal trust relationship between the IMAP 635 and SMTP SUBMIT servers. 637 Lemonade "forward without download" has the advantage of maintaining 638 one submission protocol, and thus avoids the risk of having multiple 639 parallel and possibly divergent mechanisms for submission. The 640 client can use [SUBMIT] extensions without these being added to IMAP. 641 Furthermore, by keeping the details of message submission in the SMTP 642 SUBMIT server, Lemonade "forward without download" can work with 643 other message retrieval protocols such as POP, NNTP, or whatever else 644 may be designed in the future. 646 8.2. Message Sending Overview 648 The act of sending an email message can be thought of as involving 649 multiple steps: initiation of a new draft, draft editing, message 650 assembly, and message submission. 652 Initiation of a new draft and draft editing takes place in the MUA. 653 Frequently, users choose to save more complex messages on an [IMAP] 654 server (via the APPEND command with the \Draft flag) for later recall 655 by the MUA and resumption of the editing process. 657 Message assembly is the process of producing a complete message from 658 the final revision of the draft and external sources. At assembly 659 time, external data is retrieved and inserted in the message. 661 Message submission is the process of inserting the assembled message 662 into the [ESMTP] infrastructure, typically using the [SUBMIT] 663 protocol. 665 8.3. Traditional Strategy 667 Traditionally, messages are initiated, edited, and assembled entirely 668 within an MUA, although drafts may be saved to an [IMAP] server and 669 later retrieved from the server. The completed text is then 670 transmitted to an MSA for delivery. 672 There is often no clear boundary between the editing and assembly 673 process. If a message is forwarded, its content is often retrieved 674 immediately and inserted into the message text. Similarly, when 675 external content is inserted or attached, the content is usually 676 retrieved immediately and made part of the draft. 678 As a consequence, each save of a draft and subsequent retrieve of the 679 draft transmits that entire (possibly large) content, as does message 680 submission. 682 In the past, this was not much of a problem, because drafts, external 683 data, and the message submission mechanism were typically located on 684 the same system as the MUA. The most common problem was running out 685 of disk quota. 687 8.4. Step by step description 689 The model distinguishes between a Messaging User Agent (MUA), an 690 IMAPv4Rev1 Server ([IMAP]) and a SMTP submit server ([SUBMIT]), as 691 illustrated in Figure 1. 693 +--------------------+ +--------------+ 694 | | <------------ | | 695 | MUA (M) | | IMAPv4Rev1 | 696 | | | Server | 697 | | ------------> | (Server I) | 698 +--------------------+ +--------------+ 699 ^ | ^ | 700 | | | | 701 | | | | 702 | | | | 703 | | | | 704 | | | | 705 | | | v 706 | | +--------------+ 707 | |----------------------> | SMTP | 708 | | Submit | 709 |-----------------------------| Server | 710 | (Server S) | 711 +--------------+ 713 Figure 1: Lemonade "forward without download" 715 Lemonade "forward without download" allows a Messaging User Agent to 716 compose and forward an e-mail combining fragments that are located in 717 an IMAP server, without having to download these fragments to the 718 client. 720 There are two ways to perform "forward without download" based on 721 where the message assembly takes place. The first uses extended 722 APPEND command [IMAP-CATENATE] to edit a draft message in the message 723 store and cause the message assembly on the IMAP server. This is 724 most often used when a copy of the message is to be retained on the 725 IMAP server, as discussed in Section 8.6. 727 The second uses a succession of BURL and BDAT commands to submit and 728 assemble through concatenation, message data from the client and 729 external data fetched from the provided URL. The two subsequent 730 sections provide step-by-step instructions on how "forward without 731 download" is achieved. 733 8.4.1. Message assembly using IMAP CATENATE extension 735 In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward 736 without download" strategy, messages are initially composed and 737 edited within an MUA. The [IMAP-CATENATE] extension to [IMAP] is 738 then used to create the messages on the IMAP server by transmitting 739 new text and assembling them. The UIDPLUS [IMAP-UIDPLUS] IMAP 740 extension is used by the client in order to learn the UID of the 741 created messages. Finally a [IMAP-URLAUTH] format URL is given to a 742 [SUBMIT] server for submission using the BURL [SMTP-BURL] extension. 744 The flow involved to support such a use case consists of: 746 M: {to I -- Optional} The client connects to the IMAP server, 747 optionally starts TLS (if data confidentiality is required), 748 authenticates, opens a mailbox ("INBOX" in the example below) and 749 fetches body structures (See [IMAP]). 751 Example: 753 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 754 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 755 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 756 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 757 "trip.txt") 758 "<960723163407.20117h@washington.example.com>" 759 "Your trip details" "BASE64" 4554 73) "MIXED")) 760 I: A0051 OK completed 762 M: {to I} The client invokes CATENATE (See [IMAP-CATENATE] for 763 details of the semantics and steps) -- this allows the MUA to create 764 messages on the IMAP server using new data combined with one or more 765 message parts already present on the IMAP server. 767 Note that the example for this step doesn't use the LITERAL+ 768 [IMAP-LITERAL+] extension. Without LITERAL+ the new message is 769 constructed using 3 round-trips. If LITERAL+ is used, the new 770 message can be constructed using one round-trip. 772 M: A0052 APPEND Sent FLAGS (\Draft \Seen $MDNSent) 773 CATENATE (TEXT {475} 774 I: + Ready for literal data 775 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 776 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 777 M: From: Bob Ar 778 M: MIME-Version: 1.0 779 M: To: foo@example.net 780 M: Subject: About our holiday trip 781 M: Content-Type: multipart/mixed; 782 M: boundary="------------030308070208000400050907" 783 M: 784 M: --------------030308070208000400050907 785 M: Content-Type: text/plain; format=flowed 786 M: 787 M: Our travel agent has sent the updated schedule. 788 M: 789 M: Cheers, 790 M: Bob 791 M: --------------030308070208000400050907 792 M: URL "/INBOX;UIDVALIDITY=385759045/; 793 UID=25627/;Section=2.MIME" URL "/INBOX; 794 UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44} 795 I: + Ready for literal data 796 M: 797 M: --------------030308070208000400050907-- 798 M: ) 799 I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed 801 M: {to I} The client uses GENURLAUTH command to request a URLAUTH URL 802 (See [IMAP-URLAUTH]). 803 I: {to M} The IMAP server returns a URLAUTH URL suitable for later 804 retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the 805 semantics and steps). 807 M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent; 808 UIDVALIDITY=387899045/;uid=45;expire=2005-10- 809 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 810 I: * GENURLAUTH "imap://bob.ar@example.org/Sent; 811 UIDVALIDITY=387899045/;uid=45;expire= 812 2005-10-28T23:59:59Z;urlauth=submit+bob.ar: 813 internal:91354a473744909de610943775f92038" 814 I: A0054 OK GENURLAUTH completed 816 M: {to S} The client connects to the mail submission server and 817 starts a new mail transaction. It uses BURL to let the SMTP submit 818 server fetch the content of the message from the IMAP server (See 819 [IMAP-URLAUTH] for details of the semantics and steps -- this allows 820 the MUA to authorize the SMTP submit server to access the message 821 composed as a result of the CATENATE step). Note that the second 822 EHLO command is required after a successful STARTTLS command. Also 823 note that there might be a third required EHLO command if the second 824 EHLO response doesn't list any BURL options. Section 8.4.2 825 demonstrates this. 827 S: 220 owlry.example.org ESMTP 828 M: EHLO potter.example.org 829 S: 250-owlry.example.com 830 S: 250-8BITMIME 831 S: 250-BINARYMIME 832 S: 250-PIPELINING 833 S: 250-BURL imap 834 S: 250-CHUNKING 835 S: 250-AUTH PLAIN 836 S: 250-DSN 837 S: 250-SIZE 10240000 838 S: 250-STARTTLS 839 S: 250 ENHANCEDSTATUSCODES 840 M: STARTTLS 841 S: 220 Ready to start TLS 842 ...TLS negotiation, subsequent data is encrypted... 843 M: EHLO potter.example.org 844 S: 250-owlry.example.com 845 S: 250-8BITMIME 846 S: 250-BINARYMIME 847 S: 250-PIPELINING 848 S: 250-BURL imap 849 S: 250-CHUNKING 850 S: 250-AUTH PLAIN 851 S: 250-DSN 852 S: 250-SIZE 10240000 853 S: 250 ENHANCEDSTATUSCODES 854 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 855 S: 235 2.7.0 PLAIN authentication successful. 856 M: MAIL FROM: 857 S: 250 2.5.0 Address Ok. 858 M: RCPT TO: 859 S: 250 2.1.5 foo@example.net OK. 860 M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/; 861 uid=45/;urlauth=submit+bar:internal: 862 91354a473744909de610943775f92038 LAST 864 S: {to I} The mail submission server uses URLFETCH to fetch the 865 message to be sent (See [IMAP-URLAUTH] for details of the semantics 866 and steps. The so-called "pawn-ticket" authorization mechanism uses 867 a URI which contains its own authorization credentials.). 869 I: {to S} Provides the message composed as a result of the CATENATE 870 step). 872 Mail submission server opens IMAP connection to the IMAP server: 874 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 875 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 876 IMAP server ready 877 S: a000 STARTTLS 878 I: a000 Start TLS negotiation now 879 ...TLS negotiation, if successful - subsequent data 880 is encrypted... 881 S: a001 LOGIN submitserver secret 882 I: a001 OK submitserver logged in 883 S: a002 URLFETCH "imap://bob.ar@example.org/Sent; 884 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 885 internal:91354a473744909de610943775f92038" 886 I: * URLFETCH "imap://bob.ar@example.org/Sent; 887 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 888 internal:91354a473744909de610943775f92038" {15065} 889 ...message body follows... 890 S: a002 OK URLFETCH completed 891 I: a003 LOGOUT 892 S: * BYE See you later 893 S: a003 OK Logout successful 895 Note that if the IMAP server doesn't send CAPABILITY response code in 896 the greeting, the mail submission server must issue the CAPABILITY 897 command to learn about supported IMAP extensions as described in 898 [IMAP]. 900 Also, if data confidentiality is not required the mail submission 901 server may omit the STARTTLS command before issuing the LOGIN 902 command. 904 S: {to M} Submission server assembles the complete message and if the 905 assembly succeeds it returns OK to the MUA: 907 S: 250 2.5.0 Ok. 909 M: {to I} The client marks the message containing the forwarded 910 attachment on the IMAP server. 912 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 913 I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) 914 I: A0053 OK STORE completed 916 Note: the UID STORE command shown above will only work if the marked 917 message is in the currently selected mailbox; otherwise, it requires 918 a SELECT. This command can be omitted, as it simply changes non- 919 operational metadata not essential to client operations or 920 interoperability. The untagged FETCH response is due to 921 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in 922 Section 5.9. 924 8.4.2. Message assembly using SMTP CHUNKING and BURL extensions 926 In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward 927 without download" strategy, messages are initially composed and 928 edited within an MUA. During submission [SUBMIT], BURL [SMTP-BURL] 929 and BDAT [SMTP-BINARYMIME] commands are used to create the messages 930 from multiple parts. New body parts are supplied using BDAT 931 commands, while existing body parts are referenced using 932 [IMAP-URLAUTH] format URLs in BURL commands. 934 The flow involved to support such a use case consists of: 935 M: {to I -- Optional} The client connects to the IMAP server, 936 optionally starts TLS (if data confidentiality is required), 937 authenticates, opens a mailbox ("INBOX" in the example below) and 938 fetches body structures (See [IMAP]). 940 Example: 942 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 943 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 944 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 945 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 946 "trip.txt") 947 "<960723163407.20117h@washington.example.com>" 948 "Your trip details" "BASE64" 4554 73) "MIXED")) 949 I: A0051 OK completed 951 M: {to I} The client uses GENURLAUTH command to request URLAUTH URLs 952 (See [IMAP-URLAUTH]) referencing pieces of the message to be 953 assembled. 954 I: {to M} The IMAP server returns URLAUTH URLs suitable for later 955 retrieval with URLFETCH (See [IMAP-URLAUTH] for details of the 956 semantics and steps). 958 M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX; 959 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 960 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" 961 INTERNAL "imap://bob.ar@example.org/INBOX; 962 UIDVALIDITY=385759045/;UID=25627/;Section=2; 963 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 964 I: * GENURLAUTH "imap://bob.ar@example.org/INBOX; 965 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 966 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 967 internal:A0DEAD473744909de610943775f9BEEF" 968 "imap://bob.ar@example.org/INBOX; 969 UIDVALIDITY=385759045/;UID=25627/;Section=2; 970 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 971 internal:BEEFA0DEAD473744909de610943775f9" 972 I: A0054 OK GENURLAUTH completed 974 M: {to S} The client connects to the mail submission server and 975 starts a new mail transaction. It uses BURL to instruct the SMTP 976 submit server to fetch from the IMAP server pieces of the message to 977 be sent (See [SMTP-BURL] for details of the semantics and steps). 979 Note that the second EHLO command is required after a successful 980 STARTTLS command. The third EHLO command is required if and only if 981 the second EHLO response doesn't list any BURL options. See 982 Section 8.4.1 for an example of submission where the third EHLO 983 command/response is not present. 985 S: 220 owlry.example.org ESMTP 986 M: EHLO potter.example.org 987 S: 250-owlry.example.com 988 S: 250-8BITMIME 989 S: 250-BINARYMIME 990 S: 250-PIPELINING 991 S: 250-BURL 992 S: 250-CHUNKING 993 S: 250-AUTH DIGEST-MD5 994 S: 250-DSN 995 S: 250-SIZE 10240000 996 S: 250-STARTTLS 997 S: 250 ENHANCEDSTATUSCODES 998 M: STARTTLS 999 S: 220 Ready to start TLS 1000 ...TLS negotiation, subsequent data is encrypted... 1001 M: EHLO potter.example.org 1002 S: 250-owlry.example.com 1003 S: 250-8BITMIME 1004 S: 250-BINARYMIME 1005 S: 250-PIPELINING 1006 S: 250-BURL 1007 S: 250-CHUNKING 1008 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 1009 S: 250-DSN 1010 S: 250-SIZE 10240000 1011 S: 250 ENHANCEDSTATUSCODES 1012 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 1013 S: 235 2.7.0 PLAIN authentication successful. 1014 M: EHLO potter.example.org 1015 S: 250-owlry.example.com 1016 S: 250-8BITMIME 1017 S: 250-BINARYMIME 1018 S: 250-PIPELINING 1019 S: 250-BURL imap imap://imap.example.org 1020 S: 250-CHUNKING 1021 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 1022 S: 250-DSN 1023 S: 250-SIZE 10240000 1024 S: 250 ENHANCEDSTATUSCODES 1025 M: MAIL FROM: BODY=BINARY 1026 S: 250 2.5.0 Address Ok. 1027 M: RCPT TO: 1028 S: 250 2.1.5 foo@example.net OK. 1029 M: BDAT 475 1030 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 1031 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 1032 M: From: Bob Ar 1033 M: MIME-Version: 1.0 1034 M: To: foo@example.net 1035 M: Subject: About our holiday trip 1036 M: Content-Type: multipart/mixed; 1037 M: boundary="------------030308070208000400050907" 1038 M: 1039 M: --------------030308070208000400050907 1040 M: Content-Type: text/plain; format=flowed 1041 M: 1042 M: Our travel agent has sent the updated schedule. 1043 M: 1044 M: Cheers, 1045 M: Bob 1046 M: --------------030308070208000400050907 1047 S: 250 2.5.0 OK 1048 M: BURL imap://bob.ar@example.org/INBOX; 1049 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 1050 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1051 internal:A0DEAD473744909de610943775f9BEEF 1052 S: 250 2.5.0 OK 1053 M: BURL imap://bob.ar@example.org/INBOX; 1054 UIDVALIDITY=385759045/;UID=25627/;Section=2; 1055 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1056 internal:BEEFA0DEAD473744909de610943775f9 1057 S: 250 2.5.0 OK 1058 M: BDAT 44 LAST 1059 M: 1060 M: --------------030308070208000400050907-- 1062 S: {to I} The mail submission server uses URLFETCH to fetch the 1063 pieces of the message to be sent (See [SMTP-BURL] for details of the 1064 semantics and steps. The so-called "pawn-ticket" authorization 1065 mechanism uses a URI which contains its own authorization 1066 credentials.). 1067 I: {to S} Returns the requested body parts. 1069 Mail submission server opens IMAP connection to the IMAP server: 1071 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 1072 CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com 1073 IMAP server ready 1074 S: a001 LOGIN submitserver secret 1075 I: a001 OK submitserver logged in 1076 S: a002 URLFETCH "imap://bob.ar@example.org/INBOX; 1077 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 1078 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1079 internal:A0DEAD473744909de610943775f9BEEF" "imap:// 1080 bob.ar@example.org/INBOX; 1081 UIDVALIDITY=385759045/;UID=25627/;Section=2; 1082 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1083 internal:BEEFA0DEAD473744909de610943775f9" 1084 I: * URLFETCH "imap://bob.ar@example.org/INBOX; 1085 UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME; 1086 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1087 internal:A0DEAD473744909de610943775f9BEEF" {84} 1088 ...message section follows... 1089 "imap://bob.ar@example.org/INBOX; 1090 UIDVALIDITY=385759045/;UID=25627/;Section=2; 1091 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 1092 internal:BEEFA0DEAD473744909de610943775f9" {15065} 1093 ...message section follows... 1094 S: a002 OK URLFETCH completed 1095 I: a003 LOGOUT 1096 S: * BYE See you later 1097 S: a003 OK Logout successful 1099 Note that if the IMAP server doesn't send CAPABILITY response code in 1100 the greeting, the mail submission server must issue the CAPABILITY 1101 command to learn about supported IMAP extensions as described in 1103 [IMAP]. 1105 Also, if data confidentiality is required the mail submission server 1106 should start TLS before issuing the LOGIN command. 1108 S: {to M} Submission server assembles the complete message and if the 1109 assembly succeeds it acknowledges acceptance of the message by 1110 sending 250 response to the last BDAT command: 1112 S: 250 2.5.0 Ok, message accepted. 1114 M: {to I} The client marks the message containing the forwarded 1115 attachment on the IMAP server. 1117 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 1118 I: * 215 FETCH (UID 25627 MODSEQ (12121231000)) 1119 I: A0053 OK STORE completed 1121 Note: the UID STORE command shown above will only work if the marked 1122 message is in the currently selected mailbox; otherwise, it requires 1123 a SELECT. As in the previous example, this command is not critical, 1124 and can be omitted. The untagged FETCH response is due to 1125 [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in 1126 Section 5.9. 1128 8.5. Security Considerations for pawn-tickets. 1130 The so-called "pawn-ticket" authorization mechanism uses a URI, which 1131 contains its own authorization credentials using [IMAP-URLAUTH]. The 1132 advantage of this mechanism is that the SMTP submit [SUBMIT] server 1133 cannot access any data on the [IMAP-URLAUTH] server without a "pawn- 1134 ticket" created by the client. 1136 The "pawn-ticket" grants access only to the specific data that the 1137 SMTP submit [SUBMIT] server is authorized to access, can be revoked 1138 by the client, and can have a time-limited validity. 1140 8.6. Copies of Sent messages: The fcc problem 1142 The "fcc problem" refers to delivering a copy of a message to a 1143 mailbox, or "file carbon copy". By far, the most common case of fcc 1144 is a client leaving a copy of outgoing mail in a "Sent Mail" or 1145 "Outbox" mailbox. 1147 In the traditional strategy, the MUA duplicates the effort spent in 1148 transmitting to the MSA by writing the message to the fcc destination 1149 in a separate step. This may be a write to a local disk file or an 1150 APPEND to a mailbox on an IMAP server. The latter is one of the 1151 "repetitive network data transmissions" which represents the 1152 "problem" aspect of the "fcc problem". 1154 The BURL [SMTP-BURL] extension can be used to eliminate the 1155 additional transmission. The final message is uploaded to the 1156 mailbox designed for outgoing mail, by the APPEND command of [IMAP]. 1157 Note that APPEND, including when enhanced by [IMAP-CATENATE], can 1158 only create a single copy of the message and this is only of use on 1159 the server which stages the outgoing message for submission. 1160 Additional copies of the message on the same server can be created by 1161 using one or more COPY commands. 1163 9. Deployment Considerations 1165 Deployment considerations are discussed extensively in 1166 [LEMONADE-DEPLOYMENTS]. 1168 10. Security Considerations 1170 Implementors are advised to examine the Security Considerations of 1171 all the referenced documents. This section merely highlights these, 1172 and advises implementors on specific issues relating to the 1173 combination of extensions. 1175 Security considerations on Lemonade "forward without download" are 1176 discussed throughout Section 8. Additional security considerations 1177 can be found in [IMAP] and other documents describing other SMTP and 1178 IMAP extensions comprising the Lemonade Profile. 1180 Note that the mandatory-to-implement authentication mechanism for 1181 SMTP submission is described in [SMTP-AUTH]. The mandatory-to- 1182 implement authentication mechanism for IMAP is described in [IMAP]. 1184 10.1. Confidentiality Protection of Submitted Messages 1186 When clients submit new messages, link protection such as TLS guards 1187 against an eavesdropper seeing the contents of the submitted message. 1188 It is worth noting, however, that even if TLS is not used, the 1189 security risks are no worse if BURL is used to reference the text 1190 than if the text is submitted directly. If BURL is not used, an 1191 eavesdropper gains access to the full text of the message. If BURL 1192 is used, the eavesdropper may or may not be able to gain such access, 1193 depending on the form of BURL used. For example, some forms restrict 1194 use of the URL to an entity authorized as a submission server or a 1195 specific user. 1197 10.2. TLS 1199 When Lemonade clients use the BURL extension to mail submission, an 1200 extension that requires sending a URLAUTH token to the mail 1201 submission server, such a token should be protected from interception 1202 to avoid a replay attack that may disclose the contents of the 1203 message to an attacker. TLS based encryption of the mail submission 1204 path will provide protection against this attack. 1206 Lemonade clients SHOULD use TLS-protected IMAP and mail submission 1207 channels when using BURL-based message submission to protect the 1208 URLAUTH token from interception. 1210 Lemonade compliant mail submission servers SHOULD use TLS-protected 1211 IMAP connections when fetching message content using the URLAUTH 1212 token provided by the Lemonade client. 1214 When a client uses SMTP STARTTLS to send a BURL command which 1215 references non-public information, there is a user expectation that 1216 the entire message content will be treated confidentially. To meet 1217 this expectation, the message submission server should use STARTTLS 1218 or a mechanism providing equivalent data confidentiality when 1219 fetching the content referenced by that URL. 1221 10.3. Additional extensions and deployment models 1223 This specification provides no additional security measures beyond 1224 those in the referenced Internet Mail and Lemonade documents. 1226 We note however the security risks associated to: 1227 o Outband notifications 1228 o Server configuration by client 1229 o Client configuration by server 1230 o Presence of proxy servers 1231 o Presence of servers as intermediaries 1232 o In general the deployment models considered by OMA MEM that are 1233 not conventional IETF deployment models. 1234 o Measures to address a perceived need to traverse firewalls and 1235 mobile network intermediaries. 1237 11. IANA considerations 1239 IMAP4 capabilities are registered by publishing a standards track or 1240 IESG approved experimental RFC. The registry is currently located at 1241 . This document 1242 defines the URL-PARTIAL IMAP capability Section 5.7.1. IANA is 1243 requested to add this extension to the IANA IMAP Capability registry. 1245 12. Version history 1247 o Version 10: 1248 * Added ManageSieve. 1249 * Added a requirement to support i;unicode-casemap in Sieve 1250 (already required in IMAP). 1251 * Added description of various Sieve extensions. 1252 * Added definition of URL-PARTIAL IMAP extension. 1253 * Added definition of $PendingSubmission and $BeingSubmitted IMAP 1254 keywords. 1255 o Version 9: 1256 * Updated references and removed extensions that there was an 1257 agreement to remove. 1258 o Version 08: 1259 * Removed LIST-EXTENDED, WITHIN and QUICKSTART. 1260 * Updated names of required extensions when they were renamed 1261 (e.g. COMPARATOR ==> I18NLEVEL=1). 1262 o Version 06: 1263 * Updated references and added extensions agreed at the Lemonade 1264 interim in Spring 2007. 1265 * Require any Lemonade compliant IMAP server to support 1266 CAPABILITY response code. 1267 o Version 04: 1268 * Major reorganization of text. 1269 * Move checklist summary to beginning of document, collate 1270 Submission and Store server requirements. 1271 o Version 03: 1272 * Replaced RECONNECT (server side quick reconned) with QRESYNC 1273 (client side quick reconnect) 1274 * Added WITHIN and LIST-EXTENDED. 1275 * Moved IDLE extension to a separate section. 1276 * Added requirement for clients to use Format=flowed. 1277 o Version 02: 1278 * Update of references and how they are displayed in the text 1279 (Comments from Randy Gellens) 1280 * Update of list of extensions to support as MUST by the Lemonade 1281 Profile Bis 1282 * Update of options for compression via placeholder imap- 1283 compression section describing compression requirements 1284 * Update of support of TCP chalenged environments 1285 * Update of support of object level encryption 1286 * Clarified the use of $Forwarded in the examples, and 1287 demonstrated how to remove the \Draft flag from the sent 1288 message 1289 * Clarified $Forwarded 1290 * Added RECONNECT to imap-condstore section 1291 * Add new section imap-bodypart, "Message part handling", 1292 describing BINARY and CONVERT requirements 1293 * Added placeholder section for notifications 1294 * Added various extensions to imap-other section, and added 1295 clarifying comments to IDLE, NAMESPACE, and a further 1296 references to TLS DEFLATE compression 1297 * Added extension names to IMAP table 1298 * Fixed all issues found with original Lemonade profile so far. 1299 o Version 01: 1300 * Lemonade profile has been introduced in-line, with some updates 1301 / corrections. 1302 * Subsequent re-organization of the text 1303 * Details of extensions proper to Lemonade Profile-bis have been 1304 updated to refer to the drafts newly accepted as WG IETF 1305 drafts. 1306 * Addition of appendix on attachements streaming. 1307 o Version 00: 1308 * It evolved from a combination of the content of Lemonade 1309 profile and the OMA MEM realization internet draft. 1311 13. Acknowledgements 1313 The editors acknowledge and appreciate the work and comments of the 1314 IETF Lemonade working group and the OMA MEM working group. 1316 In particular, the editors would like to thank Eric Burger, Randall 1317 Gellens, Filip Navara, Zoltan Ordogh, Greg Vaudreuil, and Fan Xiaohui 1318 for their comments and reviews. 1320 14. References 1322 14.1. Normative References 1324 [FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters", 1325 RFC 3676, February 2004. 1327 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1328 4rev1", RFC 3501, March 2003. 1330 [IMAP-BINARY] 1331 Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 1332 April 2003. 1334 [IMAP-CATENATE] 1335 Resnick, P., "Internet Message Access Protocol (IMAP) 1336 CATENATE Extension", RFC 4469, April 2006. 1338 [IMAP-COMPRESS] 1339 Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, 1340 August 2007. 1342 [IMAP-CONDSTORE] 1343 Melnikov, A. and S. Hole, "IMAP Extension for Conditional 1344 STORE Operation or Quick Flag Changes Resynchronization", 1345 RFC 4551, June 2006. 1347 [IMAP-CONTEXT] 1348 Cridland, D. and C. King, "Contexts for IMAP4", 1349 draft-cridland-imap-context-05 (work in progress), 1350 April 2008. 1352 [IMAP-CONVERT] 1353 Melnikov, A. and P. Coates, "IMAP CONVERT extension", 1354 draft-ietf-lemonade-convert-20 (work in progress), 1355 May 2008. 1357 [IMAP-ENABLE] 1358 Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 1359 Extension", RFC 5161, March 2008. 1361 [IMAP-ESEARCH] 1362 Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH 1363 Command for Controlling What Kind of Information Is 1364 Returned", RFC 4731, November 2006. 1366 [IMAP-I18N] 1367 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 1368 Message Access Protocol Internationalization", RFC 5255, 1369 June 2008. 1371 [IMAP-IDLE] 1372 Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 1374 [IMAP-LITERAL+] 1375 Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 1376 January 1997. 1378 [IMAP-NAMESPACE] 1379 Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 1380 May 1998. 1382 [IMAP-NOTIFY] 1383 King, C., "The IMAP NOTIFY Extension", 1384 draft-ietf-lemonade-imap-notify-06 (work in progress), 1385 June 2008. 1387 [IMAP-QRESYNC] 1388 Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 1389 Extensions for Quick Mailbox Resynchronization", RFC 5162, 1390 March 2008. 1392 [IMAP-SASL-IR] 1393 Siemborski, R. and A. Gulbrandsen, "IMAP Extension for 1394 Simple Authentication and Security Layer (SASL) Initial 1395 Client Response", RFC 4959, September 2007. 1397 [IMAP-SORT] 1398 Crispin, M. and K. Murchison, "Internet Message Access 1399 Protocol - SORT and THREAD Extensions", RFC 5256, 1400 June 2008. 1402 [IMAP-UIDPLUS] 1403 Crispin, M., "Internet Message Access Protocol (IMAP) - 1404 UIDPLUS extension", RFC 4315, December 2005. 1406 [IMAP-URL] 1407 Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, 1408 November 2007. 1410 [IMAP-URLAUTH] 1411 Crispin, M., "Internet Message Access Protocol (IMAP) - 1412 URLAUTH Extension", RFC 4467, May 2006. 1414 [KEYWORDS] 1415 Bradner, S., "Key words for use in RFCs to Indicate 1416 Requirement Levels", BCP 14, RFC 2119, March 1997. 1418 [MANAGE-SIEVE] 1419 Melnikov, A. and T. Martin, "A Protocol for Remotely 1420 Managing Sieve Scripts", draft-martin-managesieve-10 (work 1421 in progress), June 2008. 1423 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 1424 Language", RFC 5228, January 2008. 1426 [SIEVE-IMAP4FLAGS] 1427 Melnikov, A., "Sieve Email Filtering: Imap4flags 1428 Extension", RFC 5232, January 2008. 1430 [SIEVE-NOTIFY] 1431 Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 1432 "SIEVE Email Filtering: Extension for Notifications", 1433 draft-ietf-sieve-notify-12 (work in progress), 1434 December 2007. 1436 [SIEVE-RELATIONAL] 1437 Segmuller, W. and B. Leiba, "Sieve Email Filtering: 1438 Relational Extension", RFC 5231, January 2008. 1440 [SIEVE-VACATION] 1441 Showalter, T. and N. Freed, "Sieve Email Filtering: 1442 Vacation Extension", RFC 5230, January 2008. 1444 [SIEVE-VARIABLES] 1445 Homme, K., "Sieve Email Filtering: Variables Extension", 1446 RFC 5229, January 2008. 1448 [SMTP-8BITMIME] 1449 Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 1450 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 1451 RFC 1652, July 1994. 1453 [SMTP-AUTH] 1454 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1455 for Authentication", RFC 4954, July 2007. 1457 [SMTP-BINARYMIME] 1458 Vaudreuil, G., "SMTP Service Extensions for Transmission 1459 of Large and Binary MIME Messages", RFC 3030, 1460 December 2000. 1462 [SMTP-BURL] 1463 Newman, C., "Message Submission BURL Extension", RFC 4468, 1464 May 2006. 1466 [SMTP-DSN] 1467 Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1468 Extension for Delivery Status Notifications (DSNs)", 1469 RFC 3461, January 2003. 1471 [SMTP-PIPELINING] 1472 Freed, N., "SMTP Service Extension for Command 1473 Pipelining", STD 60, RFC 2920, September 2000. 1475 [SMTP-SIZE] 1476 Klensin, J., Freed, N., and K. Moore, "SMTP Service 1477 Extension for Message Size Declaration", STD 10, RFC 1870, 1478 November 1995. 1480 [SMTP-STATUSCODES] 1481 Freed, N., "SMTP Service Extension for Returning Enhanced 1482 Error Codes", RFC 2034, October 1996. 1484 [SMTP-TLS] 1485 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1486 Transport Layer Security", RFC 3207, February 2002. 1488 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 1489 RFC 4409, April 2006. 1491 [TLS-COMP] 1492 Hollenbeck, S., "Transport Layer Security Protocol 1493 Compression Methods", RFC 3749, May 2004. 1495 [UNICODE-CASEMAP] 1496 Crispin, M., "i;unicode-casemap - Simple Unicode Collation 1497 Algorithm", RFC 5051, October 2007. 1499 14.2. Informative References 1501 [ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1502 April 2001. 1504 [FINGER-HACK] 1505 Gellens, R., "Simple New Mail Notification", RFC 4146, 1506 August 2005. 1508 [IMAP-FILTERS] 1509 Melnikov, A. and C. King, "IMAP4 extension for named 1510 searches (filters)", draft-melnikov-imapext-filters-05 1511 (work in progress), July 2008. 1513 [IMAP-SYNC-HOWTO] 1514 Melnikov, A., "Synchronization Operations for Disconnected 1515 IMAP4 Clients", RFC 4549, June 2006. 1517 [LEMONADE-DEPLOYMENTS] 1518 Gellens, R., "Deployment Considerations for lemonade- 1519 compliant Mobile Email", 1520 draft-ietf-lemonade-deployments-09 (work in progress), 1521 June 2007. 1523 [OMA-EMN] Open Mobile Alliance, "Open Mobile Alliance Email 1524 Notification Version 1.0", OMA http:// 1525 www.openmobilealliance.org/tech/docs/EmailNot/ 1526 OMA-Push-EMN-V1_0-20020830-C.pdf, August 2002. 1528 [OMA-MEM-ARCH] 1529 Open Mobile Alliance, "Mobile Email Architecture 1530 Document", OMA (Work in Progress), 1531 http://www.openmobilealliance.org/, October 2005. 1533 [OMA-MEM-REQ] 1534 Open Mobile Alliance, "Mobile Email Requirements 1535 Document", OMA http://www.openmobilealliance.org/ 1536 release_program/docs/RD/ 1537 OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005. 1539 Authors' Addresses 1541 Dave Cridland (editor) 1542 Isode Limited 1543 5 Castle Business Village 1544 36 Station Road 1545 Hampton, Middlesex TW12 2BX 1546 UK 1548 Email: dave.cridland@isode.com 1550 Alexey Melnikov (editor) 1551 Isode Limited 1552 5 Castle Business Village 1553 36 Station Road 1554 Hampton, Middlesex TW12 2BX 1555 UK 1557 Email: Alexey.Melnikov@isode.com 1559 Stephane H. Maes (editor) 1560 Oracle 1561 MS 4op634, 500 Oracle Parkway 1562 Redwood Shores, CA 94539 1563 USA 1565 Phone: +1-203-300-7786 1566 Email: stephane.maes@oracle.com 1568 Full Copyright Statement 1570 Copyright (C) The IETF Trust (2008). 1572 This document is subject to the rights, licenses and restrictions 1573 contained in BCP 78, and except as set forth therein, the authors 1574 retain all their rights. 1576 This document and the information contained herein are provided on an 1577 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1578 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1579 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1580 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1581 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1582 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1584 Intellectual Property 1586 The IETF takes no position regarding the validity or scope of any 1587 Intellectual Property Rights or other rights that might be claimed to 1588 pertain to the implementation or use of the technology described in 1589 this document or the extent to which any license under such rights 1590 might or might not be available; nor does it represent that it has 1591 made any independent effort to identify any such rights. Information 1592 on the procedures with respect to rights in RFC documents can be 1593 found in BCP 78 and BCP 79. 1595 Copies of IPR disclosures made to the IETF Secretariat and any 1596 assurances of licenses to be made available, or the result of an 1597 attempt made to obtain a general license or permission for the use of 1598 such proprietary rights by implementers or users of this 1599 specification can be obtained from the IETF on-line IPR repository at 1600 http://www.ietf.org/ipr. 1602 The IETF invites any interested party to bring to its attention any 1603 copyrights, patents or patent applications, or other proprietary 1604 rights that may cover technology that may be required to implement 1605 this standard. Please address the information to the IETF at 1606 ietf-ipr@ietf.org.