idnits 2.17.1 draft-ietf-lemonade-firewall-binding-00.txt: -(465): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(473): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(519): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(520): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(530): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(599): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(695): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(755): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(848): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(852): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 943. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 949. ** 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: ---------------------------------------------------------------------------- == There are 26 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 46 has weird spacing: '...ransfer comma...' -- 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 (February 2006) is 6642 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: 'RFC821' is mentioned on line 70, but not defined ** Obsolete undefined reference: RFC 821 (Obsoleted by RFC 2821) == Missing Reference: 'UIDVALIDITY 12345678' is mentioned on line 585, but not defined == Missing Reference: 'READ-WRITE' is mentioned on line 586, but not defined == Missing Reference: '1' is mentioned on line 871, but not defined == Unused Reference: 'LEMONADEPROFILE' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'RFC2088' is defined on line 831, but no explicit reference was found in the text == Unused Reference: 'RFC2442' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 844, but no explicit reference was found in the text == Unused Reference: 'WEBDAV' is defined on line 864, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 875, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 878, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 881, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 884, but no explicit reference was found in the text -- No information found for draft-ietf-lemonade-profile-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LEMONADEPROFILE' -- Possible downref: Normative reference to a draft: ref. 'LUOTONEN' -- No information found for draft-maes-lemonade-mobile-email-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEMAIL' -- No information found for draft-ietf-lemonade-server-to-client-notifications-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NOTIFICATIONS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-ME-AD' -- Possible downref: Non-RFC (?) normative reference: ref. 'OMA-ME-RD' -- No information found for draft-maes-lemonade-p-imap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'P-IMAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'REST' ** Obsolete normative reference: RFC 2088 (Obsoleted by RFC 7888) ** Downref: Normative reference to an Informational RFC: RFC 2442 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3205 (Obsoleted by RFC 9205) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2518 (ref. 'WEBDAV') (Obsoleted by RFC 4918) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 February 2006 3 Lemonade S. H. Maes 4 Internet Draft: Lemonade Bindings for firewalls R. Cromwell 5 and mobile network intermediaries N. Mitra 6 Informational Track (Editors) 8 Document: draft-ietf-lemonade-firewall-binding-00 9 Expires: August 2006 February 2006 11 Lemonade bindings to cross firewalls and mobile network 12 intermediaries 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 As part of the LEMONADE work to define extensions to the IMAP and 44 SMTP protocols that provide optimizations in a variety of settings, 45 the this document describes an alternative, optional binding for IMAP 46 and SMTP showing how HTTP can be used to transfer commands and 47 responses. This binding is intended to facilitate the use of IMAP and 48 SMTP in deployments involving a variety of intermediaries. Bindings 49 to SOAP, REST and WebDAV are also provided. 51 February 2006 53 Conventions used in this document 55 In examples, "C:" and "S:" indicate lines sent by the client and 56 server respectively. 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 An implementation is not compliant if it fails to satisfy one or more 63 of the MUST or REQUIRED level requirements for the protocol(s) it 64 implements. An implementation that satisfies all the MUST or REQUIRED 65 level and all the SHOULD level requirements for a protocol is said to 66 be "unconditionally compliant" to that protocol; one that satisfies 67 all the MUST level requirements but not all the SHOULD level 68 requirements is said to be "conditionally compliant." When 69 describing the general syntax, some definitions are omitted as they 70 are defined in [RFC3501], [RFC821], and related documents.. 72 Table of Contents 74 Status of this Memo................................................1 75 Copyright Notice...................................................1 76 Abstract...........................................................1 77 Conventions used in this document..................................2 78 Table of Contents..................................................2 79 1. Introduction and motivation.....................................3 80 2. Techniques for binding over HTTP................................4 81 2.1. Tunneling Approaches.......................................4 82 2.1.1. Non-Persistent HTTP for In-response Connectivity Mode.6 83 2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer 84 Encoding for In-band Connectivity Mode................7 85 2.1.3. Using HTTP Connect....................................9 86 2.1.4. Using HTTP as a binding for SMTP......................9 87 2.2. Syntactic Mapping Approaches..............................10 88 2.3. Using SOAP (Web Services) as a binding for IMAP...........10 89 2.4. REST Mapping..............................................12 90 2.4.1. IMAP resources as REST resources and interface.......13 91 2.4.2. IMAP commands as HTTP commands on REST resources.....14 92 2.4.3. Representation of transferred resources..............15 93 2.4.4. Challenges...........................................15 94 2.5. WebDAV Mapping............................................15 95 3. Security Considerations........................................16 96 4. References.....................................................17 97 5. Future Work....................................................18 98 6. Version History................................................19 99 Acknowledgments...................................................19 100 February 2006 102 Authors Addresses.................................................19 103 Intellectual Property Statement...................................19 104 Disclaimer of Validity............................................20 105 Copyright Statement...............................................20 107 1. 108 Introduction and motivation 110 As part of the LEMONADE goal to define extensions to the IMAP and 111 SMTP protocols [RFC3501] for providing optimizations in a variety of 112 settings, this document describes how HTTP can optionally be used to 113 transfer IMAP and SMTP commands and responses. This binding is 114 intended to facilitate the use of IMAP and SMTP in deployments 115 involving a variety of intermediaries, and offers a standardized 116 alternative to de facto proprietary implementations of such a 117 feature. 119 The need for an optional HTTP binding is driven by the needs of the 120 mobile network operator community (see [MEMAIL][OMA-ME-RD]), where 121 the reuse of an existing and well-understood technology will allow 122 operators to apply their experience in solving practical deployment 123 issues. Specifically, HTTP allows operators to reuse a similar setup 124 and model that is already used for many other similar and related 125 services, such as certain proprietary push e-mail and synchronization 126 offerings, OMA Data Synchronization, Web services and Web access. 128 Using HTTP/HTTPS can simplify deployment in a corporate network 129 through the potential use of a reverse proxy to achieve end-to-end 130 encryption. This also has the advantage of not requiring changes to 131 any firewall configurations and reduces the concerns that this often 132 presents to corporation. In general the solution is compatible with 133 any existing firewall. A reverse proxy can also support deployment 134 models that offer roles to other service providers in the value 135 chains, as discussed in [OMA-ME-AD]. 137 The confidentiality, integrity, and compression capabilities used 138 with HTTP and already implemented in a wide range of existing mobile 139 device, can also be reused. 141 Studies have also shown that a persistent HTTP session has usually 142 proven more resilient than an IMAP IDLE over TCP connection over an 143 unreliable bearer such as a GPRS-based mobile network. 145 The use of HTTP as an underlying protocol for other application 146 protocols has received much attention (see [RFC3205]). In particular, 147 the concern exists that this circumvents firewall security policies. 148 Another concern is the potential misuse or neglect of HTTP semantics 149 by the application protocol that uses HTTP as a substrate. 151 February 2006 153 Note that if the suppression of IMAP (or indeed any other 154 application) traffic on HTTP/HTTPS is an issue, firewall 155 administrators can still prevent such passage and this can provide 156 incentives to re-configure firewalls to allow solutions on other 157 transports (e.g. TLS) or offer the HTTP-based solution using another 158 provisioned port (e.g. manually, out of band or via instructions like 159 XGETLPREFS (see [NOTIFICATIONS])). The aim, therefore, is to allow 160 for the use of this solution in the widest possible set of 161 circumstances by codifying a standard way to do so that works with 162 existing, deployed (i.e., HTTP only) firewalls, while explicitly 163 allowing the possibility of detecting and filtering such traffic in 164 deployments using the HTTP Content-Type in deployments where this is 165 not permitted. 167 SOAP, REST and WeDAV binding are also described. 169 2. 170 Techniques for binding over HTTP 172 There are two general approaches described below for binding IMAP 173 over HTTP. The first approach shows how to tunnel regular IMAP 174 requests and responses over HTTP using POST. The second approach 175 proposes a syntactic change which recodes IMAP requests and responses 176 as SOAP documents, WebDAV requests, or REST requests and attempts to 177 obey the underlying semantics of those protocols. At the current 178 stage of the draft, the SOAP, REST, and DAV mappings are meant more 179 as informative examples for further research and discussion. 181 2.1. 182 Tunneling Approaches 184 To use HTTP/HTTPS as the transfer protocol for IMAP commands and 185 responses between the IMAP client and server, the client MUST send an 186 HTTP POST request to the server, and embed IMAP commands (commands to 187 an IMAPv4 Rev1 server or IMAP servers supporting Lemonade extensions) 188 in the body of the request. A server MUST reject a HTTP GET request 189 from the client. The content-type header of the POST request MUST be 190 set to "application/vnd.lemonade". Multiple IMAP commands may be 191 included in one POST request. In general, the HTTP server is expected 192 to preserve session state between HTTP commands to the best of its 193 ability, therefore the client does not need to reauthenticate and 194 reissue a SELECT until it receives an (IMAP) error response showing 195 that it is not authenticated. 197 In what follows, the term Lemonade client/server is used to refer to 198 a client/server that supports both IMAPv4 Rev1 as well as any 199 LEMONADE extensions. 201 February 2006 203 When the HTTP binding is used, the Lemonade server listens on 204 whatever port has been configured for this. 206 The following is an example of a possible Lemonade HTTP request: 208 POST /lemonadePath HTTP/1.1 209 Content-Type: application/vnd.lemonade 210 [other headers] 211 212 ( SP | literal ) 213 [( SP | literal )] 215 The Lemonade command MUST be plain text (7bit). 217 Multiple Lemonade commands MAY be sent on the same request. Thus 218 Lemonade commands must be tagged. The client must be able to deal 219 with recovering from errors when commands are batched. See RFC2442 220 Batch SMTP for a further discussion. In general, if a command is 221 expected to produce a synchronized literal or continuation request, 222 it MUST be the last command in the batch. 224 The Content-Type header is the only HTTP headers that MUST be sent to 225 a Lemonade server. Other headers such as Cache-Control MAY be 226 included. 228 When the Lemonade server sends back a response it is in following 229 format: 231 HTTP/1.1 232 Content-Type: text/plain 233 234 [] 235 SP 236 [] 237 SP 239 Notes: 240 The Lemonade Server uses the following HTTP status codes, and what 241 each code indicates is given below: 242 - 100 243 - This indicates the presence of a synchronizing literal or 244 continuation request. The server is waiting for more data from 245 the client (another HTTP request) before continuing. If the 246 HTTP request includes batched commands after the command which 247 generates a continuation request or synchronized literal, the 248 server MUST generate a 5xx request. 250 - 200 251 February 2006 253 - This indicates normal execution of the Lemonade commands 254 from an IMAP perspective. The client should further parse 255 the response body to get the tagged responses to the 256 commands and process those accordingly. 257 - 401 258 - This indicates that the execution of the IMAP commands might 259 have been successful, but the session is no longer 260 authenticated. The client should try to reauthenticate to the 261 IMAP server, and then resend the commands. 263 - 5xx 264 - This indicates that at least one command was 265 malformed/protocol level error, or, a command could not 266 complete due to a problem in the IMAP server. In conforming to 267 HTTP semantics, this means the IMAP server responses such as 268 BAD or NO on a tagged response generate a HTTP 500 response 269 code. 271 When using HTTP to transfer IMAP commands and responses, the client 272 SHOULD utilize built-in features of HTTP to their advantage. For 273 example, the client SHOULD use HTTPS instead of HTTP whenever 274 possible, since HTTPS has built in encryption and MAY have 275 compression capabilities. STARTTLS should not be needed in this 276 case, as it just requires additional overhead without any additional 277 benefit. 279 HTTP can be used in both in-response and in-band modes. Details 280 about these transport modes are given in the following two 281 subsections. 283 2.1.1. Non-Persistent HTTP for In-response Connectivity Mode 285 If the client uses a traditional HTTP connection (either by 286 establishing a different socket for each HTTP request to the Lemonade 287 server, or by reusing the same socket for all HTTP requests, but 288 sending each request under its own header), it has in-response 289 connectivity to the server. The client can issue as many commands as 290 it would like in one HTTP request to the server, and the server 291 responds by sending back one HTTP response with all the responses to 292 all the commands in the HTTP request. With this connectivity mode, 293 the IDLE command cannot be issued. Other commands that use a 294 continuation response or synchronized literal cannot be issued unless 295 they are the last command in the batch. [LITERAL+] SHOULD be used to 296 eliminate synchronized literals when using APPEND. 298 In order for the server to identify separate HTTP requests as 299 belonging to the same session, an in-response HTTP client needs to 300 February 2006 302 accept cookies. A session-id is passed in the cookie to identify the 303 session. 305 Example: the headers for a HTTP In-response Response after the client 306 has issued its first HTTP request to the server. 308 HTTP/1.1 309 Content-Type: text/plain 310 Set-Cookie:JSESSIONID=94571a8530d91e1913bfydafa; 311 path=/lemonade 312 313 [] 314 SP 315 [[] 316 SP ] 318 Example: the headers for a HTTP In-response Response after the client 319 has issued its first HTTP request to the server, with the final 320 command generating a continuation request. 322 HTTP/1.1 100 Continue 323 Content-Type: text/plain 324 Set-Cookie:JSESSIONID=94571a8530d91e1913bfydafa; 325 path=/lemonade 326 327 [] 328 SP 329 +continuation-request 331 The client must then save this cookie and send it back to the server 332 with the next request in order for the server to reattach these 333 commands to the same session as the previous commands. 335 POST /lemonadePath HTTP/1.1 336 Content-Type: application/vnd.lemonade 337 Cookie: JSESSIONID=94571a8530d91e1913bfydafa 338 [other headers] 339 340 SP 341 [ SP ] 343 2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer Encoding for In- 344 band Connectivity Mode 346 It is possible to use persistent HTTP or persistent HTTPS plus 347 chunked- transfer-encoding so that the server can instantly send 348 February 2006 350 notifications to the client while a session is open. The client 351 needs to open a persistent connection and keep it active. In this 352 case, the HTTP headers must be sent the first time the client device 353 opens the connection to the Lemonade Server and these headers MUST 354 set the transfer coding to be chunk-encoded [RFC2616, Sec. 3.6.1]. 355 All subsequent client-server requests are written to the open 356 connection, without needing any additional headers negotiations. The 357 server can use this open channel to push events to the client device 358 at any time. In this case, the client SHOULD NOT accept cookies. 360 The client must send the HTTP headers one time only: 362 POST /lemonadeServletPath HTTP/1.1 363 Content-Type: application/vnd.lemonade 364 Connection: keep-alive 365 Pragma: no-cache 366 Transfer-Encoding: chunked 368 The server responds with the following header: 370 HTTP/1.1 371 Cache-Control: private 372 Keep-Alive: timeout=15, max=100 (or other suitable setting) 373 Connection: Keep-Alive 374 Transfer-Encoding: chunked 375 Content-Type: text/plain 377 Then the client can send a command anytime it wants with the 378 following format: 379 380 SP 381 383 And example of an actual client command is: 384 e 385 2 CAPABILITY 386 388 The server responds to each command with as many untagged responses 389 as needed, and one tagged response, where each response is in the 390 format that follows: 391 392 393 395 An actual Server response might be: 396 d5 397 February 2006 399 * CAPABILITY IMAP4REV1 AUTH=LOGIN NAMESPACE SORT MULTIAPPEND 400 LITERAL+ UIDPLUS IDLE XORACLE X-ORACLE-LIST X-ORACLE-COMMENT X- 401 ORACLE-QUOTA X-ORACLE-PREF X-ORACLE-MOVE X-ORACLE-DELETE ACL X- 402 ORACLE-PASSWORD LDELIVER LZIP LCONVERT LFILTER LSETPREF LGETPREF 403 404 1b 405 2 OK CAPABILITY completed 406 408 Note however that the HTTP protocol is in general not meant to be 409 used in such a way. To maintain such an open channel might be a 410 practical challenge to proxies/firewalls, which might not forward the 411 requests chunk by chunk to the server, and meanwhile route responses 412 back to the client chunk by chunk. Consequently the session closes. 413 Chunked transfer encoding requests MAY not be honored by an HTTP 414 server. In cases where such requests are denied, the client should be 415 prepared to use the non-chunked encoding technique from section 2.1 417 The same challenges exist for TCP session. 419 In any case, the session can be automatically started again by the 420 client after a lost connection or by the server through out-of-band; 421 after some defined time-out. 423 2.1.3. Using HTTP Connect 425 If a HTTP proxy server is available to the client which supports the 426 HTTP CONNECT method, and the IMAP server the user wishes to reach 427 allows external connections outside the destination network�s 428 firewall, the client may wish to tunnel a regular TCP connection 429 through the HTTP proxy. 431 See [LUOTONEN] or section 5.2 of [RFC2817] for a detailed 432 description of the technique. Note that HTTP Proxy servers may not 433 honor all CONNECT requests, and may in fact, limit CONNECT requests 434 to a small number of common ports, such as 80, 443, 8080, etc. It is 435 advised that networks wishing to allow their users to use this 436 feature allow clients within their network to CONNECT to ports 25, 437 143, 587, and 993. 439 2.1.4. Using HTTP as a binding for SMTP 441 All of the techniques described in sections 2.1, 2.2, and 2.3 may 442 be used for SMTP as well. The only difference between IMAP and SMTP 443 will be the HTTP URL used. Servers implementing the HTTP binding are 444 February 2006 446 expected to differentiate between IMAP and SMTP protocol bodies via 447 the URL. 449 2.2. 450 Syntactic Mapping Approaches 452 The following mappings shows how synthactic mapping approaches can be 453 used to map IMAP /SMTO over SOAP, REST, and WebDAV. 455 2.3. 456 Using SOAP (Web Services) as a binding for IMAP 458 The SOAP binding attempts to map IMAP commands to SOAP methods, and 459 IMAP data types and grammar (atoms, lists, et al) to document- 460 literals supplied as the soap body. This is essentially a tunneling 461 technique with a syntactic change. The following general encoding 462 rules are proposed: 464 - IMAP commands are translated into SOAP methods of the same name, 465 e.g. the �FETCH� command becomes the �FETCH� SOAP method name. (UID 466 FETCH is mapped to UID_FETCH). 467 - SOAP document literal style is used 468 - Terminals in the IMAP grammar which represent atoms become elements 469 (e.g. FLAGS becomes ). Flags are stripped of leading 470 backslash and uppercased. 471 - Non-terminals which are an ATOM followed by a single parameter are 472 represented as a non-empty element containing that parameter(e.g. 473 �CHARSET foo� becomes foo, or �SENTBEFORE date� 474 becomes date). 475 - Lists are represented as containing zero or more elements 476 (including other s) 477 - Unless otherwise defined, if a particular keyword is followed by 478 more than one value, each value is encoded as

