Subject: [lemonade] Last Call: 'Lemonade Profile' to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 15 Dec 2005 22:19:21 -0500

The IESG has received a request from the Enhancements to Internet email to 
support diverse service environments WG to consider the following document:

- 'Lemonade Profile '
   <draft-ietf-lemonade-profile-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-01-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-06.txt

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Randall Gellens <[email-masked]>
Date: Thu, 29 Dec 2005 09:39:31 -0800

The draft is in good shape and ready to advance.  I do have a few 
comments, all but one of which are editorial.  I want to thank the 
editors for all their hard work in preparing this draft -- I really 
appreciate it.

(1a) In section 2.4.1, the example includes:

      S2: {to M} OK (2XX)

      Submission server returns OK to the MUA:
         S: 250 2.5.0 Ok.

(1b) In Section 2.4.2, the example includes:

      S2: {to M} OK (2XX)

      Submission server acknowledges acceptance of the message by sending
      250 response to the last BDAT command:
         S: 250 2.5.0 Ok, message accepted.

In both cases, I think the line 'S2: {to M} OK (2XX)' is not needed, 
is confusing (since 'S2' is not mentioned in the Conventions), and is 
incorrect since the next line shows the submission server 'S' 
replying to the messaging client 'M'.

(2) I think the first paragraph of 2.4.2 reads poorly, and I suggest 
changing it from:

    In the [BURL]/[CHUNKING] variant of the Lemonade "forward without
    download" strategy, messages are initially composed and edited within
    an MUA.  The BURL [BURL] and BDAT [CHINKING] commands are then used
    to create the messages from multiple parts during submission
    [RFC2476], existing body parts are referenced using [URLAUTH] format
    URLs.

to:

    In the [BURL]/[CHUNKING] variant of the Lemonade "forward without
    download" strategy, messages are initially composed and edited within
    an MUA.  During submission [RFC2476], BURL [BURL] and BDAT [CHINKING]
     commands are used
    to create the messages from multiple parts.  New body parts are 
supplied using
     BDAT commands, while existing body parts are referenced using 
[URLAUTH] format
    URLs in BURL commands.

(3) Also in 2.4.2, I'd suggest rewording the sentence:

     It uses BURL to let the SMTP submit
      server fetch pieces of the message to be sent from the IMAP server
      (See [BURL] for details of the semantics and steps).

as:

     It uses BURL to instruct the SMTP submit
      server to fetch from the IMAP server pieces of the message to be sent
      (See [BURL] for details of the semantics and steps).

(4) Section 2.5 states:
    BURL MUST support
    URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap"
    option following the BURL EHLO keyword.

Is this in conflict with the example in section 2.4.2 showing the 
client connecting to a submission server that doesn't announce 'imap' 
as part of its BURL support?

Personally, I like seeing the example, and the requirement is 
reasonable.  But it can be a bit confusing to read the requirement 
after seeing the example.

(5) In section 2.7, I suggest changing 'one or more COPY command' to 
'one or more COPY commands' (make 'command' plural).

(6) In section 2.8, I think ' $Forwarded IMAP keyword' should be 'The 
$Forwarded IMAP keyword".

(7) In section 3.3, I think:

    Note a LEMONADE compliant mail submission server must perform message
    size limit enforcement after performing "expansion" of all BURL
    parts.

Perhaps should be changed to:

    LEMONADE compliant mail submission servers MUST resolve ("expand") all BURL
    parts before enforcing a message size limit enforcement.

(8) In section 5, "without the need for constant polling for changes" 
might be better worded as "without needing to poll for changes".

(9) In section 6, perhaps delete 'an' from table headings 'Name of an 
SMTP extension' and 'Name of an IMAP extension or feature'.  Maybe 
change 'Comment' to 'Source' in the second column table heading.

(10) In section 7, 'access of email from' might be better as 'usage 
of email by', to include both submission and retrieval.

(11) In section 8.2, I suggest changing 'a replay attack that will 
disclose' to 'a replay attack that may disclose', since it is not 
certain that a reply attack will disclose the contents.

(12) Also in section 8.2, I think you should make 'connection' plural 
in 'submission servers SHOULD use TLS protected IMAP connection'.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Procedures!  Of course, that's what you'd use with a *sophisticated*
machine like this.  Procedures.    --'Ceaser Smith' in _Hot_Millions_