Subject: [lemonade] Please review IMAP/SMTP extensions included in Lemonade profile Phase 1

From: Alexey Melnikov <[email-masked]>
Date: Mon, 03 Oct 2005 12:48:39 +0100

As per discussion at Lemonade interim, Stephane and I would like to do 
the following changes to the Lemonade Profile Phase 1 document:

1). Add LITERAL+
2). Remove quick reconnect (as the document is not ready) and add 
CONDSTORE (quick synchronization).
3). Removed POSTADDRESS (was an open issue), as it depends on 
LIST-EXTENDED, which is not quite done yet.

Any objections to the change? Any additional changes?

Thanks,
Alexey

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

---

From: Dave Cridland <[email-masked]>
Date: Mon, 03 Oct 2005 14:05:55 +0100

On Mon Oct  3 12:48:39 2005, Alexey Melnikov wrote:
> As per discussion at Lemonade interim, Stephane and I would like to 
> do the following changes to the Lemonade Profile Phase 1 document:
> 
> 1). Add LITERAL+

I knew there was something else I meant to bring up.

IDLE isn't present in the list of extensions. Given the comments made 
at the meeting about long-lived connections being better for mobile 
devices, and transmission being very costly to the battery, this 
suggests that IDLE is likely a requirement.

Secondly, I think the examples need reworking such that the 
capability strings returned include all required extensions, and 
preferably no undefined ones (one example includes SCAN).

Examples:

A0051 (Page 6): Reviewed, appears fine to me. Note that explanatory 
paragraph following has mismatched parenthesis.

A0052 (Page 6/7):
a) Includes a Received and a Return-Path header, which seems unlikely
b) Has an extraneous SP after " in first URL string.
c) Format=flowed message C-T header has superfluous charset 
parameter, C-T-E is also superfluous.

A0053: I didn't know $Forwarded could be applied to a message for 
which only some parts had been forwarded. I'm not sure we should be 
trying to complicate the issue by referring to keywords which haven't 
yet been standardized, without any reference. In any case, this flag 
shouldn't be set until after the ESMTP transaction has been 
completed, IMHO.

A0054: This should use an EXPIRES - otherwise someone intercepting 
the ESMTP transaction traffic can resend the message to themselves.

ESMTP Transaction (Page 7/8): Should use TLS. Server should be 
lemonade compliant, supporting all mandatory to implement extensions.

b0002 (Page 11): I think this is being cut, but in any case, the 
capability strings include "SCAN", and do not include mandatory to 
implement Lemonade extensions.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Oct 2005 12:18:04 +0100

> paragraph following has mismatched parenthesis.

Fixed, thanks.

> a) Includes a Received and a Return-Path header, which seems unlikely

We are forwarding a received message.

> b) Has an extraneous SP after " in first URL string.

Fixed, thanks.

> c) Format=flowed message C-T header has superfluous charset parameter, 
> C-T-E is also superfluous.

I would rather not change the messages, as this would affect byte counts.

> which only some parts had been forwarded.

The example if effectively forwarding the whole message. Plus it adds a 
textual annotation to it.

> I'm not sure we should be trying to complicate the issue by referring 
> to keywords which haven't yet been standardized, without any reference.

This is easy to fix, if people want me to address the issue.
I can extract the relevant text from draft-melnikov-imap-keywords-03.txt 
and add it to Lemonade Profile, or publish as a separate document.

> In any case, this flag shouldn't be set until after the ESMTP 
> transaction has been completed, IMHO.

Fixed.

> A0054: This should use an EXPIRES - otherwise someone intercepting the 
> ESMTP transaction traffic can resend the message to themselves.

[I wish URLAUTH had an example that I could use ;-).] Done

---

From: Dave Cridland <[email-masked]>
Date: Thu, 06 Oct 2005 14:02:48 +0100

> We are forwarding a received message.
Sort of. You're forwarding an attachment of an existing message. 
Certainly my implementation wouldn't copy trace headers in this 
instance.

