Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-04.txt

From: [email-masked]
Date: Fri, 20 Oct 2006 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Enhancements to Internet email to Support Diverse Service Environments Working Group of the IETF.

	Title		: LEMONADE profile bis
	Author(s)	: S. Maes, et al.
	Filename	: draft-ietf-lemonade-profile-bis-04.txt
	Pages		: 39
	Date		: 2006-10-20
	
This document describes the LEMONADE profile.  It contains pointers
   to or descriptions of all the features that are normatively part of
   this version of the LEMONADE profile.

   This document describes a profile (a set of required extensions,
   restrictions and usage modes) of the IMAP and mail submission
   protocols.  This profile allows clients (especially those that are
   constrained in memory, bandwidth, processing power, or other areas)
   to efficiently use IMAP and Submission to access and submit mail.
   This includes the ability to forward received mail without needing to
   download and upload the mail, to optimize submission and to
   efficiently resynchronize in case of loss of connectivity with the
   server.

   The Lemonade profile relies upon extensions to IMAP and Mail
   Submission protocols; specifically URLAUTH and CATENATE IMAP protocol
   extensions and BURL extension to the SUBMIT protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-lemonade-profile-bis-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-profile-bis-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Mon, 23 Oct 2006 18:03:44 -0700

A few comments on this version:

----------------------------------------
(1) Please explicitly state that servers MUST support [message 
submission] on port 587.  Also, Lemonade clients MUST use port 587 by 
default.  (I proposed this on the list back in March and saw some 
agreement and no disagreement.)  The current document says that it 
"assumes RFC 4409" but I think it would be helpful to be more clear 
about this.

----------------------------------------
(2) In Section "4.  Message Submission", please add "more" to the 
text "to make message submission efficient", that is, "more 
efficient".

----------------------------------------
(3) In Section "4.3.  Message size declaration", the text:
    LEMONADE compliant mail submission servers MUST resolve all BURL
    parts before enforcing a message size limit.

Requires the servers to expand all BURL parts, even if the message 
already exceeds the message size limit.  A while back I suggested 
saying "Servers MUST NOT consider a message's size to be acceptable 
if it has not expanded all BURL parts."  I'm not wedded to that 
phrasing, but I do think we should allow servers to reject messages 
before expanding everything.

----------------------------------------
(4) Section 6.  Additional requirements on MUAs
    LEMONADE capable clients that can reply to existing messages MUST
    support the Format and DelSp parameters to text/plain media type
    [RFC3676]

A display-only client can still usefully support (and benefit from 
supporting) format=flowed, so I suggest deleting "that can reply to 
existing messages".  Also, a typo: "to text/plain" should be "to the 
text/plain".

----------------------------------------
(5) Section "8.  OMA MEM Requirement document"

    The OMA MEM activity has collected a set of use cases and derived
    requirements for a mobile email enabler (MEM). the resulting work is
s/the/The/

    summarized in OMA MEM Requirement document [MEM-req].  Some
    requirements relates to email protocols, some involve other OMA
s/relates/relate/

----------------------------------------
(6) In Section "8.3.  OMA MEM proxy", please delete the last part of 
the sentence after "deployed":

    The OMA MEM Architecture document [MEM-arch] identifies OMA MEM
    server proxies as server components that may be deployed ahead of
    firewalls to facilitate traversal of firewalls.

Why a proxy is deployed is not the issue.  Furthermore, IMAP and 
Message Submission do traverse firewalls just fine without a proxy.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
If God lived on Earth, people would knock out all His windows.
                                             --Yiddish saying

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Oct 2006 19:53:02 +0100

> A few comments on this version:

Tell me which section should say that.

> (2) In Section "4.  Message Submission", please add "more" to the text 
> "to make message submission efficient", that is, "more efficient".

Done.

> saying "Servers MUST NOT consider a message's size to be acceptable if 
> it has not expanded all BURL parts."  I'm not wedded to that phrasing, 
> but I do think we should allow servers to reject messages before 
> expanding everything.

