The IESG has approved the following documents: - 'Internet Message Access Protocol (IMAP) - URLAUTH Extension ' <draft-ietf-lemonade-urlauth-08.txt> as a Proposed Standard - 'Message Submission BURL Extension ' <draft-ietf-lemonade-burl-04.txt> as a Proposed Standard - 'Internet Message Access Protocol (IMAP) CATENATE Extension ' <draft-ietf-lemonade-catenate-05.txt> as a Proposed Standard These documents are products of the Enhancements to Internet email to support diverse service environments Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-urlauth-08.txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-burl-04.txt http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-05.txt Technical Summary This set of documents meets the "Forward without Download" milestone of the Lemonade working group charter. The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server which may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message on to a new message without having to first download the data and then upload it back to the server. The URLAUTH extension to IMAP provides a means by which an IMAP client can use URIs carrying authorization to access limited message data on the IMAP server. These URIs, like a pawn ticket, can be redeemed by whoever presents them and carry no authentication information. The BURL specification extends the submission profile of SMTP by adding a new BURL command which can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. It is presumed that BURL will generally be used with IMAP URLAUTH style URIs. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. Working Group Summary Considerable debate and contributions in the last year lead to a WG decision to standardize this pull based mechanism instead of a push or a proxy based mechanism. There is now at least rough consensus in the working group on this approach. These documents have received considerable review in the WG. Note that the detailed description of how the two IMAP extensions and the SMTP Submitextension work together will be published in the draft-ietf-lemonade-profile-03.txt, which will be sent for WG last call in another month or so. Protocol Quality This document was reviewed for the IESG by Ted Hardie. The PROTO shepherd for this document is Glenn Parsons Note to RFC Editor In draft-ietf-lemonade-catenate, please update the text as below OLD: resp-text-code =/ toobig_response_code / badurl_response_code toobig_response_code = "TOOBIG" badurl_response_code = "BADURL" SP url-resp-text NEW: resp-text-code =/ toobig-response-code / badurl-response-code toobig-response-code = "TOOBIG" badurl-response-code = "BADURL" SP url-resp-text _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce