From lemonade-bounces@ietf.org Mon Jul 03 08:46:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxNog-0000XZ-Oy; Mon, 03 Jul 2006 08:46:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxNoe-0000XR-V5; Mon, 03 Jul 2006 08:46:16 -0400
Received: from ihemail2.lucent.com ([192.11.222.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxNoe-0008VP-Jg; Mon, 03 Jul 2006 08:46:16 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com
	[135.1.23.83])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k63CkF4P024170; 
	Mon, 3 Jul 2006 07:46:15 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service
	(5.5.2657.72) id <N5R5SAVP>; Mon, 3 Jul 2006 07:46:15 -0500
Message-ID: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Lemonade@ietf.org
Date: Mon, 3 Jul 2006 07:46:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: iesg@ietf.org
Subject: [lemonade] Future Release Discussion
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org


I have collected the following discussion comments (praphrased) and proposed resolutions.  I plan to submit a revised ID with these changes after the current posting embargo lifts.

Greg V.


Francis Dupont via Brian Carpenter: .
----------------------------------------------------

Various editorial nits, all accepted

Radia Perlman via Russ Housley
-----------------------------------------------

  1) Need error code indicating that required authorization has not been performed prior to use of this extension.

	- SMTP-Submit itself requires authorization.  This authorization be be performed by a number of in-band or out-of-band protocol mechanisms including address filtering, or pop before submission.  It is not the intention of this draft to raise the authentication requirements for submission. 

	Suggested change:  Clarify that the MUST requirement level is re-itterating the requirement for submission in general.  If the client cannot authorize, the full submission service is unavailable.

   2) Need an error code indicating system quota exceded but user quota is still available.  

	Suggested change:  Add the suggested error code.

Yoshiko Chong
-----------------------

IANA registration questions

    1) Registration of HOLDFOR and HOLDUNTIL mail from parameters.

Suggested change:  Modify the IANA request to exclude registration of these parameters. It has not been common practice to register specific parameters separately from the service extensions themselves.  While it is increasingly valueable to collect in a single registary the various RCPT TO and MAIL FROM parameters, I suggest this is an independent action from the approval of this specific extension. 

    2) Registration for new status codes.  Status codes are extended only by standards track document.  As with the handful of previous status-code extension documents, this document is the sole registration for these new codes. 

Suggested change:  None.  It is reasonable for IANA to add a registry for status codes for ease of reference, but I suggest that this document not be held up for such.  

Lars Eggert (two messages)
-----------------

Need to ensure accurate time for HOLDUNTIL to avoid unanticipated premature or late release, a security-related side-effect.  Why not just use HOLDFOR?

The inclusion of both HOLDUNTIL and HOLDFOR in this extension was made after very extensive discussion on the LEMONADE mailing list.  There are good arguments for the HOLDUNTIL variant, and while security risk associated with an inaccurate server clock was not raised, I don't believe we can easily reach agreement to drop this option.

   Suggested Change:  Author will augment security considerations section to describe the additional risks of the HOLDUNTIL option as well as include pointer text in the description of the HOLDUNTIL option.

   2nd Suggested Change:  Add text that a submission server SHOULD only offer futurerelease if it has accurate time.  There is no mechanism for indicating support of HOLDFOR only in the current proposal.

   Editorial change s/trivally/triviallly/ accepted.

Magnus Westerland:  
------------------------------

  1) ABNF for max-future-release-date is incompletely or incorrectly specified.  2) Missing definition for internet-style-date-time-utc.  Request for a collected grammer.

Suggested change:  Delete the -utc from the attribute name yielding the following text.

     The max-future-release-date-time is a timestamp, normalized to
      Universal Coordinated Time (UTC), indicating the most remote date
      and time in the future until which the MSA will hold messages for
      future release.
      
      Using ABNF [n2], the syntax of this parameter is as follows:

         max-future-release-date-time = Internet-style-date-time

      where the format of Internet-style-date-time is defined in [n10].

Suggested change:  Collect the grammer in a new section.
 
  3) Section 6 comment.

Suggested change:  Modify the text to indicate that IANA will add this extension as part of the document approval and publishing process and leave out the incorrect detail.

Sam Hartman, reply comment by Bell Fenner
---------------------

Uncomfortable with binding of this extension to submission port.  

No change.  This is not an SMTP extension, but an extension to SMTP-Submit which is defined to execute on a particular port. There are greater distinctions between submission and relay than simply the alternate port number. This is one of several such submit-only extensions including recently approved and published BURL (RFC 4468)



_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 03 09:54:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxOsA-0004Jv-G7; Mon, 03 Jul 2006 09:53:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxOs9-0004Jn-M7; Mon, 03 Jul 2006 09:53:57 -0400
Received: from kalyani.oryx.com ([195.30.37.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxOs8-0006Iv-75; Mon, 03 Jul 2006 09:53:57 -0400
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9])
	by kalyani.oryx.com (Postfix) with ESMTP id 00F764ACE9;
	Mon,  3 Jul 2006 15:53:53 +0200 (CEST)
Message-Id: <Y7uZYOTq2sCEBGJU5XUI2w.md5@libertango.oryx.com>
Date: Mon, 3 Jul 2006 15:55:08 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: lemonade@ietf.org
Subject: Re: [lemonade] Future Release Discussion
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
In-Reply-To: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: iesg@ietf.org, gregv@lucent.com
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Vaudreuil, Greg M (Greg) writes:
>    2nd Suggested Change: Add text that a submission server SHOULD only 
>    offer futurerelease if it has accurate time. There is no mechanism 
>    for indicating support of HOLDFOR only in the current proposal.

I've a bad feeling about this; it confuses the implementer, software and 
sysadmin.

The implementer of an SMTP SUBMIT server does not know whether the 
software will run on hosts with reliable time (except in rather special 
circumstances), so it's unreasonable to make this demand of the 
implementer.

The software can't easily tell whether it's running on a host with 
reliable time. If it tries hard enough, it can, but I think it's 
unreasonable to ask SMTP server software to try that hard.

The sysadmin is IMO all too likely to act overconfidently, and assume 
that the server will have reliable time. (Example: Buy a typical PC 
motherboard in a 19" case, install linux, set up ntpd, never check that 
the motherboard clock is within ntpd's sanity limits.)

I'd just as soon drop this SHOULD, it's not going to do anything, and 
just have some general prose on the importance of accurate time.

Arnt

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 03 11:07:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxQ1O-0004m6-OB; Mon, 03 Jul 2006 11:07:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxQ1N-0004lt-Jo; Mon, 03 Jul 2006 11:07:33 -0400
Received: from mxout3.cac.washington.edu ([140.142.32.166])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxQ1L-0004st-89; Mon, 03 Jul 2006 11:07:33 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout3.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k63F7Tfx004192; Mon, 3 Jul 2006 08:07:30 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([166.209.81.135])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id
	k63F6Mqu012059
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 3 Jul 2006 08:07:20 -0700
Date: Mon, 3 Jul 2006 08:06:13 -0700
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Subject: Re: [lemonade] Future Release Discussion
In-Reply-To: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
Message-ID: <Pine.WNT.4.65.0607030757550.1948@Shimo-Tomobiki.panda.com>
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: Lemonade@ietf.org, iesg@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

With regard to this part of the issue:

Your suggestion implies that future release is prohibited in SMTP and only 
permitted in SUBMISSION.

I have no objection to this prohibition; but I can come up with no 
particularly compelling reason for it.  If we wish to go this route, we 
need to provide this reasoning.

Also, what if the SUBMISSION client authenticated with ANONYMOUS?

Just flesh out these details, and I think that we're good to go.  Once 
again, I don't see a compelling need for future deliver with SMTP or with 
ANONYMOUS authentication, but Radia is correct in observing that we need 
an error code saying that this transaction is not authorized (which can be 
a reference back to the submission document).

On Mon, 3 Jul 2006, Vaudreuil, Greg M (Greg) wrote:
> Radia Perlman via Russ Housley
>  1) Need error code indicating that required authorization has not been 
> performed prior to use of this extension.
> 	- SMTP-Submit itself requires authorization.  This authorization 
> be be performed by a number of in-band or out-of-band protocol 
> mechanisms including address filtering, or pop before submission.  It is 
> not the intention of this draft to raise the authentication requirements 
> for submission.
> 	Suggested change:  Clarify that the MUST requirement level is 
> re-itterating the requirement for submission in general.  If the client 
> cannot authorize, the full submission service is unavailable.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 03 11:11:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxQ54-0005hB-W0; Mon, 03 Jul 2006 11:11:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxQ53-0005h3-VH; Mon, 03 Jul 2006 11:11:21 -0400
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxQ52-0004yz-ML; Mon, 03 Jul 2006 11:11:21 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:51213)
	by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25)
	with esmtpa (EXTERNAL:fanf2) id 1FxQ4w-0005Ff-Tt (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 03 Jul 2006 16:11:14 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1FxQ4w-000157-6u (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 03 Jul 2006 16:11:14 +0100
Date: Mon, 3 Jul 2006 16:11:14 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Mark Crispin <MRC@CAC.Washington.EDU>
Subject: Re: [lemonade] Future Release Discussion
In-Reply-To: <Pine.WNT.4.65.0607030757550.1948@Shimo-Tomobiki.panda.com>
Message-ID: <Pine.LNX.4.64.0607031609150.4888@hermes-1.csi.cam.ac.uk>
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
	<Pine.WNT.4.65.0607030757550.1948@Shimo-Tomobiki.panda.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: Lemonade@ietf.org, iesg@ietf.org, "Vaudreuil,
	Greg M \(Greg\)" <gregv@lucent.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 3 Jul 2006, Mark Crispin wrote:
>
> Your suggestion implies that future release is prohibited in SMTP and
> only permitted in SUBMISSION. I have no objection to this prohibition;
> but I can come up with no particularly compelling reason for it.  If we
> wish to go this route, we need to provide this reasoning.

I would have thought that this kind of restriction would be an operational
matter rather than something required for standards-conformance.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
SHANNON: SOUTHEAST ROCKALL NORTHERLY 4 OR 5, OCCASIONALLY 6 IN SHANNON.
FAIR. GOOD.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 03 11:25:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxQJA-000388-KA; Mon, 03 Jul 2006 11:25:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxQJ9-000380-89; Mon, 03 Jul 2006 11:25:55 -0400
Received: from mxout4.cac.washington.edu ([140.142.33.19])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FxQJ7-0005OU-SD; Mon, 03 Jul 2006 11:25:55 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout4.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k63FPo0F030659; Mon, 3 Jul 2006 08:25:50 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([166.209.81.135])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id
	k63FPV6b014777
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 3 Jul 2006 08:25:44 -0700
Date: Mon, 3 Jul 2006 08:25:12 -0700
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Tony Finch <dot@dotat.at>
Subject: Re: [lemonade] Future Release Discussion
In-Reply-To: <Pine.LNX.4.64.0607031609150.4888@hermes-1.csi.cam.ac.uk>
Message-ID: <Pine.WNT.4.65.0607030823400.1948@Shimo-Tomobiki.panda.com>
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
	<Pine.WNT.4.65.0607030757550.1948@Shimo-Tomobiki.panda.com>
	<Pine.LNX.4.64.0607031609150.4888@hermes-1.csi.cam.ac.uk>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Lemonade@ietf.org, iesg@ietf.org, "Vaudreuil,
	Greg M \(Greg\)" <gregv@lucent.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 3 Jul 2006, Tony Finch wrote:
> On Mon, 3 Jul 2006, Mark Crispin wrote:
>> Your suggestion implies that future release is prohibited in SMTP and
>> only permitted in SUBMISSION. I have no objection to this prohibition;
>> but I can come up with no particularly compelling reason for it.  If we
>> wish to go this route, we need to provide this reasoning.
> I would have thought that this kind of restriction would be an operational
> matter rather than something required for standards-conformance.

If it is an operational matter, then the error code is definitely needed. 
The only way that we can avoid it (as Greg advocates) is to have a 
standards level restriction.

I don't particularly care either way.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 04 13:46:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FxoyF-00055L-FU; Tue, 04 Jul 2006 13:45:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FxoyE-00055G-5b
	for lemonade@ietf.org; Tue, 04 Jul 2006 13:45:58 -0400
Received: from laweleka.osafoundation.org ([204.152.186.98])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxoyC-0008PY-NY
	for lemonade@ietf.org; Tue, 04 Jul 2006 13:45:58 -0400
Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net
	[69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by laweleka.osafoundation.org (Postfix) with ESMTP id B0333142262;
	Tue,  4 Jul 2006 10:45:55 -0700 (PDT)
In-Reply-To: <p06300008c0b8e7750b00@[192.168.1.13]>
References: <4486CC85.80400@isode.com>
	<7ED1AE38-5BA6-4100-B072-07B1397C8E95@osafoundation.org>
	<p0630000ac0afc94c73f6@[129.46.172.15]>
	<2753C43F-FA4A-487B-8834-3650FC05A51E@osafoundation.org>
	<p06300008c0b8e7750b00@[192.168.1.13]>
Mime-Version: 1.0 (Apple Message framework v750)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A680FEC4-74EA-4030-BDF6-4366DF6057B8@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: [lemonade] Notifications for multiple devices per user
Date: Tue, 4 Jul 2006 10:44:48 -0700
To: Randall Gellens <randy@qualcomm.com>
X-Mailer: Apple Mail (2.750)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: Lemonade WG <lemonade@ietf.org>,
	Alexey Melnikov <alexey.melnikov@isode.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Sorry I'm behind on the list, catching up since my trip to Dublin.   
Responses inline...

On Jun 16, 2006, at 4:11 PM, Randall Gellens wrote:

> At 10:15 AM -0700 6/15/06, Lisa Dusseault wrote:
>
>>>  At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote:
>>>
>>>>   There's an alternative architecture for the same use case, and  
>>>> that's to let the notification server (SIP or XMPP, in  
>>>> particular) do fanout.  Then the IMAP server simply sends the  
>>>> notification to the user's notification address (plus some  
>>>> application field if specified) and the user decides which  
>>>> devices subscribe to those notifications.
>
>
>>  It's easier for the device to simply to subscribe, or no, to some  
>> address to which notifications are sent (not nonstop but whenever  
>> there's a receiver) according to a previously configured script or  
>> rule.
>
> I apologize if this was covered in a draft that I missed, but I'd  
> like to understand this better.
>
> So Sieve would be used to test messages, and generate notification  
> events as appropriate.  If you had, say, progressively more  
> restrictive filter criteria, the Sieve script would contain tests  
> for each set.
>
> The Sieve script could be written such that it did the most  
> restrictive (fewest notifications) tests first, in the equivalent  
> of a deep IF-THEN-ELSEIF, and therefore at most one notification  
> would be generated per message.  Or, the Sieve script could be  
> written such that it did all tests against all messages, and  
> therefore might generate multiple notifications per message.   
> Notifications generated by the Sieve script would be have an  
> identifier that looked like an IM address, and be published to  
> something that looked like an IM server.  In the case of  
> progressively more restrictive filter criteria, each would have its  
> own address.  For example, 'randy.urgent- 
> messages@jabber.example.org', 'randy.interesting- 
> messages@jabber.example.org', etc.
>
> Devices would subscribe to the notifications using the identifier.

Yes, this is the way I see it working best; good description.

>
> How does the Sieve script get created and updated?  Which device  
> does this, and how much knowledge does it need about the others?

I imagine the primary mail client would do this.  The other main  
alternative is a server interface (particularly in the short term,  
email servers can offer Web UIs).  The user would likely have the  
best UI available in the primary mail client with which to edit  
filters.  In fact, I can't imagine that my mobile device will have  
much of an interface at all to edit sieve filters.

There's definitely a use case for somebody who doesn't want to (or  
can't) install an IMAP client on their phone at all, but they do want  
to see the Subject lines of mails from their boss, or the subject/ 
from of mails that contain iMIP content.  However when leaving on  
vacation he might well want to turn this off, *from the phone.*    
Ideally the user wouldn't have to install any new code on the mobile  
device to accomplish this use case.

>
> How is the Sieve script or engine configured to send notifications  
> to the addresses?

The primary client or server WebUI would set up the script and  
provide a notification address.

>
> How do devices learn which notification identifier they need to  
> subscribe to?

This can involve some coordination, for example noting the address  
these are sent to in the email client, and switching to some other  
client, application or device to subscribe to the same address.

If the user chooses an address which delivers to an IM server (or  
more generally, a notification aggregation server),  their mobile  
devices might already be subscribed.  E.g. if I chose to send the  
subject lines of mails from Ekr to my main IM address, my phone is  
already subscribed to those messages whenever I launch the IM client.

>
> Note that I think these questions apply generally to any out of  
> band notification mechanism.

agreed.

Lisa


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 05 13:37:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyBJp-0000JM-Os; Wed, 05 Jul 2006 13:37:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBJo-0000JH-67
	for lemonade@ietf.org; Wed, 05 Jul 2006 13:37:44 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBJm-0005gB-VF
	for lemonade@ietf.org; Wed, 05 Jul 2006 13:37:44 -0400
X-IronPort-AV: i="4.06,210,1149480000"; 
	d="scan'208"; a="35092389:sNHT30021000"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 5 Jul 2006 13:37:33 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <330A23D8336C0346B5C1A5BB19666647033C282B@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Contexts
Thread-Index: AcagWbJdtU3qRAsxRyqIIp9mu+fOYQ==
From: "Burger, Eric" <eburger@cantata.com>
To: <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: [lemonade] Contexts
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

There has been some discussion on the list about Dave's Contexts draft.
For those that have not followed IMAP-EXT, you can find a link to the
draft at:

http://dave.cridland.net/draft-cridland-imap-contexts.txt

Since most of the IMAP-EXT community overlaps with LEMONADE, I would
like to refer to this document as well in Montreal.  I have added the
link to the draft agenda:

http://www3.ietf.org/proceedings/06jul/agenda/lemonade.txt

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 05 13:38:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyBKJ-0000L3-VR; Wed, 05 Jul 2006 13:38:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FyBKI-0000Ky-82
	for lemonade@ietf.org; Wed, 05 Jul 2006 13:38:14 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyBKG-0005iw-VR
	for lemonade@ietf.org; Wed, 05 Jul 2006 13:38:14 -0400
X-IronPort-AV: i="4.06,210,1149480000"; 
	d="scan'208"; a="35092422:sNHT31026936"
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 5 Jul 2006 13:38:07 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <330A23D8336C0346B5C1A5BB19666647033C2831@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft Agenda
Thread-Index: AcagWcbyOu4UN/HPQpykzrZMpYrIig==
From: "Burger, Eric" <eburger@cantata.com>
To: <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Subject: [lemonade] Draft Agenda
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

The most up-to-date agenda will be posted to:
http://www3.ietf.org/proceedings/06jul/agenda/lemonade.txt




D R A F T    D R A F T    D R A F T    D R A F T    D R A F T
[Updated 060705 1335 ET]



lemonade Work Group Meetings
IETF 66, Montreal, PQ, Canada


Agenda Bashing

Drafts' Status
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-futuredelivery-0
4.txt


Profile-bis
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-03.t
xt


Reconnect
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client
-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.txt


Other Bis Components
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-04.txt
http://www.ietf.org/internet-drafts/draft-maes-lemonade-xencrypted-02.tx
t
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-03.t
xt


Views
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-02
.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-01.txt
http://dave.cridland.net/draft-cridland-imap-contexts.txt


Notifications
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notification-pro
tocol-00.txt
http://www.ietf.org/internet-drafts/draft-melnikov-lemonade-imap-events-
00.txt


Streaming Media
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-00.txt
http://www.ietf.org/internet-drafts/draft-burger-lemonade-streamctrls-00
.txt

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 05 15:26:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyD1R-000112-3P; Wed, 05 Jul 2006 15:26:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyD1Q-0000z9-1R; Wed, 05 Jul 2006 15:26:52 -0400
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148]
	helo=carter-zimmerman.mit.edu)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyD1O-0002ax-Pq; Wed, 05 Jul 2006 15:26:52 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 1A1CCE0087; Wed,  5 Jul 2006 10:24:27 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: Re: [lemonade] Future Release Discussion
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
	<Y7uZYOTq2sCEBGJU5XUI2w.md5@libertango.oryx.com>
Date: Wed, 05 Jul 2006 10:24:27 -0400
In-Reply-To: <Y7uZYOTq2sCEBGJU5XUI2w.md5@libertango.oryx.com> (Arnt
	Gulbrandsen's message of "Mon, 3 Jul 2006 15:55:08 +0200")
Message-ID: <tslk66sdt9g.fsf@cz.mit.edu>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: lemonade@ietf.org, iesg@ietf.org, gregv@lucent.com
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

>>>>> "Arnt" == Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> writes:

    Arnt> Vaudreuil, Greg M (Greg) writes:
    >> 2nd Suggested Change: Add text that a submission server SHOULD
    >> only offer futurerelease if it has accurate time. There is no
    >> mechanism for indicating support of HOLDFOR only in the current
    >> proposal.

    Arnt> I've a bad feeling about this; it confuses the implementer,
    Arnt> software and sysadmin.


During IESG discussion on the telechat, it seemed fairly clear that we
wanted such a restriction as operational advice, not as a standards
level restriction.  "Don't enable future release unless your server
has accurate time," provided as operational advice.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 05 15:26:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyD1R-00011G-8B; Wed, 05 Jul 2006 15:26:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FyD1Q-0000zU-IE; Wed, 05 Jul 2006 15:26:52 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FyD1Q-0002bK-Gr; Wed, 05 Jul 2006 15:26:52 -0400
Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148]
	helo=carter-zimmerman.mit.edu)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1FyD1P-0006Mu-R1; Wed, 05 Jul 2006 15:26:52 -0400
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042)
	id 2DE0DE0089; Wed,  5 Jul 2006 10:25:28 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Mark Crispin <MRC@CAC.Washington.EDU>
Subject: Re: [lemonade] Future Release Discussion
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
	<Pine.WNT.4.65.0607030757550.1948@Shimo-Tomobiki.panda.com>
Date: Wed, 05 Jul 2006 10:25:28 -0400
In-Reply-To: <Pine.WNT.4.65.0607030757550.1948@Shimo-Tomobiki.panda.com> (Mark
	Crispin's message of "Mon, 3 Jul 2006 08:06:13 -0700")
Message-ID: <tslfyhgdt7r.fsf@cz.mit.edu>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: Lemonade@ietf.org, iesg@ietf.org, "Vaudreuil,
	Greg M \(Greg\)" <gregv@lucent.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

>>>>> "Mark" == Mark Crispin <MRC@CAC.Washington.EDU> writes:

    Mark> With regard to this part of the issue: Your suggestion
    Mark> implies that future release is prohibited in SMTP and only
    Mark> permitted in SUBMISSION.

    Mark> I have no objection to this prohibition; but I can come up
    Mark> with no particularly compelling reason for it.  If we wish
    Mark> to go this route, we need to provide this reasoning.

The draft makes it clear the future release is prohibited for SMTP
already.  I found that odd, but it's already in the text.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 07 19:29:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fyzl0-0005mt-3P; Fri, 07 Jul 2006 19:29:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyzky-0005mo-Sq
	for lemonade@ietf.org; Fri, 07 Jul 2006 19:29:08 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyzkx-000482-IA
	for lemonade@ietf.org; Fri, 07 Jul 2006 19:29:08 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k67NT3MT009296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Jul 2006 16:29:04 -0700
Received: from [192.168.1.13] (vpn-10-50-0-181.qualcomm.com [10.50.0.181])
	by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k67NT0d3020463; 
	Fri, 7 Jul 2006 16:29:02 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300011c0d497ce0ff3@[192.168.1.13]>
In-Reply-To: <32030.1151359954.696131@peirce.dave.cridland.net>
References: <32030.1151359954.696131@peirce.dave.cridland.net>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 7 Jul 2006 16:25:12 -0700
To: Dave Cridland <dave@cridland.net>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Profile Bis -03
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Sadly, the references have reverted from names to RFC numbers.


Typo in 3.4.1: "using the BUTL [RFC4468] extension."


In 3.4, "This command can be omitted." might not be clear enough. 
Maybe say "This command can be omitted if the $Forwarded keyword is 
not desired."?


In 3.7, maybe change "mailbox designed" to "mailbox designated"? 
Also, I'd suggest rearranging the sentence, from:
    The final message is uploaded to the mailbox designed
    for outgoing mail, by the APPEND command of [RFC3501].

to:
    The final message is uploaded by the APPEND command of
    [RFC3501] into the mailbox designated for outgoing mail.


In 4.3, the text:
    LEMONADE compliant mail submission servers MUST resolve all BURL
    parts before enforcing a message size limit.

I thought Alexey had new wording to avoid implying that servers 
couldn't reject a message that was already too big even if some BURL 
parts remain unresolved.


In 5.3, perhaps add "at present" after "the working group acknowledges that".


In 7.3, I'd suggest deleting "to facilitate traversal of firewalls".


In 8.3, perhaps change:
       Measures to address the need to traverse firewalls and mobile
       network intermediaries.

to:
       Measures to address the need to traverse mobile
       network intermediaries and/or tunnel over HTTP.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I can't even program a VCR, and I'm on-line!!!  --AOL user (in AOL ad)

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 07 20:10:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fz0PQ-00009P-5k; Fri, 07 Jul 2006 20:10:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz0PO-0008Vz-LK
	for lemonade@ietf.org; Fri, 07 Jul 2006 20:10:54 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz0PN-00032P-A0
	for lemonade@ietf.org; Fri, 07 Jul 2006 20:10:54 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k680Ak1V008450
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Jul 2006 17:10:47 -0700
Received: from [192.168.1.13] (vpn-10-50-0-181.qualcomm.com [10.50.0.181])
	by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k680Afpn006442; 
	Fri, 7 Jul 2006 17:10:44 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300014c0d4a62e6e66@[192.168.1.13]>
In-Reply-To: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com>
References: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 7 Jul 2006 17:10:36 -0700
To: <Zoltan.Ordogh@nokia.com>, <dave@cridland.net>, <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Profile Bis -03
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 1:35 PM +0300 6/27/06, <Zoltan.Ordogh@nokia.com> wrote:

>  3.4.1 "This command can be omitted, being for metadata only." 
> Suggest wording change to: "This command is only metadata, thus it 
> can be omitted."
>  3.4.2 "This command can be omitted." Suggest same wording as 
> previous: "This command is only metadata, thus it can be omitted."

I'd prefer the current wording, as your suggestion may imply too low 
a value for the command.  Alternatively, what about saying "Clients 
that do not use or set the $Forwarded flag may omit this command"?

>  4.3 One question on this: should we mention that the size declared 
> is supposed to be "before compression, encyption, transfer 
> encoding, etc".

I don't think we need to go into that detail, but if you think there 
is a potential for confusion, I'd suggest including it in parenthesis.

>   Another question: if I do forward without download, what size do I 
> declare here? I might not have fetched the attachment, so I might 
> have no idea how big it is - does the "size of the message after 
> expansion of all BURL parts" statement take care of this?

The client knows the sizes of the attachments from the BODYSTRUCTURE response.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Algol was a great improvement on most of its successors.
                                          --C.A.R Hoare

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 07 20:20:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fz0YQ-0006ZE-31; Fri, 07 Jul 2006 20:20:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz0YP-0006Z9-EI
	for lemonade@ietf.org; Fri, 07 Jul 2006 20:20:13 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz0YO-0003FY-2l
	for lemonade@ietf.org; Fri, 07 Jul 2006 20:20:13 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k680K6ha009599
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Jul 2006 17:20:07 -0700
Received: from [192.168.1.13] (vpn-10-50-0-181.qualcomm.com [10.50.0.181])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k680K2M4019747; Fri, 7 Jul 2006 17:20:05 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300015c0d4a9c3453d@[192.168.1.13]>
In-Reply-To: <oODXxvcygqTytjHEXuqUxA.md5@libertango.oryx.com>
References: <20060629023509687.00000005412@smaes-lap3>
	<oODXxvcygqTytjHEXuqUxA.md5@libertango.oryx.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 7 Jul 2006 17:19:14 -0700
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] compress=deflate: why turn compression off?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: "Stephane H. Maes" <stephane.maes@oracle.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 11:28 AM +0200 6/29/06, Arnt Gulbrandsen wrote:
>  All the evidence I've seen so far is that receiving data data 
> compressed requires less CPU than uncompressed.


At 12:35 PM +0200 6/29/06, Arnt Gulbrandsen wrote:

>  Perhaps the distinction between compression and decompression got 
> lost somewhere along the line?
>
>  It's easy to find files that require lots of CPU (and battery 
> power) to compress. It's plausible that in some (or many?) cases, 
> compress+transmit is more expensive than transmit. But that's 
> irrelevant. Usually the sender isn't battery-constrained, and even 
> when it is, the sender already has the possibility to adjust its 
> compression expense up and down, all the way down to zero.
>
>  Decompression is the issue. Decompression seems (from what everyone 
> says) to be a win-or-even in terms of power. Can you (or anyone) 
> find exceptions?


In talking to handset people, I've repeatedly been told that 
compression saves power.  For client-to-server data, when the client 
needs to compress rather than decompress, the client is saving radio 
transmission, which is even more expensive than radio reception.  So 
it's a win in both cases.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Violence is the last refuge of the incompetent.
                Salvador Hardin

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 07 20:28:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fz0gA-0000eF-Fa; Fri, 07 Jul 2006 20:28:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz0gA-0000e9-10
	for lemonade@ietf.org; Fri, 07 Jul 2006 20:28:14 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz0g8-0003Py-LD
	for lemonade@ietf.org; Fri, 07 Jul 2006 20:28:13 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k680S9Ns017320
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 7 Jul 2006 17:28:10 -0700
Received: from [192.168.1.13] (vpn-10-50-0-181.qualcomm.com [10.50.0.181])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k680S2TW007396; Fri, 7 Jul 2006 17:28:04 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300016c0d4ab90b174@[192.168.1.13]>
In-Reply-To: <8537.1151616823.309195@peirce.dave.cridland.net>
References: <0FA975F2D8295A448BE3ADC16124465760400B@esebe199.NOE.Nokia.com>
	<8537.1151616823.309195@peirce.dave.cridland.net>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 7 Jul 2006 17:26:55 -0700
To: Dave Cridland <dave@cridland.net>,
	"Zoltan.Ordogh@Nokia.com" <Zoltan.Ordogh@nokia.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: RE: [lemonade] Profile Bis -03
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 10:33 PM +0100 6/29/06, Dave Cridland wrote:

>  On Tue Jun 27 11:35:42 2006, Zoltan.Ordogh@Nokia.com wrote:
>>  Thank You Dave for the update.
>>  Goog progress.
>>  Here are some comments/questions I came across while reading it:
>>  General: shouldn't the cover page say dated June, expires in December?
>
>  Yes, I'd slightly messed up the boilerplate, which meant it was rejected.
>
>  The good news is that not only has that been put right, but it gave 
> me the opportunity to address your comments in part. It's almost 
> like I planned it all along.

Sorry, my earlier comments were based on the version you mailed to the list.


>>  3.4.1 "This command can be omitted, being for metadata only." 
>> Suggest wording change to: "This command is only metadata, thus it 
>> can be omitted."
>>  3.4.2 "This command can be omitted." Suggest same wording as 
>> previous: "This command is only metadata, thus it can be omitted."
>
>  I looked at what the RFC Editor did to the original ("This command 
> can be omitted" in both), and I don't actually like it much, 
> because it fails to explain why it can be omitted. I've tried out a 
> new variant.

Perhaps this new variant goes too far in making the command sound 
useless and worthy of omission?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
"SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of
San Francisco Police Jacket, as reported by Herb Cain in SF Chronicle

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sat Jul 08 07:25:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzAvz-0001He-3V; Sat, 08 Jul 2006 07:25:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAvx-0001HX-Qh
	for lemonade@ietf.org; Sat, 08 Jul 2006 07:25:13 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzAvw-0007mK-C2
	for lemonade@ietf.org; Sat, 08 Jul 2006 07:25:13 -0400
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com 
	via TCP (submission) with ESMTPA; Sat, 8 Jul 2006 12:25:09 +0100
Message-ID: <44AD7006.3010308@isode.com>
Date: Thu, 06 Jul 2006 21:18:14 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Lemonade WG <lemonade@ietf.org>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Subject: [lemonade] Recommended timeouts for BDAT/BURL?
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Hi,
I was looking at RFC 3030 and RFC 4468 and couldn't find any recommended 
timeouts for server response to BDAT/BURL commands.
RFC 2821 has the following recommendations about the DATA command:

   DATA Initiation: 2 minutes
      This is while awaiting the "354 Start Input" reply to a DATA
      command.

   Data Block: 3 minutes
      This is while awaiting the completion of each TCP SEND call
      transmitting a chunk of data.

   DATA Termination: 10 minutes.
      This is while awaiting the "250 OK" reply.  When the receiver gets
      the final period terminating the message data, it typically
      performs processing to deliver the message to a user mailbox.  A
      spurious timeout at this point would be very wasteful and would
      typically result in delivery of multiple copies of the message,
      since it has been successfully sent and the server has accepted
      responsibility for delivery.  See section 6.1 for additional
      discussion.
=========
So I guess the timeout for BDAT/BURL "LAST"  should be 10 minutes as 
well. What about non-last BDAT/BURL?

Alexey



_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sat Jul 08 22:24:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzOyX-0008SX-Bd; Sat, 08 Jul 2006 22:24:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzOyW-0008SS-DE
	for Lemonade@ietf.org; Sat, 08 Jul 2006 22:24:48 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzOyT-00072r-TN
	for Lemonade@ietf.org; Sat, 08 Jul 2006 22:24:48 -0400
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com 
	via TCP (submission) with ESMTPA; Sun, 9 Jul 2006 03:24:39 +0100
Message-ID: <44AFBA4B.2080100@isode.com>
Date: Sat, 08 Jul 2006 14:59:39 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
Subject: Re: [lemonade] Future Release Discussion
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
In-Reply-To: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: Lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Vaudreuil, Greg M (Greg) wrote:

>   2) Need an error code indicating system quota exceded but user quota is still available.
>  
>
Hi Greg,
I have a clarifying question: How is this new error code to be used? Is 
its purpose to signal to the client that even though the future release 
request failed this time, it may succeed in the future?

>	Suggested change:  Add the suggested error code.
>  
>



_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sat Jul 08 23:31:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzQ0l-000450-Sj; Sat, 08 Jul 2006 23:31:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzQ0k-00044v-T9
	for Lemonade@ietf.org; Sat, 08 Jul 2006 23:31:10 -0400
Received: from [206.117.180.234] (helo=mauve.mrochek.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzQ0j-0003lV-Je
	for Lemonade@ietf.org; Sat, 08 Jul 2006 23:31:10 -0400
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01M4K5GDX39S00J594@mauve.mrochek.com> for
	Lemonade@ietf.org; Sat, 8 Jul 2006 20:31:06 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1152415866;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=t7dDEzy8nJY6Gy7tEzdCSajaW
	ardTEsBrl+0EwTSj2Z9OkbqJcdWs2nhylxZAJJ1K/nee3nIRyzasoNJQG4fIQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01M4IKNYZ1EO0008CX@mauve.mrochek.com>; Sat,
	08 Jul 2006 20:31:03 -0700 (PDT)
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-id: <01M4K5GC9TXY0008CX@mauve.mrochek.com>
Date: Sat, 08 Jul 2006 20:28:49 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: [lemonade] Future Release Discussion
In-reply-to: "Your message dated Sat, 08 Jul 2006 14:59:39 +0100"
	<44AFBA4B.2080100@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
	<44AFBA4B.2080100@isode.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Lemonade@ietf.org, Vaudreuil Greg M Greg <gregv@lucent.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

> >   2) Need an error code indicating system quota exceded but user quota is still available.

> I have a clarifying question: How is this new error code to be used? Is
> its purpose to signal to the client that even though the future release
> request failed this time, it may succeed in the future?

That's my understanding of its purpose at least.

> >	Suggested change:  Add the suggested error code.

I have no objection to adding the error code, but I have to say that if past
experience with similar error codes in email protocols that suggest a further
action to take is any indication the chances of clients actually taking
advantage of this information is remote in the extreme.

				Ned

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sun Jul 09 00:01:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzQUC-0002VS-Dp; Sun, 09 Jul 2006 00:01:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzQUA-0002U9-Kz
	for lemonade@ietf.org; Sun, 09 Jul 2006 00:01:34 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzQLJ-00085A-Nd
	for lemonade@ietf.org; Sat, 08 Jul 2006 23:52:27 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k693qOlm017797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 8 Jul 2006 20:52:25 -0700
Received: from [192.168.1.13] (vpn-10-50-0-149.qualcomm.com [10.50.0.149])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k693qJaq004177; Sat, 8 Jul 2006 20:52:23 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300004c0d5b98307c0@[192.168.1.13]>
In-Reply-To: <44AD7006.3010308@isode.com>
References: <44AD7006.3010308@isode.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Sat, 8 Jul 2006 12:37:18 -0700
To: Alexey Melnikov <alexey.melnikov@isode.com>,
	Lemonade WG <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Recommended timeouts for BDAT/BURL?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.2 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 9:18 PM +0100 7/6/06, Alexey Melnikov wrote:

>  So I guess the timeout for BDAT/BURL "LAST"  should be 10 minutes 
> as well. What about non-last BDAT/BURL?

We had some discussion of this a while back (maybe a year or two?). 
As I recall, there seemed to be some agreement that the current SMTP 
timeouts were too large for mobile clients and could be reduced for 
lemonade.  Also, there was some discussion of adding intermediate 
"command in progress" responses to let the client know that the 
server hadn't vanished.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Some days you feel like Schrodinger's cat.   --M. S. Hutchenreuther

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sun Jul 09 00:02:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzQUt-00031t-OF; Sun, 09 Jul 2006 00:02:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzQUA-0002Tb-Kz
	for lemonade@ietf.org; Sun, 09 Jul 2006 00:01:34 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzQLH-00084d-Pp
	for lemonade@ietf.org; Sat, 08 Jul 2006 23:52:24 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k693qMfh017794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 8 Jul 2006 20:52:22 -0700
Received: from [192.168.1.13] (vpn-10-50-0-149.qualcomm.com [10.50.0.149])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k693qJao004177; Sat, 8 Jul 2006 20:52:21 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300003c0d5b5861874@[192.168.1.13]>
In-Reply-To: <A680FEC4-74EA-4030-BDF6-4366DF6057B8@osafoundation.org>
References: <4486CC85.80400@isode.com>
	<7ED1AE38-5BA6-4100-B072-07B1397C8E95@osafoundation.org>
	<p0630000ac0afc94c73f6@[129.46.172.15]>
	<2753C43F-FA4A-487B-8834-3650FC05A51E@osafoundation.org>
	<p06300008c0b8e7750b00@[192.168.1.13]>
	<A680FEC4-74EA-4030-BDF6-4366DF6057B8@osafoundation.org>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Sat, 8 Jul 2006 12:31:37 -0700
To: Lisa Dusseault <lisa@osafoundation.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Notifications for multiple devices per user
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 10:44 AM -0700 7/4/06, Lisa Dusseault wrote:

>  Sorry I'm behind on the list, catching up since my trip to Dublin.

...And I'm catching up since my trip to an Internet-free zone in Australia.


>  Responses inline...
>
>  On Jun 16, 2006, at 4:11 PM, Randall Gellens wrote:
>
>>  At 10:15 AM -0700 6/15/06, Lisa Dusseault wrote:
>>
>>>>   At 4:40 PM -0700 6/9/06, Lisa Dusseault wrote:
>>>>
>>>>>    There's an alternative architecture for the same use case, 
>>>>> and that's to let the notification server (SIP or XMPP, in 
>>>>> particular) do fanout.  Then the IMAP server simply sends the 
>>>>> notification to the user's notification address (plus some 
>>>>> application field if specified) and the user decides which 
>>>>> devices subscribe to those notifications.
>>
>>
>>>   It's easier for the device to simply to subscribe, or no, to 
>>> some address to which notifications are sent (not nonstop but 
>>> whenever there's a receiver) according to a previously configured 
>>> script or rule.
>>
>>  I apologize if this was covered in a draft that I missed, but I'd 
>> like to understand this better.
>>
>>  So Sieve would be used to test messages, and generate notification 
>> events as appropriate.  If you had, say, progressively more 
>> restrictive filter criteria, the Sieve script would contain tests 
>> for each set.
>>
>>  The Sieve script could be written such that it did the most 
>> restrictive (fewest notifications) tests first, in the equivalent 
>> of a deep IF-THEN-ELSEIF, and therefore at most one notification 
>> would be generated per message.  Or, the Sieve script could be 
>> written such that it did all tests against all messages, and 
>> therefore might generate multiple notifications per message.  
>>  Notifications generated by the Sieve script would be have an 
>> identifier that looked like an IM address, and be published to 
>> something that looked like an IM server.  In the case of 
>> progressively more restrictive filter criteria, each would have 
>> its own address.  For example, 
>> 'randy.urgent-messages@jabber.example.org', 
>> 'randy.interesting-messages@jabber.example.org', etc.
>>
>>  Devices would subscribe to the notifications using the identifier.
>
>  Yes, this is the way I see it working best; good description.

Do we need to identify which approach should be used?


>>  How does the Sieve script get created and updated?  Which device 
>> does this, and how much knowledge does it need about the others?
>
>  I imagine the primary mail client would do this.  The other main 
> alternative is a server interface (particularly in the short term, 
> email servers can offer Web UIs).  The user would likely have the 
> best UI available in the primary mail client with which to edit 
> filters.  In fact, I can't imagine that my mobile device will have 
> much of an interface at all to edit sieve filters.

I can see the appeal of having the user set up notifications using a 
primary mail client or a web interface, but I'm concerned that this 
makes mobile email more difficult for average users; a new device 
won't simply work out of the box.

I can see several potential approaches to notifications, and I'm 
unsure which direction is better.  For example, there is some appeal 
in a client's ability to create notifications for itself, perhaps 
using a simple check-box UI ("be notified of [] all new messages [] 
new messages in inbox [] new high-priority messages [] new messages 
from ______").  On the other hand, there will always be some users 
who want more flexibility and won't mind going through extra steps to 
set it up.

>  There's definitely a use case for somebody who doesn't want to (or 
> can't) install an IMAP client on their phone at all, but they do 
> want to see the Subject lines of mails from their boss, or the 
> subject/from of mails that contain iMIP content.  However when 
> leaving on vacation he might well want to turn this off, *from the 
> phone.*   
>  Ideally the user wouldn't have to install any new code on the 
> mobile device to accomplish this use case.

Maybe, but that seems to be different from the use case where 
notifications trigger a client fetch of the message, so that 
"interesting" messages just appear in the mail client.

Without a mail client on the device, notifications would be directed 
at the user, rather than at the client.  The user could of course 
then use a web browser on the device to read the new mail, but that 
seems beyond the scope of lemonade.


>>  How is the Sieve script or engine configured to send notifications 
>> to the addresses?
>
>  The primary client or server WebUI would set up the script and 
> provide a notification address.
>
>>  How do devices learn which notification identifier they need to 
>> subscribe to?
>
>  This can involve some coordination, for example noting the address 
> these are sent to in the email client, and switching to some other 
> client, application or device to subscribe to the same address.
>
>  If the user chooses an address which delivers to an IM server (or 
> more generally, a notification aggregation server),  their mobile 
> devices might already be subscribed.  E.g. if I chose to send the 
> subject lines of mails from Ekr to my main IM address, my phone is 
> already subscribed to those messages whenever I launch the IM 
> client.

This is troubling, since it means that clients can't do much on their 
own, and the significant amount of user coordination and 
configuration is needed.  Personally, I think that ease of setup will 
be critical in the success of mobile email (at least for the 
non-engineer).

It seems to me that we need a mechanism that either has clients 
create the notification filters themselves, or that allows clients to 
discover the notifications that have been created and their criteria. 
Otherwise we don't have an interoperable solution, but rather we 
force users to configure their environment and coordinate their 
devices.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Lottery: A tax on people who are bad at math.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sun Jul 09 11:22:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fzb79-00029J-Oa; Sun, 09 Jul 2006 11:22:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzb78-00029E-Pm
	for lemonade@ietf.org; Sun, 09 Jul 2006 11:22:30 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzb76-0005BK-S7
	for lemonade@ietf.org; Sun, 09 Jul 2006 11:22:30 -0400
Received: from [10.2.244.141] ([206.47.204.99]) by rufus.isode.com 
	via TCP (submission) with ESMTPA; Sun, 9 Jul 2006 16:22:13 +0100
Message-ID: <44B11F1B.50505@isode.com>
Date: Sun, 09 Jul 2006 16:22:03 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Recommended timeouts for BDAT/BURL?
References: <44AD7006.3010308@isode.com> <p06300004c0d5b98307c0@[192.168.1.13]>
In-Reply-To: <p06300004c0d5b98307c0@[192.168.1.13]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Randall Gellens wrote:

> At 9:18 PM +0100 7/6/06, Alexey Melnikov wrote:
>
>>  So I guess the timeout for BDAT/BURL "LAST"  should be 10 minutes as 
>> well. What about non-last BDAT/BURL?
>
> We had some discussion of this a while back (maybe a year or two?). As 
> I recall, there seemed to be some agreement that the current SMTP 
> timeouts were too large for mobile clients and could be reduced for 
> lemonade.

Ok. Is this something we want to cover in Lemonade Profile bis?

> Also, there was some discussion of adding intermediate "command in 
> progress" responses to let the client know that the server hadn't 
> vanished.

You reminded me that I actually volunteered to co-edit it :-).


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sun Jul 09 12:11:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fzbss-0005mB-Vf; Sun, 09 Jul 2006 12:11:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzbss-0005m6-JG
	for lemonade@ietf.org; Sun, 09 Jul 2006 12:11:50 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzbsr-0001eF-8o
	for lemonade@ietf.org; Sun, 09 Jul 2006 12:11:50 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k69GBlYU001749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sun, 9 Jul 2006 09:11:48 -0700
Received: from [192.168.1.13] (vpn-10-50-0-149.qualcomm.com [10.50.0.149])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k69GBfgW009107; Sun, 9 Jul 2006 09:11:43 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300014c0d6daca5020@[192.168.1.13]>
In-Reply-To: <44B11F1B.50505@isode.com>
References: <44AD7006.3010308@isode.com>
	<p06300004c0d5b98307c0@[192.168.1.13]> <44B11F1B.50505@isode.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Sun, 9 Jul 2006 09:11:20 -0700
To: Alexey Melnikov <alexey.melnikov@isode.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Recommended timeouts for BDAT/BURL?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 4:22 PM +0100 7/9/06, Alexey Melnikov wrote:

>  Randall Gellens wrote:
>
>>  At 9:18 PM +0100 7/6/06, Alexey Melnikov wrote:
>>
>>>   So I guess the timeout for BDAT/BURL "LAST"  should be 10 
>>> minutes as well. What about non-last BDAT/BURL?
>>
>>  We had some discussion of this a while back (maybe a year or 
>> two?). As I recall, there seemed to be some agreement that the 
>> current SMTP timeouts were too large for mobile clients and could 
>> be reduced for lemonade.
>
>  Ok. Is this something we want to cover in Lemonade Profile bis?

I think we need to, yes.


>>  Also, there was some discussion of adding intermediate "command in 
>> progress" responses to let the client know that the server hadn't 
>> vanished.
>
>  You reminded me that I actually volunteered to co-edit it :-).

I'm happy to help with that.

We should probably try and get rough consensus in the group that it 
is something we still want to do.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Lottery: A tax on people who are bad at math.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sun Jul 09 17:23:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzgkK-0005EI-Sb; Sun, 09 Jul 2006 17:23:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzgkJ-0005EA-OH
	for lemonade@ietf.org; Sun, 09 Jul 2006 17:23:19 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzgkI-00024f-6p
	for lemonade@ietf.org; Sun, 09 Jul 2006 17:23:19 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by heisenberg.zen.co.uk with esmtp (Exim 4.30)
	id 1FzgkH-000572-CX; Sun, 09 Jul 2006 21:23:17 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 18BFF498003;
	Sun,  9 Jul 2006 22:24:16 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 11520-02; Sun, 9 Jul 2006 22:24:11 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown
	[IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a])
	by turner.dave.cridland.net (Postfix) with ESMTP id 9794E498002;
	Sun,  9 Jul 2006 22:24:11 +0100 (BST)
Date: Sun, 09 Jul 2006 22:23:10 +0100
Subject: Re: [lemonade] Recommended timeouts for BDAT/BURL?
References: <44AD7006.3010308@isode.com>
	<p06300004c0d5b98307c0@[192.168.1.13]> <44B11F1B.50505@isode.com>
In-Reply-To: <44B11F1B.50505@isode.com>
MIME-Version: 1.0
Message-Id: <19843.1152480190.321320@peirce.dave.cridland.net>
From: Dave Cridland <dave@cridland.net>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Heisenberg-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>, Randall Gellens <randy@qualcomm.com>,
	Tony Finch <dot@dotat.at>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Sun Jul  9 16:22:03 2006, Alexey Melnikov wrote:
> Randall Gellens wrote:
> 
>> At 9:18 PM +0100 7/6/06, Alexey Melnikov wrote:
>> 
>>>  So I guess the timeout for BDAT/BURL "LAST"  should be 10 
>>> minutes as well. What about non-last BDAT/BURL?
>> 
>> We had some discussion of this a while back (maybe a year or 
>> two?). As I recall, there seemed to be some agreement that the 
>> current SMTP timeouts were too large for mobile clients and could 
>> be reduced for lemonade.
> 
> Ok. Is this something we want to cover in Lemonade Profile bis?
> 
> 
I think that's the best place for it, but I disagree with the 
principle - that is, I don't think timeouts should be reduced, I 
think another approach is needed - but if the consensus of the group 
is that we should simply change timeouts, I'd have thought it'd be 
simpler to put that in Profile Bis rather than a new draft.


>> Also, there was some discussion of adding intermediate "command in 
>> progress" responses to let the client know that the server hadn't 
>> vanished.
> 
> You reminded me that I actually volunteered to co-edit it :-).

Personally I'm more interested in Tony Finch's reworking of 
CHECKPOINT - I think making RFC1845 work with BDAT and BURL, and 
making it more pipelinable, is of considerably more generic utility. 
It allows the issue of timeouts to be rather moot, since a client 
which decides not to wait, or is cut off before the response comes 
back, can later establish not only whether the message send succeeded 
as a whole, but which data needs to be resent.

Maybe there's another aspect to timeouts I've missed, though.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sun Jul 09 23:03:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fzm3E-0004Ec-GK; Sun, 09 Jul 2006 23:03:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzm3D-0004EU-8X
	for lemonade@ietf.org; Sun, 09 Jul 2006 23:03:11 -0400
Received: from zcars04e.nortel.com ([47.129.242.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzm3B-00007v-O9
	for lemonade@ietf.org; Sun, 09 Jul 2006 23:03:11 -0400
Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com
	[47.129.230.95])
	by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id
	k6A2vXP01970
	for <lemonade@ietf.org>; Sun, 9 Jul 2006 22:57:33 -0400 (EDT)
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 9 Jul 2006 23:03:04 -0400
Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0AF7A01F@zcarhxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IETF 66 Agenda
Thread-Index: AcajxUxhtm5xSa46QIaF5ADvusM25g==
From: "Glenn Parsons" <gparsons@nortel.com>
To: "Enhancements to Internet email to support diverse serviceenivronments"
	<lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c
Subject: [lemonade] IETF 66 Agenda
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0351267200=="
Errors-To: lemonade-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0351267200==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6A3CD.5C876E7F"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A3CD.5C876E7F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The link on the agenda page:

http://www3.ietf.org/proceedings/06jul/agenda/ilemonade.txt

Is the agenda from the interim meeting.

A slightly tweaked URL will give you the IETF 66 agenda (as is on the
proceedings page):

http://www3.ietf.org/proceedings/06jul/agenda/lemonade.txt

Cheers,
Glenn.

PS.  The content of the agenda is:


LEMONADE Work Group Meetings
IETF 66, Montreal, PQ, Canada


Monday - 3:20pm ET - 519B
MP3 - http://videolab.uoregon.edu/events/ietf/ietf668.m3u

Tuesday - 1pm ET - 513B
MP3 - http://videolab.uoregon.edu/events/ietf/ietf664.m3u



Agenda Bashing

Interop event

OMA liaison
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D235

Drafts in last call Status
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-futuredelivery-0
4.txt

Drafts ready for last call status
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-within-02
.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-03.t
xt

Streaming Media
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming-00.txt
http://www.ietf.org/internet-drafts/draft-burger-lemonade-streamctrls-00
.txt

Other Bis Components
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-01.txt
http://www.ietf.org/internet-drafts/draft-maes-lemonade-xencrypted-02.tx
t
http://www.ietf.org/internet-drafts/draft-maes-lemonade-tcp-challenged-e
nvironments-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-2192bis-02.txt

Notifications
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-03
.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notification-pro
tocol-00.txt
http://www.ietf.org/internet-drafts/draft-melnikov-lemonade-imap-events-
00.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-01.tx
t

Reconnect
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-client
-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect-07.txt

Views
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-01.txt
http://dave.cridland.net/draft-cridland-imap-contexts.txt

Profile-bis
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-03.t
xt

Milestones

Charter Discussion

------_=_NextPart_001_01C6A3CD.5C876E7F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7233.69">
<TITLE>IETF 66 Agenda</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">The link on the agenda page:</FONT>
</P>

<P><A =
HREF=3D"http://www3.ietf.org/proceedings/06jul/agenda/ilemonade.txt"><U><=
FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www3.ietf.org/proceedings/06jul/agenda/ilemonade.tx=
t</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is the agenda from the interim =
meeting.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A slightly tweaked URL will give you =
the IETF 66 agenda (as is on the proceedings page):</FONT>
</P>

<P><A =
HREF=3D"http://www3.ietf.org/proceedings/06jul/agenda/lemonade.txt"><U><F=
ONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www3.ietf.org/proceedings/06jul/agenda/lemonade.txt=
</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Glenn.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">PS.&nbsp; The content of the agenda =
is:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">LEMONADE Work Group Meetings</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">IETF 66, Montreal, PQ, Canada</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Monday - 3:20pm ET - 519B</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">MP3 - </FONT><A =
HREF=3D"http://videolab.uoregon.edu/events/ietf/ietf668.m3u"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://videolab.uoregon.edu/events/ietf/ietf668.m3u</FONT>=
</U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Tuesday - 1pm ET - 513B</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">MP3 - </FONT><A =
HREF=3D"http://videolab.uoregon.edu/events/ietf/ietf664.m3u"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://videolab.uoregon.edu/events/ietf/ietf664.m3u</FONT>=
</U></A>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Agenda Bashing</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Interop event</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">OMA liaison</FONT>

<BR><A =
HREF=3D"https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D=
235"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">https://datatracker.ietf.org/public/liaison_detail.cgi?det=
ail_id=3D235</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Drafts in last call Status</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-futuredel=
ivery-04.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-fu=
turedelivery-04.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Drafts ready for last call =
status</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-convert-0=
4.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-co=
nvert-04.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-search-wi=
thin-02.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-se=
arch-within-02.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deploymen=
ts-03.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-de=
ployments-03.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Streaming Media</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-streaming=
-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-st=
reaming-00.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-burger-lemonade-streamc=
trls-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-burger-lemonade-=
streamctrls-00.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Other Bis Components</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-=
01.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-co=
mpress-01.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-maes-lemonade-xencrypte=
d-02.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-maes-lemonade-xe=
ncrypted-02.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-maes-lemonade-tcp-chall=
enged-environments-01.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-maes-lemonade-tc=
p-challenged-environments-01.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-2192bis-0=
2.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-21=
92bis-02.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Notifications</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-msgevent-=
00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-ms=
gevent-00.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notificat=
ions-03.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-no=
tifications-03.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notificat=
ion-protocol-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-no=
tification-protocol-00.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-melnikov-lemonade-imap-=
events-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-melnikov-lemonad=
e-imap-events-00.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-siev=
e-01.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-im=
ap-sieve-01.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Reconnect</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect=
-client-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-re=
connect-client-00.txt</FONT></U></A>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-reconnect=
-07.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-re=
connect-07.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Views</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vfolder-0=
1.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-vf=
older-01.txt</FONT></U></A>

<BR><A =
HREF=3D"http://dave.cridland.net/draft-cridland-imap-contexts.txt"><U><FO=
NT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://dave.cridland.net/draft-cridland-imap-contexts.txt<=
/FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Profile-bis</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-b=
is-03.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/internet-drafts/draft-ietf-lemonade-pr=
ofile-bis-03.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Milestones</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Charter Discussion</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A3CD.5C876E7F--


--===============0351267200==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--===============0351267200==--




From lemonade-bounces@ietf.org Mon Jul 10 10:03:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzwMC-0005Bx-P3; Mon, 10 Jul 2006 10:03:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzLXe-0005dq-K6; Sat, 08 Jul 2006 18:44:50 -0400
Received: from kyoto.netlab.nec.de ([195.37.70.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FzLXd-0006Mw-3g; Sat, 08 Jul 2006 18:44:50 -0400
Received: from lars.local (unknown [206.47.204.99])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 7E0061BACA3;
	Sun,  9 Jul 2006 00:30:53 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by lars.local (Postfix) with ESMTP id EE0901338BC;
	Sat,  8 Jul 2006 14:04:58 -0400 (EDT)
In-Reply-To: <tslk66sdt9g.fsf@cz.mit.edu>
References: <54E40201497DF142B06B27255953F7971F4D1F06@il0015exch007u.ih.lucent.com>
	<Y7uZYOTq2sCEBGJU5XUI2w.md5@libertango.oryx.com>
	<tslk66sdt9g.fsf@cz.mit.edu>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: <928F8608-5800-4908-8027-B08071E81DEC@netlab.nec.de>
From: Lars Eggert <lars.eggert@netlab.nec.de>
Subject: Re: [lemonade] Future Release Discussion
Date: Sat, 8 Jul 2006 15:09:05 +0200
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
X-Mailman-Approved-At: Mon, 10 Jul 2006 10:03:27 -0400
Cc: lemonade@ietf.org, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>,
	iesg@ietf.org, gregv@lucent.com
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1596335337=="
Errors-To: lemonade-bounces@ietf.org


--===============1596335337==
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-65-110770516;
	protocol="application/pkcs7-signature"


--Apple-Mail-65-110770516
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Jul 5, 2006, at 16:24, Sam Hartman wrote:
>>>>>> "Arnt" == Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> writes:
>     Arnt> Vaudreuil, Greg M (Greg) writes:
>>> 2nd Suggested Change: Add text that a submission server SHOULD
>>> only offer futurerelease if it has accurate time. There is no
>>> mechanism for indicating support of HOLDFOR only in the current
>>> proposal.
>
>     Arnt> I've a bad feeling about this; it confuses the implementer,
>     Arnt> software and sysadmin.
>
> During IESG discussion on the telechat, it seemed fairly clear that we
> wanted such a restriction as operational advice, not as a standards
> level restriction.  "Don't enable future release unless your server
> has accurate time," provided as operational advice.

Right, my DISCUSS on this was sloppily phrased. The intent was  
exactly what Sam has expressed above. (Sorry for jumping in late,  
working through my email backlog after a vacation.)

Lars
-- 
Lars Eggert                                     NEC Network Laboratories



--Apple-Mail-65-110770516
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw
ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE
EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN
AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv
AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK
xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF
DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ
vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C
AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l
dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS
vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2
usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu
mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa
LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud
HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs
Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf
qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa
9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G
CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy
ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT
FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq
hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw
NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx
EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO
ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI
hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT
wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z
9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY
LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD
VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy
ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz
MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0
QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9
3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR
piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB
KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwNzA4MTMwOTA2WjAjBgkqhkiG9w0BCQQxFgQU3U7PLHUBJUw0Mn7by60p
POa5RK8wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu
LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg
THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu
bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq
hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl
bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD
VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw
JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA
BIIBAEPI27mMHwewv0KuDs54+nGBPZZD+F/9XGFRaWiLlfV6SnX9xlBnAza6q+7FvCk9FJDGAYkw
rI448qXMl8mufBAelReOsGQOnApjwPL3fmG/pLNrnHzd9UtXTQSy7oWAIYw1NfAF2k+q7XnRZBj+
zqVK/o0W84inmF56U6i7B9nW4UZqlszsSUm1zifmoF0VSYFuztXQS7dGE655h8P/d3g1IG9kvHYB
AAUMHoRUExueVRfmn+vxaMwIHjGgwSnQ9BF0o9fEh6RItWHhVnIC7m+Y0ZajLRTLZGsJ3EX7+lK9
mrL0q+cZhbdxWXULBO4UfHcQQuM/UdiNwrfzs5S+FT8AAAAAAAA=

--Apple-Mail-65-110770516--


--===============1596335337==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--===============1596335337==--




From lemonade-bounces@ietf.org Mon Jul 10 10:24:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzwgF-0004xw-7h; Mon, 10 Jul 2006 10:24:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwgE-0004x2-80
	for lemonade@ietf.org; Mon, 10 Jul 2006 10:24:10 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwgB-0001k9-VI
	for lemonade@ietf.org; Mon, 10 Jul 2006 10:24:10 -0400
X-IronPort-AV: i="4.06,225,1149480000"; 
	d="scan'208"; a="35275117:sNHT42275448"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] Recommended timeouts for BDAT/BURL?
Date: Mon, 10 Jul 2006 10:24:03 -0400
Message-ID: <330A23D8336C0346B5C1A5BB196666470341E4EF@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] Recommended timeouts for BDAT/BURL?
Thread-Index: AcajcrLhSgZyUgTTT/WxPbCh0boQQwAuUyUA
From: "Burger, Eric" <eburger@cantata.com>
To: "Randall Gellens" <randy@qualcomm.com>,
	"Alexey Melnikov" <alexey.melnikov@isode.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Having written draft-burger-smtp-rdlv-00 back in August 2004, I think
it's about time to get this done :-)

Alexey - you're now writing more than me :-))

Randy, want the XML source?

-----Original Message-----
From: Randall Gellens [mailto:randy@qualcomm.com]=20
Sent: Sunday, July 09, 2006 12:11 PM
To: Alexey Melnikov
Cc: Lemonade WG
Subject: Re: [lemonade] Recommended timeouts for BDAT/BURL?

At 4:22 PM +0100 7/9/06, Alexey Melnikov wrote:

>  Randall Gellens wrote:
>
>>  At 9:18 PM +0100 7/6/06, Alexey Melnikov wrote:
>>
>>>   So I guess the timeout for BDAT/BURL "LAST"  should be 10=20
>>> minutes as well. What about non-last BDAT/BURL?
>>
>>  We had some discussion of this a while back (maybe a year or=20
>> two?). As I recall, there seemed to be some agreement that the=20
>> current SMTP timeouts were too large for mobile clients and could=20
>> be reduced for lemonade.
>
>  Ok. Is this something we want to cover in Lemonade Profile bis?

I think we need to, yes.


>>  Also, there was some discussion of adding intermediate "command in=20
>> progress" responses to let the client know that the server hadn't=20
>> vanished.
>
>  You reminded me that I actually volunteered to co-edit it :-).

I'm happy to help with that.

We should probably try and get rough consensus in the group that it=20
is something we still want to do.

--=20
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Lottery: A tax on people who are bad at math.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 10:35:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fzwr7-0005WI-Q1; Mon, 10 Jul 2006 10:35:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwr6-0005W7-Ed
	for Lemonade@ietf.org; Mon, 10 Jul 2006 10:35:24 -0400
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwr5-0002Bk-5H
	for Lemonade@ietf.org; Mon, 10 Jul 2006 10:35:24 -0400
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com
	[135.1.23.83])
	by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k6AEZHfJ022640;
	Mon, 10 Jul 2006 09:35:22 -0500 (CDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service
	(5.5.2657.72) id <3G02NAPV>; Mon, 10 Jul 2006 09:35:17 -0500
Message-ID: <54E40201497DF142B06B27255953F7971F6798F1@il0015exch007u.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: Ned Freed <ned.freed@mrochek.com>, Alexey Melnikov
	<alexey.melnikov@isode.com>
Subject: RE: [lemonade] Future Release Discussion
Date: Mon, 10 Jul 2006 09:35:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Lemonade@ietf.org, Vaudreuil Greg M Greg <gregv@lucent.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org


I agree clients are unlikely to exploit the difference beween the personal and system quota full error codes.  I see this more as an end-user diagnostic to address the "why full?  This is my first use of this feature!".  Think of it as an opportunity for the client to cut down on helpdesk calls.

Greg V.


-----Original Message-----
From: Ned Freed [mailto:ned.freed@mrochek.com]
Sent: Saturday, July 08, 2006 11:29 PM
To: Alexey Melnikov
Cc: Vaudreuil Greg M Greg; Lemonade@ietf.org
Subject: Re: [lemonade] Future Release Discussion


> >   2) Need an error code indicating system quota exceded but user quota is still available.

> I have a clarifying question: How is this new error code to be used? Is
> its purpose to signal to the client that even though the future release
> request failed this time, it may succeed in the future?

That's my understanding of its purpose at least.

> >	Suggested change:  Add the suggested error code.

I have no objection to adding the error code, but I have to say that if past
experience with similar error codes in email protocols that suggest a further
action to take is any indication the chances of clients actually taking
advantage of this information is remote in the extreme.

				Ned

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 12:01:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FzyCB-0003yN-GJ; Mon, 10 Jul 2006 12:01:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FzyC9-0003yH-RS
	for lemonade@ietf.org; Mon, 10 Jul 2006 12:01:13 -0400
Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzyC7-0007rZ-IY
	for lemonade@ietf.org; Mon, 10 Jul 2006 12:01:13 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34447)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:fanf2) id 1FzyBr-00066J-4G (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Jul 2006 17:00:55 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1FzyBr-0004Yj-0K (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Jul 2006 17:00:55 +0100
Date: Mon, 10 Jul 2006 17:00:55 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: "Burger, Eric" <eburger@cantata.com>
Subject: RE: [lemonade] Recommended timeouts for BDAT/BURL?
In-Reply-To: <330A23D8336C0346B5C1A5BB196666470341E4EF@ATLANTIS.Brooktrout.com>
Message-ID: <Pine.LNX.4.64.0607101647520.14969@hermes-1.csi.cam.ac.uk>
References: <330A23D8336C0346B5C1A5BB196666470341E4EF@ATLANTIS.Brooktrout.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Randall Gellens <randy@qualcomm.com>,
	Alexey Melnikov <alexey.melnikov@isode.com>,
	Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 10 Jul 2006, Burger, Eric wrote:

> Having written draft-burger-smtp-rdlv-00 back in August 2004, I think
> it's about time to get this done :-)

I don't think RDLV is robust against connection lossage: it only reduces
the window. It isn't compatible with pipelining.

I intend to produce a revised version of REPLAY which is more compatible
with RFC 1845 and has less irrelevant verbiage. It should provide similar
functionality to RDLV+DETA, plus it avoids the race between sending data
and getting the first response from the server.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FAIR ISLE: SOUTH VEERING WEST 5 TO 7. OCCASIONAL RAIN. MODERATE OR GOOD
OCCASIONALLY POOR.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 16:15:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G02Ag-0004MW-EV; Mon, 10 Jul 2006 16:15:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Af-0004MR-1o
	for lemonade@ietf.org; Mon, 10 Jul 2006 16:15:57 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02Ad-0005Xk-MY
	for lemonade@ietf.org; Mon, 10 Jul 2006 16:15:57 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6AKFstS009888
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Jul 2006 13:15:54 -0700
Received: from [192.168.1.13] (vpn-10-50-0-1.qualcomm.com [10.50.0.1])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6AKFpHA017396; Mon, 10 Jul 2006 13:15:52 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630002fc0d8659e6b68@[192.168.1.13]>
In-Reply-To: <p0630000cc0b795dc3f24@[192.168.1.13]>
References: <E1Fo42U-0002kA-0g@stiedprstage1.ietf.org>
	<p0630000cc0b795dc3f24@[192.168.1.13]>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Mon, 10 Jul 2006 13:15:44 -0700
To: Chris Newman <chris.newman@sun.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Please include the modseq for the event, so a client can know if it 
has already processed the event (perhaps via inband notifications or 
a duplicate notification).

Also, my earlier comments against -00:

At 4:01 PM -0700 6/15/06, Randall Gellens wrote:

>  Thanks, Chris, for (re)submitting this.
>
>  A few requested clarifications for Section 5 (Event Parameters):
>
>  The 'service' parameter is interesting in the case where the the 
> user accesses the mail store via one protocol (such as HTTP) which 
> itself accesses the mail store via another protocol (such as IMAP). 
> As an example, there are a number of popular webmail products which 
> use IMAP (or even POP!) to access mail.  From the mail store's 
> perspective, all such access is via IMAP and likely from an IP 
> address that is not especially interesting (such as 127.0.0.1). 
> I'm not sure how to accommodate this in a general event framework, 
> though.  A 'pass-through' parameter would be useful, but there 
> isn't anything I can think of off-hand in IMAP to pass such 
> information through, so it might be best left for future extension, 
> perhaps with a note about it.
>
>  The 'timestamp' parameter should be specified as to its form.
>  --
>  Randall Gellens
>  Opinions are personal;    facts are suspect;    I speak for myself only
>  -------------- Randomly-selected tag: ---------------
>  There will be no lasting peace on our earth as long as politicians and
>  dictators continue to lead masses of people who are endemically
>  neurotic and sexually sick.                            --Wilhelm Reich
>
>  _______________________________________________
>  lemonade mailing list
>  lemonade@ietf.org
>  https://www1.ietf.org/mailman/listinfo/lemonade


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The optimist proclaims that we live in the best of all possible worlds,
and the pessimist fears this is true.            --James Branch Cabell

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 16:20:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G02Ef-0004pA-IX; Mon, 10 Jul 2006 16:20:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Ee-0004p5-AJ
	for lemonade@ietf.org; Mon, 10 Jul 2006 16:20:04 -0400
Received: from [213.236.237.54] (helo=[10.0.3.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02Ed-0005hG-0W
	for lemonade@ietf.org; Mon, 10 Jul 2006 16:20:04 -0400
Message-Id: <D0nMHkfCXtOSXRkvGrd8nA.md5@[10.0.3.26]>
Date: Mon, 10 Jul 2006 22:19:54 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: lemonade@ietf.org
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-msgevent-00.txt
References: <E1Fo42U-0002kA-0g@stiedprstage1.ietf.org>
	<p0630000cc0b795dc3f24@[192.168.1.13]>
	<p0630002fc0d8659e6b68@[192.168.1.13]>
In-Reply-To: <p0630002fc0d8659e6b68@[192.168.1.13]>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: Randall Gellens <randy@qualcomm.com>, Chris Newman <Chris.Newman@Sun.COM>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Randall Gellens writes:
> Please include the modseq for the event, so a client can know if it 
> has already processed the event (perhaps via inband notifications or 
> a duplicate notification).

I believe modseq and UID are both necessary, since multiple messages can 
share a modseq. (For example, if you issue COPY 1:1000 otherfolder, 
then a reasonable implementation may use one modseq for all thousand 
copies made.)

Arnt

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 17:26:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G03GT-0003tm-E3; Mon, 10 Jul 2006 17:26:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G03GS-0003th-36
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:26:00 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03GQ-0008GT-Pb
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:26:00 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6ALPv3i024331
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <lemonade@ietf.org>; Mon, 10 Jul 2006 14:25:57 -0700
Received: from [192.168.1.13] (vpn-10-50-0-1.qualcomm.com [10.50.0.1])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6ALPsts024992
	for <lemonade@ietf.org>; Mon, 10 Jul 2006 14:25:56 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300031c0d8757b2319@[192.168.1.13]>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Mon, 10 Jul 2006 14:25:48 -0700
To: lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [lemonade] Notes on Compression
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

 From talking to our client people:

- potential reasons for disabling compression: server bugs, general 
robustness (but clients will likely handle this by closing and 
re-opening the connection anyway, so no need to disable compression 
once it has been enabled)

- no good reason to negotiate down & up separately: do whatever is 
simpler for the protocol

- potential memory requirements? Server compresses something that 
exceeds client ability (size of dictionary): is this handled by 
compression mechanism?

- ordering: do TLS first (of course), then compression, then SASL. 
Note that if TLS compression is used, then SASL authentication will 
be compressed anyway, so may as well compress SASL exchange when 
using IMAP/Submission compression

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Adding manpower to a late software project makes it later.
                -- Fred Brooks in _The Mythical Man Month_

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 17:29:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G03JS-0005NV-Nn; Mon, 10 Jul 2006 17:29:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G03J8-0004NW-7C
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:28:46 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03J6-0008P0-TJ
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:28:46 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6ALSh7c021655
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <lemonade@ietf.org>; Mon, 10 Jul 2006 14:28:44 -0700
Received: from [192.168.1.13] (vpn-10-50-0-1.qualcomm.com [10.50.0.1])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6ALSc5F015192
	for <lemonade@ietf.org>; Mon, 10 Jul 2006 14:28:42 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300032c0d876625955@[192.168.1.13]>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Mon, 10 Jul 2006 14:28:09 -0700
To: lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Subject: [lemonade] Notes on Virtual Mailboxes / Contexts
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Notes on virtual mailboxes/contexts from talking to our client people:
- not useful if only one backing mailbox
- Good to have ability for client to have out-of-the-box default 
views, but also ability for user to create complex criteria that are 
stored on server, listed by clients, subscribed by user per device
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Every man thinks God is on his side.
The rich and powerful know he is.
                     --Jean Anouilh

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 17:46:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G03aF-0007sB-B3; Mon, 10 Jul 2006 17:46:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G03aE-0007s6-N1
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:46:26 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03aD-0003au-EJ
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:46:26 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:33373)
	by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G03aA-0005QQ-2P (Exim 4.54) for
	lemonade@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Jul 2006 22:46:22 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk)
	with local-esmtp id 1G03aA-0006fb-LD (Exim 4.53) for lemonade@ietf.org
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Jul 2006 22:46:22 +0100
Date: Mon, 10 Jul 2006 22:46:22 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: lemonade@ietf.org
Message-ID: <Pine.LNX.4.64.0607102243040.14969@hermes-1.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Subject: [lemonade] notifications - xmpp pubsub
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

The publish/subscribe extension to Jabber seems like a reasonable way of
doing out-of-band notifications. Perhaps it also answers the question of
how a client can plausibly download and display the state of a user's
notification filters.

http://www.jabber.org/jeps/jep-0060.html

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
SHANNON ROCKALL MALIN HEBRIDES BAILEY: SOUTH OR SOUTHWEST 5 TO 7, VEERING WEST
FOR A TIME. RAIN OR SHOWERS. MODERATE OR GOOD, BECOMING POOR AT TIMES.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 18:04:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G03rj-00067D-DC; Mon, 10 Jul 2006 18:04:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G03rh-000678-M9
	for lemonade@ietf.org; Mon, 10 Jul 2006 18:04:29 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03rg-0004UY-9a
	for lemonade@ietf.org; Mon, 10 Jul 2006 18:04:29 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by heisenberg.zen.co.uk with esmtp (Exim 4.30)
	id 1G03rf-00042q-Ez; Mon, 10 Jul 2006 22:04:27 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 80E78498003;
	Mon, 10 Jul 2006 23:05:37 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 19442-03; Mon, 10 Jul 2006 23:05:27 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown
	[IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a])
	by turner.dave.cridland.net (Postfix) with ESMTP id 9FF30498002;
	Mon, 10 Jul 2006 23:05:27 +0100 (BST)
Date: Mon, 10 Jul 2006 23:04:15 +0100
Subject: Re: [lemonade] Notes on Compression
References: <p06300031c0d8757b2319@[192.168.1.13]>
In-Reply-To: <p06300031c0d8757b2319@[192.168.1.13]>
MIME-Version: 1.0
Message-Id: <14344.1152569056.035240@peirce.dave.cridland.net>
From: Dave Cridland <dave@cridland.net>
To: Randall Gellens <randy@qualcomm.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Heisenberg-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon Jul 10 22:25:48 2006, Randall Gellens wrote:
> From talking to our client people:
> 
> - potential reasons for disabling compression: server bugs, general 
> robustness (but clients will likely handle this by closing and 
> re-opening the connection anyway, so no need to disable compression 
> once it has been enabled)
> 
> - no good reason to negotiate down & up separately: do whatever is 
> simpler for the protocol
> 
> - potential memory requirements? Server compresses something that 
> exceeds client ability (size of dictionary): is this handled by 
> compression mechanism?
> 
> 
Deflate wouldn't suffer this problem - its memory requirements are 
pretty well constant no matter what the encoded stream.


> - ordering: do TLS first (of course), then compression, then SASL. 
> Note that if TLS compression is used, then SASL authentication will 
> be compressed anyway, so may as well compress SASL exchange when 
> using IMAP/Submission compression
> 
> 
This is fine, until you consider the case where SASL negotiates a 
security layer.

Two ways of handling this:

1) SASL refuses to negotiate a security layer if compression is 
already in effect. Compression negotiated after a security layer is 
okay.

2) SASL negotiates a security layer anyway, and inserts the layer 
under the existing compression layer.

My implementation of Arnt's draft doesn't do security layers in SASL 
at all, but I would lean toward (2) - I don't think it's as 
complicated as it sounds. (I may revise that opinion, though).

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 19:20:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G053M-0003vD-M6; Mon, 10 Jul 2006 19:20:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G04yW-0002Dx-Km
	for lemonade@ietf.org; Mon, 10 Jul 2006 19:15:36 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G021E-0004l0-SE
	for lemonade@ietf.org; Mon, 10 Jul 2006 16:06:12 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G01uE-0008RP-Rt
	for lemonade@ietf.org; Mon, 10 Jul 2006 15:59:00 -0400
X-IronPort-AV: i="4.06,225,1149480000"; 
	d="scan'208"; a="35284241:sNHT28802304"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 10 Jul 2006 15:58:54 -0400
Message-ID: <330A23D8336C0346B5C1A5BB196666470341E827@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Nit on lemonade-deployments-03
Thread-Index: AcakW0Wxu/FYdxHvS3q3zHDGvYv5lA==
From: "Burger, Eric" <eburger@cantata.com>
To: "Lemonade WG" <lemonade@ietf.org>
X-Spam-Score: -1.8 (-)
X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31
Subject: [lemonade] Nit on lemonade-deployments-03
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

I would offer we require networks that advertise TCP to conform with STD
7 (TCP) as something that folks MUST do (section 4.2).

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 21:06:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G06i8-0004pb-TU; Mon, 10 Jul 2006 21:06:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G06i7-0004pR-6Q
	for lemonade@ietf.org; Mon, 10 Jul 2006 21:06:47 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G03Ot-0000Uw-U5
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:34:43 -0400
Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G03Jg-0002lH-9c
	for lemonade@ietf.org; Mon, 10 Jul 2006 17:29:22 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58742)
	by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25)
	with esmtpa (EXTERNAL:fanf2) id 1G03JZ-0006XO-6B (Exim 4.54)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Jul 2006 22:29:13 +0100
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk
	(hermes.cam.ac.uk) with local-esmtp id 1G03JZ-0004fc-RI (Exim 4.53)
	(return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Jul 2006 22:29:13 +0100
Date: Mon, 10 Jul 2006 22:29:13 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Notes on Compression
In-Reply-To: <p06300031c0d8757b2319@[192.168.1.13]>
Message-ID: <Pine.LNX.4.64.0607102227420.14969@hermes-1.csi.cam.ac.uk>
References: <p06300031c0d8757b2319@[192.168.1.13]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -2.2 (--)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 10 Jul 2006, Randall Gellens wrote:
>
> - ordering: do TLS first (of course), then compression, then SASL. Note that
> if TLS compression is used, then SASL authentication will be compressed
> anyway, so may as well compress SASL exchange when using IMAP/Submission
> compression

Does the profile exclude SASL encryption layers? If not, the order of TLS
and SASL depends on the SASL mechanism.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
SHETLAND ISLES: SOUTHEAST 5 OR 6 VEERING WEST OR SOUTHWEST 4 OR 5,
OCCASIONALLY 6 LATER ON TUESDAY. RAIN, THEN SHOWERS ON TUESDAY. MODERATE OR
GOOD, OCCASIONALLY POOR AT FIRST. MODERATE OR ROUGH ON EXPOSED WATERS.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 10 21:42:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G07H1-0002vf-Hf; Mon, 10 Jul 2006 21:42:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G07Gz-0002vX-K0
	for lemonade@ietf.org; Mon, 10 Jul 2006 21:42:49 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G07Gy-0008OW-AU
	for lemonade@ietf.org; Mon, 10 Jul 2006 21:42:49 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6B1ghJu030264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 10 Jul 2006 18:42:43 -0700
Received: from [192.168.1.13] (vpn-10-50-16-145.qualcomm.com [10.50.16.145])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6B1gZHJ025579; Mon, 10 Jul 2006 18:42:39 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300035c0d8b095c0b9@[192.168.1.13]>
In-Reply-To: <330A23D8336C0346B5C1A5BB196666470341E827@ATLANTIS.Brooktrout.com>
References: <330A23D8336C0346B5C1A5BB196666470341E827@ATLANTIS.Brooktrout.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Mon, 10 Jul 2006 18:35:55 -0700
To: "Burger, Eric" <eburger@cantata.com>, "Lemonade WG" <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Nit on lemonade-deployments-03
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 1.1 (+)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 3:58 PM -0400 7/10/06, Eric Burger wrote:

>  I would offer we require networks that advertise TCP to conform with STD
>  7 (TCP) as something that folks MUST do (section 4.2).

Do we need to say this?  I'd hope this, at least, would be obvious.

What would the wording be?  (For example, what is "advertise TCP"?)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
yoin (yoh-EEN; Japanese; noun): experiential reverberation that
continues to move one long after the initial external stimulus
has ceased.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 06:49:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0Fo8-0003RW-Ax; Tue, 11 Jul 2006 06:49:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Fo7-0003RR-43
	for lemonade@ietf.org; Tue, 11 Jul 2006 06:49:35 -0400
Received: from smtp-out.sendmail.com ([209.246.26.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Fo5-0002cg-Kx
	for lemonade@ietf.org; Tue, 11 Jul 2006 06:49:35 -0400
Received: from lab.smi.sendmail.com ([10.210.100.93])
	by foon.sendmail.com (Switch-3.2.2/Switch-3.2.0) with ESMTP id
	k6BAn2KX027286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Jul 2006 03:49:02 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k6BAn2KX027286
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim;
	t=1152614950; bh=HkL7I8hieGo9c7UV5oSXQd4j+9w=; h=X-DomainKeys:
	DomainKey-Signature:Received:Message-Id:To:Cc:From:Subject:
	In-Reply-To:References:Date:Sender; b=gtsuDLcyhTxBk7vyNyPAUAWeyu0e2
	Vu77jY1xYR01neasJ/17k3n88yPpHmifkQUP5VqecCufSCTeyTUXo8UTlIV6RE/+KM1
	Gb4uUqdn/Y0lu7L0ldx6cLPbjNFW30SjTrPuHE5YYGuggo1xHOCdWnI7LWJs4cWSHg3
	UrzfBKuk=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com
	k6BAn2KX027286
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns;
	h=received:message-id:to:cc:from:subject:in-reply-to:
	references:date:sender;
	b=bvahVEfcDxFPslWD4sxoKvoG58TF+e86Tr9zVuzt5dffKiavuw4IsZjH/q4naCnBj
	inz5YynJKZHBE09viPRxWa+rlBV04B1deEhQJc+URPDNpIiTGBQc/sdJjgeppCyEbF6
	cvCwvf7bmUcWKlvfC/S73ltZ9GSc7h/ZrNZRPrE=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1])
	by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id k6BAn18l030736;
	Tue, 11 Jul 2006 03:49:01 -0700 (PDT)
	(envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200607111049.k6BAn18l030736@lab.smi.sendmail.com>
To: Tony Finch <dot@dotat.at>
From: Philip Guenther <guenther+lemonade@sendmail.com>
Subject: Re: [lemonade] Notes on Compression
In-Reply-To: <Pine.LNX.4.64.0607102227420.14969@hermes-1.csi.cam.ac.uk>
References: <p06300031c0d8757b2319@[192.168.1.13]>
	<Pine.LNX.4.64.0607102227420.14969@hermes-1.csi.cam.ac.uk>
Date: Tue, 11 Jul 2006 03:49:01 -0700
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: Randall Gellens <randy@qualcomm.com>, lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 10 Jul 2006, Tony Finch wrote:
> On Mon, 10 Jul 2006, Randall Gellens wrote:
>> - ordering: do TLS first (of course), then compression, then SASL. Note that
>> if TLS compression is used, then SASL authentication will be compressed
>> anyway, so may as well compress SASL exchange when using IMAP/Submission
>> compression
>
> Does the profile exclude SASL encryption layers? If not, the order of TLS
> and SASL depends on the SASL mechanism.

I believe Randall's ordering is the order you should turn them one.
I.e., First do STARTTLS, then negotatiate TLS compression, then
AUTHENTICATE.  In terms of the processing of the data stream, the stacking
will still be
	IMAP protocol stream ->
	SASL security layer ->
	TLS w/compression ->
	TCP stream

Yes, that means that you really shouldn't try to use TLS compression
with a SASL security layer that does confidentiality.  Trying to
insert SASL layers into the middle of the TLS processing is a
non-starter...


Philip Guenther


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 11:40:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0KM3-0005Be-SE; Tue, 11 Jul 2006 11:40:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0KM2-0005BJ-9J
	for lemonade@ietf.org; Tue, 11 Jul 2006 11:40:54 -0400
Received: from klee.esys.ca ([198.161.92.168])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0KEc-0008Up-Fb
	for lemonade@ietf.org; Tue, 11 Jul 2006 11:33:16 -0400
Received: from edmholes.am.tsacorp.com (gallileo.esys.ca [198.161.92.72]) by
	klee.esys.ca via TCP (smtp internal) with ESMTPA;
	Tue, 11 Jul 2006 09:33:06 -0600
From: Steve Hole <steve.hole@messagingdirect.com>
Date: Tue, 11 Jul 2006 09:33:03 -0700
To: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Notes on Virtual Mailboxes / Contexts
In-Reply-To: <p06300032c0d876625955@[192.168.1.13]>
References: <p06300032c0d876625955@[192.168.1.13]>
Message-ID: <EXECMAIL.20060711093303.C@edmholes.am.tsacorp.com>
Priority: NORMAL
X-Mailer: Execmail for Win32 6.0.0 alpha Build (1)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 10 Jul 2006 14:28:09 -0700 Randall Gellens <randy@qualcomm.com>=20
wrote:

> Notes on virtual mailboxes/contexts from talking to our client people:
> - not useful if only one backing mailbox

Hmm ... this is interesting.

It is also somewhat counter to our experience.   I suspect that the=20
opinion is based on a "what if scenario" rather than actual experience=20
(not criticizing -- just suggesting that might be the case).

Our experience has been that people don't much care where things are=20
physically stored as long as they can get to them quickly.   Having=20
logical "views" of mail is one of those features that, once you have it,=20
it is almost impossible to do without.  It is, without any doubt, the=20
single most successful feature we have ever incorporated into any our (now
many) messaging systems.   This includes "basic" things like search, sort=
=20
and threads.

Something to think about at any rate.

Cheers.

---
Steve Hole
Chief Technical Officer - Electronic Billing and Payment Systems
ACI Worldwide

Email: holes@aciworldwide.com
Phone: 780 424 4922



_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 13:50:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0MNS-0001Mw-Cy; Tue, 11 Jul 2006 13:50:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MNR-0001Mr-7s
	for lemonade@ietf.org; Tue, 11 Jul 2006 13:50:29 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MNO-00044x-1U
	for lemonade@ietf.org; Tue, 11 Jul 2006 13:50:29 -0400
X-IronPort-AV: i="4.06,230,1149480000"; 
	d="scan'208"; a="35316311:sNHT27614748"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 11 Jul 2006 13:50:22 -0400
Message-ID: <330A23D8336C0346B5C1A5BB1966664703468387@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Compress result code
Thread-Index: AcalEnst4qMlXTYwTRuvbPz1QAMJww==
From: "Burger, Eric" <eburger@cantata.com>
To: "Lemonade WG" <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574
Subject: [lemonade] Compress result code
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Why "NO" if the connection is already compressed?  Wouldn't "OK" be ok?
Otherwise, if the connection is already compressed, and I see a "NO", I
might think that the connection is now no longer compressed.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 13:51:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0MO7-0001QI-KU; Tue, 11 Jul 2006 13:51:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MO6-0001QD-V7
	for lemonade@ietf.org; Tue, 11 Jul 2006 13:51:10 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MO4-0004Cj-59
	for lemonade@ietf.org; Tue, 11 Jul 2006 13:51:10 -0400
Received: from [132.219.2.206] (h02ce-net84db.lab.risq.net [132.219.2.206]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Tue, 11 Jul 2006 18:50:48 +0100
Message-ID: <44B3E4E2.9070102@isode.com>
Date: Tue, 11 Jul 2006 18:50:26 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
Subject: Re: [lemonade] Notes on Compression
References: <p06300031c0d8757b2319@[192.168.1.13]>
	<14344.1152569056.035240@peirce.dave.cridland.net>
In-Reply-To: <14344.1152569056.035240@peirce.dave.cridland.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Dave Cridland wrote:

>> - ordering: do TLS first (of course), then compression, then SASL. 
>> Note that if TLS compression is used, then SASL authentication will 
>> be compressed anyway, so may as well compress SASL exchange when 
>> using IMAP/Submission compression
>
> This is fine, until you consider the case where SASL negotiates a 
> security layer.
>
> Two ways of handling this:
>
> 1) SASL refuses to negotiate a security layer if compression is 
> already in effect. Compression negotiated after a security layer is okay.
>
> 2) SASL negotiates a security layer anyway, and inserts the layer 
> under the existing compression layer.
>
> My implementation of Arnt's draft doesn't do security layers in SASL 
> at all, but I would lean toward (2) - I don't think it's as 
> complicated as it sounds. (I may revise that opinion, though). 

I am also leaning toward 2).


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 13:52:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0MOx-0001Xc-74; Tue, 11 Jul 2006 13:52:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MOw-0001XX-Di
	for lemonade@ietf.org; Tue, 11 Jul 2006 13:52:02 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MOv-0004ij-7v
	for lemonade@ietf.org; Tue, 11 Jul 2006 13:52:02 -0400