I am not exactly happy with your replacement text, this might be too 
subtle for people to notice. I need to think about better alternatives.

> existing messages".

Done.

> Also, a typo: "to text/plain" should be "to the text/plain".

Fixed.

Both fixed.

Done.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 30 Oct 2006 14:06:16 -0800

At 7:53 PM +0100 10/25/06, Alexey Melnikov wrote:

>> submission] on port 587.  Also, Lemonade clients MUST use port 587 
>> by default.  (I proposed this on the list back in March and saw 
>> some agreement and no disagreement.)  The current document says 
>> that it "assumes RFC 4409" but I think it would be helpful to be 
>> more clear about this.
>

I was thinking either a short new paragraph at the end of either 
Section 3.5 "Normative statements related to forward without 
download", or, if you prefer, Section 6 "Additional requirements on 
MUAs".

>> saying "Servers MUST NOT consider a message's size to be 
>> acceptable if it has not expanded all BURL parts."  I'm not wedded 
>> to that phrasing, but I do think we should allow servers to reject 
>> messages before expanding everything.
>
>  I am not exactly happy with your replacement text, this might be 
> too subtle for people to notice. I need to think about better 
> alternatives.

If you'd like to make the situation very explicit and clear, how about:

Interoperability problems and user confusion would result from 
submission servers accepting a message with a 2xx result code, and 
then, after expanding BURL parts, determining that the final size of 
the message is too large.  In such cases, the submission server would 
then generate an DSN bounce, which the client would need to receive 
and process during some subsequent mail check.  Correct matching of 
the DSN to the original message is difficult, subject to 
unpredictable delay, and much user annoyance.  If the bounce contains 
the expanded BURL parts, it's size could make it difficult for the 
client to receive it.  Therefore, servers MUST NOT consider a 
message's size to be acceptable before all of its BURL parts have not 
been expanded.  Servers MAY reject a message as being too large 
before expanding all BURL parts, and it is RECOMMENDED that servers 
check the message's size after expanding each BURL, to guard against 
denial of service attacks.

-------------- Randomly-selected tag: ---------------
If you lend someone $20, and never see that person again,
it was probably worth it.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 30 Oct 2006 15:09:15 -0800

>  the bounce contains the expanded BURL parts, it's size could make 
> it difficult for the client to receive it.

s/it's/its/

-------------- Randomly-selected tag: ---------------
Democracy is also a form of worship.
It is the worship of Jackals by Jackasses.
                          --H. L. Mencken

---

From: <[email-masked]>
Date: Tue, 31 Oct 2006 15:28:01 +0200

>acceptable if 
>I am not exactly happy with your replacement text, this might 
>be too subtle for people to notice. I need to think about 
>better alternatives.
I would prefer writing it down as well. I am not sure how to put it
though. Here is another attempt:
LEMONADE compliant mail submission servers MUST resolve all BURL parts
before enforcing a message size limit and MUST NOT reject email messages
where the total size of the email message reassembled from BURL parts is
smaller than the message size limit.

---

From: <[email-masked]>
Date: Tue, 31 Oct 2006 16:32:23 +0200

>submission] on port 587.  Also, Lemonade clients MUST use port 
>587 by default.  (I proposed this on the list back in March 
>and saw some agreement and no disagreement.)  The current 
>document says that it "assumes RFC 4409" but I think it would 
>be helpful to be more clear about this.
>
I saw the port number stated in the deployment draft, section 3 - as
MUSTs.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 31 Oct 2006 11:22:48 -0800

Hi Zoltan,

>  smaller than the message size limit.

The problem with that text is that the first sentence is identical to 
the original text and thus doesn't fix the flaw that I discuss (see 
the quoted text from me, above).  The new suggested text I sent in 
yesterday does fix it and also addresses Alexey's concerns.  Also, 
the second sentence in your text doesn't permit servers to reject 
messages for any reason other than size, which I'm sure isn't your 
intent :-)

-------------- Randomly-selected tag: ---------------
I make a fortune from criticizing the policy of the government, and
then hand it over to the government in taxes to keep it going.
                                              --George Bernard Shaw