Subject: Re: [lemonade] Profile WG last call

From: Randall Gellens <[email-masked]>
Date: Sun, 6 Nov 2005 16:57:37 -0800

(1) Editorial comment: I think it would be more clear to use
"U" instead of "M" in examples and figures to
represent the messaging User Agent.

(2) Editorial: In

The advent of client/server email using
the [RFC3501], [RFC2821] and

[RFC2476] protocols has changed what formerly were local
disk

operations to
become excessive and repetitive network data

transmissions.

Delete "excessive".

(3) Editorial: In

Lemonade "forward without
download" has the advantage of maintaining

one submission protocol, and thus avoids the risk of
having multiple

parallel and
possible divergent mechanisms for submission. The

I think "possible" should be
"possibly".

(4) I suggested changing the [RFC2476] reference to the update
which is in the RFC Editor's queue.  I don't recall anyone
disagreeing, but perhaps I missed it.  Is there a reason not
to?

(5) In "assembling them. [UIDPLUS] IMAP extension is used by
the client in ", add "The" before
"[UIDPLUS]".

(6) In example on page 6, "of the semantics and steps) -
this allows the MUA to create", you want a dash, not a hyphen,
and this is generally represented in ASCII as two hyphens, so make it
"of the semantics and steps) -- this allows the MUA to
create".

(7) Same example on page 6, "messages on the IMAP using new
data combined with one or more", add "server" after
"IMAP".

(8) Same example on page 6, "message part already present on
the IMAP server. ", change "part" to
"parts".

(9) Same comment as (6), but on page 7: "[BURL] for details
of the semantics and steps - this allows the MUA " should be
"[BURL] for details of the semantics and steps -- this allows the
MUA ".

(10) In 3.1. Pipelining, is it accurate to say that use of
pipelining reduces round-trips?  Certainly it avoids waiting
during round-trips.  Also, I don't think use of pipelining
reduces bandwidth usage, but it certainly reduces elapsed time and can
reduce traffic channel usage.

(11) In 3.3. Message size declaration, do we want to say that
clients SHOULD use message size declaration?  No point in sending
a message that the server will reject, especially given the bandwidth
and elapsed time usage to do so.

(12) In 4. Quick resynchronization, change "has occurred"
to "have occurred".

(13) In 7. Future work, change "Future phases of the
Lemonade profile are expected to address issues related to access of
email from mobile devices, possibly including" to "Ongoing
work within the lemonade wg is looking into additional issues related
to access of email from mobile devices, possibly
including:"

(14) in 8.2 TLS, change "When LEMONADE clients uses the BURL
extension to mail Submission" to "When LEMONADE clients use
the BURL extension to mail submission" (make "use"
agree with "clients" and don't capitalize
"submission").

(15)  Also in 8.2, change "LEMONADE Compliant mail
submission server SHOULD use TLS protected" to "LEMONADE
compliant mail submission servers SHOULD use TLS protected"
(don't capitalize "compliant", and make "server"
plural).

(16) Also in 8.2, in:

When a
client uses SMTP STARTTLS to send a BURL command which

references non-public information there is a user
expectation that

the entire message content will be treated
confidentially.  To

address this expectation, the message submission server
should use

STARTTLS or a mechanism providing equivalent data
confidentiality

when fetching the content referenced by that URL.

(a) add a comma after "references non-public
information"

(b) change "address" to "meet".

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly-selected tag: ---------------

A child of five would understand this.  Send somebody to

fetch a child of five.        --Groucho Marx, _Duck Soup_

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Nov 2005 21:20:44 +0000

Ok, I've addressed all editorial changes listed below.

Randall Gellens wrote:

> (2) Editorial: In
>         The advent of client/server email using the [RFC3501], 
> [RFC2821] and
>    [RFC2476] protocols has changed what formerly were local disk
>    operations to become excessive and repetitive network data
>    transmissions. 
> Delete "excessive".

> (3) Editorial: In
>         Lemonade "forward without download" has the advantage of 
> maintaining
>    one submission protocol, and thus avoids the risk of having multiple
>    parallel and possible divergent mechanisms for submission. The
> I think "possible" should be "possibly".

> (5) In "assembling them. [UIDPLUS] IMAP extension is used by the 
> client in ", add "The" before "[UIDPLUS]".

> (6) In example on page 6, "of the semantics and steps) - this allows 
> the MUA to create", you want a dash, not a hyphen, and this is 
> generally represented in ASCII as two hyphens, so make it "of the 
> semantics and steps) -- this allows the MUA to create".

> (7) Same example on page 6, "messages on the IMAP using new data 
> combined with one or more", add "server" after "IMAP".

> (8) Same example on page 6, "message part already present on the IMAP 
> server. ", change "part" to "parts".

> (9) Same comment as (6), but on page 7: "[BURL] for details of the 
> semantics and steps - this allows the MUA " should be "[BURL] for 
> details of the semantics and steps -- this allows the MUA ".

> (12) In 4. Quick resynchronization, change "has occurred" to "have 
> occurred".

> (14) in 8.2 TLS, change "When LEMONADE clients uses the BURL extension 
> to mail Submission" to "When LEMONADE clients use the BURL extension 
> to mail submission" (make "use" agree with "clients" and don't 
> capitalize "submission").

> (15)  Also in 8.2, change "LEMONADE Compliant mail submission server 
> SHOULD use TLS protected" to "LEMONADE compliant mail submission 
> servers SHOULD use TLS protected" (don't capitalize "compliant", and 
> make "server" plural).

> (16) Also in 8.2, in:
>         When a client uses SMTP STARTTLS to send a BURL command which
>    references non-public information there is a user expectation that
>    the entire message content will be treated confidentially.  To
>    address this expectation, the message submission server should use
>    STARTTLS or a mechanism providing equivalent data confidentiality
> (a) add a comma after "references non-public information"
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Nov 2005 17:34:48 +0000

Randy, thank you for the comments.

Randall Gellens wrote:

> (1) Editorial comment: I think it would be more clear to use "U" 
> instead of "M" in examples and figures to represent the messaging User 
> Agent.

I would rather not mess with the document at this stage.

> (4) I suggested changing the [RFC2476] reference to the update which 
> is in the RFC Editor's queue.  I don't recall anyone disagreeing, but 
> perhaps I missed it.  Is there a reason not to?

Sure.

> (10) In 3.1. Pipelining, is it accurate to say that use of pipelining 
> reduces round-trips?  Certainly it avoids waiting during round-trips.  
> Also, I don't think use of pipelining reduces bandwidth usage, but it 
> certainly reduces elapsed time and can reduce traffic channel usage.

IMHO, use of pipelining can potentially save some bandwidth at TCP 
level, i.e. there are less TCP packets to be sent.

> (11) In 3.3. Message size declaration, do we want to say that clients 
> SHOULD use message size declaration?  No point in sending a message 
> that the server will reject, especially given the bandwidth and 
> elapsed time usage to do so.

Good point. Our MTA already does that.
I've added:

A LEMONADE compliant client SHOULD use message size declaration. In 
particular it SHOULD NOT send a message to a mail submission server, if 
the client knows that the message exceeds the maximal message size 
advertised by the submission server.

Alexey