X-IronPort-AV: i="4.06,230,1149480000"; 
	d="scan'208"; a="35316353:sNHT26955432"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 11 Jul 2006 13:51:59 -0400
Message-ID: <330A23D8336C0346B5C1A5BB196666470346838A@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Compress responses
Thread-Index: AcalErVNsGeU2SBySN6jURKC1u+bPg==
From: "Burger, Eric" <eburger@cantata.com>
To: "Lemonade WG" <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Subject: [lemonade] Compress responses
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Make it clear the responses are in clear text.

That does raise the issue of someone requesting compression of a
compressed stream.  I doubt they would get the 4 octet string
"NO<cr><lf>"; they would probably get some byte or bit stream
representing NO.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 16:04:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0OTM-0002vI-EF; Tue, 11 Jul 2006 16:04:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OTL-0002uw-Eu
	for lemonade@ietf.org; Tue, 11 Jul 2006 16:04:43 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OTK-00056b-3x
	for lemonade@ietf.org; Tue, 11 Jul 2006 16:04:43 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BK4eYi010809
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 13:04:41 -0700
Received: from [142.131.134.210] (vpn-10-50-16-148.qualcomm.com [10.50.16.148])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BK4clL001613; Tue, 11 Jul 2006 13:04:39 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630000ac0d9b29ba1a9@[142.131.134.210]>
In-Reply-To: <EXECMAIL.20060711093303.C@edmholes.am.tsacorp.com>
References: <p06300032c0d876625955@[192.168.1.13]>
	<EXECMAIL.20060711093303.C@edmholes.am.tsacorp.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 13:00:27 -0700
To: Steve Hole <steve.hole@messagingdirect.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Notes on Virtual Mailboxes / Contexts
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 9:33 AM -0700 7/11/06, Steve Hole wrote:

>  On Mon, 10 Jul 2006 14:28:09 -0700 Randall Gellens <randy@qualcomm.com>
>  wrote:
>
>>  Notes on virtual mailboxes/contexts from talking to our client people:
>>  - not useful if only one backing mailbox
>
>  Hmm ... this is interesting.

Hi Steve -- good to see you here.

>
>  It is also somewhat counter to our experience.   I suspect that the
>  opinion is based on a "what if scenario" rather than actual experience
>  (not criticizing -- just suggesting that might be the case).

It is an impression from looking at adding a feature to a client, not 
from experience using the feature.

>  Our experience has been that people don't much care where things are
>  physically stored as long as they can get to them quickly.

But people may have desktop clients and/or server-based filtering, 
and hence already have mail in various mailboxes.

>  Having logical "views" of mail is one of those features that, once 
> you have it,
>  it is almost impossible to do without.  It is, without any doubt, the
>  single most successful feature we have ever incorporated into any our (now
>  many) messaging systems.   This includes "basic" things like search, sort
>  and threads.

But is this a logical view limited to one mailbox, or is it something 
that, as far as the user is concerned, mostly ignores details such as 
which mailbox a message happens to be in?

>  Something to think about at any rate.

Something I'd like to understand better.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
We must respect the other fellow's religion, but only in the sense and to
the extent that we respect his theory that his wife is beautiful and his
children are smart.                                      --H.L. Mencken

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 18:44:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0Qxb-0002JX-BM; Tue, 11 Jul 2006 18:44:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Qxa-0002JK-KV
	for lemonade@ietf.org; Tue, 11 Jul 2006 18:44:06 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0QxZ-0001Sb-5r
	for lemonade@ietf.org; Tue, 11 Jul 2006 18:44:06 -0400
Received: from [132.219.2.206] (h02ce-net84db.lab.risq.net [132.219.2.206]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Tue, 11 Jul 2006 23:43:53 +0100
Message-ID: <44B42993.9040809@isode.com>
Date: Tue, 11 Jul 2006 23:43:31 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Burger, Eric" <eburger@cantata.com>
Subject: Re: [lemonade] Compress result code
References: <330A23D8336C0346B5C1A5BB1966664703468387@ATLANTIS.Brooktrout.com>
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703468387@ATLANTIS.Brooktrout.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Burger, Eric wrote:

>Why "NO" if the connection is already compressed?  Wouldn't "OK" be ok?
>Otherwise, if the connection is already compressed, and I see a "NO", I
>might think that the connection is now no longer compressed.
>  
>
The client must know if application level compression is already running 
or not. The client must not attempt to do something which is guaranteed 
to fail.
The server should actually return BAD in this case, IMHO.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 18:46:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0Qzi-0002nw-By; Tue, 11 Jul 2006 18:46:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Qzh-0002nr-8C
	for lemonade@ietf.org; Tue, 11 Jul 2006 18:46:17 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Qzg-0001X7-21
	for lemonade@ietf.org; Tue, 11 Jul 2006 18:46:17 -0400
X-IronPort-AV: i="4.06,230,1149480000"; 
	d="scan'208"; a="35322877:sNHT39285688"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] Compress result code
Date: Tue, 11 Jul 2006 18:46:12 -0400
Message-ID: <330A23D8336C0346B5C1A5BB1966664703468574@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] Compress result code
Thread-Index: AcalO8uF7W0DyFViTMeI2KtvYi3JRAAAAGxw
From: "Burger, Eric" <eburger@cantata.com>
To: "Alexey Melnikov" <alexey.melnikov@isode.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

I could live with this, too.

-----Original Message-----
From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20
Sent: Tuesday, July 11, 2006 6:44 PM
To: Burger, Eric
Cc: Lemonade WG
Subject: Re: [lemonade] Compress result code

Burger, Eric wrote:

>Why "NO" if the connection is already compressed?  Wouldn't "OK" be ok?
>Otherwise, if the connection is already compressed, and I see a "NO", I
>might think that the connection is now no longer compressed.
> =20
>
The client must know if application level compression is already running

or not. The client must not attempt to do something which is guaranteed=20
to fail.
The server should actually return BAD in this case, IMHO.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 19:07:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0RJq-0002vC-0q; Tue, 11 Jul 2006 19:07:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RJn-0002tt-UR
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:07:03 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RJn-0005W1-Ry
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:07:03 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0RJj-0006oH-U4
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:07:03 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by heisenberg.zen.co.uk with esmtp (Exim 4.30)
	id 1G0RJa-0007a4-HI; Tue, 11 Jul 2006 23:06:50 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 1707B498003;
	Wed, 12 Jul 2006 00:08:12 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 27081-03; Wed, 12 Jul 2006 00:08:09 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown
	[IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a])
	by turner.dave.cridland.net (Postfix) with ESMTP id 5A163498002;
	Wed, 12 Jul 2006 00:08:09 +0100 (BST)
Date: Wed, 12 Jul 2006 00:06:47 +0100
Subject: Re: [lemonade] Compress result code
References: <330A23D8336C0346B5C1A5BB1966664703468387@ATLANTIS.Brooktrout.com>
In-Reply-To: <330A23D8336C0346B5C1A5BB1966664703468387@ATLANTIS.Brooktrout.com>
MIME-Version: 1.0
Message-Id: <14344.1152659207.307413@peirce.dave.cridland.net>
From: Dave Cridland <dave@cridland.net>
To: "Burger\, Eric" <eburger@cantata.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Heisenberg-IP: [217.155.137.60]
X-Spam-Score: -2.2 (--)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Tue Jul 11 18:50:22 2006, Burger, Eric wrote:
> Why "NO" if the connection is already compressed?  Wouldn't "OK" be 
> ok?
> Otherwise, if the connection is already compressed, and I see a 
> "NO", I
> might think that the connection is now no longer compressed.

In my code, a successful result to a COMPRESS command inserts a new 
compression layer.

NO is fine.

BAD is arguably better, except that there are times when you don't 
know if the TLS layer has already done compression for you, as a 
client, so it's a good faith error - a NO - rather than a bug - a BAD.

I'd be happy with a second COMPRESS command causing a BAD, though.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 19:12:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0RP8-0004JK-CQ; Tue, 11 Jul 2006 19:12:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RP7-0004JF-JO
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:12:33 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RP6-0005lM-8N
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:12:33 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6BNCQAh010169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 11 Jul 2006 16:12:26 -0700
Received: from [142.131.134.210] (vpn-10-50-0-114.qualcomm.com [10.50.0.114])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6BNCKLc019954; Tue, 11 Jul 2006 16:12:22 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300011c0d9df714c89@[142.131.134.210]>
In-Reply-To: <44B42993.9040809@isode.com>
References: <330A23D8336C0346B5C1A5BB1966664703468387@ATLANTIS.Brooktrout.com>
	<44B42993.9040809@isode.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Tue, 11 Jul 2006 16:10:18 -0700
To: Alexey Melnikov <alexey.melnikov@isode.com>,
	"Burger, Eric" <eburger@cantata.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] Compress result code
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: Lemonade WG <lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 11:43 PM +0100 7/11/06, Alexey Melnikov wrote:

>  Burger, Eric wrote:
>
>>  Why "NO" if the connection is already compressed?  Wouldn't "OK" be ok?
>>  Otherwise, if the connection is already compressed, and I see a "NO", I
>>  might think that the connection is now no longer compressed.
>>
>  The client must know if application level compression is already 
> running or not. The client must not attempt to do something which 
> is guaranteed to fail.
>  The server should actually return BAD in this case, IMHO.

This seems to be an order of command (state) error.  RFC 3501 says:

    It is a protocol error for the
    client to attempt a command while the connection is in an
    inappropriate state, and the server will respond with a BAD or
    NO (depending upon server implementation) command completion
    result.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
How does a project get to be a year behind schedule?
One day at a time.   --Fred Brooks in _The Mythical Man Month_

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 19:13:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0RQK-0004NV-NP; Tue, 11 Jul 2006 19:13:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RQJ-0004NO-Ea
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:13:47 -0400
Received: from pythagoras.zen.co.uk ([212.23.3.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RQH-0005oQ-0Y
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:13:47 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by pythagoras.zen.co.uk with esmtp (Exim 4.30)
	id 1G0RQF-0002TU-7h; Tue, 11 Jul 2006 23:13:43 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 11ACE498003;
	Wed, 12 Jul 2006 00:15:05 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 27081-06; Wed, 12 Jul 2006 00:14:56 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown
	[IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a])
	by turner.dave.cridland.net (Postfix) with ESMTP id 8C5D3498002;
	Wed, 12 Jul 2006 00:14:56 +0100 (BST)
Date: Wed, 12 Jul 2006 00:13:34 +0100
Subject: Re: [lemonade] Notes on Virtual Mailboxes / Contexts
References: <p06300032c0d876625955@[192.168.1.13]>
	<EXECMAIL.20060711093303.C@edmholes.am.tsacorp.com>
In-Reply-To: <EXECMAIL.20060711093303.C@edmholes.am.tsacorp.com>
MIME-Version: 1.0
Message-Id: <14344.1152659614.463747@peirce.dave.cridland.net>
From: Dave Cridland <dave@cridland.net>
To: Steve Hole <steve.hole@messagingdirect.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Pythagoras-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>, Randall Gellens <randy@qualcomm.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Tue Jul 11 17:33:03 2006, Steve Hole wrote:
> On Mon, 10 Jul 2006 14:28:09 -0700 Randall Gellens 
> <randy@qualcomm.com> wrote:
> 
> > Notes on virtual mailboxes/contexts from talking to our client 
> people:
> > - not useful if only one backing mailbox
> 
> Hmm ... this is interesting.
> 
> 
This is my opinion on virtual mailboxes.

Contexts I actively use existing fallbacks for - ie, I have filtered 
views setup client-side that I frequently use. These are based on 
IMAP SEARCH, just as both contexts and virtual mailboxes are.


> It is also somewhat counter to our experience.   I suspect that the 
> opinion is based on a "what if scenario" rather than actual 
> experience (not criticizing -- just suggesting that might be the 
> case).
> 
> Our experience has been that people don't much care where things 
> are physically stored as long as they can get to them quickly.   
> Having logical "views" of mail is one of those features that, once 
> you have it, it is almost impossible to do without.  It is, without 
> any doubt, the single most successful feature we have ever 
> incorporated into any our (now
> many) messaging systems.   This includes "basic" things like 
> search, sort and threads.

I think you're actually agreeing with Randy's point here in a sense - 
virtual mailboxes based on a single mailbox are not interesting - 
virtual mailboxes capable of being based on all mailboxes are 
interesting.

Of course, if there is only one mailbox, the two issues are collapsed.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 19:18:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0RUx-00056v-V8; Tue, 11 Jul 2006 19:18:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RUw-00056q-FE
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:18:34 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RUu-0005wg-VP
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:18:34 -0400
X-IronPort-AV: i="4.06,230,1149480000"; 
	d="scan'208,217"; a="35323461:sNHT46294200"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: Re: [lemonade] Compress result code
Date: Tue, 11 Jul 2006 19:20:30 -0400
Message-ID: <330A23D8336C0346B5C1A5BB196666470231C56F@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] Compress result code
Thread-Index: AcalPv0P5NGsiQjcS6uh79Oz24o0ZwAAZ1ya
From: "Burger, Eric" <eburger@cantata.com>
To: "Dave Cridland" <dave@cridland.net>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0301716477=="
Errors-To: lemonade-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0301716477==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6A540.9A2C16BC"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A540.9A2C16BC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

How would a client not know? If it loses its mind and decides, "I want =
compression now," the server KEEPS COMPRESSION ON and says, "Here you =
go: compression is on."

Or, am I missing the point: the client, which by the way is already =
handling transport-layer encryption (because it can have a dialog with =
the server in the first place) is really going to invoke another =
instance of a transport-layer compression engine that will compress / =
decompress the already compressed stream?

--
Sent from my Palm Treo - Sorry if Terse

 -----Original Message-----
From: 	Dave Cridland [mailto:dave@cridland.net]
Sent:	Tuesday, July 11, 2006 07:08 PM Eastern Standard Time
To:	Burger, Eric
Cc:	Enhancements to Internet email to support diverse service =
enivronments
Subject:	Re: [lemonade] Compress result code

On Tue Jul 11 18:50:22 2006, Burger, Eric wrote:
> Why "NO" if the connection is already compressed?  Wouldn't "OK" be=20
> ok?
> Otherwise, if the connection is already compressed, and I see a=20
> "NO", I
> might think that the connection is now no longer compressed.

In my code, a successful result to a COMPRESS command inserts a new=20
compression layer.

NO is fine.

BAD is arguably better, except that there are times when you don't=20
know if the TLS layer has already done compression for you, as a=20
client, so it's a good faith error - a NO - rather than a bug - a BAD.

I'd be happy with a second COMPRESS command causing a BAD, though.

Dave.
--=20
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

------_=_NextPart_001_01C6A540.9A2C16BC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [lemonade] Compress result code</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>How would a client not know? If it loses its mind and =
decides, &quot;I want compression now,&quot; the server KEEPS =
COMPRESSION ON and says, &quot;Here you go: compression is on.&quot;<BR>
<BR>
Or, am I missing the point: the client, which by the way is already =
handling transport-layer encryption (because it can have a dialog with =
the server in the first place) is really going to invoke another =
instance of a transport-layer compression engine that will compress / =
decompress the already compressed stream?<BR>
<BR>
--<BR>
Sent from my Palm Treo - Sorry if Terse<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Dave Cridland [<A =
HREF=3D"mailto:dave@cridland.net">mailto:dave@cridland.net</A>]<BR>
Sent:&nbsp;&nbsp; Tuesday, July 11, 2006 07:08 PM Eastern Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Burger, Eric<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; Enhancements to Internet email to support =
diverse service enivronments<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [lemonade] =
Compress result code<BR>
<BR>
On Tue Jul 11 18:50:22 2006, Burger, Eric wrote:<BR>
&gt; Why &quot;NO&quot; if the connection is already compressed?&nbsp; =
Wouldn't &quot;OK&quot; be<BR>
&gt; ok?<BR>
&gt; Otherwise, if the connection is already compressed, and I see a<BR>
&gt; &quot;NO&quot;, I<BR>
&gt; might think that the connection is now no longer compressed.<BR>
<BR>
In my code, a successful result to a COMPRESS command inserts a new<BR>
compression layer.<BR>
<BR>
NO is fine.<BR>
<BR>
BAD is arguably better, except that there are times when you don't<BR>
know if the TLS layer has already done compression for you, as a<BR>
client, so it's a good faith error - a NO - rather than a bug - a =
BAD.<BR>
<BR>
I'd be happy with a second COMPRESS command causing a BAD, though.<BR>
<BR>
Dave.<BR>
--<BR>
Dave Cridland - <A =
HREF=3D"mailto:dave@cridland.net">mailto:dave@cridland.net</A> - =
xmpp:dwd@jabber.org<BR>
&nbsp; - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/<BR>
&nbsp; - <A =
HREF=3D"http://dave.cridland.net/">http://dave.cridland.net/</A><BR>
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A540.9A2C16BC--


--===============0301716477==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--===============0301716477==--




From lemonade-bounces@ietf.org Tue Jul 11 19:27:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0Rdf-0006ny-7l; Tue, 11 Jul 2006 19:27:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Rdd-0006mD-W2
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:27:33 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Rdc-0006Eq-M9
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:27:33 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by heisenberg.zen.co.uk with esmtp (Exim 4.30)
	id 1G0Rdb-0006Ad-TV; Tue, 11 Jul 2006 23:27:31 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id E790F498003;
	Wed, 12 Jul 2006 00:28:53 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 27262-04; Wed, 12 Jul 2006 00:28:45 +0100 (BST)
Received: from peirce.dave.cridland.net (unknown
	[IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a])
	by turner.dave.cridland.net (Postfix) with ESMTP id 687FC498002;
	Wed, 12 Jul 2006 00:28:45 +0100 (BST)
Date: Wed, 12 Jul 2006 00:27:23 +0100
Subject: Re: [lemonade] Compress result code
References: <330A23D8336C0346B5C1A5BB196666470231C56F@ATLANTIS.Brooktrout.com>
In-Reply-To: <330A23D8336C0346B5C1A5BB196666470231C56F@ATLANTIS.Brooktrout.com>
MIME-Version: 1.0
Message-Id: <14344.1152660443.198534@peirce.dave.cridland.net>
From: Dave Cridland <dave@cridland.net>
To: "Burger\, Eric" <eburger@cantata.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Heisenberg-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Wed Jul 12 00:20:30 2006, Burger, Eric wrote:
> How would a client not know? If it loses its mind and decides, "I 
> want compression now," the server KEEPS COMPRESSION ON and says, 
> "Here you go: compression is on."
> 
> 
My client has, unfortunately, no idea at all if the TLS 
implementation has negotiated compression. It's a product of the API. 
So where TLS is compressing, I want COMPRESS to say NO. If it said 
BAD, it'd raise a dialog box telling the user I screwed up.


> Or, am I missing the point: the client, which by the way is already 
> handling transport-layer encryption (because it can have a dialog 
> with the server in the first place) is really going to invoke 
> another instance of a transport-layer compression engine that will 
> compress / decompress the already compressed stream?

Transport-layer, no. Application layer, yes.

If my client were to send two COMPRESS commands, then an OK to the 
second would break it. It'd be broken anyway, of course, in order to 
send the second COMPRESS, so realistically, I think we should say BAD 
here.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 19:37:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0RnQ-0007ge-4W; Tue, 11 Jul 2006 19:37:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RnO-0007gQ-8s
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:37:38 -0400
Received: from orthanc.ca ([2002:d159:4635::1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RnM-0006Vh-Mi
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:37:38 -0400
Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0)
	by orthanc.ca (8.13.4/8.13.4) with ESMTP id k6BNbQhl071029
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Jul 2006 17:37:26 -0600 (MDT)
	(envelope-from lyndon@orthanc.ca)
Date: Tue, 11 Jul 2006 17:37:26 -0600 (MDT)
From: Lyndon Nerenberg <lyndon@orthanc.ca>
To: Dave Cridland <dave@cridland.net>
Subject: Re: [lemonade] Compress result code
In-Reply-To: <14344.1152660443.198534@peirce.dave.cridland.net>
Message-ID: <20060711173228.D68440@orthanc.ca>
References: <330A23D8336C0346B5C1A5BB196666470231C56F@ATLANTIS.Brooktrout.com>
	<14344.1152660443.198534@peirce.dave.cridland.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS 
	autolearn=ham version=3.1.3
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on orthanc.ca
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

> If my client were to send two COMPRESS commands, then an OK to the second 
> would break it. It'd be broken anyway, of course, in order to send the second 
> COMPRESS, so realistically, I think we should say BAD here.

If your client can't tell what the TLS layer is doing then it cannot know 
that the TLS layer didn't decide to turn compression off (why is 
immaterial) after that first COMPRESS command was issued.

Since the IMAP stream cannot know what the TLS layer is doing, COMPRESS is 
at best a hint, and could very well be a no-op.  Therefore the responses 
of OK and NO are equally valid (and content free), and BAD should only be 
issued when the server does not support the COMPRESS command at all.

--lyndon

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 19:48:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0RxS-0000kf-Vb; Tue, 11 Jul 2006 19:48:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RxR-0000ka-Qx
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:48:01 -0400
Received: from smtp-out.sendmail.com ([209.246.26.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0RxQ-0000Af-DB
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:48:01 -0400
Received: from lab.smi.sendmail.com ([10.210.100.93])
	by foon.sendmail.com (Switch-3.2.2/Switch-3.2.0) with ESMTP id
	k6BNlnPf017721
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 11 Jul 2006 16:47:50 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k6BNlnPf017721
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim;
	t=1152661671; bh=o7yKPAGvJ250qYqjzG6t3OZyAjM=; h=X-DomainKeys:
	DomainKey-Signature:Received:Message-Id:From:To:Cc:Subject:Date:
	Sender; b=Hlws73KtWaNOC7BDbBtE30KhJwUeCa6HtTrIqXBLH6zS6ISpTHDr+Nytj
	sYoN3s7CFkW8ej/4oGC6JeGXg4moQ2QyRGrszUmOXXAubPSkIapkmDoiU6hqdtODD0k
	HresroSzeieS9KYN+QoV7Kjt0WhKFXE2Wqve6PbnVt0qrbs=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com
	k6BNlnPf017721
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns;
	h=received:message-id:from:to:cc:subject:date:sender;
	b=XHXJGZ2J4gh5UTeP6509Ilr5GUOpxTEfe5XaRBezFh/lyOt0CWyrnxx+n80JzCtwA
	RcZbOikXSg9DLlUxEAgtlrUfjgADt8r4gIPAGPIdIVvLOlW/JX9mgMmGuygC5jNXrbH
	JCg3KHxRAm/CgA+Zw5nI4adSemNAAPi6JgDLNW4=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1])
	by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id k6BNlnen052698;
	Tue, 11 Jul 2006 16:47:49 -0700 (PDT)
	(envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200607112347.k6BNlnen052698@lab.smi.sendmail.com>
From: Philip Guenhter <guenther+lemonade@sendmail.com>
To: Dave Cridland <dave@cridland.net>
Subject: Re: [lemonade] Compress result code
Date: Tue, 11 Jul 2006 16:47:49 -0700
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Wed, 12 Jul 2006, Dave Cridland wrote:
...
> My client has, unfortunately, no idea at all if the TLS implementation has
> negotiated compression. It's a product of the API. So where TLS is
> compressing, I want COMPRESS to say NO. If it said BAD, it'd raise a dialog
> box telling the user I screwed up.

While a server _could_ refuse to support COMPRESS if TLS-level compression
has been negotiated, I don't think it conceptually needs to be banned.  It
certainly isn't a direct result of the model, as they are not a the same
layer.  Indeed, if there's a SASL layer (perhaps integrity), then the SASL
layer would be between COMPRESS's compression and TLS (and its
compression).

btw, is there any reason to believe the server's TLS library is more
likely to support determination of whether compression has been
negotiated?


Philip Guenther


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 19:56:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0S5O-0001zh-9u; Tue, 11 Jul 2006 19:56:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0S5M-0001zX-Ur
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:56:12 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0S5L-0000NT-HQ
	for lemonade@ietf.org; Tue, 11 Jul 2006 19:56:12 -0400
Received: from [132.219.2.206] (h02ce-net84db.lab.risq.net [132.219.2.206]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Wed, 12 Jul 2006 00:56:03 +0100
Message-ID: <44B43A8C.80807@isode.com>
Date: Wed, 12 Jul 2006 00:55:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Lyndon Nerenberg <lyndon@orthanc.ca>
Subject: Re: [lemonade] Compress result code
References: <330A23D8336C0346B5C1A5BB196666470231C56F@ATLANTIS.Brooktrout.com>	<14344.1152660443.198534@peirce.dave.cridland.net>
	<20060711173228.D68440@orthanc.ca>
In-Reply-To: <20060711173228.D68440@orthanc.ca>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: support diverse service enivronments <lemonade@ietf.org>, Enhancements
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Lyndon Nerenberg wrote:

>> If my client were to send two COMPRESS commands, then an OK to the 
>> second would break it. It'd be broken anyway, of course, in order to 
>> send the second COMPRESS, so realistically, I think we should say BAD 
>> here.
>
> If your client can't tell what the TLS layer is doing then it cannot 
> know that the TLS layer didn't decide to turn compression off (why is 
> immaterial) after that first COMPRESS command was issued.

Right.

> Since the IMAP stream cannot know what the TLS layer is doing, 
> COMPRESS is at best a hint, and could very well be a no-op.  Therefore 
> the responses of OK and NO are equally valid

I am Ok with this.

> (and content free),

> and BAD should only be issued when the server does not support the 
> COMPRESS command at all.

If the client sends COMPRESS twice this is clearly an error and the 
second COMPRESS must result in BAD. But I wouldn't complain about server 
that sends NO.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Tue Jul 11 21:01:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0T6Q-0006FD-5A; Tue, 11 Jul 2006 21:01:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0T6P-0006F7-5v
	for lemonade@ietf.org; Tue, 11 Jul 2006 21:01:21 -0400
Received: from orthanc.ca ([2002:d159:4635::1])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0T6N-0001rS-Ja
	for lemonade@ietf.org; Tue, 11 Jul 2006 21:01:21 -0400
Received: from [192.168.15.2] (d154-5-28-131.bchsia.telus.net [154.5.28.131])
	(authenticated bits=0)
	by orthanc.ca (8.13.4/8.13.4) with ESMTP id k6C11Dxa071463;
	Tue, 11 Jul 2006 19:01:13 -0600 (MDT)
	(envelope-from lyndon@orthanc.ca)
In-Reply-To: <44B43A8C.80807@isode.com>
References: <330A23D8336C0346B5C1A5BB196666470231C56F@ATLANTIS.Brooktrout.com>	<14344.1152660443.198534@peirce.dave.cridland.net>
	<20060711173228.D68440@orthanc.ca> <44B43A8C.80807@isode.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3CA55DCB-B205-4F4B-B062-C9CF8CEC1A28@orthanc.ca>
Content-Transfer-Encoding: 7bit
From: Lyndon Nerenberg <lyndon@orthanc.ca>
Subject: Re: [lemonade] Compress result code
Date: Tue, 11 Jul 2006 18:01:07 -0700
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,RCVD_IN_NJABL_DUL 
	autolearn=no version=3.1.3
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on orthanc.ca
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org


On Jul 11, 2006, at 4:55 PM, Alexey Melnikov wrote:

> If the client sends COMPRESS twice this is clearly an error and the  
> second COMPRESS must result in BAD. But I wouldn't complain about  
> server that sends NO.

No it's not, since the client cannot reliably determine the state of  
compression at any given moment.  And why the hell should the server  
even care?  Tracking the state is just extra useless code in the server.

--lyndon

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 12 04:05:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0ZiM-00010t-L6; Wed, 12 Jul 2006 04:04:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ZiL-000102-40
	for lemonade@ietf.org; Wed, 12 Jul 2006 04:04:57 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ZiL-0006W7-2P
	for lemonade@ietf.org; Wed, 12 Jul 2006 04:04:57 -0400
Received: from rutherford.zen.co.uk ([212.23.3.142])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0Zey-0007JU-Hw
	for lemonade@ietf.org; Wed, 12 Jul 2006 04:01:30 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by rutherford.zen.co.uk with esmtp (Exim 4.34)
	id 1G0Zex-0005iV-K7; Wed, 12 Jul 2006 08:01:27 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 4420F498003;
	Wed, 12 Jul 2006 09:02:53 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 29599-07; Wed, 12 Jul 2006 09:02:44 +0100 (BST)
Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:1514:9be0:f4c4:fd9])
	by turner.dave.cridland.net (Postfix) with ESMTP id D4024498002;
	Wed, 12 Jul 2006 09:02:43 +0100 (BST)
Date: Wed, 12 Jul 2006 09:01:13 +0100
Subject: Re: [lemonade] Compress result code
References: <200607112347.k6BNlnen052698@lab.smi.sendmail.com>
In-Reply-To: <200607112347.k6BNlnen052698@lab.smi.sendmail.com>
MIME-Version: 1.0
Message-Id: <2936.1152691274.227000@JOHN>
From: Dave Cridland <dave@cridland.net>
To: Philip Guenhter <guenther+lemonade@sendmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Wed Jul 12 00:47:49 2006, Philip Guenhter wrote:
> On Wed, 12 Jul 2006, Dave Cridland wrote:
> ...
> > My client has, unfortunately, no idea at all if the TLS 
> implementation has
> > negotiated compression. It's a product of the API. So where TLS is
> > compressing, I want COMPRESS to say NO. If it said BAD, it'd 
> raise a dialog
> > box telling the user I screwed up.
> 
> While a server _could_ refuse to support COMPRESS if TLS-level 
> compression
> has been negotiated, I don't think it conceptually needs to be 
> banned.  It
> certainly isn't a direct result of the model, as they are not a the 
> same
> layer.  Indeed, if there's a SASL layer (perhaps integrity), then 
> the SASL
> layer would be between COMPRESS's compression and TLS (and its
> compression).
> 
> 
Indeed. It doesn't hurt interop to have both TLS and COMPRESS doing 
compression, it's just silly. Silly is a "SHOULD respond with NO" 
situation. If the client is trying to have two COMPRESS compression 
layers, this is broken. Broken is a "MUST respond with BAD" situation.

