Message Submission BURL Extension
draft-ietf-lemonade-burl-04

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    lemonade mailing list <lemonade@ietf.org>, 
    lemonade chair <lemonade-chairs@tools.ietf.org>
Subject: Protocol Action: 'Internet Message Access Protocol 
         (IMAP) CATENATE Extension' to Proposed Standard 

The IESG has approved the following documents:

- 'Internet Message Access Protocol (IMAP) - URLAUTH Extension '
   <draft-ietf-lemonade-urlauth-09.txt> as a Proposed Standard
- 'Message Submission BURL Extension '
   <draft-ietf-lemonade-burl-05.txt> as a Proposed Standard
- 'Internet Message Access Protocol (IMAP) CATENATE Extension '
   <draft-ietf-lemonade-catenate-06.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 Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-06.txt

Ballot Text

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

RFC Editor Note