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

From: Randall Gellens <[email-masked]>
Date: Thu, 5 Jan 2006 15:26:08 -0800

At 12:52 PM +0300 12/30/05, Alexey Melnikov wrote:

>  Randall Gellens wrote:
>
>>  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),
>>
>  Corrected, thanks.
>
>>  and is incorrect since the next line shows the submission server 
>> 'S' replying to the messaging client 'M'.
>>
>  In both cases the text should read:
>  <> S: {to M} Submission server assembles the complete message and 
> if the assembly succeeds it acknowledges acceptance of the message 
> by sending 250 response to the last BDAT command:

I think the text needs to be slightly different in the two cases, 
since in one case only BURL is used, while in the second, both BURL 
and BDAT are used.

>
>>  (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.

Was this suggested change OK?

>>
>>
>>  (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).

Was this suggested change OK?

>>
>>
>>  (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?
>>
>  The BURL document says that if SMTP BURL keyword has no parameters, 
> then authentication/TLS is required to use BURL.
>  If you check the example, the response to the third EHLO contains 
> "BURL imap".

Indeed so.  Plus you have text that says "The third EHLO command is 
required if and only if the second EHLO response doesn't list any 
BURL options."  I apologize -- somehow it didn't register when I was 
looking at the example.

>
>  I understand that this can be easily overlooked. Any suggestions 
> how to make this clearer?

All I can think of offhand would be to break the example into three 
sections (one for each EHLO) and include a sentence or two before 
each section explaining it.  But that might be overkill.

>>  (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".
>>
>  Done: (5) and (6)
>
>>  (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.
>>
>  Done (I've dropped the last "enforcement").

Indeed that's better still.

>
>>  (8) In section 5, "without the need for constant polling for 
>> changes" might be better worded as "without needing to poll for 
>> changes".
>>
>  Changed.
>
>>  (9) In section 6, perhaps delete 'an' from table headings 'Name of 
>> an SMTP extension' and 'Name of an IMAP extension or feature'.
>>
>  Changed.
>
>>  Maybe change 'Comment' to 'Source' in the second column table heading.
>>
>  Some extensions have comments like "required by RFC XXXX". So I 
> would rather leave this as is.

I think 'Source' is correct in both cases, as it is the source of the 
requirement.  This is much more than a comment.

>
>>  (10) In section 7, 'access of email from' might be better as 
>> 'usage of email by',
>>
>  Changed.
>
>>  to include both submission and retrieval.
>>
>  I am not sure I understand the last part.

I just meant that changing the wording from 'access of email from' to 
'usage of email by' is better because the new wording ('access') 
includes both submission and retrieval, while the old wording 
('access') implies retrieval only.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Green light in A.M. for new projects.  Red light in P.M. for traffic
tickets.

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 28 Dec 2005 15:37:16 -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.

      S2: {to M} OK (2XX)

      S2: {to M} OK (2XX)

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:

to:

as:

(4) Section 2.5 states:
    BURL MUST support

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".

    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'.

-------------- Randomly-selected tag: ---------------
Procedures!  Of course, that's what you'd use with a *sophisticated*
machine like this.  Procedures.    --'Ceaser Smith' in _Hot_Millions_

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Jan 2006 13:02:31 +0000

Randall Gellens wrote:

>>> needed, is confusing (since 'S2' is not mentioned in the Conventions),
>>
>>  Corrected, thanks.
>>
>>  S: {to M} Submission server assembles the complete message and if 
>> the assembly succeeds it acknowledges acceptance of the message by 
>> sending 250 response to the last BDAT command:
>
>

Yes, the text is actually different to reflect that.

> Was this suggested change OK?

Yes, the document was updated.

> Was this suggested change OK? 

Yes.

> required if and only if the second EHLO response doesn't list any BURL 
> options."  I apologize -- somehow it didn't register when I was 
> looking at the example.
>
>>  I understand that this can be easily overlooked. Any suggestions how 
>> to make this clearer?
>
> sections (one for each EHLO) and include a sentence or two before each 
> section explaining it.  But that might be overkill.

I think it would be overkill as well. An attentive reader will come to 
the proper conclusion.

> requirement.  This is much more than a comment. 

I don't feel strongly about this.

>>> of email by',

Ah, Ok.

Alexey