What you probably want to do, in an ideal world, is renegotiate TLS 
compression off when you receive a "silly" COMPRESS command and 
respond OK - this is because you can control the compression 
algorithm much better through, say, the zlib API, and achieve much 
better compression.


> btw, is there any reason to believe the server's TLS library is more
> likely to support determination of whether compression has been
> negotiated?
> 
> 
My particular instance is where my client only has access to the 
standard Python library, in which case it has the ability to start 
TLS, and not even access the certificates. The specific openssl API I 
use where available (PyOpenSSL) has a much better API, but that's 
still lacking compression information. I'm not clear if Symbian, for 
instance, has the API calls to handle this either.

For servers, the prevelant implementation, OpenSSL, only supports 
compression from it's 0.9.8 stream, which in turn has a distinct API 
from 0.9.7, forcing explicit support, and has the API relevant to 
discovering if it has negotiated compression or not.

It is possible that a server may not have the ability to know if TLS 
compression is happening, of course, but I'd say it's a less likely 
situation than in clients, and will probably remain so.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 12 08:03:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0dQi-00073I-9d; Wed, 12 Jul 2006 08:03:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0dQg-0006xT-V3
	for lemonade@ietf.org; Wed, 12 Jul 2006 08:02:58 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ZiN-0006W7-VY
	for lemonade@ietf.org; Wed, 12 Jul 2006 04:05:00 -0400
Received: from rutherford.zen.co.uk ([212.23.3.142])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0ZSv-00079B-26
	for lemonade@ietf.org; Wed, 12 Jul 2006 03:49:03 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by rutherford.zen.co.uk with esmtp (Exim 4.34)
	id 1G0ZSt-0007ca-3l; Wed, 12 Jul 2006 07:48:59 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 91F70498003;
	Wed, 12 Jul 2006 08:50:24 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 29621-02; Wed, 12 Jul 2006 08:50:15 +0100 (BST)
Received: from JOHN (unknown [IPv6:2001:4bd0:2029:0:1514:9be0:f4c4:fd9])
	by turner.dave.cridland.net (Postfix) with ESMTP id E1EFC498002;
	Wed, 12 Jul 2006 08:50:14 +0100 (BST)
Date: Wed, 12 Jul 2006 08:48:43 +0100
Subject: Re: [lemonade] Compress result code
References: <330A23D8336C0346B5C1A5BB196666470231C56F@ATLANTIS.Brooktrout.com>
	<14344.1152660443.198534@peirce.dave.cridland.net>
	<20060711173228.D68440@orthanc.ca>
In-Reply-To: <20060711173228.D68440@orthanc.ca>
MIME-Version: 1.0
Message-Id: <2936.1152690525.401000@JOHN>
From: Dave Cridland <dave@cridland.net>
To: Lyndon Nerenberg <lyndon@orthanc.ca>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Wed Jul 12 00:37:26 2006, Lyndon Nerenberg wrote:
>> If my client were to send two COMPRESS commands, then an OK to the 
>> second would break it. It'd be broken anyway, of course, in order 
>> to send the second COMPRESS, so realistically, I think we should 
>> say BAD here.
> 
> If your client can't tell what the TLS layer is doing then it 
> cannot know that the TLS layer didn't decide to turn compression 
> off (why is immaterial) after that first COMPRESS command was 
> issued.
> 
> 
This, and other cases, are all true, but not cases that I 
particularly care about optimizing for.


> Since the IMAP stream cannot know what the TLS layer is doing, 
> COMPRESS is at best a hint, and could very well be a no-op.  
> Therefore the responses of OK and NO are equally valid (and content 
> free), and BAD should only be issued when the server does not 
> support the COMPRESS command at all.

Reading this and subsequent messages makes me think you've 
misunderstood the draft.

The client might not know about TLS level compression, and even the 
server might not. But both absolutely should know about application 
layer compression, because they're doing it.

If an application tries to insert two compression layers, this is 
obviously an error. It's an excusable error if the two compression 
layers are in different locations in the stack, although both ends 
should be trying to avoid this, but it's a programming error if the 
two layers are the same.

In particular, the COMPRESS command is never a no-op if it succeeds.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 12 14:44:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G0jha-0001vj-Dz; Wed, 12 Jul 2006 14:44:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jhZ-0001ve-B7
	for lemonade@ietf.org; Wed, 12 Jul 2006 14:44:49 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jhX-0003YC-0F
	for lemonade@ietf.org; Wed, 12 Jul 2006 14:44:49 -0400
X-IronPort-AV: i="4.06,236,1149480000"; 
	d="scan'208"; a="35352612:sNHT43407792"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] Compress result code
Date: Wed, 12 Jul 2006 14:44:38 -0400
Message-ID: <330A23D8336C0346B5C1A5BB19666647034688E3@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] Compress result code
Thread-Index: AcalijOZuJb8R6/AQeeYDghoqSEFIAAWP9nQ
From: "Burger, Eric" <eburger@cantata.com>
To: "Dave Cridland" <dave@cridland.net>,
	"Philip Guenhter" <guenther+lemonade@sendmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

I like this.

-----Original Message-----
From: Dave Cridland [mailto:dave@cridland.net]=20
Sent: Wednesday, July 12, 2006 4:01 AM
To: Philip Guenhter
Cc: Enhancements to Internet email to support diverse service
enivronments
Subject: Re: [lemonade] Compress result code

On Wed Jul 12 00:47:49 2006, Philip Guenhter wrote:
> On Wed, 12 Jul 2006, Dave Cridland wrote:
> ...
> > My client has, unfortunately, no idea at all if the TLS=20
> implementation has
> > negotiated compression. It's a product of the API. So where TLS is
> > compressing, I want COMPRESS to say NO. If it said BAD, it'd=20
> raise a dialog
> > box telling the user I screwed up.
>=20
> While a server _could_ refuse to support COMPRESS if TLS-level=20
> compression
> has been negotiated, I don't think it conceptually needs to be=20
> banned.  It
> certainly isn't a direct result of the model, as they are not a the=20
> same
> layer.  Indeed, if there's a SASL layer (perhaps integrity), then=20
> the SASL
> layer would be between COMPRESS's compression and TLS (and its
> compression).
>=20
>=20
Indeed. It doesn't hurt interop to have both TLS and COMPRESS doing=20
compression, it's just silly. Silly is a "SHOULD respond with NO"=20
situation. If the client is trying to have two COMPRESS compression=20
layers, this is broken. Broken is a "MUST respond with BAD" situation.

What you probably want to do, in an ideal world, is renegotiate TLS=20
compression off when you receive a "silly" COMPRESS command and=20
respond OK - this is because you can control the compression=20
algorithm much better through, say, the zlib API, and achieve much=20
better compression.


> btw, is there any reason to believe the server's TLS library is more
> likely to support determination of whether compression has been
> negotiated?
>=20
>=20
My particular instance is where my client only has access to the=20
standard Python library, in which case it has the ability to start=20
TLS, and not even access the certificates. The specific openssl API I=20
use where available (PyOpenSSL) has a much better API, but that's=20
still lacking compression information. I'm not clear if Symbian, for=20
instance, has the API calls to handle this either.

For servers, the prevelant implementation, OpenSSL, only supports=20
compression from it's 0.9.8 stream, which in turn has a distinct API=20
from 0.9.7, forcing explicit support, and has the API relevant to=20
discovering if it has negotiated compression or not.

It is possible that a server may not have the ability to know if TLS=20
compression is happening, of course, but I'd say it's a less likely=20
situation than in clients, and will probably remain so.

Dave.
--=20
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 17 15:50:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2Z6f-0004gF-4T; Mon, 17 Jul 2006 15:50:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G2Z6S-0004dB-OC; Mon, 17 Jul 2006 15:50:04 -0400
Received: from oak.neustar.com ([209.173.53.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G2Z6Q-00007c-5B; Mon, 17 Jul 2006 15:50:04 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6HJo11u023872
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Jul 2006 19:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1G2Z6P-0007ZB-OR; Mon, 17 Jul 2006 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1G2Z6P-0007ZB-OR@stiedprstage1.ietf.org>
Date: Mon, 17 Jul 2006 15:50:01 -0400
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: lemonade@ietf.org
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-02.txt 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: The IMAP COMPRESS=DEFLATE Extension
	Author(s)	: A. Gulbrandsen
	Filename	: draft-ietf-lemonade-compress-02.txt
	Pages		: 8
	Date		: 2006-7-17
	
The COMPRESS=DEFLATE extension allows an IMAP connection to be
    compressed using the DEFLATE algorithm, such that effective
    compression is available even when TLS is used.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-lemonade-compress-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-compress-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-7-17134024.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-lemonade-compress-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-lemonade-compress-02.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-7-17134024.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--NextPart--





From lemonade-bounces@ietf.org Thu Jul 20 15:32:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3eGK-0004xx-E6; Thu, 20 Jul 2006 15:32:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eGI-0004vs-O9
	for lemonade@ietf.org; Thu, 20 Jul 2006 15:32:42 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3e6f-0006FN-Dq
	for lemonade@ietf.org; Thu, 20 Jul 2006 15:22:46 -0400
X-IronPort-AV: i="4.07,163,1151899200"; 
	d="scan'208"; a="35621630:sNHT29440648"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 Jul 2006 15:22:42 -0400
Message-ID: <330A23D8336C0346B5C1A5BB19666647034EECF5@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC draft-ietf-lemonade-deployments-03.txt
Thread-Index: AcasMTVSRLSqW3TQRdGoEMG1G54GQAAAJGjQ
From: "Burger, Eric" <eburger@cantata.com>
To: <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [lemonade] WGLC draft-ietf-lemonade-deployments-03.txt
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

The Work Group Last Call for draft-ietf-lemonade-deployments-03.txt will
close 5 August 2006.  Please prepend the string "WGLC deployments-03" to
the subject line of your comments.

Thank you.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-03.t
xt

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Thu Jul 20 15:32:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3eGK-0004xi-57; Thu, 20 Jul 2006 15:32:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eGI-0004vB-5O
	for lemonade@ietf.org; Thu, 20 Jul 2006 15:32:42 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3e7s-0006HN-CQ
	for lemonade@ietf.org; Thu, 20 Jul 2006 15:24:01 -0400
X-IronPort-AV: i="4.07,163,1151899200"; 
	d="scan'208"; a="35621665:sNHT26965188"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 Jul 2006 15:23:57 -0400
Message-ID: <330A23D8336C0346B5C1A5BB19666647034EECF9@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Roundup
Thread-Index: AcasMgvi+LUb+OLQSjWpClarzsNJ7A==
From: "Burger, Eric" <eburger@cantata.com>
To: <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Subject: [lemonade] Roundup
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

We do NOT have roundup running yet, but we didn't want to wait too long
before staring some last calls.  These two should be rather
non-controversial and they do not depend on other drafts.

Enjoy, and get your comments in, either the problems or some +1's.

Thanks.
--
- Eric

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Thu Jul 20 15:33:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3eGe-0005T6-SH; Thu, 20 Jul 2006 15:33:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3eGZ-0005Lm-J8
	for lemonade@ietf.org; Thu, 20 Jul 2006 15:32:59 -0400
Received: from mxgate1.brooktrout.com ([204.176.74.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3e28-00064g-Sj
	for lemonade@ietf.org; Thu, 20 Jul 2006 15:18:06 -0400
X-IronPort-AV: i="4.07,163,1151899200"; 
	d="scan'208"; a="35621507:sNHT27092520"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 Jul 2006 15:17:57 -0400
Message-ID: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: WGLC draft-ietf-lemonade-compress-02.txt 
Thread-Index: AcasMTVSRLSqW3TQRdGoEMG1G54GQA==
From: "Burger, Eric" <eburger@cantata.com>
To: <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Subject: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

The Work Group Last Call for draft-ietf-lemonade-compress-02.txt will
close 5 August 2006.  Please prepend the string "WGLC compress-02" to
the subject line of your comments.

Thank you.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-02.txt

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 21 05:32:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3rN0-0007WJ-Ul; Fri, 21 Jul 2006 05:32:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3rMy-0007UV-Bc
	for lemonade@ietf.org; Fri, 21 Jul 2006 05:32:28 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3rMw-00015W-Pj
	for lemonade@ietf.org; Fri, 21 Jul 2006 05:32:28 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Fri, 21 Jul 2006 10:31:54 +0100
Message-ID: <44C01838.4030303@isode.com>
Date: Fri, 21 Jul 2006 00:56:40 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
In-Reply-To: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Burger, Eric wrote:

>The Work Group Last Call for draft-ietf-lemonade-compress-02.txt will
>close 5 August 2006.  Please prepend the string "WGLC compress-02" to
>the subject line of your comments.
>
>Thank you.
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-02.txt
>  
>
I think the document is in a good shape, but at least one more revision 
is needed.
(Also, Dave has a real implementation issue with this extension, but I 
let him report it.)

 >2.  Introduction and Overview
[...]
 >    The goal of COMPRESS=DEFLATE is to reduce the bandwidth usage of
 >    IMAP.  On regular IMAP connections, the PPP or MNP compression used
 >    with many low-bandwidth links compresses IMAP well. However, when
 >    TLS is used, PPP/MNP compression is ineffective. TLS too may provide
 >    compression, but a careful IMAP implementation can do much better.

I don't like the last sentence. It doesn't provide any explanation on 
why TLS compression is worse.

 >    In order to increase interoperation, it is desirable to have as few
 >    different compression algorithms as possible, so this document
 >    specifies only one.  The DEFLATE algorithm is standard, widely
 >    available, unencumbered by patents and fairly efficient.  Hopefully
 >    it will not be necessary to define additional algorithms.

I think a reference to the DEFLATE algorithm description is needed the 
first time it is mentioned.

 >3.  The COMPRESS Command
[...]
 >    If both [STARTTLS] and COMPRESS are in use, the data should be

SASL is not listed here, but listed below. I suggest to change the 
beginning of the first sentence to read:

 >    If both [STARTTLS]/SASL security layer [SASL][IMAP] and COMPRESS 
are in use, the data should be

 >    compressed before it is encrypted (and decrypted before it is
 >    decompressed), independent of the order in which the client issues
 >    COMPRESS, AUTHENTICATE and STARTTLS.

Section 3 doesn't describe when exactly compression starts in both 
directions. Suggested text:

      Compression takes effect immediately following the
      CRLF that concludes the COMPRESS command for the client,
      and the CRLF of the tagged OK response for the server.

 >4.  Compression Efficiency

This is not a big deal, but I would recommend moving this into 
Informative Appendix.

 >5.  Formal Syntax
[...]
 >        command-any =/ compress
 >
 >        compress    = "COMPRESS" SP algorithm
 >
 >        algorithm   = "DEFLATE"

Does this mean that sending DEFLATE as quoted string (or literal) is not 
allowed?

I would rather see the following:

        algorithm   = astring
                            ;; Only "DEFLATE" is registered by this document

Or if you really want to use atom:

        algorithm   = atom
                            ;; Only "DEFLATE" is registered by this document

BTW, be prepared to answer IESG why you don't want an IANA registry.

 >6.  Security Considerations
 >
 >    As for [TLSCOMP] RFC 3749.

That is probably Ok, but wouldn't it be better to cut&paster Security 
Considerations from RFC 3749 and do explicit acknowledgment of the 
copied text?

 >9.1. Normative References
 >
 >    [IMAP]     Crispin, "Internet Message Access Protocol - Version
 >               4rev1", RFC 3501, University of Washington, June 2003.

[...]

 >    [STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC
 >               2595, June 1999.

This reference got replaced by RFC 3501, drop it.
*
*


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 21 06:53:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3sdh-0003v3-9R; Fri, 21 Jul 2006 06:53:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sdd-0003sz-29
	for lemonade@ietf.org; Fri, 21 Jul 2006 06:53:45 -0400
Received: from rutherford.zen.co.uk ([212.23.3.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3sXQ-0000Hm-5z
	for lemonade@ietf.org; Fri, 21 Jul 2006 06:47:22 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by rutherford.zen.co.uk with esmtp (Exim 4.50)
	id 1G3sXP-0002UA-Fw; Fri, 21 Jul 2006 10:47:19 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 882D7498004;
	Fri, 21 Jul 2006 11:50:13 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 07326-04; Fri, 21 Jul 2006 11:50:03 +0100 (BST)
Received: from invsysm1 (unknown [10.42.211.198])
	by turner.dave.cridland.net (Postfix) with ESMTP id 85364498002;
	Fri, 21 Jul 2006 11:50:03 +0100 (BST)
Date: Fri, 21 Jul 2006 11:47:03 +0100
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<44C01838.4030303@isode.com>
In-Reply-To: <44C01838.4030303@isode.com>
MIME-Version: 1.0
Message-Id: <6483.1153478826.555212@invsysm1>
From: Dave Cridland <dave@cridland.net>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: [lemonade] WGLC compress-02 IANA registry
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Fri Jul 21 00:56:40 2006, Alexey Melnikov wrote:
> BTW, be prepared to answer IESG why you don't want an IANA registry.

I asked Arnt about this in private mail a while back, and Arnt's 
response was that currently, there was little need for the complexity 
when we have effectively a single unencumbered candidate. (In fact, 
LZW is now out of patent, if memory serves, but implementations are 
fewer). We would, in any case, have to mandate DEFLATE support for 
interoperability purposes.

I actually think that a better way forward would be to define a 
distinct document which created the IANA registry and populated it 
with DEFLATE as the MTI, and then subsequently this document would 
then reference it. Subsequent documents providing an ESMTP analogue 
of this document would do the same.

However, the latter path is going to take longer and delay this 
document.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 21 06:53:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3sdg-0003us-VZ; Fri, 21 Jul 2006 06:53:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sdc-0003qe-Vk
	for lemonade@ietf.org; Fri, 21 Jul 2006 06:53:45 -0400
Received: from pythagoras.zen.co.uk ([212.23.3.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3sXS-0000KT-Fy
	for lemonade@ietf.org; Fri, 21 Jul 2006 06:47:24 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by pythagoras.zen.co.uk with esmtp (Exim 4.50)
	id 1G3sXQ-0000Se-2t; Fri, 21 Jul 2006 10:47:20 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id 520CC498002;
	Fri, 21 Jul 2006 11:50:14 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 07455-01; Fri, 21 Jul 2006 11:50:09 +0100 (BST)
Received: from invsysm1 (unknown [10.42.211.198])
	by turner.dave.cridland.net (Postfix) with ESMTP id ADC47498003;
	Fri, 21 Jul 2006 11:50:09 +0100 (BST)
Date: Fri, 21 Jul 2006 11:47:12 +0100
Subject: Re: [lemonade] WGLC compress-02 comments
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<11016.1153439508.644241@peirce.dave.cridland.net>
	<44C0A242.3030503@isode.com>
In-Reply-To: <44C0A242.3030503@isode.com>
MIME-Version: 1.0
Message-Id: <6483.1153478832.770878@invsysm1>
From: Dave Cridland <dave@cridland.net>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Pythagoras-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Fri Jul 21 10:45:38 2006, Alexey Melnikov wrote:
> Dave Cridland wrote:
> 
>> 3) In section 3 (The COMPRESS Command), it would be useful if the 
>> example showed a DIGEST-MD5 or GSSAPI layer negotiating a security 
>> layer in SASL. Whilst the combination of TLS and a SASL security 
>> layer is unlikely, the contrived example would clearly show where 
>> the compression layer takes effect.
> 
> I was thinking about this, but saying that COMPRESS happens [when 
> sending] before SASL and TLS is sufficient, as the order of SASL 
> and TLS encryption is detailed in other specs.
> Oh wait, RFC 3501 is silent on relative order of TLS and SASL 
> security layer encryption, because it was written to conform to RFC 
> 2222, but this issue was identified later in RFC 4422.
> 
> 
I still think the example would be more useful if it showed the 
complex case. In particular, the current example doesn't show the 
layer insertion that's somewhat unique to this specification.

Essentially, we're looking at the layers changing from:

IMAP/TCP =STARTTLS=> IMAP/TLS/TCP =COMPRESS=> IMAP/COMPRESS/TLS/TCP 
=AUTHENTICATE=> IMAP/COMPRESS/SASL/TLS/TCP

Of course, when you show the IMAP layer, the layer insertion looks 
rather mundane.


>> 4) I'm not clear if a security considerations section which merely 
>> points to an informative reference is a good idea or not. Maybe 
>> that reference needs to be normative?
> 
> Yes, this relates to my comment about cut&pasting the text.
> 
> 
I'm actually okay with a normative reference, thinking about it, as 
it hopefully means that a new TLS compression RFC would be examined 
for new Security Considerations. Perhaps, though, key considerations 
could be cut and pasted as well.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 21 07:10:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3sty-00015f-1t; Fri, 21 Jul 2006 07:10:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3str-00012T-Qw
	for lemonade@ietf.org; Fri, 21 Jul 2006 07:10:31 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3siR-0003Aa-JD
	for lemonade@ietf.org; Fri, 21 Jul 2006 06:58:47 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Fri, 21 Jul 2006 11:58:28 +0100
Message-ID: <44C0B335.5030102@isode.com>
Date: Fri, 21 Jul 2006 11:57:57 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<44C01838.4030303@isode.com> <6483.1153478826.555212@invsysm1>
In-Reply-To: <6483.1153478826.555212@invsysm1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: [lemonade] Re: WGLC compress-02 IANA registry
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Dave Cridland wrote:

> On Fri Jul 21 00:56:40 2006, Alexey Melnikov wrote:
>
>> BTW, be prepared to answer IESG why you don't want an IANA registry.
>
> I asked Arnt about this in private mail a while back, and Arnt's 
> response was that currently, there was little need for the complexity 
> when we have effectively a single unencumbered candidate. (In fact, 
> LZW is now out of patent, if memory serves, but implementations are 
> fewer). We would, in any case, have to mandate DEFLATE support for 
> interoperability purposes.
>
> I actually think that a better way forward would be to define a 
> distinct document which created the IANA registry and populated it 
> with DEFLATE as the MTI, and then subsequently this document would 
> then reference it.

After writing draft on comparators Arnt should be an expert on IANA 
registrations ;-).

> Subsequent documents providing an ESMTP analogue of this document 
> would do the same.

Sure. Can we just reuse an existing registry?

> However, the latter path is going to take longer and delay this document.

Yes.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 21 08:01:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3thK-0002lR-8f; Fri, 21 Jul 2006 08:01:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3roF-0000AG-6o
	for lemonade@ietf.org; Fri, 21 Jul 2006 06:00:39 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3raM-00027u-CY
	for lemonade@ietf.org; Fri, 21 Jul 2006 05:46:19 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Fri, 21 Jul 2006 10:46:05 +0100
Message-ID: <44C0A242.3030503@isode.com>
Date: Fri, 21 Jul 2006 10:45:38 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
Subject: Re: [lemonade] WGLC compress-02 comments
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<11016.1153439508.644241@peirce.dave.cridland.net>
In-Reply-To: <11016.1153439508.644241@peirce.dave.cridland.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
X-Mailman-Approved-At: Fri, 21 Jul 2006 08:01:36 -0400
Cc: to support diverse service enivronments <lemonade@ietf.org>,
	Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, Enhancements
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Dave Cridland wrote:

> 3) In section 3 (The COMPRESS Command), it would be useful if the 
> example showed a DIGEST-MD5 or GSSAPI layer negotiating a security 
> layer in SASL. Whilst the combination of TLS and a SASL security layer 
> is unlikely, the contrived example would clearly show where the 
> compression layer takes effect.

I was thinking about this, but saying that COMPRESS happens [when 
sending] before SASL and TLS is sufficient, as the order of SASL and TLS 
encryption is detailed in other specs.
Oh wait, RFC 3501 is silent on relative order of TLS and SASL security 
layer encryption, because it was written to conform to RFC 2222, but 
this issue was identified later in RFC 4422.

> 4) I'm not clear if a security considerations section which merely 
> points to an informative reference is a good idea or not. Maybe that 
> reference needs to be normative?

Yes, this relates to my comment about cut&pasting the text.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 21 10:04:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G3vc4-0003MZ-Sw; Fri, 21 Jul 2006 10:04:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vc3-0003LB-OL
	for lemonade@ietf.org; Fri, 21 Jul 2006 10:04:19 -0400
Received: from mail120.messagelabs.com ([216.82.250.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3vaI-00043S-T2
	for lemonade@ietf.org; Fri, 21 Jul 2006 10:02:32 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-13.tower-120.messagelabs.com!1153490549!70882!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 18841 invoked from network); 21 Jul 2006 14:02:29 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-13.tower-120.messagelabs.com with SMTP;
	21 Jul 2006 14:02:29 -0000
Received: from [135.210.107.10] (unknown[135.210.107.10](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060721140229gw1003jo30e> (Authid: tony);
	Fri, 21 Jul 2006 14:02:29 +0000
Message-ID: <44C0DE76.10304@att.com>
Date: Fri, 21 Jul 2006 10:02:30 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
CC: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
Subject: Re: [lemonade] WGLC compress-02 IANA registry
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>	<44C01838.4030303@isode.com>
	<6483.1153478826.555212@invsysm1>
In-Reply-To: <6483.1153478826.555212@invsysm1>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

The complexity of adding a single section to the IANA Considerations
seems pretty minimal to me. (I've written a few and didn't find them
onerous at all.)

	Tony Hansen
	tony@att.com

Dave Cridland wrote:
> On Fri Jul 21 00:56:40 2006, Alexey Melnikov wrote:
>> BTW, be prepared to answer IESG why you don't want an IANA registry.
> 
> I asked Arnt about this in private mail a while back, and Arnt's
> response was that currently, there was little need for the complexity
> when we have effectively a single unencumbered candidate. (In fact, LZW
> is now out of patent, if memory serves, but implementations are fewer).
> We would, in any case, have to mandate DEFLATE support for
> interoperability purposes.
> 
> I actually think that a better way forward would be to define a distinct
> document which created the IANA registry and populated it with DEFLATE
> as the MTI, and then subsequently this document would then reference it.
> Subsequent documents providing an ESMTP analogue of this document would
> do the same.
> 
> However, the latter path is going to take longer and delay this document.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 21 18:06:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G438r-00019v-ON; Fri, 21 Jul 2006 18:06:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G438p-00019b-Te
	for lemonade@ietf.org; Fri, 21 Jul 2006 18:06:39 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G438n-00013F-GC
	for lemonade@ietf.org; Fri, 21 Jul 2006 18:06:39 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6LM6X3a003307
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 21 Jul 2006 15:06:33 -0700
Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6LM6R2p017121; Fri, 21 Jul 2006 15:06:32 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630000ec0e7000ce8ff@[192.168.1.13]>
In-Reply-To: <Pine.LNX.4.64.0607102243040.14969@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0607102243040.14969@hermes-1.csi.cam.ac.uk>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 21 Jul 2006 15:06:17 -0700
To: Tony Finch <dot@dotat.at>, lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] notifications - xmpp pubsub
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 10:46 PM +0100 7/10/06, Tony Finch wrote:

>  The publish/subscribe extension to Jabber seems like a reasonable way of
>  doing out-of-band notifications. Perhaps it also answers the question of
>  how a client can plausibly download and display the state of a user's
>  notification filters.
>
>  http://www.jabber.org/jeps/jep-0060.html

Could someone more familiar than I with the details of the protocol 
say how the client would discover the details of the available 
notifications?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Everyone knows that dragons don't exist.  But while this simplistic
formulation may satisfy the layman, it does not suffice for the
scientific mind.  The School of Higher Neantical Nillity is in fact
wholly unconcerned with what does exist.  Indeed, the banality of
existence has been so amply demonstrated, there is no need for us to
discuss it any further here.  The brilliant Cerebron, attacking the
problem analytically, discovered three distinct kinds of dragon: the
mythical, the chimerical, and the purely hypothetical.  They were all,
one might say, nonexistent, but each nonexisted in an entirely
different way......

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sat Jul 22 14:50:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G4MYV-0007Hw-Vh; Sat, 22 Jul 2006 14:50:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G4MYV-0007Hr-7B
	for lemonade@ietf.org; Sat, 22 Jul 2006 14:50:27 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4MYT-0003kn-Ih
	for lemonade@ietf.org; Sat, 22 Jul 2006 14:50:27 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Sat, 22 Jul 2006 19:50:20 +0100
Message-ID: <44C2734C.7040406@isode.com>
Date: Sat, 22 Jul 2006 19:49:48 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Crispin <MRC@CAC.Washington.EDU>
Subject: Re: [lemonade] WGLC compress-02 comments
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<11016.1153439508.644241@peirce.dave.cridland.net>
	<44C0A242.3030503@isode.com>
	<Pine.WNT.4.65.0607210903500.2252@Shimo-Tomobiki.panda.com>
In-Reply-To: <Pine.WNT.4.65.0607210903500.2252@Shimo-Tomobiki.panda.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: lemonade@ietf.org, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Mark Crispin wrote:

> On Fri, 21 Jul 2006, Alexey Melnikov wrote:
>
>> Oh wait, RFC 3501 is silent on relative order of TLS and SASL 
>> security layer encryption, because it was written to conform to RFC 
>> 2222, but this issue was identified later in RFC 4422.
>
> However, RFC 3501 does say that STARTTLS must happen before 
> AUTHENTICATE. That pretty much defines the order unambiguously.

And the order is ...?
Most of the new protocols say that TLS is always below SASL security 
layer, no matter in which order they were negotiated (e.g. LDAP allow 
STARTTLS after SASL). The main argument here is that TLS is frequently 
provided by OS.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Sun Jul 23 00:57:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G4W28-00008j-Pg; Sun, 23 Jul 2006 00:57:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G4W27-0008Ua-5X
	for lemonade@ietf.org; Sun, 23 Jul 2006 00:57:39 -0400
Received: from mxout2.cac.washington.edu ([140.142.33.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4W24-00025a-Qc
	for lemonade@ietf.org; Sun, 23 Jul 2006 00:57:39 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout2.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k6N4vSja002012; Sat, 22 Jul 2006 21:57:29 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([166.209.122.127])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id
	k6N4v68O001443
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Sat, 22 Jul 2006 21:57:23 -0700
Date: Sat, 22 Jul 2006 20:56:59 -0800
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [lemonade] WGLC compress-02 comments
In-Reply-To: <44C2734C.7040406@isode.com>
Message-ID: <Pine.WNT.4.65.0607222054500.3212@Shimo-Tomobiki.panda.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<11016.1153439508.644241@peirce.dave.cridland.net>
	<44C0A242.3030503@isode.com>
	<Pine.WNT.4.65.0607210903500.2252@Shimo-Tomobiki.panda.com>
	<44C2734C.7040406@isode.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935,
	Antispam-Data: 2006.7.22.214432
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: lemonade@ietf.org, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Sat, 22 Jul 2006, Alexey Melnikov wrote:
>>> Oh wait, RFC 3501 is silent on relative order of TLS and SASL security 
>>> layer encryption, because it was written to conform to RFC 2222, but this 
>>> issue was identified later in RFC 4422.
>> However, RFC 3501 does say that STARTTLS must happen before AUTHENTICATE. 
>> That pretty much defines the order unambiguously.
> And the order is ...?
> Most of the new protocols say that TLS is always below SASL security layer, 
> no matter in which order they were negotiated (e.g. LDAP allow STARTTLS after 
> SASL). The main argument here is that TLS is frequently provided by OS.

I'm surprised that LDAP allows STARTTLS after SASL.  What's the point of 
allowing that?

As far as I'm concerned, it only makes sense to have TLS below the SASL 
security layer.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 24 07:11:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G4yLc-0003pf-N1; Mon, 24 Jul 2006 07:11:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yUz-0008Dp-0V
	for lemonade@ietf.org; Fri, 21 Jul 2006 13:09:13 -0400
Received: from mxout7.cac.washington.edu ([140.142.32.178])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ySW-0006sM-HO
	for lemonade@ietf.org; Fri, 21 Jul 2006 13:06:41 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout7.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k6LH6WiE027715; Fri, 21 Jul 2006 10:06:32 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([166.209.107.234])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id
	k6LH68qq025938
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 21 Jul 2006 10:06:26 -0700
Date: Fri, 21 Jul 2006 09:05:59 -0800
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [lemonade] WGLC compress-02 comments
In-Reply-To: <44C0A242.3030503@isode.com>
Message-ID: <Pine.WNT.4.65.0607210903500.2252@Shimo-Tomobiki.panda.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<11016.1153439508.644241@peirce.dave.cridland.net>
	<44C0A242.3030503@isode.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
X-Mailman-Approved-At: Mon, 24 Jul 2006 07:11:39 -0400
Cc: to support diverse service enivronments <lemonade@ietf.org>,
	Enhancements@CAC.Washington.EDU,
	Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Fri, 21 Jul 2006, Alexey Melnikov wrote:
> Oh wait, RFC 3501 is silent on relative order of TLS and SASL security layer 
> encryption, because it was written to conform to RFC 2222, but this issue was 
> identified later in RFC 4422.

However, RFC 3501 does say that STARTTLS must happen before AUTHENTICATE. 
That pretty much defines the order unambiguously.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 24 07:36:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G4yjY-0005uS-Rn; Mon, 24 Jul 2006 07:36:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yjX-0005uK-Q3
	for lemonade@ietf.org; Mon, 24 Jul 2006 07:36:23 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4yjW-0007KS-A0
	for lemonade@ietf.org; Mon, 24 Jul 2006 07:36:23 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Mon, 24 Jul 2006 12:36:16 +0100
Message-ID: <44C4B091.4050507@isode.com>
Date: Mon, 24 Jul 2006 12:35:45 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Mark Crispin <MRC@CAC.Washington.EDU>
Subject: Re: [lemonade] WGLC compress-02 comments
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<11016.1153439508.644241@peirce.dave.cridland.net>
	<44C0A242.3030503@isode.com>
	<Pine.WNT.4.65.0607210903500.2252@Shimo-Tomobiki.panda.com>
	<44C2734C.7040406@isode.com>
	<Pine.WNT.4.65.0607222054500.3212@Shimo-Tomobiki.panda.com>
In-Reply-To: <Pine.WNT.4.65.0607222054500.3212@Shimo-Tomobiki.panda.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Mark Crispin wrote:

> As far as I'm concerned, it only makes sense to have TLS below the 
> SASL security layer.

I agree with that, but can this be clarified in 3501 errata in order to 
avoid all doubts?


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 26 06:30:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5geS-0000oA-Mh; Wed, 26 Jul 2006 06:30:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5geQ-0000iq-9a
	for lemonade@ietf.org; Wed, 26 Jul 2006 06:30:02 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5geO-0007Et-Rq
	for lemonade@ietf.org; Wed, 26 Jul 2006 06:30:02 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k6QATuXp011624; Wed, 26 Jul 2006 13:29:58 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Jul 2006 13:29:51 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Jul 2006 13:29:51 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] Profile Bis -03
Date: Wed, 26 Jul 2006 13:28:45 +0300
Message-ID: <0FA975F2D8295A448BE3ADC1612446579AD023@esebe199.NOE.Nokia.com>
In-Reply-To: <p06300014c0d4a62e6e66@[192.168.1.13]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] Profile Bis -03
Thread-Index: AcaiIv+X7xYtr/m3R9mDNQFQccDeqgOexJdQ
From: <Zoltan.Ordogh@nokia.com>
To: <randy@qualcomm.com>, <dave@cridland.net>, <lemonade@ietf.org>
X-OriginalArrivalTime: 26 Jul 2006 10:29:51.0724 (UTC)
	FILETIME=[6DA132C0:01C6B09E]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Hi all,
Just catching up with my email backlog.=20

-----Original Message-----
From: ext Randall Gellens [mailto:randy@qualcomm.com]=20
Sent: 08 July, 2006 03:11
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); dave@cridland.net; =
lemonade@ietf.org
Subject: RE: [lemonade] Profile Bis -03

At 1:35 PM +0300 6/27/06, <Zoltan.Ordogh@nokia.com> wrote:

>  3.4.1 "This command can be omitted, being for metadata only."=20
> Suggest wording change to: "This command is only metadata, thus it can =

> be omitted."
>  3.4.2 "This command can be omitted." Suggest same wording as
> previous: "This command is only metadata, thus it can be omitted."

I'd prefer the current wording, as your suggestion may imply too low a =
value for the command.  Alternatively, what about saying "Clients that =
do not use or set the $Forwarded flag may omit this command"?

[Z=D6r] Yes, this is the best so far. Needs the touch of an expert :-)

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 26 06:54:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5h1p-0003Cr-92; Wed, 26 Jul 2006 06:54:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5h1m-0003Ca-Uo
	for lemonade@ietf.org; Wed, 26 Jul 2006 06:54:10 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5gmK-0000Kw-LQ
	for lemonade@ietf.org; Wed, 26 Jul 2006 06:38:12 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5gZc-0004BU-IC
	for lemonade@ietf.org; Wed, 26 Jul 2006 06:25:06 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k6QAOxev011339
	for <lemonade@ietf.org>; Wed, 26 Jul 2006 13:25:01 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Jul 2006 13:24:49 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Jul 2006 13:24:49 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-03.txt -
	comment
Date: Wed, 26 Jul 2006 13:23:32 +0300
Message-ID: <0FA975F2D8295A448BE3ADC1612446579AD019@esebe199.NOE.Nokia.com>
In-Reply-To: <E1Fw2WZ-0003WM-Qa@stiedprstage1.ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-03.txt -
	comment
Thread-Index: AcabvQg93mZoGUV2RkSjkMOWK0w3BgU3nfQQ
From: <Zoltan.Ordogh@nokia.com>
To: <lemonade@ietf.org>
X-OriginalArrivalTime: 26 Jul 2006 10:24:49.0020 (UTC)
	FILETIME=[B9343BC0:01C6B09D]
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Hi all,
I have a few comments:
"7.2.  OMA MEM Deployment Issues

   The OMA MEM Architecture document [MEM-arch] further identifies
   deployment models.

   Certain of these deployment models are not what IETF has
   conventionally modeled.  They require special attention to end-to-end
   security aspects and may warrant introduction of additional security
   measures (e.g. object level encryption)."
I think that there is a loop here.
OMA MEM will use LEMONADE. Because of this, the text above is saying =
that LEMONADE requires object-level encryption in certain deployment =
cases and needs special attention for those as well.
Or, I misunderstand the whole thing in which case I would like to get =
some clarification on this.

Same comment for section 7.3 about proxies.

Typo in section 7.5.2.2, second last paragraph:
"They may involved functions performed in the" -> involve

Thank You.

Best regards: Zolt=E1n =D6rd=F6gh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566


-----Original Message-----
From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20
Sent: 29 June, 2006 22:50
To: i-d-announce@ietf.org
Cc: lemonade@ietf.org
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-bis-03.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the Enhancements to Internet email to =
support diverse service environments Working Group of the IETF.

	Title		: LEMONADE profile bis
	Author(s)	: S. Maes, et al.
	Filename	: draft-ietf-lemonade-profile-bis-03.txt
	Pages		: 39
	Date		: 2006-6-29
=09
This document describes the LEMONADE profile.  It contains pointers to =
or descriptions of all the features that are normatively part of this =
version of the LEMONADE profile.

This document describes a profile (a set of required extensions, =
restrictions and usage modes) of the IMAP and mail submission protocols. =
 This profile allows clients (especially those that are constrained in =
memory, bandwidth, processing power, or other areas) to efficiently use =
IMAP and Submission to access and submit mail.
This includes the ability to forward received mail without needing to =
download and upload the mail, to optimize submission and to efficiently =
resynchronize in case of loss of connectivity with the server.

The Lemonade profile relies upon extensions to IMAP and Mail Submission =
protocols; specifically URLAUTH and CATENATE IMAP protocol extensions =
and BURL extension to the SUBMIT protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-bis-03.tx=
t

To remove yourself from the I-D Announcement list, send a message to =
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the =
username "anonymous" and a password of your e-mail address. After =
logging in, type "cd internet-drafts" and then
	"get draft-ietf-lemonade-profile-bis-03.txt".

A list of Internet-Drafts directories can be found in =
http://www.ietf.org/shadow.html or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-profile-bis-03.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Wed Jul 26 06:57:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5h5G-0003y7-H8; Wed, 26 Jul 2006 06:57:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5h5F-0003y0-P5
	for lemonade@ietf.org; Wed, 26 Jul 2006 06:57:45 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5h5E-000468-8I
	for lemonade@ietf.org; Wed, 26 Jul 2006 06:57:45 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k6QAveaP010373
	for <lemonade@ietf.org>; Wed, 26 Jul 2006 13:57:43 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Jul 2006 13:57:40 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 26 Jul 2006 13:57:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [lemonade] WGLC compress-02 RE: [lemonade] I-D
	ACTION:draft-ietf-lemonade-compress-02.txt 
Date: Wed, 26 Jul 2006 13:57:11 +0300
Message-ID: <0FA975F2D8295A448BE3ADC1612446579AD056@esebe199.NOE.Nokia.com>
In-Reply-To: <E1G2Z6P-0007ZB-OR@stiedprstage1.ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] WGLC compress-02 RE: [lemonade] I-D
	ACTION:draft-ietf-lemonade-compress-02.txt 
Thread-Index: Acap2k9z3IS6ux96ThmDfliCXyfmkAGxg7QA
From: <Zoltan.Ordogh@nokia.com>
To: <lemonade@ietf.org>
X-OriginalArrivalTime: 26 Jul 2006 10:57:39.0117 (UTC)
	FILETIME=[4F792DD0:01C6B0A2]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Hi all,
Here are my comments on this draft:
Section 2:
"but a careful IMAP implementation can do much better"  What makes and =
IMAP implementation 'careful'? I know what You mean, but I think we =
should find a better word here.
"Hopefully it will not be necessary to define additional algorithms." =
Suggest removal.

Section 3:
"The client MUST NOT send any commands until it has seen the result of =
COMPRESS." This is fine, but can the server send anything else in the =
meantime? I mean I can turn it on at any time during the session.

Section 3 and section 5:
How can it be turned off?

Thank You.

Best regards: Zolt=E1n =D6rd=F6gh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566


-----Original Message-----
From: ext lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]=20
Sent: 17 July, 2006 22:50
To: i-d-announce@ietf.org
Cc: lemonade@ietf.org
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-compress-02.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
This draft is a work item of the Enhancements to Internet email to =
support diverse service environments Working Group of the IETF.

	Title		: The IMAP COMPRESS=3DDEFLATE Extension
	Author(s)	: A. Gulbrandsen
	Filename	: draft-ietf-lemonade-compress-02.txt
	Pages		: 8
	Date		: 2006-7-17
=09
The COMPRESS=3DDEFLATE extension allows an IMAP connection to be
    compressed using the DEFLATE algorithm, such that effective
    compression is available even when TLS is used.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-compress-02.txt

To remove yourself from the I-D Announcement list, send a message to =
i-d-announce-request@ietf.org with the word unsubscribe in the body of =
the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the =
username "anonymous" and a password of your e-mail address. After =
logging in, type "cd internet-drafts" and then
	"get draft-ietf-lemonade-compress-02.txt".

A list of Internet-Drafts directories can be found in =
http://www.ietf.org/shadow.html or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-compress-02.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Thu Jul 27 01:49:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G5ykg-0006VL-N2; Thu, 27 Jul 2006 01:49:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ykf-0006VA-Dn
	for lemonade@ietf.org; Thu, 27 Jul 2006 01:49:41 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ykd-0004KR-3q
	for lemonade@ietf.org; Thu, 27 Jul 2006 01:49:41 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3100LVCS9K3J@szxga01-in.huawei.com> for
	lemonade@ietf.org; Thu, 27 Jul 2006 13:51:20 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J310036QS9K6C@szxga01-in.huawei.com> for
	lemonade@ietf.org; Thu, 27 Jul 2006 13:51:20 +0800 (CST)
Received: from l48785 ([10.164.120.48])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J3100BN2SOM1T@szxml04-in.huawei.com> for
	lemonade@ietf.org; Thu, 27 Jul 2006 14:00:24 +0800 (CST)
Date: Thu, 27 Jul 2006 13:48:49 +0800
From: Gang Liang <lianggang79@huawei.com>
Subject: [lemonade] some questions in draft-ietf-lemonade-notifications-03
To: lemonade@ietf.org
Message-id: <001501c6b140$55be8390$3078a40a@china.huawei.com>
Organization: Huawei
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-Priority: 3
X-MSMail-priority: Normal
References: <01f901c6b065$caaf9d50$3478a40a@china.huawei.com>
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Gang Liang <lianggang79@huawei.com>
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1055001526=="
Errors-To: lemonade-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1055001526==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_YUgw97C0o3NU0S7xUW5hdg)"

This is a multi-part message in MIME format.

--Boundary_(ID_YUgw97C0o3NU0S7xUW5hdg)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi All,

 

I have some questions as follows:

 

Questions 1: 

In 10.2 (Provision Entries), "push.shared" is defined as an attribute of in-band notifications (not the attribute of outband notifications) while in the first example in 10.4 "push.shared" is regarded as the attribute of outband notifications. 

Why? Maybe "push.shared" should be defined as an attribute of outband notifications too.

 

Question 2: 

In 10.3

"limit.priv" = "size=" nz-number  | "total=" nz-number 

;the maximum number of bytes to send in notification payloads or the total number of messages to send. Both per-day 

What's the benefit of limiting the total number of messages (notifications) per-day? If the number of notifications sent that day has reached the limit (e.g. 10 notifications per-day ) but then a very important email arrives, what should the server do? 

 

Question 3:

In 10.3:

"push.priv" = "push" / "pull" 

;specifies whether the client expects new messages to be pushed via the unsolicited FETCH response defined above, or via client issued FETCH in response to an EXISTS response. 

Is it possible to push new messages via outband notifications? E.g. through MMS channel. If it's possible, maybe we could define such an attribute for outband notification.

 

Question 4:

In 13.8

It MUST be possible to provide acknowledgment by the target to the messaging system or to repeat notification until such an acknowledgement is provided if supported by the notification channel.

Does it mean that the target (client) should provide acknowledgment for per-notification and the messaging system should repeat the same notification (not send the following notifications) until receive the acknowledgment for the notification?

If so, maybe it's more appropriate to send a notification after determining that the client is online (e.g. according to presence status of the client provided by presence enabler).



Best Regards,
Lingyan
Huawei Technologies Co., Ltd.

--Boundary_(ID_YUgw97C0o3NU0S7xUW5hdg)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2800.1555" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2></FONT>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Hi All,</FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman"><o:p></o:p></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">I have some questions as 
follows:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman"><SPAN 
style="mso-spacerun: yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Questions 1: 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3>In 10.2 (Provision Entries), "push.shared" is 
defined as an attribute of in-band notifications (not the attribute of outband 
notifications) while in the first example in 10.4 "push.shared" is regarded as 
the attribute of outband notifications. </FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Why? Maybe "push.shared" should be defined 
as an attribute of outband notifications 
too.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 2: 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 10.3<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">"limit.priv" = "size=" nz-number<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>| "total=" nz-number 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">;the maximum number of bytes to send in 
notification payloads or the total number of messages to send. Both per-day 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">What's the benefit of limiting the total 
number of messages (notifications) per-day? If the number of notifications sent 
that day has reached the limit (e.g. 10 notifications per-day ) but then a very 
important email arrives, what should the server do? 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 
3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 10.3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">"push.priv" = "push" / "pull" 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">;specifies whether the client expects new 
messages to be pushed via the unsolicited FETCH response defined above, or via 
client issued FETCH in response to an EXISTS response. 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Is it possible to push new messages via 
outband notifications? E.g. through MMS channel. If it's possible, maybe we 
could define such an attribute for outband 
notification.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 
4:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 13.8<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">It MUST be possible to provide 
acknowledgment by the target to the messaging system or to repeat notification 
until such an acknowledgement is provided if supported by the notification 
channel.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Does it mean that the target (client) should 
provide acknowledgment for per-notification and the messaging system should 
repeat the same notification (not send the following notifications) until 
receive the acknowledgment for the 
notification?<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3>If so, maybe it's more appropriate to send a 
notification after determining that the client is online (e.g. according to 
presence status of the client provided by presence enabler).</FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US>Best 
Regards,<BR>Lingyan<BR>Huawei Technologies Co., 
Ltd.</SPAN></P></DIV></BODY></HTML>

--Boundary_(ID_YUgw97C0o3NU0S7xUW5hdg)--


--===============1055001526==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--===============1055001526==--




From lemonade-bounces@ietf.org Thu Jul 27 10:10:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G66ZI-0004YF-8U; Thu, 27 Jul 2006 10:10:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5aNP-00031f-NA
	for lemonade@ietf.org; Tue, 25 Jul 2006 23:48:03 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5aNO-0008Mb-Nm
	for lemonade@ietf.org; Tue, 25 Jul 2006 23:48:03 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J2Z00KOZS6MBD@szxga03-in.huawei.com> for
	lemonade@ietf.org; Wed, 26 Jul 2006 11:54:22 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J2Z00B63S6L4J@szxga03-in.huawei.com> for
	lemonade@ietf.org; Wed, 26 Jul 2006 11:54:22 +0800 (CST)
Received: from w48795 ([10.164.120.52])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J2Z000SOS9AXM@szxml04-in.huawei.com> for
	lemonade@ietf.org; Wed, 26 Jul 2006 11:55:59 +0800 (CST)
Date: Wed, 26 Jul 2006 11:44:26 +0800
From: Lingyan Wu <wly0027@sina.com>
Subject: [lemonade] some questions in draft-ietf-lemonade-notifications-03
To: lemonade@ietf.org
Message-id: <01f901c6b065$caaf9d50$3478a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 1.7 (+)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5
X-Mailman-Approved-At: Thu, 27 Jul 2006 10:10:26 -0400
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1653745324=="
Errors-To: lemonade-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1653745324==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_8Q61TT8ICVJUL+Ub3/OEcA)"

This is a multi-part message in MIME format.

--Boundary_(ID_8Q61TT8ICVJUL+Ub3/OEcA)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi All,



I have some questions as follows:

 

Questions 1: 

In 10.2 (Provision Entries), "push.shared" is defined as an attribute of in-band notifications (not the attribute of outband notifications) while in the first example in 10.4 "push.shared" is regarded as the attribute of outband notifications. 

Why? Maybe "push.shared" should be defined as an attribute of outband notifications too.

 

Question 2: 

In 10.3

"limit.priv" = "size=" nz-number  | "total=" nz-number 

;the maximum number of bytes to send in notification payloads or the total number of messages to send. Both per-day 

What's the benefit of limiting the total number of messages (notifications) per-day? If the number of notifications sent that day has reached the limit (e.g. 10 notifications per-day ) but then a very important email arrives, what should the server do? 

 

Question 3:

In 10.3:

"push.priv" = "push" / "pull" 

;specifies whether the client expects new messages to be pushed via the unsolicited FETCH response defined above, or via client issued FETCH in response to an EXISTS response. 

Is it possible to push new messages via outband notifications? E.g. through MMS channel. If it's possible, maybe we could define such an attribute for outband notification.

 

Question 4:

In 13.8

It MUST be possible to provide acknowledgment by the target to the messaging system or to repeat notification until such an acknowledgement is provided if supported by the notification channel.

Does it mean that the target (client) should provide acknowledgment for per-notification and the messaging system should repeat the same notification (not send the following notifications) until receive the acknowledgment for the notification?

If so, maybe it's more appropriate to send a notification after determining that the client is online (e.g. according to presence status of the client provided by presence enabler).



Best Regards,
Lingyan
Huawei Technologies Co., Ltd. 

--Boundary_(ID_8Q61TT8ICVJUL+Ub3/OEcA)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Hi All,</FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman"><?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" 
/><o:p></o:p></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">I have some questions as 
follows:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman"><SPAN 
style="mso-spacerun: yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Questions 1: 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3>In 10.2 (Provision Entries), "push.shared" is 
defined as an attribute of in-band notifications (not the attribute of outband 
notifications) while in the first example in 10.4 "push.shared" is regarded as 
the attribute of outband notifications. </FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Why? Maybe "push.shared" should be defined 
as an attribute of outband notifications 
too.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 2: 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 10.3<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">"limit.priv" = "size=" nz-number<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>| "total=" nz-number 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">;the maximum number of bytes to send in 
notification payloads or the total number of messages to send. Both per-day 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">What's the benefit of limiting the total 
number of messages (notifications) per-day? If the number of notifications sent 
that day has reached the limit (e.g. 10 notifications per-day ) but then a very 
important email arrives, what should the server do? 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 
3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 10.3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">"push.priv" = "push" / "pull" 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">;specifies whether the client expects new 
messages to be pushed via the unsolicited FETCH response defined above, or via 
client issued FETCH in response to an EXISTS response. 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Is it possible to push new messages via 
outband notifications? E.g. through MMS channel. If it's possible, maybe we 
could define such an attribute for outband 
notification.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 
4:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 13.8<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">It MUST be possible to provide 
acknowledgment by the target to the messaging system or to repeat notification 
until such an acknowledgement is provided if supported by the notification 
channel.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Does it mean that the target (client) should 
provide acknowledgment for per-notification and the messaging system should 
repeat the same notification (not send the following notifications) until 
receive the acknowledgment for the 
notification?<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3>If so, maybe it's more appropriate to send a 
notification after determining that the client is online (e.g. according to 
presence status of the client provided by presence enabler).</FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US>Best 
Regards,<BR>Lingyan<BR>Huawei Technologies Co., Ltd. 
</SPAN></P></FONT></DIV></BODY></HTML>

--Boundary_(ID_8Q61TT8ICVJUL+Ub3/OEcA)--


--===============1653745324==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--===============1653745324==--




From lemonade-bounces@ietf.org Thu Jul 27 10:10:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G66ZI-0004YK-Eo; Thu, 27 Jul 2006 10:10:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G5fnH-0008V5-Ps
	for lemonade@ietf.org; Wed, 26 Jul 2006 05:35:07 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5fnE-0008N1-4h
	for lemonade@ietf.org; Wed, 26 Jul 2006 05:35:07 -0400
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3000G3M8KDPQ@szxga02-in.huawei.com> for
	lemonade@ietf.org; Wed, 26 Jul 2006 17:48:13 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3000E7R8KC72@szxga02-in.huawei.com> for
	lemonade@ietf.org; Wed, 26 Jul 2006 17:48:13 +0800 (CST)
Received: from w48795 ([10.164.120.52])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J30001488B5SQ@szxml04-in.huawei.com> for
	lemonade@ietf.org; Wed, 26 Jul 2006 17:42:42 +0800 (CST)
Date: Wed, 26 Jul 2006 17:31:11 +0800
From: Lingyan Wu <wly0027@sina.com>
Subject: [lemonade] some questions in draft-ietf-lemonade-notifications-03
To: lemonade@ietf.org
Message-id: <022801c6b096$3b544800$3478a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
X-Mailman-Approved-At: Thu, 27 Jul 2006 10:10:26 -0400
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1256409386=="
Errors-To: lemonade-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1256409386==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_zRNICeui/mmZ7EGNO57M+A)"

This is a multi-part message in MIME format.

--Boundary_(ID_zRNICeui/mmZ7EGNO57M+A)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi All,

 

I have some questions as follows:

 

Questions 1: 

In 10.2 (Provision Entries), "push.shared" is defined as an attribute of in-band notifications (not the attribute of outband notifications) while in the first example in 10.4 "push.shared" is regarded as the attribute of outband notifications. 

Why? Maybe "push.shared" should be defined as an attribute of outband notifications too.

 

Question 2: 

In 10.3

"limit.priv" = "size=" nz-number  | "total=" nz-number 

;the maximum number of bytes to send in notification payloads or the total number of messages to send. Both per-day 

What's the benefit of limiting the total number of messages (notifications) per-day? If the number of notifications sent that day has reached the limit (e.g. 10 notifications per-day ) but then a very important email arrives, what should the server do? 

 


Question 3:

In 10.3:

"push.priv" = "push" / "pull" 

;specifies whether the client expects new messages to be pushed via the unsolicited FETCH response defined above, or via client issued FETCH in response to an EXISTS response. 

Is it possible to push new messages via outband notifications? E.g. through MMS channel. If it's possible, maybe we could define such an attribute for outband notification.

 

Question 4:

In 13.8

It MUST be possible to provide acknowledgment by the target to the messaging system or to repeat notification until such an acknowledgement is provided if supported by the notification channel.

Does it mean that the target (client) should provide acknowledgment for per-notification and the messaging system should repeat the same notification (not send the following notifications) until receive the acknowledgment for the notification?

If so, maybe it's more appropriate to send a notification after determining that the client is online (e.g. according to presence status of the client provided by presence enabler).



Best Regards,
Lingyan
Huawei Technologies Co., Ltd. 

--Boundary_(ID_zRNICeui/mmZ7EGNO57M+A)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>
<DIV><FONT size=2>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Hi All,</FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman"><?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" 
/><o:p></o:p></FONT></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">I have some questions as 
follows:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman"><SPAN 
style="mso-spacerun: yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Questions 1: 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3>In 10.2 (Provision Entries), "push.shared" is 
defined as an attribute of in-band notifications (not the attribute of outband 
notifications) while in the first example in 10.4 "push.shared" is regarded as 
the attribute of outband notifications. </FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Why? Maybe "push.shared" should be defined 
as an attribute of outband notifications 
too.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 2: 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 10.3<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">"limit.priv" = "size=" nz-number<SPAN 
style="mso-spacerun: yes">&nbsp; </SPAN>| "total=" nz-number 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">;the maximum number of bytes to send in 
notification payloads or the total number of messages to send. Both per-day 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">What's the benefit of limiting the total 
number of messages (notifications) per-day? If the number of notifications sent 
that day has reached the limit (e.g. 10 notifications per-day ) but then a very 
important email arrives, what should the server do? 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 
3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 10.3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">"push.priv" = "push" / "pull" 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">;specifies whether the client expects new 
messages to be pushed via the unsolicited FETCH response defined above, or via 
client issued FETCH in response to an EXISTS response. 
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Is it possible to push new messages via 
outband notifications? E.g. through MMS channel. If it's possible, maybe we 
could define such an attribute for outband 
notification.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><o:p><FONT 
face="Times New Roman" size=3>&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Question 
4:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">In 13.8<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">It MUST be possible to provide 
acknowledgment by the target to the messaging system or to repeat notification 
until such an acknowledgement is provided if supported by the notification 
channel.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
size=3><FONT face="Times New Roman">Does it mean that the target (client) should 
provide acknowledgment for per-notification and the messaging system should 
repeat the same notification (not send the following notifications) until 
receive the acknowledgment for the 
notification?<o:p></o:p></FONT></FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3>If so, maybe it's more appropriate to send a 
notification after determining that the client is online (e.g. according to 
presence status of the client provided by presence enabler).</FONT></SPAN></P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US><FONT 
face="Times New Roman" size=3></FONT></SPAN>&nbsp;</P>
<P class=MsoNormal style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-US>Best 
Regards,<BR>Lingyan<BR>Huawei Technologies Co., Ltd. 
</SPAN></P></FONT></DIV></FONT></DIV></BODY></HTML>

--Boundary_(ID_zRNICeui/mmZ7EGNO57M+A)--


--===============1256409386==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--===============1256409386==--




From lemonade-bounces@ietf.org Thu Jul 27 21:40:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6HL9-00007l-M4; Thu, 27 Jul 2006 21:40:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HL8-00007g-8n
	for lemonade@ietf.org; Thu, 27 Jul 2006 21:40:34 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6HL6-0007dR-HH
	for lemonade@ietf.org; Thu, 27 Jul 2006 21:40:34 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J33000XMBENDF@szxga01-in.huawei.com> for
	lemonade@ietf.org; Fri, 28 Jul 2006 09:42:24 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J33009E6BEND7@szxga01-in.huawei.com> for
	lemonade@ietf.org; Fri, 28 Jul 2006 09:42:23 +0800 (CST)
