idnits 2.17.1 draft-ietf-lemonade-profile-07.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 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1056. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1063. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1069. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1150 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([SUBMIT], [RFC3501]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (January 2006) is 6675 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) == Missing Reference: 'RFC2476' is mentioned on line 419, but not defined ** Obsolete undefined reference: RFC 2476 (Obsoleted by RFC 4409) == Missing Reference: 'CHINKING' is mentioned on line 419, but not defined == Missing Reference: 'REF2197' is mentioned on line 686, but not defined == Unused Reference: 'RFC2197' is defined on line 888, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1015, but no explicit reference was found in the text -- No information found for draft-ietf-lemonade-burl-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BURL' ** Obsolete normative reference: RFC 1652 (ref. '8BITMIME') (Obsoleted by RFC 6152) -- No information found for draft-ietf-lemonade-catenate-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CATENATE' -- No information found for draft-crispin-imap-rfc2359bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UIDPLUS' ** Obsolete normative reference: RFC 2197 (Obsoleted by RFC 2920) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- No information found for draft-ietf-lemonade-urlauth-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'URLAUTH' ** Obsolete normative reference: RFC 2554 (ref. 'SMTPAUTH') (Obsoleted by RFC 4954) -- Possible downref: Non-RFC (?) normative reference: ref. 'CONDSTORE' -- No information found for draft-melnikov-imap-disc-XX - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: Lemonade Profile S. H. Maes 2 Document: draft-ietf-lemonade-profile-07.txt A. Melnikov 3 Expires: July 2006 January 2006 5 Lemonade Profile 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes a profile (a set of required extensions, 33 restrictions and usage modes) of the IMAP and mail submission 34 protocols. This profile allows clients (especially those that are 35 constrained in memory, bandwidth, processing power, or other areas) 36 to efficiently use IMAP and Submission to access and submit mail. 37 This includes the ability to forward received mail without needing to 38 download and upload the mail, to optimize submission and to 39 efficiently resynchronize in case of loss of connectivity with the 40 server. 42 The Lemonade profile relies upon extensions to IMAP and Mail 43 Submission protocols; specifically URLAUTH and CATENATE IMAP protocol 44 [RFC3501] extensions and BURL extension to the SUBMIT protocol 45 [SUBMIT]. 47 Conventions used in this document 49 In examples, "M:", "I:" and "S:" indicate lines sent by the client 50 messaging user agent, IMAP e-mail server and SMTP submit server 51 respectively. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 All examples in this document are optimized for Lemonade use and 58 might not represent examples of proper protocol usage for a general 59 use Submit/IMAP client. In particular examples assume that Lemonade 60 Submit and IMAP servers support all Lemonade extensions described in 61 this document, so they don't show how to deal with absence of an 62 extension. 64 Table of Contents 66 Status of this Memo 1 67 Abstract 1 68 Conventions used in this document 2 69 Table of Contents 2 70 1. Introduction 3 71 2. Forward without download 4 72 2.1. Motivations 4 73 2.2. Message Sending Overview 4 74 2.3. Traditional Strategy 5 75 2.4. Step by step description 6 76 2.4.1. Message assembly using IMAP CATENATE extension 7 77 2.4.2. Message assembly using SMTP CHUNKING and BURL extensions 78 10 79 2.5. Normative statements related to forward without download 14 80 2.6. Security Considerations for pawn-tickets. 14 81 2.7. The fcc problem 14 82 2.8. Registration of $Forwarded IMAP keyword 15 83 3. Message Submission 15 84 3.1. Pipelining 15 85 3.2. DSN Support 16 86 3.3. Message size declaration 16 87 3.4. Enhanced status code Support 16 88 3.5. TLS 16 89 4. Quick resynchronization 16 90 5. Additional IMAP extensions 16 91 6. Summary of the required IMAP and SMTP extensions 17 92 7. Future work 18 93 8. Security Considerations 18 94 8.1. Confidentiality Protection of Submitted Messages 18 95 8.2. TLS 19 96 9. IANA Considerations 19 97 10. References 19 98 10.1. Normative References 19 99 10.2. Informative References 21 100 Open issues 21 101 Version History 21 102 Acknowledgments 22 103 Authors Addresses 23 104 Intellectual Property Statement 23 106 1. Introduction 108 Lemonade provides enhancements to Internet email to support diverse 109 service environments. 111 This document describes the lemonade profile that includes: 112 - "Forward without download" that describes exchanges between 113 Lemonade clients and servers to allow to submit new email 114 messages incorporating content which resides on locations 115 external to the client. 116 - Quick mailbox resynchronization using [CONDSTORE]. 117 - Several IMAP and SMTP extensions that allow saving bandwidth 118 and/or number of round trips required to send/receive data. 120 The organization of this document is as follows. Section 2 describes 121 the Forward without download. Section 3 describes additional SMTP 122 extensions that must be supported by all Lemonade Submission servers. 123 Section 4 describes IMAP quick resynchronization. 125 2. Forward without download 127 2.1. Motivations 129 The advent of client/server email using the [RFC3501], [RFC2821] and 130 [SUBMIT] protocols has changed what formerly were local disk 131 operations to become repetitive network data transmissions. 133 Lemonade "forward without download" makes use of the [BURL] SUBMIT 134 extension to enable access to external sources during the submission 135 of a message. In combination with the IMAP [URLAUTH] extension, 136 inclusion of message parts or even entire messages from the IMAP mail 137 store is possible with a minimal trust relationship between the IMAP 138 and SMTP SUBMIT servers. 140 Lemonade "forward without download" has the advantage of maintaining 141 one submission protocol, and thus avoids the risk of having multiple 142 parallel and possibly divergent mechanisms for submission. The client 143 can use Submit/SMTP [SUBMIT] extensions without these being added to 144 IMAP. Furthermore, by keeping the details of message submission in 145 the SMTP SUBMIT server, Lemonade "forward without download" can work 146 with other message retrieval protocols such as POP, NNTP, or whatever 147 else may be designed in the future. 149 2.2. Message Sending Overview 151 The act of sending an email message can be thought of as involving 152 multiple steps: initiation of a new draft, draft editing, message 153 assembly, and message submission. 155 Initiation of a new draft and draft editing takes place in the MUA. 156 Frequently, users choose to save more complex messages on an 157 [RFC3501] server (via the APPEND command with the \Draft flag) for 158 later recall by the MUA and resumption of the editing process. 160 Message assembly is the process of producing a complete message from 161 the final revision of the draft and external sources. At assembly 162 time, external data is retrieved and inserted in the message. 164 Message submission is the process of inserting the assembled message 165 into the [RFC2821] infrastructure, typically using the [SUBMIT] 166 protocol. 168 2.3. Traditional Strategy 170 Traditionally, messages are initiated, edited, and assembled entirely 171 within an MUA, although drafts may be saved to an [RFC3501] server 172 and later retrieved from the server. The completed text is then 173 transmitted to an MSA for delivery. 175 There is often no clear boundary between the editing and assembly 176 process. If a message is forwarded, its content is often retrieved 177 immediately and inserted into the message text. Similarly, when 178 external content is inserted or attached, the content is usually 179 retrieved immediately and made part of the draft. 181 As a consequence, each save of a draft and subsequent retrieve of the 182 draft transmits that entire (possibly large) content, as does message 183 submission. 185 In the past, this was not much of a problem, because drafts, external 186 data, and the message submission mechanism were typically located on 187 the same system as the MUA. The most common problem was running out 188 of disk quota. 190 2.4. Step by step description 192 The model distinguishes between a Messaging User Agent (MUA), an 193 IMAPv4Rev1 Server ([RFC3501]) and a SMTP submit server ([SUBMIT]), as 194 illustrated in Figure 1. 196 +--------------------+ +--------------+ 197 | | <------------ | | 198 | MUA (M) | | IMAPv4Rev1 | 199 | | | Server | 200 | | ------------> | (Server I) | 201 +--------------------+ +--------------+ 202 ^ | ^ | 203 | | | | 204 | | | | 205 | | | | 206 | | | | 207 | | | | 208 | | | v 209 | | +--------------+ 210 | |----------------------> | SMTP | 211 | | Submit | 212 |-----------------------------| Server | 213 | (Server S) | 214 +--------------+ 215 Figure 1: Lemonade "forward without download" 217 Lemonade "forward without download" allows a Messaging User Agent to 218 compose and forward an e-mail combining fragments that are located in 219 an IMAP server, without having to download these fragments to the 220 client. 222 There are two ways to perform "forward without download" based on 223 where the message assembly takes place. The first uses extended 224 APPEND command [CATENATE] to edit a draft message in the message 225 store and cause the message assembly on the IMAP server. The second 226 uses a succession of BURL and BDAT commands to submit and assemble 227 through concatenation, message data from the client and external data 228 fetched from the provided URL. The two subsequent sections provide 229 step-by-step instructions on how "forward without download" is 230 achieved. 232 2.4.1. Message assembly using IMAP CATENATE extension 234 In the [BURL]/[CATENATE] variant of the Lemonade "forward without 235 download" strategy, messages are initially composed and edited within 236 an MUA. The [CATENATE] extension to [RFC3501] is then used to create 237 the messages on the IMAP server by transmitting new text and 238 assembling them. The [UIDPLUS] IMAP extension is used by the client 239 in order to learn the UID of the created messages. Finally a 240 [URLAUTH] format URL is given to a [SUBMIT] server for submission 241 using the [BURL] extension. 243 The flow involved to support such a use case consists of: 244 M: {to I -- Optional} The client connects to the IMAP server, 245 optionally starts TLS (if data confidentiality is required), 246 authenticates, opens a mailbox ("INBOX" in the example below) and 247 fetches body structures (See [RFC3501]). 249 Example: 250 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 251 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 252 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 253 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 254 "trip.txt") 255 "<960723163407.20117h@washington.example.com>" 256 "Your trip details" "BASE64" 4554 73) "MIXED")) 257 I: A0051 OK completed 259 M: {to I} The client invokes CATENATE (See [CATENATE] for details 260 of the semantics and steps) -- this allows the MUA to create 261 messages on the IMAP server using new data combined with one or 262 more message parts already present on the IMAP server. 264 Note that the example for this step doesn't use the LITERAL+ 265 [LITERAL+] extension. Without LITERAL+ the new message is 266 constructed using 3 round-trips. If LITERAL+ is used, the new 267 message can be constructed using one round-trip. 269 M: A0052 APPEND Sent FLAGS (\Seen $MDNSent) 270 CATENATE (TEXT {475} 271 I: + Ready for literal data 272 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 273 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 274 M: From: Bob Ar 275 M: MIME-Version: 1.0 276 M: To: foo@example.net 277 M: Subject: About our holiday trip 278 M: Content-Type: multipart/mixed; 279 M: boundary="------------030308070208000400050907" 280 M: 281 M: --------------030308070208000400050907 282 M: Content-Type: text/plain; format=flowed 283 M: 284 M: Our travel agent has sent the updated schedule. 285 M: 286 M: Cheers, 287 M: Bob 288 M: --------------030308070208000400050907 289 M: URL "/INBOX;UIDVALIDITY=385759045/; 290 UID=25627;Section=2.MIME" URL "/INBOX; 291 UIDVALIDITY=385759045/;UID=25627;Section=2" TEXT {44} 292 I: + Ready for literal data 293 M: 294 M: --------------030308070208000400050907-- 295 M: ) 296 I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed 298 M: {to I} The client uses GENURLAUTH command to request a URLAUTH 299 URL (See [URLAUTH]). 300 I: {to M} The IMAP server returns a URLAUTH URL suitable for later 301 retrieval with URLFETCH (See [URLAUTH] for details of the semantics 302 and steps). 304 M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent; 305 UIDVALIDITY=387899045/;uid=45/;expire=2005-10- 306 28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 307 I: * GENURLAUTH "imap://bob.ar@example.org/Sent; 308 UIDVALIDITY=387899045/;uid=45/;expire= 309 2005-10-28T23:59:59Z;urlauth=submit+bob.ar: 310 internal:91354a473744909de610943775f92038" 311 I: A0054 OK GENURLAUTH completed 313 M: {to S} The client connects to the mail submission server and 314 starts a new mail transaction. It uses BURL to let the SMTP submit 315 server fetch the content of the message from the IMAP server (See 316 [BURL] for details of the semantics and steps -- this allows the 317 MUA to authorize the SMTP submit server to access the message 318 composed as a result of the CATENATE step). Note that the second 319 EHLO command is required after a successful STARTTLS command. 320 Also note that there might be a third required EHLO command if the 321 second EHLO response doesn't list any BURL options. Section 2.4.2 322 demonstrates this. 324 S: 220 owlry.example.org ESMTP 325 M: EHLO potter.example.org 326 S: 250-owlry.example.com 327 S: 250-8BITMIME 328 S: 250-BINARYMIME 329 S: 250-PIPELINING 330 S: 250-BURL imap 331 S: 250-CHUNKING 332 S: 250-AUTH PLAIN 333 S: 250-DSN 334 S: 250-SIZE 10240000 335 S: 250-STARTTLS 336 S: 250 ENHANCEDSTATUSCODES 337 M: STARTTLS 338 S: 220 Ready to start TLS 339 ...TLS negotiation, subsequent data is encrypted... 340 M: EHLO potter.example.org 341 S: 250-owlry.example.com 342 S: 250-8BITMIME 343 S: 250-BINARYMIME 344 S: 250-PIPELINING 345 S: 250-BURL imap 346 S: 250-CHUNKING 347 S: 250-AUTH PLAIN 348 S: 250-DSN 349 S: 250-SIZE 10240000 350 S: 250 ENHANCEDSTATUSCODES 351 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 352 S: 235 2.7.0 PLAIN authentication successful. 353 M: MAIL FROM: 354 S: 250 2.5.0 Address Ok. 355 M: RCPT TO: 356 S: 250 2.1.5 foo@example.net OK. 357 M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/; 358 uid=45/;urlauth=submit+bar:internal: 359 91354a473744909de610943775f92038 LAST 361 S: {to I} The mail submission server uses URLFETCH to fetch the 362 message to be sent (See [URLAUTH] for details of the semantics and 363 steps. The so-called "pawn-ticket" authorization mechanism uses a 364 URI which contains its own authorization credentials.). 365 I: {to S} Provides the message composed as a result of the 366 CATENATE step). 368 Mail submission server opens IMAP connection to the IMAP server: 370 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 371 CATENATE URLAUTH] imap.example.com 372 IMAP server ready 373 S: a000 STARTTLS 374 I: a000 Start TLS negotiation now 375 ...TLS negotiation, if successful - subsequent data 376 is encrypted... 377 S: a001 LOGIN submitserver secret 378 I: a001 OK submitserver logged in 379 S: a002 URLFETCH "imap://bob.ar@example.org/Sent; 380 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 381 internal:91354a473744909de610943775f92038" 382 I: * URLFETCH "imap://bob.ar@example.org/Sent; 383 UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar: 384 internal:91354a473744909de610943775f92038" {15065} 385 ...message body follows... 386 S: a002 OK URLFETCH completed 387 I: a003 LOGOUT 388 S: * BYE See you later 389 S: a003 OK Logout successful 391 Note that if the IMAP server doesn't send CAPABILITY response code 392 in the greeting, the mail submission server must issue the 393 CAPABILITY command to learn about supported IMAP extensions as 394 described in RFC 3501. 396 Also, if data confidentiality is not required the mail submission 397 server may omit the STARTTLS command before issuing the LOGIN 398 command. 400 S: {to M} Submission server assembles the complete message and if 401 the assembly succeeds it returns OK to the MUA: 402 S: 250 2.5.0 Ok. 404 M: {to I} The client marks the forwarded message on the IMAP 405 server. 407 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 408 I: A0053 OK STORE completed 410 Note: the UID STORE command shown above will only work if the 411 marked message is in the currently selected mailbox. This command 412 can be omitted. The $Forwarded IMAP keyword is described in section 413 2.8. 415 2.4.2. Message assembly using SMTP CHUNKING and BURL extensions 417 In the [BURL]/[CHUNKING] variant of the Lemonade "forward without 418 download" strategy, messages are initially composed and edited within 419 an MUA. During submission [RFC2476], BURL [BURL] and BDAT [CHINKING] 420 commands are used to create the messages from multiple parts. New 421 body parts are supplied using BDAT commands, while existing body 422 parts are referenced using [URLAUTH] format URLs in BURL commands. 424 The flow involved to support such a use case consists of: 425 M: {to I -- Optional} The client connects to the IMAP server, 426 optionally starts TLS (if data confidentiality is required), 427 authenticates, opens a mailbox ("INBOX" in the example below) and 428 fetches body structures (See [RFC3501]). 430 Example: 431 M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE) 432 I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN" 433 ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)( 434 "TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" 435 "trip.txt") 436 "<960723163407.20117h@washington.example.com>" 437 "Your trip details" "BASE64" 4554 73) "MIXED")) 438 I: A0051 OK completed 440 M: {to I} The client uses GENURLAUTH command to request URLAUTH 441 URLs (See [URLAUTH]) referencing pieces of the message to be 442 assembled. 443 I: {to M} The IMAP server returns URLAUTH URLs suitable for later 444 retrieval with URLFETCH (See [URLAUTH] for details of the semantics 445 and steps). 447 M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX; 448 UIDVALIDITY=385759045/;UID=25627;Section=2.MIME; 449 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" 450 INTERNAL "imap://bob.ar@example.org/INBOX; 451 UIDVALIDITY=385759045/;UID=25627;Section=2; 452 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL 453 I: * GENURLAUTH "imap://bob.ar@example.org/INBOX; 454 UIDVALIDITY=385759045/;UID=25627;Section=2.MIME; 455 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 456 internal:A0DEAD473744909de610943775f9BEEF" 457 "imap://bob.ar@example.org/INBOX; 458 UIDVALIDITY=385759045/;UID=25627;Section=2; 459 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 460 internal:BEEFA0DEAD473744909de610943775f9" 461 I: A0054 OK GENURLAUTH completed 463 M: {to S} The client connects to the mail submission server and 464 starts a new mail transaction. It uses BURL to instruct the SMTP 465 submit server to fetch from the IMAP server pieces of the message 466 to be sent (See [BURL] for details of the semantics and steps). 467 Note that the second EHLO command is required after a successful 468 STARTTLS command. The third EHLO command is required if and only if 469 the second EHLO response doesn't list any BURL options. See section 470 2.4.1 for an example of submission where the third EHLO 471 command/response is not present. 473 S: 220 owlry.example.org ESMTP 474 M: EHLO potter.example.org 475 S: 250-owlry.example.com 476 S: 250-8BITMIME 477 S: 250-BINARYMIME 478 S: 250-PIPELINING 479 S: 250-BURL 480 S: 250-CHUNKING 481 S: 250-AUTH DIGEST-MD5 482 S: 250-DSN 483 S: 250-SIZE 10240000 484 S: 250-STARTTLS 485 S: 250 ENHANCEDSTATUSCODES 486 M: STARTTLS 487 S: 220 Ready to start TLS 488 ...TLS negotiation, subsequent data is encrypted... 489 M: EHLO potter.example.org 490 S: 250-owlry.example.com 491 S: 250-8BITMIME 492 S: 250-BINARYMIME 493 S: 250-PIPELINING 494 S: 250-BURL 495 S: 250-CHUNKING 496 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 497 S: 250-DSN 498 S: 250-SIZE 10240000 499 S: 250 ENHANCEDSTATUSCODES 500 M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8= 501 S: 235 2.7.0 PLAIN authentication successful. 502 M: EHLO potter.example.org 503 S: 250-owlry.example.com 504 S: 250-8BITMIME 505 S: 250-BINARYMIME 506 S: 250-PIPELINING 507 S: 250-BURL imap imap://imap.example.org 508 S: 250-CHUNKING 509 S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL 510 S: 250-DSN 511 S: 250-SIZE 10240000 512 S: 250 ENHANCEDSTATUSCODES 513 M: MAIL FROM: BODY=BINARY 514 S: 250 2.5.0 Address Ok. 515 M: RCPT TO: 516 S: 250 2.1.5 foo@example.net OK. 517 M: BDAT 475 518 M: Message-ID: <419399E1.6000505@caernarfon.example.org> 519 M: Date: Thu, 12 Nov 2004 16:57:05 +0000 520 M: From: Bob Ar 521 M: MIME-Version: 1.0 522 M: To: foo@example.net 523 M: Subject: About our holiday trip 524 M: Content-Type: multipart/mixed; 525 M: boundary="------------030308070208000400050907" 526 M: 527 M: --------------030308070208000400050907 528 M: Content-Type: text/plain; format=flowed 529 M: 530 M: Our travel agent has sent the updated schedule. 531 M: 532 M: Cheers, 533 M: Bob 534 M: --------------030308070208000400050907 535 S: 250 2.5.0 OK 536 M: BURL imap://bob.ar@example.org/INBOX; 537 UIDVALIDITY=385759045/;UID=25627;Section=2.MIME; 538 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 539 internal:A0DEAD473744909de610943775f9BEEF 540 S: 250 2.5.0 OK 541 M: BURL imap://bob.ar@example.org/INBOX; 542 UIDVALIDITY=385759045/;UID=25627;Section=2; 543 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 544 internal:BEEFA0DEAD473744909de610943775f9 545 S: 250 2.5.0 OK 546 M: BDAT 44 LAST 547 M: 548 M: --------------030308070208000400050907-- 550 S: {to I} The mail submission server uses URLFETCH to fetch the 551 pieces of the message to be sent (See [URLAUTH] for details of the 552 semantics and steps. The so-called "pawn-ticket" authorization 553 mechanism uses a URI which contains its own authorization 554 credentials.). 555 I: {to S} Returns the requested body parts. 557 Mail submission server opens IMAP connection to the IMAP server: 559 I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+ 560 CATENATE URLAUTH] imap.example.com 561 IMAP server ready 562 S: a001 LOGIN submitserver secret 563 I: a001 OK submitserver logged in 564 S: a002 URLFETCH "imap://bob.ar@example.org/INBOX; 565 UIDVALIDITY=385759045/;UID=25627;Section=2.MIME; 566 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 567 internal:A0DEAD473744909de610943775f9BEEF" "imap:// 568 bob.ar@example.org/INBOX; 569 UIDVALIDITY=385759045/;UID=25627;Section=2; 570 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 571 internal:BEEFA0DEAD473744909de610943775f9" 572 I: * URLFETCH "imap://bob.ar@example.org/INBOX; 573 UIDVALIDITY=385759045/;UID=25627;Section=2.MIME; 574 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 575 internal:A0DEAD473744909de610943775f9BEEF" {84} 576 ...message section follows... 577 "imap://bob.ar@example.org/INBOX; 578 UIDVALIDITY=385759045/;UID=25627;Section=2; 579 expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar: 580 internal:BEEFA0DEAD473744909de610943775f9" {15065} 581 ...message section follows... 582 S: a002 OK URLFETCH completed 583 I: a003 LOGOUT 584 S: * BYE See you later 585 S: a003 OK Logout successful 587 Note that if the IMAP server doesn't send CAPABILITY response code 588 in the greeting, the mail submission server must issue the 589 CAPABILITY command to learn about supported IMAP extensions as 590 described in RFC 3501. 592 Also, if data confidentiality is required the mail submission 593 server should start TLS before issuing the LOGIN command. 595 S: {to M} Submission server assembles the complete message and if 596 the assembly succeeds it acknowledges acceptance of the message by 597 sending 250 response to the last BDAT command: 598 S: 250 2.5.0 Ok, message accepted. 600 M: {to I} The client marks the forwarded message on the IMAP 601 server. 603 M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded) 604 I: A0053 OK STORE completed 606 Note: the UID STORE command shown above will only work if the 607 marked message is in the currently selected mailbox. This command 608 can be omitted. The $Forwarded IMAP keyword is described in section 609 2.8. 611 2.5. Normative statements related to forward without download 613 Lemonade compliant IMAP servers MUST support IMAPv4Rev1 [RFC3501], 614 CATENATE [CATENATE], UIDPLUS [UIDPLUS] and URLAUTH [URLAUTH]. This 615 support MUST be declared via CAPABILITY [RFC3501]. 617 Lemonade compliant submit servers MUST support the BURL [BURL], 618 8BITMIME [8BITMIME], BINARYMIME [CHUNKING] and CHUNKING [CHUNKING]. 619 This support MUST be declared via EHLO [RFC2821]. BURL MUST support 620 URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap" 621 option following the BURL EHLO keyword (See [BURL] for more details). 623 Additional normative statements are provided in other sections. 625 2.6. Security Considerations for pawn-tickets. 627 The so-called "pawn-ticket" authorization mechanism uses a URI, which 628 contains its own authorization credentials using [URLAUTH]. The 629 advantage of this mechanism is that the SMTP submit [SUBMIT] server 630 cannot access any data on the [RFC3501] server without a "pawn- 631 ticket" created by the client. 633 The "pawn-ticket" grants access only to the specific data that the 634 SMTP submit [SUBMIT] server is authorized to access, can be revoked 635 by the client, and can have a time-limited validity. 637 2.7. The fcc problem 639 The "fcc problem" refers to delivering a copy of a message to a "file 640 carbon copy" recipient. By far, the most common case of fcc is a 641 client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox" 642 mailbox. 644 In the traditional strategy, the MUA duplicates the effort spent in 645 transmitting to the MSA by writing the message to the fcc destination 646 in a separate step. This may be a write to a local disk file or an 647 APPEND to a mailbox on an IMAP server. The latter is one of the " 648 repetitive network data transmissions" which represents the "problem" 649 aspect of the "fcc problem". 651 The [CATENATE] extension to [RFC3501] can be used to address the fcc 652 problem. The final message is constructed in the mailbox designed for 653 outgoing mail. Note that the [CATENATE] extension can only create a 654 single message and only on the server which stages the outgoing 655 message for submission. Additional copies of the message can be 656 created on the same server using one or more COPY commands. 658 2.8. Registration of $Forwarded IMAP keyword 660 The $Forwarded IMAP keyword is used by several IMAP clients to 661 specify that the message was resent to another email address, 662 embedded within or attached to a new message. A mail client sets this 663 keyword when it successfully forwards the message to another email 664 address. Typical usage of this keyword is to show a different (or 665 additional) icon for a message that has been forwarded. Once set the 666 flag SHOULD NOT be cleared. 668 Lemonade compliant servers MUST be able to store the $Forwarded 669 keyword. They MUST preserve it on the COPY operation. The servers 670 MUST support the SEARCH KEYWORD $Forwarded. 672 3. Message Submission 674 LEMONADE compliant mail submission servers are expected to implement 675 the following set of SMTP extensions to make message submission 676 efficient. 678 Lemonade clients SHOULD take advantage of these features. 680 3.1. Pipelining 682 Mobile clients regularly use networks with a relatively high latency. 683 Avoidance of round-trips within a transaction has a great advantage 684 for the reduction in both bandwidth and total transaction time. For 685 this reason LEMONADE compliant mail submission servers MUST support 686 the SMTP Service Extensions for Command Pipelining [REF2197]. 688 Clients SHOULD pipeline SMTP commands when possible. 690 3.2. DSN Support 692 LEMONADE compliant mail submission servers MUST support SMTP service 693 extensions for delivery status notifications [RFC3461]. 695 3.3. Message size declaration 697 LEMONADE compliant mail submission servers MUST support the SMTP 698 Service Extension for Message Size Declaration [RFC1870]. 700 LEMONADE compliant mail submission servers MUST ("expand") all BURL 701 parts before enforcing a message size limit. 703 A LEMONADE compliant client SHOULD use message size declaration. In 704 particular it SHOULD NOT send a message to a mail submission server, 705 if the client knows that the message exceeds the maximal message size 706 advertised by the submission server. 708 3.4. Enhanced status code Support 710 LEMONADE compliant mail submission servers MUST support SMTP Service 711 Extension for Returning Enhanced Error Codes [RFC2034]. 713 3.5. TLS 715 LEMONADE Compliant mail submission servers MUST support SMTP Service 716 Extension for Secure SMTP over TLS [SMTP-TLS]. 718 4. Quick resynchronization 720 LEMONADE Compliant IMAP servers MUST support the CONDSTORE 721 [CONDSTORE] extension. It allows a client to quickly resynchronize 722 any mailbox by asking the server to return all flag changes that have 723 occurred since the last known mailbox synchronization mark. 725 [IMAP-DISC] shows how to perform quick mailbox resynchronization. 727 5. Additional IMAP extensions 729 Lemonade compliant IMAP servers MUST support the NAMESPACE 730 [NAMESPACE] extension. The extension allows clients to discover 731 shared mailboxes and mailboxes belonging to other users. 733 Lemonade compliant IMAP servers MUST support the LITERAL+ [LITERAL+] 734 extension. The extension allows clients to save a round trip each 735 time a non-synchronizing literal is sent. 737 Lemonade compliant IMAP servers MUST support the IDLE [IDLE] 738 extension. The extension allows clients to receive instant 739 notifications about changes in the selected mailbox, without needing 740 to poll for changes. 742 LEMONADE Compliant IMAP servers MUST support IMAP over TLS [RFC3501] 743 as required by RFC 3501. 745 6. Summary of the required IMAP and SMTP extensions 747 -----------------------------------------------------| 748 | Name of SMTP extension | Comment | 749 |-------------------------|--------------------------| 750 | PIPELINING | Section 3.1 | 751 |-------------------------|--------------------------| 752 | DNS | Section 3.2 | 753 |-------------------------|--------------------------| 754 | SIZE | Section 3.3 | 755 |-------------------------|--------------------------| 756 | ENHANCEDSTATUSCODES | Section 3.4 | 757 |-------------------------|--------------------------| 758 | STARTTLS | Section 3.5 | 759 |-------------------------|--------------------------| 760 | BURL | Forward without download,| 761 | | Section 2 | 762 |-------------------------|--------------------------| 763 | URLAUTH support in BURL | Section 2.5 | 764 |-------------------------|--------------------------| 765 | CHUNKING, | Section 2.5 | 766 | BINARYMIME | Section 2.5 | 767 |-------------------------|--------------------------| 768 | 8BITMIME, | Required by BURL | 769 |-------------------------|--------------------------| 770 | AUTH | Required by Submission, | 771 | | See [SMTPAUTH]. | 772 |-------------------------|--------------------------| 774 -----------------------------------------------------| 775 | Name of IMAP extension | Comment | 776 | or feature | | 777 |-------------------------|--------------------------| 778 | NAMESPACE | Section 5 | 779 |-------------------------|--------------------------| 780 | CONDSTORE | Section 4 | 781 |-------------------------|--------------------------| 782 | STARTTLS |Required by IMAP (RFC3501)| 783 |-------------------------|--------------------------| 784 | URLAUTH, | Forward without download,| 785 | CATENATE, | Section 2 | 786 | UIDPLUS | | 787 |-------------------------|--------------------------| 788 | LITERAL+ | Section 5 | 789 |-------------------------|--------------------------| 790 | IDLE | Section 5 | 791 |-------------------------|--------------------------| 792 | $Forwarded IMAP keyword | Section 2.8 793 | 794 |-------------------------|--------------------------| 796 7. Future work 798 The Lemonade Working Group is looking into additional issues related 799 to usage of email by mobile devices, possibly including: 800 - Media conversion (static and possibly streamed) 801 - Transport optimization for low or costly bandwidth and less 802 reliable mobile networks (e.g. quick reconnect) 803 - Server to client notifications, possibly outside of the 804 traditional IMAP band 805 - Dealing with firewall and intermediaries 806 - Compression and other bandwidth optimization 807 - Filtering 808 - Other considerations for mobile clients 810 8. Security Considerations 812 Security considerations on Lemonade "forward without download" are 813 discussed throughout section 2. Additional security considerations 814 can be found in [RFC3501] and other documents describing other SMTP 815 and IMAP extensions comprising the Lemonade Profile. 817 Note that the mandatory to implement authentication mechanism for 818 SMTP submission is described in [SUBMIT]. The mandatory to implement 819 authentication mechanism for IMAP is described in [RFC3501]. 821 8.1. Confidentiality Protection of Submitted Messages 823 When clients submit new messages, link protection such as TLS guards 824 against an eavesdropper seeing the contents of the submitted message. 825 It's worth noting, however, that even if TLS is not used, the 826 security risks are no worse if BURL is used to reference the text 827 than if the text is submitted directly. If BURL is not used, an 828 eavesdropper gains access to the full text of the message. If BURL 829 is used, the eavesdropper may or may not be able to gain such access, 830 depending on the form of BURL used. For example, some forms restrict 831 use of the URL to an entity authorized as a submission server or a 832 specific user. 834 8.2. TLS 836 When LEMONADE clients use the BURL extension to mail submission, an 837 extension that requires sending a URLAUTH token to the mail 838 submission server, such a token should be protected from interception 839 to avoid a replay attack that may disclose the contents of the 840 message to an attacker. TLS based encryption of the mail submission 841 path will provide protection against this attack. 843 LEMONADE clients SHOULD use TLS protected IMAP and mail submission 844 channels when using BURL-based message submission to protect the 845 URLAUTH token from interception. 847 LEMONADE compliant mail submission servers SHOULD use TLS protected 848 IMAP connections when fetching message content using the URLAUTH 849 token provided by the LEMONADE client. 851 When a client uses SMTP STARTTLS to send a BURL command which 852 references non-public information, there is a user expectation that 853 the entire message content will be treated confidentially. To meet 854 this expectation, the message submission server should use STARTTLS 855 or a mechanism providing equivalent data confidentiality when 856 fetching the content referenced by that URL. 858 9. IANA Considerations 860 This document doesn't require any IANA registration or action. 862 10. References 864 10.1. Normative References 866 [BURL] Newman, C. "Message Composition", draft-ietf-lemonade-burl- 867 XX.txt (work in progress). 869 [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 870 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 871 1652, July 1994. 873 [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission 874 of Large and Binary MIME Messages", RFC 3030, December 2000. 876 [CATENATE] Resnick, P. "Internet Message Access Protocol (IMAP) 877 CATENATE Extension", draft-ietf-lemonade-catenate-XX.txt, (work in 878 progress). 880 [UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - 881 UIDPLUS extension", work in progress, draft-crispin-imap- 882 rfc2359bis-XX.txt. 884 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate 885 Requirement Levels", RFC 2119, March 1997. 886 http://www.ietf.org/rfc/rfc2119 888 [RFC2197] Freed, N. "SMTP Service Extension for Command Pipelining", 889 RFC 2197, September 1997. http://www.ietf.org/rfc/rfc2197 891 [RFC1870] Freed, N. and K. Moore, "SMTP Service Extension for Message 892 Size Declaration", RFC 1870, November 1995. 894 [SUBMIT] Gellens, R. and Klensin, J., "Message Submission for Mail", 895 draft-gellens-submit-bis-02.txt. 897 [SMTP-TLS] Hoffman, P. "SMTP Service Extension for Secure SMTP over 898 TLS ", RFC 3207, February 2002. http://www.ietf.org/rfc/rfc3207 900 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 901 April 2001. 903 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 904 Version 4 rev1", RFC 3501, March 2003. 905 http://www.ietf.org/rfc/rfc3501 907 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 908 Extension for Delivery Status Notifications (DSNs)", RFC 3461, 909 January 2003. http://www.ietf.org/rfc/rfc3461 911 [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access 912 Protocol (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth- 913 XX.txt, (work in progress). 915 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced 916 Error Codes", RFC 2034, October 1996. 918 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 919 May 1998. 921 [SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", 922 RFC 2554, March 1999. 924 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 925 January 1997. 927 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional 928 STORE", work in progress. 930 [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997. 932 10.2. Informative References 934 [IMAP-DISC] Melnikov, A. "Synchronization Operations For 935 Disconnected Imap4 Clients", IMAP-DISC, work in progress, draft- 936 melnikov-imap-disc-XX.txt 938 Version History 940 This section will be deleted before publication. 942 Version 07: 943 [1] Addressed editorial comments from Randy Gellens and Dave 944 Cridland. 946 Version 06: 947 [1] Updated the reference to SMTP STARTTLS. 948 [2] Updated the CATENATE example as per comments from Dave Cridland 949 (message context, missing additional EHLO, etc.). 950 [3] Added a new section showing use of BURL/BDAT for message 951 assembly. 952 [4] Added a requirement to support IMAP IDLE extension. 953 [5] Added description of the $Forwarded IMAP keyword. 954 [6] Added a requirement to support URLAUTH in BURL. 955 [7] Mentioned mandatory to implement authentication in the Security 956 Considerations. 957 [8] Other editorial fixes from Randy and Greg. 959 Version 05: 960 [1] Removed any references to POSTADDRESS and quick reconnect. 961 [2] Added reference to LITERAL+. 962 [3] Added a new section about CONDSTORE. 963 [4] Split TLS text between 3 sections. 964 [5] Added new text that security of BURL is no worse than sending in 965 the clear. 966 [6] Added ";expire" to the URLAUTHs in the forward without download 967 example. 969 Version 04: 970 [1] Removed future delivery from the phase 1 of the profile. 971 [2] Updated the list of required SMTP and IMAP extensions and 972 associated normative statements. 973 [3] Updated the references. 974 [4] Moved (and updated) text about TLS to the Security Considerations 975 section. 976 [5] Removed most editor's notes. 977 [6] Proposed terminology Lemonade profile phase 1 (and later phases) 978 to distinguish current status from future work. 980 Version 03: 981 [1] Updated boilerplate. 982 [2] Addressed most of the comments raised by Randy Gellens and some 983 from Pete Resnick. 984 [3] Purged and updated references. 985 [4] Updated examples as per changes in CATENATE and other documents. 986 [5] Replaced Lemonade Pull model by Lemonade "forward without 987 download". 988 [6] Qualified normative statement on future delivery. 990 Version 02: 991 [1] Improved abstract based on review comments as well as change to 992 reflect the re-organized content of the present Lemonade profile. 993 [2] Editorial improvement of section 2.1 994 [3] Addition of section 2.5 with normative statements for lemonade 995 compliant clients and servers regarding forward without download. 996 [4] Addition of section 3 on message submission. 997 [5] Move of media conversion to future work 998 [6] Add section 4.1 on normative statements related to quick 999 reconnect scheme. 1000 [6] Addition of Binary and 8-bit MIME Transport to future work. 1001 [7] Addition of IANA statement. 1002 [8] Update and fix of the references. 1004 Version 01: 1005 [1] We removed the sections of the profile related to mobile e-mail 1006 as well as discussion. This will be part of the next version of 1007 the Lemonade profile work. 1008 [2] We added detailed examples for the different steps included in 1009 section 2.4. 1010 [3] We added section 3 on media conversion. 1011 [4] We added examples on Quick reconnect schemes in section 4. 1012 [5] We updated the security considerations. 1013 [6] We fixed references based on updates above. 1014 [7] We added a future work section. 1015 [8] We fixed the boiler plate statements on the "status of this memo" 1016 and "Copyright". 1018 Acknowledgments 1020 This document is a product of Lemonade WG. The editors' thanks the 1021 Lemonade WG members that contributed comments and corrections, in 1022 particular: Randy Gellens, Dave Cridland and Greg Vaudreuil. 1024 This document borrows some text from draft-crispin-lemonade-pull- 1025 xx.txt as well as the trio [BURL], [CATENATE] and [URLAUTH]. 1027 Authors' Addresses 1029 Stephane H. Maes 1030 Oracle Corporation 1031 500 Oracle Parkway 1032 M/S 4op634 1033 Redwood Shores, CA 94065 1034 USA 1035 Phone: +1-650-607-6296 1036 Email: stephane.maes@oracle.com 1038 Alexey Melnikov 1039 Isode Limited 1040 5 Castle Business Village 1041 36 Station Road 1042 Hampton, Middlesex 1043 TW12 2BX 1044 UK 1045 Email: Alexey.melnikov@isode.com 1047 Intellectual Property Statement 1049 The IETF takes no position regarding the validity or scope of any 1050 Intellectual Property Rights or other rights that might be claimed to 1051 pertain to the implementation or use of the technology described in 1052 this document or the extent to which any license under such rights 1053 might or might not be available; nor does it represent that it has 1054 made any independent effort to identify any such rights. Information 1055 on the procedures with respect to rights in RFC documents can be 1056 found in BCP 78 and BCP 79. 1058 Copies of IPR disclosures made to the IETF Secretariat and any 1059 assurances of licenses to be made available, or the result of an 1060 attempt made to obtain a general license or permission for the use of 1061 such proprietary rights by implementers or users of this 1062 specification can be obtained from the IETF on-line IPR repository at 1063 http://www.ietf.org/ipr. 1065 The IETF invites any interested party to bring to its attention any 1066 copyrights, patents or patent applications, or other proprietary 1067 rights that may cover technology that may be required to implement 1068 this standard. Please address the information to the IETF at ietf- 1069 ipr@ietf.org. 1071 The IETF has been notified of intellectual property rights claimed in 1072 regard to some or all of the specification contained in this 1073 document. For more information consult the online list of claimed 1074 rights. 1076 Disclaimer of Validity 1078 This document and the information contained herein are provided on an 1079 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1080 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1081 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1082 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1083 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1084 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1086 Copyright Statement 1088 Copyright (C) The Internet Society (2006). This document is subject 1089 to the rights, licenses and restrictions contained in BCP 78, and 1090 except as set forth therein, the authors retain all their rights. 1092 Acknowledgement 1094 Funding for the RFC Editor function is currently provided by the 1095 Internet Society.