I think you'd need Resent-From, etc, if you're submitting a message 
with trace headers, and I'm dubious that using a Return-Path: 
pointing to Bob is correct in this case. Moreover, I think you risk 
confusing client implementors into thinking they should insert trace 
headers themselves.

And to *really* nitpick, I'm most impressed that Bob can forward a 
message two seconds before it's arrived. Now I know what future 
delivery really means... ;-)

> I would rather not change the messages, as this would affect byte 
I'm nitpicking, I know. Would this help?

[...] (TEXT {462}
I: + Ready for literal data
M: Message-ID: <[email-masked]>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <[email-masked]>
M: MIME-Version: 1.0
M: To: [email-masked]
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M:      boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M:
M: --------------030308070208000400050907
M: URL [...]

I've stripped out the trace headers, any redundant MIME parameters 
and headers, and removed the X- prefixed header. Don't ask me why it 
comes out only 62% of the size.

> The example if effectively forwarding the whole message. Plus it 
> adds a textual annotation to it.
> 
> 
I'm not quite sure I agree.

>> I'm not sure we should be trying to complicate the issue by 
>> referring to keywords which haven't yet been standardized, without 
>> any reference.
> 
> I can extract the relevant text from 
> draft-melnikov-imap-keywords-03.txt and add it to Lemonade Profile, 
> or publish as a separate document.
> 
> 
Entirely up to the panel - I use $Forwarded anyway, and I'm quite 
happy with it.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Oct 2005 15:57:28 +0100

> suggests that IDLE is likely a requirement.

IDLE is closely related to push notifications. I would rather postpone 
it till phase 2.

> Secondly, I think the examples need reworking such that the capability 
> strings returned include all required extensions, and preferably no 
> undefined ones (one example includes SCAN).

This is done now.

> lemonade compliant, supporting all mandatory to implement extensions.

Fixed as well.

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Fri, 14 Oct 2005 17:05:30 -0700 (Pacific Daylight Time)

On 2005-10-14/15:57 [+0100], [email-masked] [Alexey Melnikov] wrote:

> > > As per discussion at Lemonade interim, Stephane and I would like to do the
> > > following changes to the Lemonade Profile Phase 1 document:
> > > 
> > > 1). Add LITERAL+
> > IDLE isn't present in the list of extensions. Given the comments 
> > made at the meeting about long-lived connections being better for 
> > mobile devices, and transmission being very costly to the battery, 
> > this suggests that IDLE is likely a requirement.
> 

Push notifications as discussed so far can be both in-band and out of 
band.  IDLE can be one way to get server initiated notifications 
delivered to the MUA in-band.  I don't see a reason to exclude that for 
now from the Lemonade profile as it will allow for MUA to keep the 
mailbox in sync with the server without polling.  I would vote for 
keeping IDLE as part of a pahse 1 required extension.

-- 
_______________
Anil SRIVASTAVA
[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 16 Oct 2005 16:52:55 +0100

Dave Cridland wrote:

> Certainly my implementation wouldn't copy trace headers in this instance.

After rereading some bits on RFC 2822 I agree with you.

> with trace headers, and I'm dubious that using a Return-Path: pointing 
> to Bob is correct in this case. Moreover, I think you risk confusing 
> client implementors into thinking they should insert trace headers 
> themselves.

Yes, there is such danger.

> I've stripped out the trace headers, any redundant MIME parameters and 
> headers, and removed the X- prefixed header. Don't ask me why it comes 
> out only 62% of the size.

Ok, I've used your example.

>> The example if effectively forwarding the whole message. Plus it adds 
>> a textual annotation to it.
>

Forwarding is an UI operation and there is no requirements on how 
exactly it should be done. All clients I've seen allow to users to edit 
forwarded messages, including subject.

> Entirely up to the panel - I use $Forwarded anyway, and I'm quite 

Ok, this is another open issue I've added to the document.