Received: from w48795 ([10.164.120.52])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J3300J1IBTQU3@szxml04-in.huawei.com> for
	lemonade@ietf.org; Fri, 28 Jul 2006 09:51:27 +0800 (CST)
Date: Fri, 28 Jul 2006 09:39:51 +0800
From: Lingyan Wu <wulingyan_48795@huawei.com>
Subject: Sorry for the repeated emails because of delay ! //Fw: [lemonade] some
	questions in draft-ietf-lemonade-notifications-03
To: lemonade@ietf.org
Message-id: <00b201c6b1e6$b87b4a80$3478a40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Lingyan Wu <wulingyan_48795@huawei.com>
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1069599131=="
Errors-To: lemonade-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1069599131==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_pyLVtNeL4TcN0bU/feNJlQ)"

This is a multi-part message in MIME format.

--Boundary_(ID_pyLVtNeL4TcN0bU/feNJlQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT


----- Original Message ----- 
From: Lingyan Wu 
To: lemonade@ietf.org 
Sent: Wednesday, July 26, 2006 11:44 AM
Subject: [lemonade] some questions in draft-ietf-lemonade-notifications-03


Hi All,

 

I have some questions as follows:

 

Questions 1: 

In 10.2 (Provision Entries), "push.shared" is defined as an attribute of in-band notifications (not the attribute of outband notifications) while in the first example in 10.4 "push.shared" is regarded as the attribute of outband notifications. 

Why? Maybe "push.shared" should be defined as an attribute of outband notifications too.

 

Question 2: 

In 10.3

"limit.priv" = "size=" nz-number  | "total=" nz-number 

;the maximum number of bytes to send in notification payloads or the total number of messages to send. Both per-day 

What's the benefit of limiting the total number of messages (notifications) per-day? If the number of notifications sent that day has reached the limit (e.g. 10 notifications per-day ) but then a very important email arrives, what should the server do? 

 

Question 3:

In 10.3:

"push.priv" = "push" / "pull" 

;specifies whether the client expects new messages to be pushed via the unsolicited FETCH response defined above, or via client issued FETCH in response to an EXISTS response. 

Is it possible to push new messages via outband notifications? E.g. through MMS channel. If it's possible, maybe we could define such an attribute for outband notification.

 

Question 4:

In 13.8

It MUST be possible to provide acknowledgment by the target to the messaging system or to repeat notification until such an acknowledgement is provided if supported by the notification channel.

Does it mean that the target (client) should provide acknowledgment for per-notification and the messaging system should repeat the same notification (not send the following notifications) until receive the acknowledgment for the notification?

If so, maybe it's more appropriate to send a notification after determining that the client is online (e.g. according to presence status of the client provided by presence enabler).



Best Regards,
Lingyan
Huawei Technologies Co., Ltd. 



--------------------------------------------------------------------------------


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--Boundary_(ID_pyLVtNeL4TcN0bU/feNJlQ)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV style=3D"FONT: 9pt =CB=CE=CC=E5">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=3Dwly0027@sina.com href=3D"mailto:wly0027@sina.com">Lingyan Wu</A> =
</DIV>
<DIV><B>To:</B> <A title=3Dlemonade@ietf.org=20
href=3D"mailto:lemonade@ietf.org">lemonade@ietf.org</A> </DIV>
<DIV><B>Sent:</B> Wednesday, July 26, 2006 11:44 AM</DIV>
<DIV><B>Subject:</B> [lemonade] some questions in=20
draft-ietf-lemonade-notifications-03</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Hi All,</FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New =
Roman"><o:p></o:p></FONT></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">I have some questions as=20
follows:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Questions 1:=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
face=3D"Times New Roman" size=3D3>In 10.2 (Provision Entries), =
"push.shared" is=20
defined as an attribute of in-band notifications (not the attribute of =
outband=20
notifications) while in the first example in 10.4 "push.shared" is =
regarded as=20
the attribute of outband notifications. </FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Why? Maybe "push.shared" should =
be defined=20
as an attribute of outband notifications=20
too.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Question 2:=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">In =
10.3<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">"limit.priv" =3D "size=3D" =
nz-number<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>| "total=3D" nz-number=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">;the maximum number of bytes to =
send in=20
notification payloads or the total number of messages to send. Both =
per-day=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">What's the benefit of limiting =
the total=20
number of messages (notifications) per-day? If the number of =
notifications sent=20
that day has reached the limit (e.g. 10 notifications per-day ) but then =
a very=20
important email arrives, what should the server do?=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Question=20
3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">In =
10.3:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">"push.priv" =3D "push" / "pull"=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">;specifies whether the client =
expects new=20
messages to be pushed via the unsolicited FETCH response defined above, =
or via=20
client issued FETCH in response to an EXISTS response.=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Is it possible to push new =
messages via=20
outband notifications? E.g. through MMS channel. If it's possible, maybe =
we=20
could define such an attribute for outband=20
notification.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Question=20
4:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">In =
13.8<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">It MUST be possible to provide=20
acknowledgment by the target to the messaging system or to repeat =
notification=20
until such an acknowledgement is provided if supported by the =
notification=20
channel.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Times New Roman">Does it mean that the target =
(client) should=20
provide acknowledgment for per-notification and the messaging system =
should=20
repeat the same notification (not send the following notifications) =
until=20
receive the acknowledgment for the=20
notification?<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
face=3D"Times New Roman" size=3D3>If so, maybe it's more appropriate to =
send a=20
notification after determining that the client is online (e.g. according =
to=20
presence status of the client provided by presence =
enabler).</FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US>Best=20
Regards,<BR>Lingyan<BR>Huawei Technologies Co., Ltd. =
</SPAN></P></FONT></DIV>
<P>
<HR>

<P></P>_______________________________________________<BR>lemonade =
mailing=20
list<BR>lemonade@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/lemon=
ade<BR></BODY></HTML>

--Boundary_(ID_pyLVtNeL4TcN0bU/feNJlQ)--


--===============1069599131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

--===============1069599131==--




From lemonade-bounces@ietf.org Fri Jul 28 18:28:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6aok-0000lQ-GN; Fri, 28 Jul 2006 18:28:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aoj-0000k6-JA
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:28:25 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6aoh-0007cy-5Z
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:28:25 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6SMRw5E019721
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 28 Jul 2006 15:28:09 -0700
Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15])
	by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6SMRdSC014553; 
	Fri, 28 Jul 2006 15:27:41 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630001ac0f03bdb99ab@[192.168.1.13]>
In-Reply-To: <E1G2Z6P-0007ZB-OR@stiedprstage1.ietf.org>
References: <E1G2Z6P-0007ZB-OR@stiedprstage1.ietf.org>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 28 Jul 2006 15:27:37 -0700
To: lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Subject: [lemonade] compress-02
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

(1) I think the Introduction should discuss the trade-offs in having 
an IMAP command for compression versus using TLS; specifically, using 
TLS has a major advantage in that all applications immediately 
benefit with no changes (for us, that's at least IMAP and message 
submission).  However, TLS compression is not yet widely supported 
(this was mentioned in -00 but dropped in -01).  Separately, as Dave 
points out, the compressing side has more control over the level of 
compression applied to a specific block of data, because of the APIs 
commonly used.

(2) In the discussion in Section 3 on ordering of compression and 
encryption, should there be advice on ordering with regard to 
authentication?  There was some discussion of this point at the 
Montreal meeting, and at a previous meeting (perhaps the interim?).

(3) The text in Section 4 says "clients which send many APPEND 
commands may want to take special care of literals, in the same way 
that servers do."  I think more specific advice would be helpful. 
What should a client do?  (Sending many APPENDs is, I think, fairly 
common for IMAP clients. )  Perhaps the text should say "in the same 
way that servers do, by sending Z_FULL_FLUSH as discussed later in 
this section".

(4) Typo in Section 4: "resembling a 6-bit bytes" -- "bytes" should 
be singular.

(5) Typo in Section 4: "change the level 0" should be "change the level to 0".
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I hope we shall...crush in its birth the aristocracy of our moneyed
corporations, which dare already to challenge our government to a
trial of strength, and bid defiance to the laws of our country.
         --Thomas Jefferson, letter to George Logan. November 12, 1816

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 18:29:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6aq0-0006j3-8Z; Fri, 28 Jul 2006 18:29:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6apz-0006iy-3c
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:29:43 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6apx-0007fv-Pj
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:29:43 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6SMTbmN019945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 28 Jul 2006 15:29:37 -0700
Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6SMTZEH003075; Fri, 28 Jul 2006 15:29:36 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630001bc0f040229a58@[192.168.1.13]>
In-Reply-To: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 28 Jul 2006 15:29:30 -0700
To: "Burger, Eric" <eburger@cantata.com>, <lemonade@ietf.org>
From: Randall Gellens <randy@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: 
Subject: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 3:17 PM -0400 7/20/06, Eric Burger wrote:

>  Please prepend the string "WGLC compress-02" to
>  the subject line of your comments.

Oops -- sorry, I forgot to do that.  [Comments in previous message.]
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The Macintosh may only have 10% of the market, but it is clearly
the top 10%.
       --Douglas Adams, 1996 WWDC.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 18:34:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6auU-0002ew-B9; Fri, 28 Jul 2006 18:34:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6auT-0002ef-VE
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:34:21 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6auR-0001Gb-IE
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:34:21 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6SMXnMq008130
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 28 Jul 2006 15:33:50 -0700
Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15])
	by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6SMXUp6004374; Fri, 28 Jul 2006 15:33:32 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630001cc0f0408ab2e4@[192.168.1.13]>
In-Reply-To: <11016.1153439508.644241@peirce.dave.cridland.net>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<11016.1153439508.644241@peirce.dave.cridland.net>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 28 Jul 2006 15:33:03 -0700
To: Dave Cridland <dave@cridland.net>, "Burger\, Eric" <eburger@cantata.com>, 
	Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] WGLC compress-02 comments
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 12:51 AM +0100 7/21/06, Dave Cridland wrote:

>  1) The abstract is confusing, implying as it does that TLS prevents 
> compression. This is only so for the types of link-level 
> compression later referred to in the draft, but I'm not aware of 
> high deployment of these outside traditional POTS modems.

Yes, this text can be improved.


>  6) Section 4 (Compression Efficiency) should, I think, be an 
> appendix. It's providing useful implementation notes, but is not 
> essential.

It is useful, it is advice, and it does not contain normative terms. 
But I think it's fine as a section.  I don't see a benefit in 
demoting it to a mere appendix.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Few ideas are really bad.  Most are either pre- or post-mature.
                                                   --Jon Postel

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 18:48:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6b8F-0000Sy-Bv; Fri, 28 Jul 2006 18:48:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6b8D-0000Ij-Gr
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:48:33 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6b8C-0005RT-4t
	for lemonade@ietf.org; Fri, 28 Jul 2006 18:48:33 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6SMm6eY022623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 28 Jul 2006 15:48:07 -0700
Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15])
	by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6SMlpPv006321; Fri, 28 Jul 2006 15:47:55 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630001dc0f0417fec3b@[192.168.1.13]>
In-Reply-To: <44C01838.4030303@isode.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<44C01838.4030303@isode.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 28 Jul 2006 15:39:26 -0700
To: Alexey Melnikov <alexey.melnikov@isode.com>,
	Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 12:56 AM +0100 7/21/06, Alexey Melnikov wrote:

>   >3.  The COMPRESS Command
>  [...]
>>     If both [STARTTLS] and COMPRESS are in use, the data should be
>
>  SASL is not listed here, but listed below. I suggest to change the 
> beginning of the first sentence to read:
>
>   >    If both [STARTTLS]/SASL security layer [SASL][IMAP] and 
> COMPRESS are in use, the data should be
>
>   >    compressed before it is encrypted (and decrypted before it is
>>     decompressed), independent of the order in which the client issues
>   >    COMPRESS, AUTHENTICATE and STARTTLS.

I think "both" becomes confusing when the first half includes two 
protocols.  Perhaps:

	If a security layer such as [STARTTLS] or [SASL] is used with COMPRESS,
	the data should be compressed before....


>  BTW, be prepared to answer IESG why you don't want an IANA registry.

May as well say clearly in the document that "deflate is the only 
currently defined mechanism.  Additional mechanisms are not expected 
to be required, but if so can be created by future RFCs which extend 
this document."
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Television is simply automated day-dreaming.
       --Lee Lovinger, _Quote_, July 30, 1967

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 19:03:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6bMD-0000NG-UH; Fri, 28 Jul 2006 19:03:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6bMC-0000NB-J6
	for lemonade@ietf.org; Fri, 28 Jul 2006 19:03:00 -0400
Received: from smtp-out.sendmail.com ([209.246.26.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6bMB-0000SI-7W
	for lemonade@ietf.org; Fri, 28 Jul 2006 19:03:00 -0400
Received: from lab.smi.sendmail.com ([10.210.100.93])
	by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id
	k6SN2fC6024528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Jul 2006 16:02:46 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k6SN2fC6024528
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim;
	t=1154127767; bh=VeGbdVgF7Fbmo/s0+nFKf7u76ms=; h=X-DomainKeys:
	DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To:
	Message-ID:References:MIME-Version:Content-Type; b=Mi7I1P9XhFF2TmHI
	nBp3AxoUenWSOESRzW1sytUKFqFsTwiO8g5WzqQJvdJ6W19bzz8r80pj2lt6VYmY9dy
	RmpeEgDPGIm+vgbpkARVPQOQX03atcv5+pctSMhJU9RIYQg/RLrir8VJnofO2UFrDI1
	HJVNfberM23bxfg+Kl7mc=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com
	k6SN2fC6024528
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id:
	references:mime-version:content-type;
	b=K6UpXuSL/g8uOqBge4IetzxXEMEHjxq8nZZrXccRHPhzl+eAGkLHo/d3T+2Dln4HF
	q2slkSJL2JE9jxu7C/IvQuglINO7bjaEqRyg9v9WtzNn/5QDhfAdHjgWMjd3Ex0QjCi
	+50BBNfPnqODO5To6zOX8k+a5lppj8eUueMLpE0=
Date: Fri, 28 Jul 2006 16:02:41 -0700
From: Philip Guenther <guenther+lemonade@sendmail.com>
X-X-Sender: guenther@lab.smi.sendmail.com
To: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
In-Reply-To: <p0630001dc0f0417fec3b@[192.168.1.13]>
Message-ID: <20060728155520.R26250@lab.smi.sendmail.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<44C01838.4030303@isode.com> <p0630001dc0f0417fec3b@[192.168.1.13]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: lemonade@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>,
	Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Fri, 28 Jul 2006, Randall Gellens wrote:
> At 12:56 AM +0100 7/21/06, Alexey Melnikov wrote:
...
>>  BTW, be prepared to answer IESG why you don't want an IANA registry.
>
> May as well say clearly in the document that "deflate is the only currently 
> defined mechanism.  Additional mechanisms are not expected to be required, 
> but if so can be created by future RFCs which extend this document."

For consistency, I suggest copying the text that the SORT/THREAD doc, 
draft-ietf-imapext-sort-17.txt, uses to describe the extensions and the 
registries.  To quote parts of that doc's Introduction and IANA 
Considerations sections:
     A server which supports the THREAD extension indicates this with one
     or more capability names consisting of "THREAD=" followed by a
     supported threading algorithm name as described in this document.
     This provides for future upwards-compatible extensions.
...
     This document creates a new [IMAP] threading algorithms registry, which
     registers threading algorithms by publishing a standards track or IESG
     approved experimental RFC.  This document constitutes registration of
     the ORDEREDSUBJECT and REFERENCES algorithms in that registry.


Philip Guenther

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 19:30:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6bmv-00024k-GX; Fri, 28 Jul 2006 19:30:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6bmu-00020n-Rn
	for lemonade@ietf.org; Fri, 28 Jul 2006 19:30:36 -0400
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6bmt-0002sn-H3
	for lemonade@ietf.org; Fri, 28 Jul 2006 19:30:36 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6SNUX0Q017348
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
	for <lemonade@ietf.org>; Fri, 28 Jul 2006 16:30:34 -0700
Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15])
	by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6SNUVXv005299
	for <lemonade@ietf.org>; Fri, 28 Jul 2006 16:30:33 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0630001fc0f0472a4044@[192.168.1.13]>
In-Reply-To: <0FA975F2D8295A448BE3ADC1612446579AD056@esebe199.NOE.Nokia.com>
References: <0FA975F2D8295A448BE3ADC1612446579AD056@esebe199.NOE.Nokia.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 28 Jul 2006 16:01:54 -0700
To: lemonade@ietf.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] WGLC compress-02
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 1:57 PM +0300 7/26/06, <Zoltan.Ordogh@nokia.com> wrote:

>  Hi all,
>  Here are my comments on this draft:
>  Section 2:
>  "but a careful IMAP implementation can do much better"  What makes 
> and IMAP implementation 'careful'? I know what You mean, but I 
> think we should find a better word here.

This is Dave's point about APIs.  I've suggested some improvements to 
the section.

>  "Hopefully it will not be necessary to define additional 
> algorithms." Suggest removal.

I sent suggested text on the issue.


>  Section 3:
>  "The client MUST NOT send any commands until it has seen the result 
> of COMPRESS." This is fine, but can the server send anything else 
> in the meantime? I mean I can turn it on at any time during the 
> session.

The server can't send anything else (such as an unsolicited response) 
in the meantime .  This seems obvious but could be explicitly stated.

>
>  Section 3 and section 5:
>  How can it be turned off?

By logging out and back in.  The added complexity of allowing it to 
be turned off doesn't seem to be justified by the low utility.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There will be no lasting peace on our earth as long as politicians and
dictators continue to lead masses of people who are endemically
neurotic and sexually sick.                            --Wilhelm Reich

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 20:23:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6cbn-0002ch-PI; Fri, 28 Jul 2006 20:23:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6cbm-0002cc-AP
	for lemonade@ietf.org; Fri, 28 Jul 2006 20:23:10 -0400
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6cbk-0007gg-VD
	for lemonade@ietf.org; Fri, 28 Jul 2006 20:23:10 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	k6T0Mipr002683
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 28 Jul 2006 17:22:55 -0700
Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15])
	by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id
	k6T0MWuF021675; Fri, 28 Jul 2006 17:22:33 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06300020c0f05a08ac4f@[192.168.1.13]>
In-Reply-To: <20060728155520.R26250@lab.smi.sendmail.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<44C01838.4030303@isode.com> <p0630001dc0f0417fec3b@[192.168.1.13]>
	<20060728155520.R26250@lab.smi.sendmail.com>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook?  Upgrade to Eudora: <http://www.eudora.com>
Date: Fri, 28 Jul 2006 17:20:36 -0700
To: Philip Guenther <guenther+lemonade@sendmail.com>
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: lemonade@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>,
	Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

At 4:02 PM -0700 7/28/06, Philip Guenther wrote:

>>>   BTW, be prepared to answer IESG why you don't want an IANA registry.
>>
>>  May as well say clearly in the document that "deflate is the only 
>> currently defined mechanism.  Additional mechanisms are not 
>> expected to be required, but if so can be created by future RFCs 
>> which extend this document."
>
>  For consistency, I suggest copying the text that the SORT/THREAD 
> doc, draft-ietf-imapext-sort-17.txt, uses to describe the 
> extensions and the registries.  To quote parts of that doc's 
> Introduction and IANA Considerations sections:
>      A server which supports the THREAD extension indicates this with one
>      or more capability names consisting of "THREAD=" followed by a
>      supported threading algorithm name as described in this document.
>      This provides for future upwards-compatible extensions.
>  ...
>      This document creates a new [IMAP] threading algorithms registry, which
>      registers threading algorithms by publishing a standards track or IESG
>      approved experimental RFC.  This document constitutes registration of
>      the ORDEREDSUBJECT and REFERENCES algorithms in that registry.


Sorry for not being clear: I don't think we need an IANA registry, 
because we don't expect to define future mechanisms.  If we find that 
we do need other mechanisms, we can define those in new RFCs that 
extend this one.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
He had occasional flashes of silence that made his conversation
perfectly delightful.                            --Sydney Smith

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 23:02:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6f5a-0001My-Kc; Fri, 28 Jul 2006 23:02:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6f5Z-0001Mt-ML
	for lemonade@ietf.org; Fri, 28 Jul 2006 23:02:05 -0400
Received: from smtp-out.sendmail.com ([209.246.26.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6f5Y-0006GW-Ag
	for lemonade@ietf.org; Fri, 28 Jul 2006 23:02:05 -0400
Received: from lab.smi.sendmail.com ([10.210.100.93])
	by foon.sendmail.com (Switch-3.2.3/Switch-3.2.0) with ESMTP id
	k6T31iST013887
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Jul 2006 20:01:45 -0700
X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k6T31iST013887
DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim;
	t=1154142113; bh=hGjI5YTDZfdC3fBfOWSP1QGtizs=; h=X-DomainKeys:
	DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To:
	Message-ID:References:MIME-Version:Content-Type; b=styQKRR6Sjfud3Cm
	xLs9eJImsPJ9/m/qSDs2NVZBvMckOsrRKSnQqf6gGhmZ4dzufAmzFjPhY4w6mkOIPK7
	bR56eh8BMlVySJLeXSYLpsJ8yZLYI0xyYscl6DVnPFwwu8yEz7NqrRP8lEia+YTkb28
	VEb0ulxQfPC8KNE0movkM=
X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com
	k6T31iST013887
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns;
	h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id:
	references:mime-version:content-type;
	b=ssFmbCPDuc5y2ghkD3zPOuIy6v5k1U5IBY9tKlCbOO70olkkCUoAvKLDDYzh/w368
	hI8piIoOq5xf+PtfONd+iXNOyAODeGZ0ymasNofbLgSML2BZfjSwF6EAaSwXke7TLlN
	bZIaNmoQx+LNX64yMdZSu4yn1tlPQrVin1b2WOs=
Date: Fri, 28 Jul 2006 20:01:44 -0700
From: Philip Guenther <guenther+lemonade@sendmail.com>
X-X-Sender: guenther@lab.smi.sendmail.com
To: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
In-Reply-To: <p06300020c0f05a08ac4f@[192.168.1.13]>
Message-ID: <20060728195619.J26250@lab.smi.sendmail.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<44C01838.4030303@isode.com> <p0630001dc0f0417fec3b@[192.168.1.13]>
	<20060728155520.R26250@lab.smi.sendmail.com>
	<p06300020c0f05a08ac4f@[192.168.1.13]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: lemonade@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>,
	Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Fri, 28 Jul 2006, Randall Gellens wrote:
...
> Sorry for not being clear: I don't think we need an IANA registry, because we 
> don't expect to define future mechanisms.  If we find that we do need other 
> mechanisms, we can define those in new RFCs that extend this one.

I don't think we expect to see future THREAD mechanisms either, but it's 
apparently simpler and less contentious to create a registry than it is to 
_not_ do so.  As author/editor/review time is the most precious commodity 
in the IETF, creating the registry and copying text to do so that people 
have already nodded their heads at seem like the most efficient choice.


Philip Guenther

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Fri Jul 28 23:15:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G6fIh-0000lD-9X; Fri, 28 Jul 2006 23:15:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G6fIf-0000l5-Mo
	for lemonade@ietf.org; Fri, 28 Jul 2006 23:15:37 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6fId-0007W2-AL
	for lemonade@ietf.org; Fri, 28 Jul 2006 23:15:37 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout5.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k6T3FYaw006399; Fri, 28 Jul 2006 20:15:34 -0700
X-Auth-Received: from Shimo-Tomobiki.panda.com ([166.209.76.136])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id
	k6T3FFCY026088
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 28 Jul 2006 20:15:29 -0700
Date: Fri, 28 Jul 2006 20:15:09 -0700
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Philip Guenther <guenther+lemonade@sendmail.com>
Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
In-Reply-To: <20060728195619.J26250@lab.smi.sendmail.com>
Message-ID: <Pine.WNT.4.65.0607282010050.1744@Shimo-Tomobiki.panda.com>
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>
	<44C01838.4030303@isode.com> <p0630001dc0f0417fec3b@[192.168.1.13]>
	<20060728155520.R26250@lab.smi.sendmail.com>
	<p06300020c0f05a08ac4f@[192.168.1.13]>
	<20060728195619.J26250@lab.smi.sendmail.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935,
	Antispam-Data: 2006.7.28.195432
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Fri, 28 Jul 2006, Philip Guenther wrote:
> I don't think we expect to see future THREAD mechanisms either, but it's 
> apparently simpler and less contentious to create a registry than it is to 
> _not_ do so.  As author/editor/review time is the most precious commodity in 
> the IETF, creating the registry and copying text to do so that people have 
> already nodded their heads at seem like the most efficient choice.

Excellent point.

It's also important to note that creating a registry is a great way to 
prevent bad ideas from getting into a protocol.  If you don't have a 
registry, then everybody who thinks that he has a Very Important Idea will 
fillibuster the specification until the bad idea is added to the 
specification.  With a registry, the people with VIIs have an outlet, but 
then have to make the VII stand on its own (which few VIIs will actually 
accomplish).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 04:15:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7SvY-0003v6-47; Mon, 31 Jul 2006 04:15:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7SvX-0003u2-2i
	for lemonade@ietf.org; Mon, 31 Jul 2006 04:15:03 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7SvV-0000mU-Eu
	for lemonade@ietf.org; Mon, 31 Jul 2006 04:15:03 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k6V7ExjT005856; Mon, 31 Jul 2006 10:15:00 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 31 Jul 2006 11:14:59 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 31 Jul 2006 11:14:59 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] WGLC compress-02
Date: Mon, 31 Jul 2006 11:14:29 +0300
Message-ID: <0FA975F2D8295A448BE3ADC161244657A1AD57@esebe199.NOE.Nokia.com>
In-Reply-To: <p0630001fc0f0472a4044@[192.168.1.13]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [lemonade] WGLC compress-02
Thread-Index: AcayneT5nJy6mlcVQ8qmDzuC2NVjVgB2l36w
From: <Zoltan.Ordogh@nokia.com>
To: <randy@qualcomm.com>, <lemonade@ietf.org>
X-OriginalArrivalTime: 31 Jul 2006 08:14:59.0367 (UTC)
	FILETIME=[6A464370:01C6B479]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: 
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Hi Randall,
Thank You for Your asnwers.
I added questions/comments to the last two issues tagged with [Z=D6r].
Thank you.

Best regards: Zolt=E1n =D6rd=F6gh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566


-----Original Message-----
From: ext Randall Gellens [mailto:randy@qualcomm.com]=20
Sent: 29 July, 2006 02:02
To: lemonade@ietf.org
Subject: Re: [lemonade] WGLC compress-02

At 1:57 PM +0300 7/26/06, <Zoltan.Ordogh@nokia.com> wrote:

>  Hi all,
>  Here are my comments on this draft:
>  Section 2:
>  "but a careful IMAP implementation can do much better"  What makes=20
> and IMAP implementation 'careful'? I know what You mean, but I think=20
> we should find a better word here.

This is Dave's point about APIs.  I've suggested some improvements to =
the section.

>  "Hopefully it will not be necessary to define additional algorithms." =

> Suggest removal.

I sent suggested text on the issue.


>  Section 3:
>  "The client MUST NOT send any commands until it has seen the result=20
> of COMPRESS." This is fine, but can the server send anything else in=20
> the meantime? I mean I can turn it on at any time during the session.

The server can't send anything else (such as an unsolicited response) in =
the meantime .  This seems obvious but could be explicitly stated.
[Z=D6r] This is true only if You issue the command during login I guess =
- if You issue it during some other time during the session, You might =
get other responses as well.
>From Your response below to my question below it seems that this command =
can be used only once - but the draft does not say that it is the login =
phase during which it has to be used when compression is desired.
Thank you.

>
>  Section 3 and section 5:
>  How can it be turned off?

By logging out and back in.  The added complexity of allowing it to be =
turned off doesn't seem to be justified by the low utility.
[Z=D6r] Question: if I do a quick reconnect, will the compression state =
be restored? (in which case disconnect will not help me much).
Another thing is that when I store an email that contains an =
uncompressable (JPG, ZIP) file, I might want to switch compression off =
before uploading it, and turn it back on afterwards. I am sure that this =
has been discussed, but I do not seem to be able to find the related =
emails - so I ask it again to get the right answers.
Thank you.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- There will be no =
lasting peace on our earth as long as politicians and dictators continue =
to lead masses of people who are endemically
neurotic and sexually sick.                            --Wilhelm Reich

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 08:24:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7Wos-0003Jz-Pp; Mon, 31 Jul 2006 08:24:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Wor-0003Ju-9h
	for lemonade@ietf.org; Mon, 31 Jul 2006 08:24:25 -0400
Received: from smarthost.yourcomms.net ([195.8.160.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Wop-0000oZ-Pp
	for lemonade@ietf.org; Mon, 31 Jul 2006 08:24:25 -0400
Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.3])
	by smarthost.yourcomms.net (8.11.7p1+Sun/8.11.6) with ESMTP id
	k6VCCN602358
	for <lemonade@ietf.org>; Mon, 31 Jul 2006 13:12:24 +0100 (BST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [lemonade] Notifications for multiple devices per user
Date: Mon, 31 Jul 2006 13:23:51 +0100
Message-ID: <22C8A0D5D5E095449AB509FE777B5F80029DE205@svr-exchange.avocado.emccsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: [lemonade] Notifications for multiple devices per user
Thread-Index: Aca0nC4+ShlxyO+dRTacUImYW1XYew==
From: "Ben Last" <Ben.Last@emccsoft.com>
To: <lemonade@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

>At Thu, 22 Jun 2006 11:38:50 -0700, Randall Gellens wrote:
>>At 3:40 PM +0300 6/22/06, <Zoltan.Ordogh at nokia.com> wrote:
>>Hi Randall,
>>this is exactly what I tried to avoid with the MOVE command. But there
is another aspect to it as well: if the message gets a new ID, the
client will have to
>re-download a mail that it already has. Repeated transfer bad.=20

>Hi Zoltan,
>The change in UID and hence re-downloading isn't another aspect, it's
the primary aspect of other clients not knowing that these are the same
message.
>The original client, the one that did the COPY, can know that these are
the same message because UIDPLUS allows it to learn the new UID. The
client can
>then update its cache to reflect this.

At the risk of following up an earlier post after an excessive delay:
has there been discussion on the list of the same effect happening with
renaming of whole folders?  That is, if folder A is renamed as folder B
using one IMAP client, other clients will see A vanish and B appear,
with no way to tell that they are the same folder?  We're currently
seeing this as the worst of all repeated-download scenarios.

Also, on a related topic, despite considerable Googling I haven't
managed to track down whether there are discussions on metadata for
folders.  For example, one server vendor has recommended to us (we're
developing a mobile Symbian LEMONADE client) that we identify the Trash
folder created by their webmail interface by looking for the name
"Trash".  The major problems with this approach are that (a) the name of
the Trash folder varies by language & locale, and is customizable by the
mail server operator and (b) the name of that and all other folders
(except the Inbox) are editable by the mailbox user.  Thus we have no
reliable way to identify the Trash (or Outbox, or Sent folders) created
by other IMAP clients.  Has there been discussion on this?

Apologies if asking the question intrudes on far more useful and
relevant list traffic! :)

Regards to all
ben

Ben Last
EMCC Software
ben.last@emccsoft.com

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 10:05:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7YOn-0003gq-A0; Mon, 31 Jul 2006 10:05:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YOm-0003gl-34
	for lemonade@ietf.org; Mon, 31 Jul 2006 10:05:36 -0400
Received: from mail121.messagelabs.com ([216.82.241.195])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7YOj-0006Aj-Ng
	for lemonade@ietf.org; Mon, 31 Jul 2006 10:05:36 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-14.tower-121.messagelabs.com!1154354733!9450113!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 23401 invoked from network); 31 Jul 2006 14:05:33 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-14.tower-121.messagelabs.com with SMTP;
	31 Jul 2006 14:05:33 -0000