value

as placed 479 as a child element. E.g. APPEND mailbox SP flaglist SP literal 480 becomes 481

mailbox

 482 - Continuation responses and requests are encapsulated as data 483 - Literals are encapsulated as text or binary 484 - Unsolicited responses are encapsulates as response 485 - The partial specifier is

offset.length

486 - The section specifier is
�
487 - A sequence set is wrapped as sequence-set 488 - The IMAP response is encoded in response 489 - Any responses which start with a number followed by an ATOM are 490 encoded as number 492 The following is an example encoding: 494 C: a1 FETCH 1:5,9 BODY[1.1.CONVERT(�TEXT/PLAIN�)]<1024.2048> 496 Becomes 497 February 2006 499 500 1:5,9 501 502
503

1.1.CONVERT(�TEXT/PLAIN�)

504
505

1024.2048

506 507 509 This would then be invoked on a Web Service via the SOAPMethodName 510 �FETCH�. The expected response would be zero or more elements 511 containing elements which encode the returned data. 513 These rules are by no means complete and exhaustive, and more 514 stringent encoding rules are needed to encompass the full range of 515 IMAP extended ABNF. The above rules are provided as a starting point. 517 SOAP by itself adds considerable overhead to requests, so it would 518 not be recommended without some form of compression or compact 519 encoding such as �Fast Web Services� (X.695 �ASN.1 Support for SOAP, 520 Web Services and the XML Information Set�)[X.695]. However, SOAP may 521 provide some benefits over raw HTTP for those who have existing 522 investments in SOAP infrastructure. 524 Usage of X.695 is optional. 526 As a final note, the above usage once again, assumes that the SOAP 527 server is not stateless and uses HTTP cookies to preserve IMAP 528 session state between requests. 530 Here�s an example session side by side with IMAP syntax(SOAP envelop 531 not shown): 533 C-SOAP:

username

password

534 C-IMAP: a1 LOGIN username password 536 S-SOAP: LOGIN Ok 537 S-IMAP: * OK LOGIN Ok 539 C-SOAP: 540 C-IMAP: a2 SELECT INBOX 542 S-SOAP: 543 544 545 546 548 February 2006 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 1234 569 570 571 0 572 573 574 575 12345678 576 577 578 579 581 S-IMAP: * FLAGS (\Answered \Draft \Flagged \Seen) 582 S-IMAP: * OK [PERMANENTFLAGS (\Answered \Draft \Flagged \Seen)] 583 S-IMAP: * 1234 EXISTS 584 S-IMAP: * 0 RECENT 585 S-IMAP: * Ok [UIDVALIDITY 12345678] 586 S-IMAP: a2 OK [READ-WRITE] 588 2.4. 589 REST Mapping 591 [REST] stands for Representation State Transfer, and is an 592 architectural style modeled on HTTP, which seeks to build 593 applications around the elements of HTTP�s design which are 594 attributed to its wide success and large scalability. 596 February 2006 598 The tunneling approach in section 2.1 violates REST principles 599 because it doesn�t model server state as resources and doesn�t seek 600 to use the underlying HTTP operations according to their true 601 semantics. 603 REST suggests that server resources should be modeled as, and 604 addressable as URLs, instead of as the result of the execution of 605 verbs. SOAP RPC seeks to model manipulation of resources as the 606 invocation of a method which returns the resource, such as 607 �executeFetch�, whereas REST seeks to model those resources via a 608 uniform interface (a URL), that can be manipulated via standard HTTP 609 commands. 611 To create a mapping of IMAP to RESTful HTTP, a discussion 612 entailing the description of what resources IMAP exports, what 613 uniform interface will be used to locate those resources, and what 614 representation will be used to exchange those resources (e.g.) must 615 be provided. 617 2.4.1. IMAP resources as REST resources and interface 619 An IMAP server primary consists of mailboxes and messages. A mailbox 620 contains a collection of messages, and a message contains message 621 contents. Both mailboxes and messages also have server specified 622 metadata attached, such as flags, annotations, etc 624 An Example REST interface to such data, might take the form of the 625 following examples: 627 http://imap.server.com/mailboxname/ 629 To refer to a mailbox resource, and 631 http://imap.server.com/mailboxname/messageuid 633 To refer to a message in a mailbox. 635 Metadata about a mailbox or message might be identified as 637 http://imap.server.com/mailboxname/annotations 639 or 641 http://imap.server.com/mailboxname/messageuid/flags 642 February 2006 644 Message body parts might be represented via a hierarchical URL 645 syntax, such as 647 http://imap.server.com/mailboxname/messageuid/body/1/2/3 648 (BODY[1.2.3]) 650 or with convert (BODY[1.2.3.CONVERT (�image/gif�..)] 652 http://imap.server.com/mailboxname/messageuid/body/1/2/3/convert/imag 653 e/gif 655 2.4.2. IMAP commands as HTTP commands on REST resources 657 REST generally views GET requests as idempotent or requests that do 658 not mutate a resource, PUT requests as storing a new resource at the 659 specified URL, DELETE as removing resources located by the URL, and 660 POST as potentially performing some server defined action on the 661 specified resource. 663 Given the above guidelines, IMAP commands such as FETCH (with 664 BODY.PEEK or BINARY.PEEK) would be considered as GET requests, 665 commands such as STORE and APPEND would be considered candidates for 666 PUT mapping, and commands such as EXPUNGE, CREATE, or RENAME might be 667 modeled as POST. 669 Commands which may return multiple resources (UID FETCH n-m,x-y) may 670 be modeled as a collection resource with a query, such as 672 http://imap.server.com/mailboxname/allmsgs?uids=n-m,x-y 674 An IMAP immediate delete of a single message can be carried out via 675 REST via a HTTP DELETE of the URL identifying that message. However, 676 an IMAP delete of several messages by marketing \Deleted, followed by 677 an expunge, would have to be carried out via several PUT requests to 678 set the flags on a particular message, followed by an EXPUNGE via 679 POST. 681 Because REST frowns on the use of PUT with query parameters, a multi- 682 update of several messages at once with the same flags, would either 683 require multiple PUTs (one per message), or a new POST URL which 684 takes a collection URL and performs the operation, such as 686 POST http://imap.server.com/mailboxname/storeflags?uids=n-m,x-y 687 (body of request indicating that \Deleted is the flag to be updated) 688 February 2006 690 2.4.3. Representation of transferred resources 692 REST does not dictate the usage of XML. Because of this, a REST 693 binding could in fact use IMAP responses for its syntax. A GET 694 request of http://imap.server.com/mailboxname/ for example, could act 695 as �FETCH 1:* UID� and return the untagged �* FETCH� responses from 696 server. 698 A GET request on a message resource could simply return RFC822 format 699 text, for example. 701 2.4.4. Challenges 703 The challenge of producing a REST binding for IMAP lies not in 704 mapping IMAP resources to HTTP URLs, but of allowing the client to 705 take advantage of efficient IMAP commands, such as fetching a subset 706 of data over a subset of a collection of messages (SEARCH and FETCH 707 commands) in a way that preserves the REST model as much as possible. 708 Also, mapping IMAP security, and IMAP extensions at this point, 709 remains a challenge and has to be done on a case by case basis. 711 Unlike the SOAP binding, which is a mere syntax transformation of 712 IMAP, producing REST notions of arbitrary IMAP extensions is an 713 unbounded scope of work. It may help however, to consider only the 714 set of extensions that MUST be implemented in Lemonade Profile Phase 715 2 as the candidates for mapping, and work from there. 717 2.5. 718 WebDAV Mapping 720 WebDAV models collections of resources with structured metadata in 721 XML form via a URL abstraction, with typical operations such 722 retrieval, copy, delete, move, and update. It is REST-like, with 723 additional semantics related to metadata. 725 WebDAV differs from REST in that it adds a more rigorous definition 726 of what request and response payloads are, specifically to manipulate 727 metadata properties, as well as defining the concept of a collection 728 of resources. WebDAV also adds new HTTP methods such as COPY and 729 MOVE. 731 Existing WebDAV mappings for IMAP already exist. Microsoft Outlook 732 contains such a mapping for HotMail, referred to as HTTPMail, which 733 treats IMAP mailboxes as WebDAV collections. 735 February 2006 737 The approach suggested here is similar, which is to model IMAP 738 mailboxes as WebDAV collections, with mailbox specific metadata 739 treated as WebDAV metadata properties about the resource (EXISTS, 740 UIDNEXT, etc). Messages within a mailbox are treated as resources 741 within a WebDAV collection. Message envelope and other metadata are 742 modeled as WebDAV properties attached to the resource. 744 Many IMAP commands can be mapped to WebDAV commands which manipulate 745 collections, however, due to differences in the underlying semantics 746 of WebDAV and the lack of some operations that exist in Lemonade 747 which do not in WebDAV, a sufficient mapping at this time is not 748 possible. 750 For example, IMAP APPEND can be mapped to WebDAV PUT, and IMAP STORE 751 can be mapped to WebDAV PROPPATCH, but Lemonade CATENATE cannot be 752 mapped to any WebDAV sequence, because WebDAV lacks the ability to 753 append to an existing resource (it can only overwrite it), and the 754 WebDAV COPY command cannot take multiple source arguments. IMAP 755 SEARCH can�t be mapped unless one takes into account the draft WebDAV 756 SEARCH command. 758 Moreover, WebDAV�s security model with respect to authorization 759 differs from IMAP further complicating a mapping, and IMAP extensions 760 like CONVERT would have to be mapped outside the bounds of the DAV 761 spec via HTTP POST. 763 As such, a strict WebDAV mapping would have to be a subset of 764 Lemonade Profile. Therefore, a complete mapping must combine the 765 approaches of REST using POST to map actions, and WebDAV for 766 resources for which a good mapping already exists. 768 3. 769 Security Considerations 771 HTTP binding has the same security requirements as IMAP when using an 772 in-response or inband connectivity mode. 774 The HTTPS protocol can be used to provide end-to-end security 776 Proxy-based implementations may still require payload encryption for 777 end-to-end security. 779 Caching is a concern. The client SHOULD use the HTTP Cache-Control 780 directive (no-cache, no-store, must-revalidate, or combinations 781 thereof) to inform proxy servers, origin servers, and client 782 libraries not to cache or store the HTTP response. To deal with HTTP 783 1.0 servers that may exist in the network, Pragma: no-cache should be 784 used as well. 786 February 2006 788 Attacks on HTTP sessions and the HTTP server may also be a concern, 789 since the HTTP server is maintaining an authenticated session to the 790 IMAP server on behalf of the user in most cases. 792 Firewall administrators wishing to block stealth deployments of HTTP 793 IMAP bindings may block HTTP requests with Content-Type 794 application/vnd.lemonade via an application level firewall. 796 4. 797 References 799 [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 800 draft-ietf-lemonade-profile-XX.txt, (work in progress). 802 [LUOTONEN] Luotonen, A., �Tunneling TCP based protocols through Web 803 proxy servers�, draft-luotonen-web-proxy-tunneling-01.txt, August 804 1998 806 [MEMAIL] Maes, S.H., �Lemonade and Mobile e-mail", draft-maes- 807 lemonade-mobile-email-xx.txt, (work in progress). 809 [NOTIFICATIONS] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. 810 and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., 811 Sohn S-M., Xiaohui F. and Lijun Z., "Server to Client 812 Notifications and Filtering", draft-ietf-lemonade-server-to- 813 client-notifications-xx.txt, (work in progress). 815 [OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document, 816 (Work in progress). http://www.openmobilealliance.org/ 818 [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, 819 (Work in progress). http://www.openmobilealliance.org/ 821 [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 822 Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn 823 S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP 824 Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in 825 progress). 827 [REST] Fielding, Roy Thomas. Architectural Styles and the Design of 828 Network-based Software Architectures. Doctoral dissertation, 829 University of California, Irvine, 2000. 831 [RFC2088] Myers, J. �IMAP non-synchronizing literals�, RFC2088, 832 January 1997 833 http://www.ietf.org/rfc/rfc2088 834 February 2006 836 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate 837 Requirement Levels", RFC 2119, March 1997. 838 http://www.ietf.org/rfc/rfc2119 840 [RFC2442] Freed, N. et al. "The Batch SMTP Media Type", RFC 2442, 841 November 1998. 842 http://www.ietf.org/rfc/rfc2442 844 [RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol -- 845 HTTP/1.1", RFC 2616, June 1999. 846 http://www.ietf.org/rfc/rfc2616 848 [RFC2817] Khare, R., �Upgrading to TLS Within HTTP/1.1�, RFC2817, May 849 2000 850 http://www.ietf.org/rfc/rfc2817.txt, May 2000 852 [RFC3205] Moore, K. �On the use of HTTP as a Substrate�, RFC 3205, 853 February 2002. 854 http://www.ietf.org/rfc/rfc3205 856 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 857 Version 4 rev1", RFC 3501, March 2003. 858 http://www.ietf.org/rfc/rfc3501 860 [X.695] X.695 �ASN.1 Support for SOAP, Web Services and the XML 861 Information Set�, ITU/ISO 862 http://java.sun.com/developer/technicalArticles/WebServices/fastWS 863 / 864 [WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S.R., and D. 865 Jensen, �HTTP Extensions for Distributed Authoring -- WEBDAV�, 866 RFC 2518, February 1999 867 . 868 5. 869 Future Work 871 TBD[1] Should an OPTIONS HTTP request be supported to allow a client 872 to probe HTTP binding capabilities, such as which protocol a given 873 URL is bound to, or whether chunking is supported? 875 [2] Should separate content types exist for IMAP and SMTP since the 876 entity body in the HTTP request is different? 878 [3] Standardizing the form of the URL for the binding may permit 879 firewall administrations to impose better filtering. 881 [4] Produce more rigorous rules for mapping IMAP and SMTP ABNF to 882 SOAP, REST, and DAV. 884 [5] Provide ways to declare supported bindings or select a binding. 886 February 2006 888 6. 889 Version History 891 Release 00 892 Initial release published in February 2006. Carried over from 893 draft-maes-lemonade-http-binding-04 and now made into a working group 894 document. Added REST and WebDAV binding discussion. Clarified HTTP 895 response codes. 897 Acknowledgments 899 The authors want to thank all who have contributed key insight and 900 extensively reviewed and discussed the concepts of HTTP Bindings and 901 its early introduction in P-IMAP [P-IMAP]. 903 Authors Addresses 905 Stephane H. Maes 906 Oracle Corporation 907 500 Oracle Parkway 908 M/S 4op634 909 Redwood Shores, CA 94065 910 USA 911 Phone: +1-650-607-6296 912 Email: stephane.maes@oracle.com 914 Ray Cromwell 915 Oracle Corporation 916 500 Oracle Parkway 917 Redwood Shores, CA 94065 918 USA 920 Nilo Mitra 921 Ericsson 922 Tel: +1 212-843-8451 923 Email: nilo.mitra@ericsson.com 925 Intellectual Property Statement 927 The IETF takes no position regarding the validity or scope of any 928 Intellectual Property Rights or other rights that might be claimed to 929 pertain to the implementation or use of the technology described in 930 this document or the extent to which any license under such rights 931 might or might not be available; nor does it represent that it has 932 made any independent effort to identify any such rights. Information 933 on the procedures with respect to rights in RFC documents can be 934 found in BCP 78 and BCP 79. 936 February 2006 938 Copies of IPR disclosures made to the IETF Secretariat and any 939 assurances of licenses to be made available, or the result of an 940 attempt made to obtain a general license or permission for the use of 941 such proprietary rights by implementers or users of this 942 specification can be obtained from the IETF on-line IPR repository at 943 http://www.ietf.org/ipr. 945 The IETF invites any interested party to bring to its attention any 946 copyrights, patents or patent applications, or other proprietary 947 rights that may cover technology that may be required to implement 948 this standard. Please address the information to the IETF at ietf- 949 ipr@ietf.org. 951 Disclaimer of Validity 953 This document and the information contained herein are provided on an 954 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 955 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 956 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 957 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 958 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 959 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 961 Copyright Statement 963 Copyright (C) The Internet Society (2006). This document is subject 964 to the rights, licenses and restrictions contained in BCP 78, and 965 except as set forth therein, the authors retain all their rights. 967 Acknowledgement 969 Funding for the RFC Editor function is currently provided by the 970 Internet Society.