Subject: RE: [lemonade] Profile WG last call

From: [email-masked]
Date: Wed, 26 Oct 2005 06:42:44 -0400

IDLE works really well for wired and WLAN terminals, so IDLE is still
something we want.
IDLE would be a great first step, but we need to keep in mind that we
will want to offer alternate signalign methods for low-resource devices.
One option is to allow OMA/3GPP networks to define their own signaling
methods from a border controller or signaling server.
We discussed this before and SIEVE seems to be taking this into account.
Make the signal transport generic and allow border controllers to select
the appropriate transport for the network.

Corby Wilson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Arnt Gulbrandsen
> Sent: Wednesday, October 26, 2005 03:44 AM
> To: [email-masked]
> Subject: Re: [lemonade] Profile WG last call
> 
> So if I understand this correctly, there aren't actually any 
> arguments 
> against IDLE as such. It's just that it's less use than on real 
> networks, because a lot of networks discard TCP connections 
> after some 
> idleness, and keepalives cannot be used.
> 
> Two specific comments:
> 
> [email-masked] writes:
> > The best success we have had is by using app level pings 
> (some random 
> > data packet that is discarded) from the server to the client which 
> > keeps the conneciton up.
> 
> This should be similar to TLS keepalives. (IIRC a TLS 
> keepalive is just 
> a packet with zero bytes plaintext and 16 bytes padding, all 
> encrypted 
> and sent to the peer.)
> 
> > Sugestions are very wellcome here. At this point, battery 
> life is at a 
> > permium and people will turn off their email application to prevent 
> > battery drain so they can continue to make/receive calls.
> 
> Will carriers configure their networks to permit 
> longer-lasting idleness 
> so customers can use email effectively?
> 
> The issue isn't specific to IDLE. IDLE makes it show up 
> clearly, but so 
> does a complex SEARCH on a big mailbox. And of course IMAP permits a 
> client to leave the connection idle without issuing IDLE. I think 
> LEMONADE will eventually have to specify something like 
> "carrier cannot 
> discard TCP connections until at least x minutes have passed" 
> or refer 
> to the autlogout part of 3501.
> 
> Arnt
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> 

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

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 28 Oct 2005 09:37:54 -0500

I see my confusion on the RFC2034 reference.  I was expecting a reference to 3463, "Enhanced Mail System Status Codes".  However, because  RFC2034 depends upon it we are covered.
 
I did not see responses from you or Stephane on the balance of my comments.
 
Greg V.

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 28 Oct 2005 15:40:17 -0500

I have overlooked this omission in London.  I had expected to see IMAP binary as an essential part of the profile, especially since we do not specify compression in Phase-1 of the profile.

I support adding IMAP binary into phase-1.  It is a stable reference, the primary criteria we adopted.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Dave Cridland
Sent: Friday, October 28, 2005 2:50 PM
To: [email-masked]
Subject: Re: [lemonade] Profile WG last call

On Tue Oct 25 16:22:13 2005, Glenn Parsons wrote:
> Please review this document paying special attention to:
>  - the list of MUST implement features
>    (note the editors suggest adding IDLE and $forward to the     
> baseline we agreed in London)

I was going to raise an issue about quality of implementation with 
IMAP BINARY, but then noticed that the IMAP BINARY extension isn't 
actually part of the profile at all.

Given that, for base64 encoded message parts, it represents a saving 
of 25%, I think it should be. Many IMAP servers already implement it, 
and although the base64 growth is somewhat mitigated by some form of 
compression, transmission in binary is going to be better. 
With gzip, for instance, a 145k JPEG compresses to 144k, but encoded 
in base64 is 196k, which compresses to 148k. Comparing gzip with 
BINARY, then, the phone has had to transmit an extra 3k of data, 
which has been encoded twice instead of not at all, presumably a 
waste of CPU resources.

My point was going to be that since one of the more bandwidth-saving 
uses of BINARY in Lemonade is likely to be in sending images from 
camera phones, we need to additionally mandate that APPEND with 
binary content MUST be implemented - some implementations only 
support FETCH ... BINARY, and issue a NO [UNKNOWN-CTE] if they see 
binary content being uploaded.

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