Received: from [135.210.97.152] (unknown[135.210.97.152](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060731140532gw1003jog5e> (Authid: tony);
	Mon, 31 Jul 2006 14:05:32 +0000
Message-ID: <44CE0E2B.50709@att.com>
Date: Mon, 31 Jul 2006 10:05:31 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] WGLC draft-ietf-lemonade-compress-02.txt
References: <330A23D8336C0346B5C1A5BB19666647034EECEB@ATLANTIS.Brooktrout.com>	<44C01838.4030303@isode.com>
	<p0630001dc0f0417fec3b@[192.168.1.13]>	<20060728155520.R26250@lab.smi.sendmail.com>	<p06300020c0f05a08ac4f@[192.168.1.13]>
	<20060728195619.J26250@lab.smi.sendmail.com>
In-Reply-To: <20060728195619.J26250@lab.smi.sendmail.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

+1

Philip Guenther wrote:
> On Fri, 28 Jul 2006, Randall Gellens wrote:
> ...
>> Sorry for not being clear: I don't think we need an IANA registry,
>> because we don't expect to define future mechanisms.  If we find that
>> we do need other mechanisms, we can define those in new RFCs that
>> extend this one.
> 
> I don't think we expect to see future THREAD mechanisms either, but it's
> apparently simpler and less contentious to create a registry than it is
> to _not_ do so.  As author/editor/review time is the most precious
> commodity in the IETF, creating the registry and copying text to do so
> that people have already nodded their heads at seem like the most
> efficient choice.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 10:56:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7ZCU-0004HM-9o; Mon, 31 Jul 2006 10:56:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZCT-0004HH-9O
	for lemonade@ietf.org; Mon, 31 Jul 2006 10:56:57 -0400
Received: from mail120.messagelabs.com ([216.82.250.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7ZCQ-0002am-Uj
	for lemonade@ietf.org; Mon, 31 Jul 2006 10:56:57 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-6.tower-120.messagelabs.com!1154357813!10922082!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 24637 invoked from network); 31 Jul 2006 14:56:53 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-6.tower-120.messagelabs.com with SMTP;
	31 Jul 2006 14:56:53 -0000
Received: from [135.210.97.152] (unknown[135.210.97.152](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060731145653gw1003jogue> (Authid: tony);
	Mon, 31 Jul 2006 14:56:53 +0000
Message-ID: <44CE1A34.8020908@att.com>
Date: Mon, 31 Jul 2006 10:56:52 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: lemonade@ietf.org
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Subject: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

I think the following covers all that is needed to handle the
possibility of future algorithms being needed, while making it suitably
difficult to actually add one.

*IF* in the future, another algorithm were added, and a server supported
both algorithms, how would the additional algorithms be announced? I
think we should choose a method comparable to that used in other
mechanisms that allow multiple values, that is, a comma separated list.

There is no ABNF specified for the COMPRESS capability, so we need to
add this to the ABNF section.

	capability =/ "COMPRESS=" algorithm-list
	algorithm-list = algorithm *["," algorithm]

Just in case, some future algorithms may require arguments to be passed.
I suggest adding the following to the compress ABNF:

        compress    = "COMPRESS" SP algorithm *[SP argument]
	argument    = 1*TEXT

For the IANA considerations section, I think the following would be
appropriate:

7. IANA Considerations

    The IANA is requested to add COMPRESS=DEFLATE to the list of IMAP
    extensions.

    The IANA is requested to maintain one new registry: IMAP Compression
    Algorithms. The registry's purpose is to register compression
    algorithms that may be used with this extension.  New IMAP
    algorithms MUST be defined in a standards track or IESG approved
    experimental RFC.  New IMAP compression algorithms MUST include the
    following information as part of their definition:

	algorithm identifier
	optional arguments
	standard commands affected
	specification reference
	discussion

That's it.

	Tony Hansen
	tony@att.com

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 11:02:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7ZHv-0007Uw-LG; Mon, 31 Jul 2006 11:02:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZHu-0007Ur-7C
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:02:34 -0400
Received: from mail120.messagelabs.com ([216.82.250.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7ZHs-00035S-SG
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:02:34 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-15.tower-120.messagelabs.com!1154358151!11395182!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 20695 invoked from network); 31 Jul 2006 15:02:31 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-15.tower-120.messagelabs.com with SMTP;
	31 Jul 2006 15:02:31 -0000
Received: from [135.210.97.152] (unknown[135.210.97.152](misconfigured sender))
	by maillennium.att.com (mailgw1) with ESMTP
	id <20060731150230gw1003joh2e> (Authid: tony);
	Mon, 31 Jul 2006 15:02:31 +0000
Message-ID: <44CE1B86.5050500@att.com>
Date: Mon, 31 Jul 2006 11:02:30 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
References: <44CE1A34.8020908@att.com>
In-Reply-To: <44CE1A34.8020908@att.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

One addition, below.

	Tony

Tony Hansen wrote:
> I think the following covers all that is needed to handle the
> possibility of future algorithms being needed, while making it suitably
> difficult to actually add one.
> 
> *IF* in the future, another algorithm were added, and a server supported
> both algorithms, how would the additional algorithms be announced? I
> think we should choose a method comparable to that used in other
> mechanisms that allow multiple values, that is, a comma separated list.
> 
> There is no ABNF specified for the COMPRESS capability, so we need to
> add this to the ABNF section.
> 
> 	capability =/ "COMPRESS=" algorithm-list
> 	algorithm-list = algorithm *["," algorithm]
> 
> Just in case, some future algorithms may require arguments to be passed.
> I suggest adding the following to the compress ABNF:
> 
>         compress    = "COMPRESS" SP algorithm *[SP argument]
> 	argument    = 1*TEXT
> 
> For the IANA considerations section, I think the following would be
> appropriate:
> 
> 7. IANA Considerations
> 
>     The IANA is requested to add COMPRESS=DEFLATE to the list of IMAP
>     extensions.
> 
>     The IANA is requested to maintain one new registry: IMAP Compression
>     Algorithms. The registry's purpose is to register compression
>     algorithms that may be used with this extension.  New IMAP
>     algorithms MUST be defined in a standards track or IESG approved
>     experimental RFC.  New IMAP compression algorithms MUST include the
>     following information as part of their definition:
> 
> 	algorithm identifier
> 	optional arguments
> 	standard commands affected
> 	specification reference
> 	discussion

    One IMAP compression algorithm is defined in this document, with the
    following registration definition:

      algorithm identifier: DEFLATE
      optional arguments: none
      standard commands affected: none
      specification reference: RFC 1951 and XXXX
      discussion: see RFC XXXX

    [RFC-EDITOR NOTE: change XXXX to this RFC number]


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 11:23:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7Zbu-0000gp-7F; Mon, 31 Jul 2006 11:23:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Zbs-0000cE-Vh
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:23:12 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Zbr-0004O0-5O
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:23:12 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Mon, 31 Jul 2006 16:23:00 +0100
Message-ID: <44CE2024.3040004@isode.com>
Date: Mon, 31 Jul 2006 16:22:12 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen <tony@att.com>
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
References: <44CE1A34.8020908@att.com>
In-Reply-To: <44CE1A34.8020908@att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Tony Hansen wrote:

>There is no ABNF specified for the COMPRESS capability, so we need to
>add this to the ABNF section.
>
>	capability =/ "COMPRESS=" algorithm-list
>	algorithm-list = algorithm *["," algorithm]
>  
>
I think we should use:

	capability =/ "COMPRESS=" algorithm
                      ;; multiple COMPRESS capabilities allowed


because existing clients don't usually parse anything after the '=' sign.


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 11:37:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7Zph-000126-5A; Mon, 31 Jul 2006 11:37:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Zpf-000121-NW
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:37:27 -0400
Received: from rutherford.zen.co.uk ([212.23.3.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Zpe-0005Ih-9l
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:37:27 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by rutherford.zen.co.uk with esmtp (Exim 4.50)
	id 1G7Zpd-0003Bs-9M; Mon, 31 Jul 2006 15:37:25 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id E8B54498003;
	Mon, 31 Jul 2006 16:42:02 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 24580-03; Mon, 31 Jul 2006 16:41:36 +0100 (BST)
Received: from invsysm1 (shiny.isode.com [62.3.217.250])
	by turner.dave.cridland.net (Postfix) with ESMTP id E6C88498002;
	Mon, 31 Jul 2006 16:41:35 +0100 (BST)
Date: Mon, 31 Jul 2006 16:36:54 +0100
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
References: <44CE1A34.8020908@att.com> <44CE2024.3040004@isode.com>
In-Reply-To: <44CE2024.3040004@isode.com>
MIME-Version: 1.0
Message-Id: <26599.1154360217.136581@invsysm1>
From: Dave Cridland <dave@cridland.net>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon Jul 31 16:22:12 2006, Alexey Melnikov wrote:
> Tony Hansen wrote:
> 
>> There is no ABNF specified for the COMPRESS capability, so we need 
>> to
>> add this to the ABNF section.
>> 
>> 	capability =/ "COMPRESS=" algorithm-list
>> 	algorithm-list = algorithm *["," algorithm]
>>  
> I think we should use:
> 
> 	capability =/ "COMPRESS=" algorithm
>                      ;; multiple COMPRESS capabilities allowed
> 
> 
> because existing clients don't usually parse anything after the '=' 
> sign.
> 
> 
I'm happier with that too, it matches how AUTH and THREAD work.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 11:46:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7ZyS-0002ps-Ho; Mon, 31 Jul 2006 11:46:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZyR-0002pn-8H
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:46:31 -0400
Received: from rufus.isode.com ([62.3.217.251])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ZyP-0005oi-Ez
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:46:31 -0400
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
	by rufus.isode.com via TCP (submission) with ESMTPA;
	Mon, 31 Jul 2006 16:46:22 +0100
Message-ID: <44CE259C.6000006@isode.com>
Date: Mon, 31 Jul 2006 16:45:32 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
	Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen <tony@att.com>
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
References: <44CE1A34.8020908@att.com>
In-Reply-To: <44CE1A34.8020908@att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

More comments below.

Tony Hansen wrote:

>Just in case, some future algorithms may require arguments to be passed.
>I suggest adding the following to the compress ABNF:
>
>        compress    = "COMPRESS" SP algorithm *[SP argument]
>	argument    = 1*TEXT
>  
>
Should this be "astring" at least?

I suggest we either use RFC 4466 or not define any extensions at all. I 
prefer the latter.

>For the IANA considerations section, I think the following would be
>appropriate:
>
>7. IANA Considerations
>
>    The IANA is requested to add COMPRESS=DEFLATE to the list of IMAP
>    extensions.
>
>    The IANA is requested to maintain one new registry: IMAP Compression
>    Algorithms. The registry's purpose is to register compression
>    algorithms that may be used with this extension.  New IMAP
>    algorithms MUST be defined in a standards track or IESG approved
>    experimental RFC.  New IMAP compression algorithms MUST include the
>    following information as part of their definition:
>
>	algorithm identifier
>	optional arguments
>  
>
I would change this to "optional arguments to COMPRESS command"

>	standard commands affected
>	specification reference
>	discussion
>  
>
It is also common to have a contact email address (or Author/controller).


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 11:48:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7a0d-000379-Lo; Mon, 31 Jul 2006 11:48:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7a0c-000371-52
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:48:46 -0400
Received: from mxout3.cac.washington.edu ([140.142.32.166])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7a0a-0005vq-R0
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:48:46 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout3.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k6VFmeAv024759; Mon, 31 Jul 2006 08:48:40 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id
	k6VFmdO6030084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 31 Jul 2006 08:48:40 -0700
Date: Mon, 31 Jul 2006 08:47:54 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
In-Reply-To: <44CE259C.6000006@isode.com>
Message-ID: <Pine.OSX.4.64.0607310847200.494@pangtzu.panda.com>
References: <44CE1A34.8020908@att.com> <44CE259C.6000006@isode.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935,
	Antispam-Data: 2006.7.31.82932
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: lemonade@ietf.org, Tony Hansen <tony@att.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 31 Jul 2006, Alexey Melnikov wrote:
>>        compress    = "COMPRESS" SP algorithm *[SP argument]
>> 	argument    = 1*TEXT
> Should this be "astring" at least?

atom.  Please.

> I suggest we either use RFC 4466 or not define any extensions at all. I 
> prefer the latter.

+1

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 11:51:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7a2n-0004UN-LK; Mon, 31 Jul 2006 11:51:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7a2m-0004RJ-LV
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:51:00 -0400
Received: from kalyani.oryx.com ([195.30.37.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7a2k-0006DG-5q
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:51:00 -0400
Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9])
	by kalyani.oryx.com (Postfix) with ESMTP id E629D4AD19;
	Mon, 31 Jul 2006 17:50:56 +0200 (CEST)
Message-Id: <saq6dmdD2Qd6ExTEqUBLJg.md5@libertango.oryx.com>
Date: Mon, 31 Jul 2006 17:50:57 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: lemonade@ietf.org
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
References: <44CE1A34.8020908@att.com> <44CE2024.3040004@isode.com>
	<26599.1154360217.136581@invsysm1>
In-Reply-To: <26599.1154360217.136581@invsysm1>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Alexey Melnikov <alexey.melnikov@isode.com>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Dave Cridland writes:
> On Mon Jul 31 16:22:12 2006, Alexey Melnikov wrote:
>> I think we should use:
>>
>>       capability =/ "COMPRESS=" algorithm
>>                      ;; multiple COMPRESS capabilities allowed
>>
>> because existing clients don't usually parse anything after the '=' sign.
>
> I'm happier with that too, it matches how AUTH and THREAD work.

Agreed. In fact I'm very unhappy with anything else (absent arguments).

I'll publish a new draft tomorrow, including (AFAICR) all suggested changes.

Arnt

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 12:11:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7aMf-00034D-8T; Mon, 31 Jul 2006 12:11:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7aMe-000344-6y
	for lemonade@ietf.org; Mon, 31 Jul 2006 12:11:32 -0400
Received: from mail120.messagelabs.com ([216.82.250.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7aMc-0007NS-SE
	for lemonade@ietf.org; Mon, 31 Jul 2006 12:11:32 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-4.tower-120.messagelabs.com!1154362269!13729395!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 31693 invoked from network); 31 Jul 2006 16:11:09 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-4.tower-120.messagelabs.com with SMTP;
	31 Jul 2006 16:11:09 -0000
Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted
	sender)) by maillennium.att.com (mailgw1) with ESMTP
	id <20060731161109gw1003joise> (Authid: tony);
	Mon, 31 Jul 2006 16:11:09 +0000
Message-ID: <44CE2B9A.6030001@att.com>
Date: Mon, 31 Jul 2006 12:11:06 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
References: <44CE1A34.8020908@att.com> <44CE259C.6000006@isode.com>
	<Pine.OSX.4.64.0607310847200.494@pangtzu.panda.com>
In-Reply-To: <Pine.OSX.4.64.0607310847200.494@pangtzu.panda.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Mark Crispin wrote:
> On Mon, 31 Jul 2006, Alexey Melnikov wrote:
>>>        compress    = "COMPRESS" SP algorithm *[SP argument]
>>>     argument    = 1*TEXT
>> Should this be "astring" at least?
> 
> atom.  Please.

atom is fine.

	Tony Hansen
	tony@att.com

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 12:28:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7acW-0001Da-CY; Mon, 31 Jul 2006 12:27:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7acV-0001DV-8X
	for lemonade@ietf.org; Mon, 31 Jul 2006 12:27:55 -0400
Received: from mail120.messagelabs.com ([216.82.250.83])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7acT-0008Ow-UE
	for lemonade@ietf.org; Mon, 31 Jul 2006 12:27:55 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-15.tower-120.messagelabs.com!1154363101!11399184!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 26164 invoked from network); 31 Jul 2006 16:25:02 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-15.tower-120.messagelabs.com with SMTP;
	31 Jul 2006 16:25:02 -0000
Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted
	sender)) by maillennium.att.com (mailgw1) with ESMTP
	id <20060731162501gw1003joj1e> (Authid: tony);
	Mon, 31 Jul 2006 16:25:01 +0000
Message-ID: <44CE2EDC.5010406@att.com>
Date: Mon, 31 Jul 2006 12:25:00 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] WGLC compress-02: multiple COMPRESS algorithms
References: <44CE1A34.8020908@att.com>
	<44CE2024.3040004@isode.com>	<26599.1154360217.136581@invsysm1>
	<saq6dmdD2Qd6ExTEqUBLJg.md5@libertango.oryx.com>
In-Reply-To: <saq6dmdD2Qd6ExTEqUBLJg.md5@libertango.oryx.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> On Mon Jul 31 16:22:12 2006, Alexey Melnikov wrote:
>>> I think we should use:
>>>
>>>       capability =/ "COMPRESS=" algorithm
>>>                      ;; multiple COMPRESS capabilities allowed
>>>
>>> because existing clients don't usually parse anything after the '=' sign.
>> I'm happier with that too, it matches how AUTH and THREAD work.
> 
> Agreed. In fact I'm very unhappy with anything else (absent arguments).

This is fine.

The intro should correspondingly be changed to:

    A server which supports the COMPRESS extension indicates this with
    one or more capability names consisting of "COMPRESS=" followed by a
    supported compression algorithm name as described in this document.

    The goal of the COMPRESS extension is to reduce the bandwidth usage
    of IMAP.  On regular IMAP connections, the PPP or MNP compression
    used with many low-bandwidth links compresses IMAP well. However,
    when TLS is used, PPP/MNP compression is ineffective. TLS too may
    provide compression, but a careful IMAP implementation can do much
    better.

    In order to increase interoperation, it is desirable to have as few
    different compression algorithms as possible, so this document
    specifies only one, DEFLATE.  The DEFLATE algorithm is standard,
    widely available, unencumbered by patents and fairly efficient.
    Hopefully it will not be necessary to define additional algorithms.

	Tony Hansen
	tony@att.com

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 15:17:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7dGQ-0003Lo-Gl; Mon, 31 Jul 2006 15:17:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dGP-0003Lg-Br
	for lemonade@ietf.org; Mon, 31 Jul 2006 15:17:17 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7aDd-0006rp-NH
	for lemonade@ietf.org; Mon, 31 Jul 2006 12:02:13 -0400
Received: from mxout4.cac.washington.edu ([140.142.33.19])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7Zo3-0002Sh-9W
	for lemonade@ietf.org; Mon, 31 Jul 2006 11:35:50 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout4.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k6VFZZ5n020895; Mon, 31 Jul 2006 08:35:35 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id
	k6VFZTrj026661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 31 Jul 2006 08:35:35 -0700
Date: Mon, 31 Jul 2006 08:34:44 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Ben Last <Ben.Last@emccsoft.com>
Subject: RE: [lemonade] Notifications for multiple devices per user
In-Reply-To: <22C8A0D5D5E095449AB509FE777B5F80029DE205@svr-exchange.avocado.emccsoft.com>
Message-ID: <Pine.OSX.4.64.0607310817520.494@pangtzu.panda.com>
References: <22C8A0D5D5E095449AB509FE777B5F80029DE205@svr-exchange.avocado.emccsoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935,
	Antispam-Data: 2006.7.31.81932
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: -2.6 (--)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 31 Jul 2006, Ben Last wrote:
> Thus we have no
> reliable way to identify the Trash (or Outbox, or Sent folders) created
> by other IMAP clients.  Has there been discussion on this?

One simple answer is "don't use a Trash mailbox, use the native IMAP 
delete/expunge model instead."

For me, the razor of the quality of an IMAP client implemention is whether 
or not it uses a Trash mailbox.  If it does, it is poor-quality by [my] 
definition.  It indicates an unimaginative client author who expects data 
in a store to implement and mirror GUI artifacts.  Such individuals tend 
to do things like "hmm, it says here that the * wildcard is harmful and 
should be avoided.  OK, I will a %/% wildcard, and walk the tree manually 
with multiple LIST commands."

I find it amusing that the same working group that is so obsessed with 
minimizing downloads would even consider a Trash mailbox, given the 
enormous costs that it imposes.  Specifically, unlike the native IMAP 
delete/expunge model, there is no way in Trash to undelete a message 
without creating a completely new instance of the message in the mailbox.

The above is my opinion, and may not be shared by others.  But I have a 
right to my opinion.

The need to identify a sent-message mailbox is a different matter, 
provided that we agree upon a firm, immutable definition of what 
constitutes a sent-message mailbox with no wiggle-room for fools to create 
non-interoperable situations.  ACAP was supposed to solve that problem...

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 15:44:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7dgK-0005QT-TB; Mon, 31 Jul 2006 15:44:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dgJ-0005QO-BN
	for lemonade@ietf.org; Mon, 31 Jul 2006 15:44:03 -0400
Received: from mail146.messagelabs.com ([216.82.245.131])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G7dgH-0004MN-2m
	for lemonade@ietf.org; Mon, 31 Jul 2006 15:44:03 -0400
X-VirusChecked: Checked
X-Env-Sender: tony@att.com
X-Msg-Ref: server-14.tower-146.messagelabs.com!1154375040!602551!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 28850 invoked from network); 31 Jul 2006 19:44:00 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4)
	by server-14.tower-146.messagelabs.com with SMTP;
	31 Jul 2006 19:44:00 -0000
Received: from [135.91.110.64] (thansen-n.mt.att.com[135.91.110.64](untrusted
	sender)) by maillennium.att.com (mailgw1) with ESMTP
	id <20060731194400gw1003jolge> (Authid: tony);
	Mon, 31 Jul 2006 19:44:00 +0000
Message-ID: <44CE5D7F.10303@att.com>
Date: Mon, 31 Jul 2006 15:43:59 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: lemonade@ietf.org
Subject: Re: [lemonade] Notifications for multiple devices per user
References: <22C8A0D5D5E095449AB509FE777B5F80029DE205@svr-exchange.avocado.emccsoft.com>
	<Pine.OSX.4.64.0607310817520.494@pangtzu.panda.com>
In-Reply-To: <Pine.OSX.4.64.0607310817520.494@pangtzu.panda.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

Mark Crispin wrote:
> The above is my opinion, and may not be shared by others.  But I have a
> right to my opinion.
> 
> The need to identify a sent-message mailbox is a different matter,
> provided that we agree upon a firm, immutable definition of what
> constitutes a sent-message mailbox with no wiggle-room for fools to
> create non-interoperable situations.  ACAP was supposed to solve that
> problem...

Can we define an standardized list of Annotations for this and other
such "special" mailboxes?

	Tony Hansen
	tony@att.com

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 18:08:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7fw9-0004TJ-3y; Mon, 31 Jul 2006 18:08:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7fw7-0004SY-RP
	for lemonade@ietf.org; Mon, 31 Jul 2006 18:08:31 -0400
Received: from rutherford.zen.co.uk ([212.23.3.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7fw4-0001ar-8z
	for lemonade@ietf.org; Mon, 31 Jul 2006 18:08:31 -0400
Received: from [217.155.137.60] (helo=turner.dave.cridland.net)
	by rutherford.zen.co.uk with esmtp (Exim 4.50)
	id 1G7fw1-0000Jk-QK; Mon, 31 Jul 2006 22:08:25 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by turner.dave.cridland.net (Postfix) with ESMTP id DEE97498003;
	Mon, 31 Jul 2006 23:13:05 +0100 (BST)
Received: from turner.dave.cridland.net ([127.0.0.1])
	by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 25936-07; Mon, 31 Jul 2006 23:12:41 +0100 (BST)
Received: from invsysm1 (unknown [213.205.237.251])
	by turner.dave.cridland.net (Postfix) with ESMTP id CAD9F498002;
	Mon, 31 Jul 2006 23:12:39 +0100 (BST)
Date: Mon, 31 Jul 2006 23:07:22 +0100
Subject: RE: [lemonade] Notifications for multiple devices per user
References: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F800?=
	=?US-ASCII?Q?9DE205@svr-exchange.avocado.emccsoft.com>?=
	<Pine.OSX.4.64.0607310817520.494@pangtzu.panda.com>
In-Reply-To: <Pine.OSX.4.64.0607310817520.494@pangtzu.panda.com>
MIME-Version: 1.0
Message-Id: <6137.1154383678.599309@invsysm1>
From: Dave Cridland <dave@cridland.net>
To: Mark Crispin <mrc@CAC.Washington.EDU>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net
X-Originating-Rutherford-IP: [217.155.137.60]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon Jul 31 16:34:44 2006, Mark Crispin wrote:
> On Mon, 31 Jul 2006, Ben Last wrote:
>> Thus we have no
>> reliable way to identify the Trash (or Outbox, or Sent folders) 
>> created
>> by other IMAP clients.  Has there been discussion on this?
> 
> One simple answer is "don't use a Trash mailbox, use the native 
> IMAP delete/expunge model instead."
> 
> 
http://dave.cridland.net/draft-cridland-imap-trash.txt

(Which was sufficiently contentious that I've not submitted, but will 
do if there's demand).

> The need to identify a sent-message mailbox is a different matter, 
> provided that we agree upon a firm, immutable definition of what 
> constitutes a sent-message mailbox with no wiggle-room for fools to 
> create non-interoperable situations.  ACAP was supposed to solve 
> that problem...

I think you're oversimplifying the problem in any case - there's two 
problems:

The first relates to the difficulty in identifying the difference 
between a message you intend to send (perhaps assembling it on the 
server with CATENATE) and one that actually has been successfully 
sent. Whether all the messages in the same category happen to be in a 
specific mailbox or not is another matter.

The second relates to interoperable configuration between clients, 
such that different clients automatically reflect the user's stated 
preferences. This is the problem that was solved by ACAP very well 
nearly a decade ago, a solution which I happily use every time I send 
a message.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade



From lemonade-bounces@ietf.org Mon Jul 31 18:16:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G7g3o-00005k-Fv; Mon, 31 Jul 2006 18:16:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G7g3n-00005f-Nf
	for lemonade@ietf.org; Mon, 31 Jul 2006 18:16:27 -0400
Received: from mxout7.cac.washington.edu ([140.142.32.178])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7g3m-0002iw-Af
	for lemonade@ietf.org; Mon, 31 Jul 2006 18:16:27 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9])
	by mxout7.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP
	id k6VMGEN3019435; Mon, 31 Jul 2006 15:16:14 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117])
	(authenticated authid=mrc)
	by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id
	k6VMGDFG015948
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 31 Jul 2006 15:16:14 -0700
Date: Mon, 31 Jul 2006 15:15:28 -0700 (PDT)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Dave Cridland <dave@cridland.net>
Subject: RE: [lemonade] Notifications for multiple devices per user
In-Reply-To: <6137.1154383678.599309@invsysm1>
Message-ID: <Pine.OSX.4.64.0607311509560.494@pangtzu.panda.com>
References: =?US-ASCII?Q?<22C8A0D5D5E095449AB509FE777B5F800?=
	=?US-ASCII?Q?9DE205@svr-exchange.avocado.emccsoft.com>?=
	<Pine.OSX.4.64.0607310817520.494@pangtzu.panda.com>
	<6137.1154383678.599309@invsysm1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 5.2.0.264296, Antispam-Engine: 2.4.0.264935,
	Antispam-Data: 2006.7.31.145432
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0,
	__CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: Enhancements to Internet email to support diverse service enivronments
	<lemonade@ietf.org>
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service
	enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>,
	<mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org

On Mon, 31 Jul 2006, Dave Cridland wrote:
> http://dave.cridland.net/draft-cridland-imap-trash.txt
> (Which was sufficiently contentious that I've not submitted, but will do if 
> there's demand).

Perhaps it should be, as an individual Informative RFC.

> The first relates to the difficulty in identifying the difference between a 
> message you intend to send (perhaps assembling it on the server with 
> CATENATE) and one that actually has been successfully sent. Whether all the 
> messages in the same category happen to be in a specific mailbox or not is 
> another matter.

I was under the impression that we were talking about a sent-messages 
mailbox, not a drafts or outgoing staging mailbox.  It is, indeed, 
important that the difference between the three (not two!) needs to be 
clearly identified.

If the same mailbox is used for more than one of these purposes (and I 
understand the attraction for doing so), then the means to distinguish 
the state of an individual message needs to be clearly defined; as is the 
means by which this state transitions.  These means need to be 
bulletproof, for some value of "bulletproof".

> The second relates to interoperable configuration between clients, such that 
> different clients automatically reflect the user's stated preferences. This 
> is the problem that was solved by ACAP very well nearly a decade ago, a 
> solution which I happily use every time I send a message.

This is what the OP referred to.  However, solving this issue depends on 
solving the first issue.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade