Subject: [lemonade] Profile extensions "under discussion"

From: Dave Cridland <[email-masked]>
Date: Fri, 19 May 2006 17:42:15 +0100

I'm going to unilaterally make some reversible decisions on the list 
of "Under discussion" extensions presented in IETF65 (Stéphane's 
slides, page 5).

1) CLEARIDLE

Dropped. I'm addressing the comment that "RFC2177 is vague on the 
exact semantics [etc]" by including some language that mandates 
unsolicited FETCH, RECENT, and EXISTS responses are sent to idling 
clients in a "timely fashion" when changes occur to the mailbox. This 
is vague, but hopefully encourages implementors to consider internal 
signalling, or relatively frequent polling.

2) CLEARIDLE+QUICKRECONNECT

Dropped. If I recall, this was a resynchronization protocol based 
around the concept of serial numbered synchronization points. I 
believe resynchronization of this nature is adequately covered by 
CONDSTORE and RECONNECT.

3) Sieve notify

Suspended: This is notification-related, and I'm ignoring 
notifications for the purposes of Profile Bis until I actually 
understand the consensus of the group.

4) "SMTP extensions by Tony Finch"

Suspended: I think there was a general consensus that some of these 
proposals were wanted, but lacked polish. Until they're at least 
submitted as drafts, I'll leave them out.

5) "Dave's 'headers from envelope' SMTP extension"

Dropped: Actually this was Chris's suggestion in response to Tony's 
envelope-from-headers suggestion, and I merely wrote it up. I believe 
this would be counter-productive to advance, since there are similar 
proposals in EAI, I believe. Unfortunately, those are experimental, 
so we can't mandate them. (Otherwise I probably would).

6) TLS compression / Deflate etc.

Included Everything: I don't feel there is any clear consensus on 
compression. My working copy currently has a section on compression 
in IMAP which includes two alternate paragraphs for LZIP and 
COMPRESS=DEFLATE.

7) XENCRYPTED

Dropped: The uncomfortable shifting in chairs came across even over 
Jabber, but I generally got the feeling that XENCRYPTED was 
considered by a substantial majority to be outright dangerous, and/or 
self-defeating. At least until our security advisor finishes the 
review of the mechanism, I'll leave it out.

8) Proxy / firewalls

Informative: I'll include the document as an informative reference.

If people disagree with these decisions, I shall be delighted to 
await the forming of consensus and document it accordingly. :-)

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

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 24 May 2006 18:44:49 -0700

> in IMAP which includes two alternate paragraphs for LZIP and 

My sense was that Ned and several others made compelling arguments 
that we should go with something like DEFLATE, and that there was no 
benefit to per-object client control, since there were no cases where 
a client capable of decompression would not want it when the server 
thought an object would benefit from it.  Therefore DEFLATE 
controlled by a single command from the client that says "compress at 
will".

>  Informative: I'll include the document as an informative reference.

Which document?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Police Begin Campaign to Run Down Jaywalkers
--Newspaper headline

off planet.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 24 May 2006 18:44:49 -0700

Which document?

---

From: Dave Cridland <[email-masked]>
Date: Thu, 25 May 2006 08:58:13 +0100

On Thu May 25 02:44:49 2006, Randall Gellens wrote:
>> compression. My working copy currently has a section on 
>> compression in IMAP which includes two alternate paragraphs for 
>> LZIP and COMPRESS=DEFLATE.
> 
> that we should go with something like DEFLATE, and that there was 
> no benefit to per-object client control, since there were no cases 
> where a client capable of decompression would not want it when the 
> server thought an object would benefit from it.  Therefore DEFLATE 
> controlled by a single command from the client that says "compress 
> at will".
> 
> 
That was my thought too, but the minutes (which include an Action for 
Pete to summarize the positions to "sharpen consensus"), and the 
slides from Lemonade Day 2 of IETF65, don't seem to quite indicate 
that.

>>  Informative: I'll include the document as an informative 

Firewall traversal using HTTP.

Deployments is currently referenced, too.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 25 May 2006 14:48:46 +0100

Dave Cridland wrote:

> slides from Lemonade Day 2 of IETF65, don't seem to quite indicate that.

I was sitting in the room in Dallas when the discussion took place and I 
don't remember any clear consensus on the issue.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 25 May 2006 10:26:15 -0700

>  Deployments is currently referenced, too.

Are we doing both?  What is the status of the HTTP one?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Chance that an American cannot name a single right protected by the
First Amendment: 1 in 3.                           (Harper's Index)

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 28 May 2006 19:11:04 +0100

> signalling, or relatively frequent polling.

Barry is doing update to RFC 2177 (draft-leiba-imap-2177bis-xx.txt) 
which should reinforce that any untagged response is allowed at any 
time. Let him know if any other clarifications are needed.

CLEARIDLE included a section listing event types and how they should be 
reported to the client (e.g. mailbox deletion, renaming, new or expunged 
messages in a non-selected mailbox). I think some sort of standard in 
this area would be valuable.
I also think that for multimailbox notifications it is important for the 
client to have some kind of control over events which get send, 
otherwise poor client can get flooded with notifications it doesn't care 
about.

Alexey

---

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 30 May 2006 20:54:29 -0700

Yes I do not believe that his si what we have decided...

Note however the proposal to dea with this in draft-ietf-lemonade-convert-03.

Thanks

Stephane 

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google)

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 12:58 AM
To: Randall Gellens
Cc: Enhancements to Internet email to support diverse service enivronments
Subject: Re: [lemonade] Profile extensions "under discussion"

On Thu May 25 02:44:49 2006, Randall Gellens wrote:
> thought an object would benefit from it.  Therefore DEFLATE controlled 
> by a single command from the client that says "compress at will".
>
>
That was my thought too, but the minutes (which include an Action for Pete to summarize the positions to "sharpen consensus"), and the slides from Lemonade Day 2 of IETF65, don't seem to quite indicate that.

Dave.

---

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 30 May 2006 20:54:58 -0700

----

This has become Lemonade in TCP Challenged Environment as in draft-maes-lemonade-tcp-challenged-environments-00.

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: Dave Cridland [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 12:58 AM
To: 'Randall Gellens'
Cc: 'Enhancements to Internet email to support diverse service enivronments'
Subject: Re: [lemonade] Profile extensions "under discussion"

Dave.